Name: James Altop
Member since: 2001-10-17 19:40:14

Homepage: jaltop@stmartin.edu

Notes:

I served in the US Navy as a cryptotech, and developed a strong interest in electronics there, later I saw on television the battlebots programm, and was severly disappointed. Their robots seemed to be more along side of an RC car, and poorly designed for combat. Personally I was also disgusted that so much energy was put into these battlebots by schools and institutions, and not more constructive scientific designs such as submergibles for oceanographics, space exploration and search and rescue uses. Not that I am any better, I am a typical male and do enjoy watching things crash into each other and explode, but there should be more to the field than tv ratings. So I have decided to try and make designs that are more useful and fun. I am interested in all aspects of designing and building robots, just recently I taught myself how to do some programming in Basic so that as I progress I will be able to program my own chips. Presently I have not completed any of my designs, which are all quite simple and basic. My designs utilize transitor logic more so than any based upon chip-burning. I am greatly interested in developing systems that provides each fuction to be defined as a "nerve cluster" that then connects to a low- level controller that will determine basic movementbased upon a sensors system to provide environmental input to determine the direction and manner of movment (move forward, uphill towards light). This system would then compose a reflex action that could be over-ridden by a seprate higher level processor (Basic or such) that would determine goal parameters (go to green light, avoid red light) and compare them to the present situation. An example of how this would work would be that the robot is told to go from the Yellow light to the Green light but to avoid the Red light. This information would be dealt with by the high processor. the low processor (really just transitor logic) would sense the lights and initiate movement towards any light and deal with obstacles (tables, chairs, chihuahuas). When the 'bot came close to a Red light the high processor would negate movement in that direction in favor of another light source not red. The bot would resume movement away from the first red light and home on another. The process would repeat until it found the green light. This is very basic and not of much use. But the point is to develope a system that would allow the high processor to function quickly on programmed commands and not be tied up trying to read sensor input and make decisions on basic movement commands.

### Recent blog entries by Jimm

Boy, it has been a long time since i was here. most of my projects have also been put on hold, but i am hoping to get more time to play soon. Work has kept me busy with projects. Among the things i have completed recently are a 8 channel strain gage amplifier, fixing a S-100 Fanuc robot, and teaching electronics and machining to students. Some of the items of interest i am working on now at the college is a distiller (for water only of course), and a rotary air valve for a robotic are we are developing. the swith itself is interesting. It is supposed to allow a 50/50 air flow split between the output to the pneumatic piston and the exhaust. the purpose of this is to simulate the twitching of your arm when you hold something heavy. i considered using a standard electronics air valve, but the response time was to slow. Plus the rotary valve, since it is motor driven, allows near infinite frequency choices for the arms movement. I will post some pictures of the arm and associated set-up once it is completed. But it will be a while, since I have to machine the whole thing out of 6061 aluminum.

Well last weekend i finished up a little project using a few photo-resistors and two four transistors in two darlington pairs. The result was a simple circuit that changed motor direction by light levels. It worked fairly well on a nine volt battery and would avoid the shadows cast by an object and the object itsef, but a problem developed in the power dropped across the power switchimg transitor and the unit would over heat and until the components cooled down only one turning direction would work.

This cicuit was really just a study in designing one "nerve" for the main robot design, but it told me alot about imporvements to do to increase the sensitivity of the cells and response time. I know that there are many other IC units that can be used in place of transistors, but I really like the durability and recovery properties of transitors. IC's are great but they have a great limitation when exsposed to high heat or electromagnetic interferance.

Some of the systems I worked on in the Navy really took this lesson home. The main room all of our equipment needed quite a large AC system. If it ever went out the bays would get hot enough to give you a good burn. After the heat went down, the only equipment to survive without great need for repairs, was the stuff built off of old 1960's and 70's designs. Everything using mostly IC circuitry would be dead or near dying. Course, not that I don't love IC's, I just think we shouldn't depend upon them for all applications, same with transistors and such.

I had another thought today,(I really should be carefull), and that was what if for obstacle detection and sensor input you used three input devices (you pick) then ran the inputs into a comparator circuit. The output of the comparator would then be sent to the CPU or controller device. Statistically this should inhibit the chances of random noises or light from confusing our mechanical friends. Especially if you used three or more inputs and offset the level that the sensors were lined up on. Example use an isocolese (I know that is spelled wrong, but hey it's public education for you!) triangle or hex patern. If you got any thoughts on if this would be a feasible alternative to more exspensive sensors and detection systems... please let me know. jaltop@stmartin.edu

sin jimm

Just a thought: one of the problems i see with reducing the weight of the robots power system is that there needs to be enough electrically energy to power and sustain the unit for x amount of time. this ussually involves one large battery or several small ones. the weight of this adds together and requires the drive motors to need more torque to move the heavier system containing all those batteries. But what if you were to use two rechargable batteries and a solar collector, a few relays and possible a comparator or time to do this: have one battery just large enough to supply the motors with enough energy for movement for x amount of time. the second battery will be charged by the soloar cell for y amount of time. When the first battery is low, a comparator, timer or relay will actuate and switch the system to the second battery which should by now be charged. The same switching then transfers the charging process to the first battery, while the robot continues on with objective. i see a few bugs in this system myself right now, but any thoughts you mighthave....

sin jimm

Jimm certified others as follows:

• Jimm certified robodave as Journeyer
• Jimm certified triple.m as Apprentice
• Jimm certified maryam as Apprentice

Others have certified Jimm as follows:

• maryam certified Jimm as Journeyer
• Ybbet certified Jimm as Journeyer
• Nettron certified Jimm as Apprentice
• winterj certified Jimm as Master

[ Certification disabled because you're not logged in. ]

# Robot of the Day

Solobot X

Built by
Chung Kong (Andy)

# Recent blogs

18 May 2013 Flanneltron (Journeyer)
17 May 2013 mwaibel (Master)
14 May 2013 steve (Master)
13 May 2013 JLaplace (Observer)
10 May 2013 AI4U (Observer)
21 Apr 2013 Pi Robot (Master)
12 Apr 2013 Pontifier (Apprentice)
31 Mar 2013 svo (Master)
16 Mar 2013 gidesa (Journeyer)
12 Mar 2013 ixisuprflyixi (Master)
28 Feb 2013 JamesBruton (Master)
13 Feb 2013 Mubot (Master)
14 Dec 2012 oleglyan (Observer)
11 Dec 2012 Christophe Menant (Master)
19 Nov 2012 currentc (Journeyer)
25 Sep 2012 robotvibes (Master)
31 Jul 2012 evilrobots (Observer)
22 Jun 2012 Keith Rowell (Journeyer)

7 Aug 2009 Titan EOD
13 May 2009 Spacechair
6 Feb 2009 K-bot
9 Jan 2009 3 in 1 Bot
15 Dec 2008 UMEEBOT
10 Nov 2008 Robot
10 Nov 2008 SAMM
24 Oct 2008 Romulus
30 Sep 2008 CD-Bot
26 Sep 2008 Little Johnny