One of my favorite hobbies is to mess around with electronic stuff. Another one is to program computers. From these two interests my newest 'project' has been born: make your very own autonomous robot. Too ambitious? We'll see about that...
Of course, my initial requirements to the robot were quite high. My imagination was working on overtime when I first cooked up the idea of a small robot. But now that the ideas have settled a little, here's what I have come up with (so far):
The robot itself will be based upon an old 8086 XT computer I still had lying around. Using a PC as the central 'heart' of the robot gives you a lot of flexibility in setting up the robot's responses to it's environment. Also, the behavior of the robot can easily be changed (put a new kernel on a floppy, and let it reboot again).
So the main board must be totally integrated in the thing. And to allow for easy 'plug and
play' capabilities, all external devices (such as sensors and motors) should be accessed via
the serial and parallel ports. So: take the robot's 'brain', plug in some wheels and some eyes,
and off the thing goes...
The design of the robot is thus split into two parts; the 'internal' (software) part, and the
'external' (hardware) part. Each part will be split up more in separate identifiable components
(ever heard of Object Oriented Programming? Turns out that it can also be applied to hardware
design, daytime activity planning, etc.!).
O.K., here's how the hardware part of the robot is going be:
The serial ports are not going to be used. They are too complex to work with (on the hardware
side), and why should I? There are two parallel ports as well. I planned to assign one to the
input, and one to the output of data. There are 8 channels (bits) in each port, so I can either
choose to split these channels over the actors and sensors, but then I would probably soon run
out of channels. Therefore, there has to be a (primitive) address selector right after each
port. This selector can then be used to route the signals (8 bit) coming from or going to the
port to all the devices the robot will use.
But then there is a problem with the actors. When the port's information is going to be
re-routed to another actor (via the selector), the input of the last selected actor will
disappear. Therefore, each actor should have a memory buffer just large enough to hold a single
command (the last command).
And for the software part:
Well, the robot will have to have a 'central processing unit'; a 'brain'. Otherwise, it will
not (be able to) function. Apart from that, it has to learn from it's surroundings. Therefore,
it needs to get a memory. And of course it should know about the various actors and sensors
attached to it.
But then the problem gets quite complex. At this point you have to define how a robot can be
able to learn; how it must use it's memory. Therefore you have to define what a 'memory' (item)
is.
In case of building a map of it's surroundings, it has to store away only situations. Every new situation it encounters, should be considered as a map addition. It would be unwise to store every single situation sketch you encounter, since there will be a lot of double information in them, and your memory capacity is limited. Therefore it is best to summarize all this kind of information into general environment information, eliminating double information. Each object in the surroundings thus has to be cataloged only once. The problem of building a map is thus a problem of how to represent objects in the robot's surroundings. I think this can best be done using polynome or vector representations of every object the robot encounters (coupled to their position). The explored part of the floor will thus be stored away as one single polynome or vector representation, adding new points as they are discovered.
When the robot needs to remember an action it has taken, the memory item thus needs to contains an action, but it should also contains a situation. Thus the robot can remember what action it took in what kind of situation. When a taken action has to be remembered, I think it is best to also use a sort of 'short term memory', in which taken actions (with the situation that triggered them) are preserved, until they can be evaluated considering their result. In other words: take some action, remember what action you decided to take under what circumstances, and when the result of your action can be evaluated, you can store the result as a memory item.
But how can you (it) evaluate whether a past action has proven to be succesful? First of all,
you have to sketch the current situation you're in. Therefore, the 'raw' sensory input must
first be translated in a 'situation sketch'. This (more general) situation can then be
evaluated as being good or bad. And once this is done, you have a potential memory: an initial
situation (valued for it's 'rightness'?), coupled to a taken action, and the resulting state
the robot will be in (happy or miserable).
The unit that will decide what action to take is more complex, however. First of all, the
current situation should be sketched, so a situation sketcher also comes in handy. Besides
this, the robot will have to decide how to act upon this situation; it must determine what the
best desired action should be (= where to go, what to manipulate, ...). This desired action
then has to be translated to different motor outputs, arm movements, etc. It should also,
together with the current situation, be translated into a potential memory element, and stored
in the temporary memory for later evaluation.
The decision on what new action should be taken, is not that simple. First of all, it should use it's previous experience. It therefore first has to query it's memory for similar situations it encountered in the past, and thus look at what possible actions can be taken (and what kind of effect they had, good or bad). Here's where the robot's 'primitives' (it's character, if you want) come in play. You should think about more general characteristics as 'being curious', 'avoiding pain', etc. From these it must be able to come up with the best desired action. If it cannot remember any like situation, it should show some new initiative of course. Also at this point the primitives can come in handy, although it will probably be easier (and more learn worthy) to let it take some random action.
The memory of the robot should work in an associative way. Since it has to come up with past experience given the current situation, other memories partially dealing with this situation will also be quite useful. The temporary memory has to be given another layout. This memory is only going to be used as a temporary situation/action storage, from which the elements have to be retrieved only when the taken action is completed. Both memory units also have to deal with the memory elements in a different way. The permanent memory has to take up any experience proven worthwhile to preserve, and when it gets full, it is best to throw away the memories that haven't proven to be useful ('access hit counters'). The temporary memory just has to store everything it is given, and it should throw away any situation/action couple that is not going to be evaluateable (since the robot will continuously take new actions, it is quite probable that some taken action paths are going to be left).
Thus we come up with the following definitions:
Object: a polynome (when representing the world only in 2D) or vector image (when in 3D)
representation of an object in the outside world, coupled to it's location;
Memory item: a situation, and in case of an 'action memory' coupled with an action, and the
total being valued to it's outcome;
Situation (sketch): an abstract description of a certain situation, in terms of objects with
positions, 'emotions' (being hungry, e.g.), etc.;
Action: a general description of movement or manipulation (thus in terms of objects), as e.g.
'turn 90 degrees and go forward 10 meters', 'pick up the object at -50 degrees and 1.5 meters
away', etc.;
Memory: an associative database of memory items;
Temporary memory: a queue of memory items waiting to be evaluated and to be taken up in the
permanent memory.
Note that with this description, a situation sketch turns out to be a summation of different
sensory inputs, all being transformed into partial situation sketches. Therefore I think it
will be possible to let every sensor have it's own 'partial situation sketcher', whose outcomes
can easily be summated to give the total situation sketch. This would make a 'plug and play'
robot quite easy in construction. A partial situation sketch would thus be (as an example; I
haven't yet though this over in detail):
| Sensor: | Possible partial sketch: |
|---|---|
| Location | the coordinates |
| Feeler | coordinate of a point in an object (not the object itself), relative to robot's position |
| Eye (IR, light?) | coordinates of objects, plus object themselves (for as far as sensory input goes), relative to robot's position |
| Pain 'switch' | pain sensation at coordinate in robot |
| Battery-low | 'hungry' feeling |
Progress is quite slow at the moment, but then this is quite a complex project. In other words: the hardware has not progressed beyond the 'design' stage, and the software part is not much further.
The real difficulty with designing the hardware is to link the separate components together. I know there are special design programs to do this for you (programs that calculate the outcome of a circuit), but these are quite costly. Does anybody know where to get a freeware one? Send info to: [email protected]; I am really going to need these kinds of programs (I only followed some introductory electronics course...).
The software is stuck on the method of making a situation sketch, and giving a general order (action). How can you transform very diverse sensory input into an abstract and general situation sketch? As for the action: it is designed to be abstract, so that it can later be translated into more specific motor commands (in the 'action center'; the place where is known what types of actors are attached to the robot). Anyway, the software is also far from finished.
Elsewhere on the net, other people are also busy designing and making their own robots. If your
hunger for robotics is still not satisfied, take a look at the following sites:
Robot Information Central.
A site cramped with information about robotics. It also contains a list of a lot of (amateur)
robots being build. Some of them have links to the maker's site, so that more detailed
information can be found there.
CircuitMaker Mixed-mode Simulation Information.
Circuit maker is a very useful electronic design (and simulation!) program. I have tested it
only quite shallowly so far (since I do not have Windows back on my own PC at home), but the
things seems quite promising.
FAQ for computer extensions.
Another quite promising software package for circuit design & simulation. This one is
SPICE-oriented (the text uses the same syntax).
Directory of /pub/cookbook.
A very useful archive of cookbook electronic circuits. If you are designing one yourself, first
take a look down there. Maybe someone else already found the solution for you.
FAQ for computer extensions.
Alt.comp.hardware.homebuilt (who's FAQ this is) is a newsgroup dealing with homebuilt hardware
extensions for computers. Ideal in my case, but bear in mind that it only deals with HOMEBUILT
hardware (no questions like 'how do I fix my harddisk?').
Galileo Informatica - A File Library Listing.
A lot of electronic simulation programs. Some of hem are actually quite good, although you have
to buy most of them.
Also take a look at my index page; there are a lot of possibly useful things in there (ranging from songtexts, links to other stuff to home-brew freeware).
If you find the time to press on a button, please give me some feedback on this page. You can express your likings for this page via the buttons below. Note that the message is transmitted via e-mail, so your browser is probably going to protest about 'insecure data posting'. Ignore this.