ABOUTARTWORKANIMATIONPHOTOGRAPHYMUSICJEWELRYFORUMLINKS

Robots          See my new robot page          TIN CAN ROBOTS

This section is quite old and I intend to rewrite it soon. I also have two new robots that are in the process of being built that will be added.

 

This section is devoted to one of my favorite interest, personal robotics. I have been building robots for over twenty years. Some have worked better than others and most were more complicated then they had to be. My first robot was constructed from two fourteen inch disk made from half inch plywood. It had a rear axle with two lawnmower wheels. the front wheel was powered and steer able. I used two motors to drive and steer it. This robot has never had a computer attached to it. I used a lead-acid motorcycle battery for power. Originally I used tethered control and later adapted a radio

control system. I used this platform to learn what works and what doesn't. 

It is not necessary to build a robot that weights hundreds of pounds. When I built this my first robot the most popular microprocessors used several voltages and needed a small card cadge full of board to make a usable computer. About the smallest computer was the size of a shoe box and commercial products were in the several thousand dollar range. Today processors like the Basic Stamp can be used and only use a few milliamps. Stamps are not all that powerful, but they are inexpensive, easy to use and the development tools are free.

My favorite processor is the MC68HC11. My most recent robots used a single board computer based on the MC68HC11. There are a lot of nice boards and components available for robot work. I have been using boards made by Axiom. Two in particular are shown below. The advantage to these is that they come assembled and tested.

Some factors to consider when designing a robot are the size of the board that you choose and the cost of the board. Many boards on the market were designed for control development. This means that there are usually additional parts on the board thus more cost and greater size than needed. In a mobile robotic application size and additional parts all add up to a bigger size board that uses more power. Stamps are the ideal controller but if you need to use interrupts forget it. Recently I have begun to discover that a lot of board manufactures building boards that are slightly larger than the CPU and a few glue chips. Connection is made via an IDC connector. Another nice feature is having a low drop out regulator on board like the LM3931. This device can regulate the computer even when power supply voltage is close to the regulated output voltage.

I have begun work on a small form factor CPU board. I have selected the 68HC11E series processor and intend to put 32K of RAM and 32K of EEPROM on board. I also intend to also have an RS232 interface. All connectors are IDC (pin) type and there are no heavy or large parts on the board. All parts except for the IDC connectors are surface mounted. To conserve space I am placing parts on both sides of the board.

 

Axiom

 

bs1cb.gif (6934 bytes)

Basic Stamp I Proto Board

bs1stand.gif (6368 bytes)

Basic Stamp I

 

bs2cb.gif (15214 bytes)

Basic Stamp II Proto Board

 

bs2.gif (8729 bytes)

Basic Stamp II

 

t3.jpg (47577 bytes)

Bot Board 2

 

handybd.jpg (14411 bytes)

The Handy Board

 

If time is not a problem there are controller board kits available. A very nice board is the Bot Board. Bot Board is basically a 68HC11 microcontroller on a board with all the connections brought out. The Bot Board has a memory device, RS-232 mode switches, a piezo speaker and lots more. These boards come with no parts. I gathered up my parts in a week or so and built it in about an hour. This board has an excellent cost to features ratio. However there is no non-volatile storage. This means that unless you keep the RAM alive your program will go way with power loss. For most desk top robotic application this is usually not a problem. The handy board was designed for MIT classroom use. It too is a good choice. It is available assembled and tested. This board also has additional components added to drive motors. It also had an LCD display mounted on the board. Both this board and the Axiom boards support LCD displays.

Another very popular choice is the Basic Stamp. Basic Stamps are really easy to program and use. The Basic Stamp 1 is connected to a PC parallel port for programming while Basic Stamp II is connected to the serial port. Both Stamp 1 and 2 have non-volatile memory. This means that once programmed the power can be removed. When the application is to be run power is applied and the program will run. My applications tend to be a little more memory hogs and Basic Stamps are not big enough. However do not write the Stamps off. They can solve problems that no other processor can. They are low powered while being easy to work with. I have designed several instruments that use the Basic Stamps and have done so cheaper, easier and requiring less power than any other processors. Many robot hobbyist prefer the Basic Stamps because they can be easily interfaced to hobby servo motors.

Where to begin

Like all thing you should begin by deciding what kind of robot that you would like to build. This will be driven by many factors such as cost and materials availability. When I was young I was always working on things that I could not find parts to build. My parents were always taking me to surplus stores so I could get the parts I needed. With the internet it is easier to find most the parts that you need.

I have always been a big fan of George Washington Carver. He was an industrial research scientist that worked for Henry Ford. One of the philosophies that he worked from was, "Doing more with less." I believe that many of the things that can be made can be made from, "Junk box parts." One of the earliest robot kits that I remember seeing was in Popular Electronics. This robot was called, "Sparkey, the robot pup." Sparkey was made inside a porcelain wash tub. Most if not all of his parts were surplus. Many of the robot builders today start out with high class totally new parts. This drives the cost of the project up to where desk top robotic is too expensive. After all a hobby like this is supposed to be fun.

When designing a robot set up a budget. Estimate the cost that you want to spend. When completed add up what the robot did cost. The determine if the cost was correct, above or below.

Keeping a robot journal 

Before you begin developing your robot get a spiral notebook. Use this for writing down all of your ideas. Start out by sketching what you want your robot to look like. List all the features that you would like the robot to have. As an example should your robot follow a line on the floor or just wander around? Does it have two wheels, three wheels, more or none? Paper is cheep and a good way to distill many ideas down to one or two.

When you have decide what sort of robot that you will make look around for the basic parts. I like to start with the computer, batteries, motors, wheels and frame parts. If you are going to use airplane servos then a trip to the local hobby store might be a good first step. Remember that you are looking not buying at this point. The internet can provide you with lots of alternatives. Local shops tend to have higher prices.

Once you have selected your parts you can begin the final design process. You should have a drafting program. There are freeware drawing packages, but there are also inexpensive packages that are very good. My favorite is Quick Cad. A necessity is the ability to draw parts and save the parts in a library. Parts like the motors and your computer will have very specific mounting requirements. The better that you model the part the easier the design and build will go. To model your part you will need either a ruler or a caliper. 

I usually begin from a pencil sketch then do a machine drawing. When cutting plastic or wood I will glue the computer print to the part to be machined. Then I will cutout and drill the piece. Once again you should live with your design for a while before building it. If possible show it to others and get their opinions. Most everyone today knows what a robot is and others may see something that you forgot in your design.

Another good tool is the mockup. You can build the robot up using your parts and sheets of cardboard. This will allow you to make any corrections before you have committed them to a more durable material. Once again you can start by gluing the paper prints to the cardboard. You should keep a photographic record of your progress. With the availability of cheep digital cameras documentation just got really easy.

Once built then what

Now that you have a built your robot you will begin to wonder what to do now. I recently built a micro mouse. A micro mouse consist of two motor driven wheels and a couple of glides to keep it from flipping over. I found a small plex bubble to cover it. Before I added the computer I connected the motors to an RC receiver. I was then able to control the robot platform from a RC controller like airplane or car would be controlled. I learned quite a bit about the platform and drive this way. Most importantly I learned that this thing is more difficult to control than I thought. I also found out that it moves faster that I thought. Unless your are entering a contest where your robot is to do something fast watch the speed.

Next came the computer. For this robot I selected the CMM-11A8 from Axiom. A Basic Stamp could also be used. I did, however, want to do more than navigation.

At this point I would like to talk about software choices. For this project I used the Motorola 68HC11 microprocessor. The two most popular choices for software development are assembler and C. Motorola has a free assembler on their web page. Most to the people that use the 68HC11 post the freeware version on their pages. Another choice is C. There are freeware C compilers also posted on the net. I own the Image Craft C compiler an like it very much. I am in the process of developing a freeware Integrated Development System for both assembler and C code development. I have the assembler IDE working and in the process of connecting up the C compiler. The idea with and IDE is that you enter the system and develop compile / assemble and up load the code in this single tool.

When finished I will post this tool on the web. I have bits and pieces of a new Glyph Development Language built. The GDL allows the programmer to place symbols on a sheet. These symbols (Glyphs) are then connected to each other. Each Glyph represents a piece of computer code. Each Glyph is created using a Glyph Editor and the underlying code is created using a normal text editor. Glyph code is reusable like a drafting symbol. Code then is developed using symbols rather than with words.

Presently I can create the symbols and then place them on a sheet. I have not had the time to develop the code generation part yet. I think for microcomputer applications it makes sense to reuse working code as often as possible. Common functions like reading an A/D converter or setting a bit in a port are no brainier. Knowing this then why should the programmer have to either rewrite code or copy code from old programs? This is a waste of time and could cause errors in the program. My solution is to select the appropriate module from the library and plop it onto the sheet. Only specialized or new code need be written and it also becomes a new symbol.

For now let us consider assembler. Assembler allows the user to access all of the computer's functions. To begin development you will need a controlled and at least one servo motor. Eventually you will need to modify your servo. The included link will take you to a page that contains information on how to convert a servo for robotic use. For initial development, however, an unmodified servo will work fine. Now find a place where you can setup your controller along with a servo and a power source. The goal is to develop a control program that can either position an unmodified servo or can control the speed and direction of a modified servo.

The theory of these small servos is that they require a power source and a pulse width modulation signal. I have discovered that they the rate is not critical. The pulse width, however, controls the position of the servo. To change the position the pulse width is increased or decreased. Even though the 68HC11 is an excellent choice there are better solutions like the 68HC12. The 68HC12 has a PWM function built in. On the 68HC12 each of the timer channels can be programmed for pulse rates, cycle time and other things. I will be discussing the 68HC11 in this section. Controllers using the 68HC11 are much cheaper and make the best price per feature choice. The 68HC11 is presently being used in many schools as a learning tool. They interface easily with all sorts of sensors, and actuators requiring a minimum of interface components.

To control a servo the input pin of the servo must be connected to one of the 68HC11's output capture registers, OCR. An OCR is a special output. This bit can be used as a regular output or programmed to do one of several special functions. Use as a timer pin the output can do nothing, go low, go high, or toggle when the associated timer times out. I like it to do nothing. I use the timer, but do not allow the time to control my pin. As I mentioned there is a associated time register with each OCR. To perform a time function each register is programmed with the time that the function requires. The program reads the present time from a free running clock. The time out time is added to this value. The computed value is then placed in the associated OCR register. When the time matches, an interrupt is generated. Inside the service routine is where I set and clear bits on the output. On time is computed and set. Off time is the difference between the cycle time and on time. The service routine is smart enough to know when to turn the bit on and off.

As an experiment you could add a variable resistor to one of the 68HC11's A/D channels. As the value of the variable resistor changes so will the position of the servo. The A/D channels can be useful for other things like the interface to sensors and to monitor system power. A few years ago I purchased a robot line follower. This robot has no computer yet it can follow a black line. When I put it together I brought it to work. My coworkers just loved it. They stretched black electrical tape all over the floor. Even though this type of robot is dumb it performs a very basic control function. Most robot builders start with something like this.

To make a line tracker you will need several photo transistors and several matching light emitters. You can buy a line tracker board already mad and attached it to you robot or make one yourself. The way that the line tracker works is as follows. The tracker optics are kept low to aid in picking up the light and dark variations and to keep the ambient light from interfering with the signal. As a censor sees light the photo transistor turns on producing a low output signal. When the sensor sees dark the sensor produces a high output signal. Logically it is easy for the robot to steer left or right to compensate for the variations. Some of the better sensors have many sensors to allow better control. Most sensors have either two or three photo detectors.

A variation on the optical sensor is the, "Wire following," system. Several years ago I worked on such a system commercially. This system is a bit more complex, but is extremely accurate. In most cases two pickup sensors are used. Commonly two sensors are mounted vertically, sided by side. The two signals are detected and measured for amplitude. Differences represent the position to the wire. A better system uses a horizontal sensor as a reference. The sensor is at right angles to the wire. A second sensor is vertical in the middle of the first sensor. As the vertical sensor moves back and forth over the wire the phase relationship to the signal changes, as does the signal output level. The two signals are summed. The sum is the error. This system has been described in many electronic magazines for decades. Many of the robot books that have been published have described this.

A robot using a black line or a wire to control it is basically a, "Trackless train." Guided robots have been used in factories for years. They are used as part carriers and go from station to station delivering parts. More recently some hospitals have adopted this system to deliver food and drugs.

When you have reached this level you will need a place to experiment with your robot. Most robot experts do not place great emphasis on where to run your robot. Many discuss being able to use them on carpeting. I assume that the robot is intended to be used on the floor. I have several problems with this. First the floor is dirty. Unless you just washed and waxed the floor there are particles of dirt, lint and hair down there. This dirt can really do a number on servo and sensors. Carpet is a real mess. The fibers can get into everything. I have hard wood floors and can do some of the things that I want to do, but am still limited. I really do not want to run black tape around the house. I really do not want to slot the floor for an antenna.

If you have built a Micro Mouse then consider desk top robotics. I have a solution that will work. Get a piece of 4' by 8' plywood. Cover the surface with something like pressurized laminate. Attach an inverted skirt of 1 by 2 on the top to keep your robot from falling off. This can be leaned up agents a wall to hide it when not in use. In a basement it can be hung by chains or put on top of a few two drawer file cabinets. The idea is that you have a clean, smooth work space. If space is a problem than make a 4' by 4' top. I like the pressure laminate tops. There are easy to keep clean and look good for years. You can also use a kitchen table, but most tables do not have an inverted skirt to keep your robot from falling off. I understand that space is usually a problem. The colonials also realized that space was a problem. They made trestle tables that came apart to be put away when not in use. A more contemporary example is the card table. When not in use it can be knocked down and pushed into a closet.

You should be able to have your working area near your computer. This hobby will not be any fun if you are constantly running up stairs to rewrite some code and to do a little downloading. If you can not move your computer and can not have your work area in the same place, then several options are available. One option is to get a notebook computer. The software for 68HC11 code development does not require a complex super computer. To use the assembler you do not even need Windows. The basic tools that you will need are the assembler program, a communications program and a text editor. The computer must have a spare serial port to communicate with the robot. Another option is to get a second computer. Once again you do not need a powerful computer. Network cards are getting cheep and more available. You can network your better computer to your development system. You could do most of your development on your better computer and use the second computer for loading and debugging at your Desktop Robotic Workstation.

If you are developing arm type robotics then you might have your robot next to your regular computer. The type of robots that you are developing is dependant on the type of work station needs that you will have. Many people build larger robots that have to be used outside. Once again if you are going out in the field get a notebook computer.

Thing to do with a robot

There are many things that can be done with your robot. Earlier I mentioned line following. This is a control scheme not an application. I have written a program in Delphi that simulates the interaction of three objects on a limited surface similar to three robots on a table top with an wall around it. The program is called bounce. Bounce is used to study the effects of collision avoidance. Presently I sense a rectangular space around the individual balls. When too close the direction of the balls is changed. A robot with a bumper skirt or other such sensors can be placed on the desk top and observed. Later other objects can be added. I like mazes. Maze pieces can be made and attached to the desk top. Many Universities have contest to see whose Micro Mouse can navigate through an obstacle course faster than others.

 

I like experiments that deal with light and color. I have a sensor design that sees color. The sensor has four photo transistors. One sensor sees light they way it normally looks. The other three have colored filters to separate out each color. Using the 68HC11's built in A/D concerted the robot can see different colors. Colored cards can be attached to the walls or objects. When the color is identified the robot can be programmed to respond.

Another sensor experiment that is quite popular is the Light Sensor. A robot can be programmed to see light changes. The robot may do one of several thing. First it may not like light. When a bright light is shined onto the robot's sensor the robot may turn and try to move to a place where the light is less intense. The opposite can also be programmed into the robot. It can be programmed to follow the brightest light source. A little more difficult but also popular is the sound activated robot. Speech recognition is still a bit off but it can be made to understand certain frequencies or patterns.

Desktop Virtual Robotics (DVR)

Desktop Virtual Robotics is software that allows robots to be designed programmed and tested on a PC. Imagine if you will being able to layout test tracks and testing your latest robot without actually having a robot or the test track. It is getting easier to create 3D models on the PC. I presently have a Virtual Robot Crane posted on another page. For more information on this program see my AI Experiments page. The idea behind DVR is to have an unlimited supply of motors and parts to create a robot. Many hobbyist get frustrated when making small robots. Parts need to be gathered and machined. The cost is so high today that having multiple robots is usually not an option. Using DVR you will be able to design different kinds of robots and test your design. The crane was my first stab at this. I am working on a motor and gearbox simulator next. This will allow the designer to place a simulated motor into a simulated gearbox. I want to have speed and position control. Next will come the virtual platform simulator. An advantage to my DVR over a real robot is that all functions can be controlled from the console. My hardware robot can only be monitored through a cable or a radio link. Also batteries are included and can run forever. If my gear box works correctly gears of any size and pitch can be selected.

I would also like to design a Virtual Controller for the robots. In real life controllers usually do not do what the designer wants. I want to add Ideal I/Os A/Ds, D/As and other devices. If all this works it would be really cool to have the designs printed out. This could include schematics and mechanical drawings.

The motor and drive train simulator is used to develop gear boxes. The first cut will allow you to pick how many gears are used and the number of teeth on the gear. Stacking is done to reduce speed and increase torque. A motor is then added and it too has a gear. Output is through a wheel. The diameter of the wheel is then input so that ground speed can be calculated. The initial simulations will be crude but I expect to improve them later.

The platform simulator is used to do a little bit of frame design. I will be using rendered images of stock parts for the simulation. Parts like wheels, motors and the gear box should be easy to design.

I am presently working on a track with a stock robot mouse. When I get this working I will post it. It is written in Delphi 5. I have used as many simple parts as I can to keep the program small and easy to use. The program has a tool bar to place each component. Components include the robot mouse and all the maze part as well as the goal. I hope to be able to add mice when needed. Presently I am working on getting the mouse to move around a virtual track and to sense objects placed on it. I am trying to devise a method of watching the V-robot's memory to see the logical processes as they occur. I would like to add an Ego logic to induce certain responses. The Ego is the, "I want," portion of behavior. Ego drives action and it would be interesting to try to model these. A few years ago I read a robot book that described the hunger response. It would also be nice to model cold, light, sleep and other things that drive living things.

Being able to build Virtual Robots have many advantages over physical robots. First there are no parts to gather or things to fabricate. Parts are in unlimited supply at no additional cost. Depending on how complex the simulation is a V-robot can be made to do anything that the programmer can think of. If space is a problem that a V-robot is an excellent choice since its entire world is inside the computer. Using a modular approach to design means that sections can be replace as easily as a few mouse clicks.

Since the robot is Virtual this means that it is not necessary to think in practical mechanical terms. The laws of physics need not apply here. An ant sized robot could easily move mountains if that is the programmers choice. However if accuracy is needed that accurate models can be designed. I once saw a since program on television that featured a scientist that build a mechanical mouse maze system. He opened it up to reviled an X-Y drive with a electromagnet to pull the mouse which was a ball bearing. All the walls were metal and the floor was squares of metal. When the ball hit a wall the computer knew where the mouse (ball) was. I remember how neat that was and that the scientist mentioned that it took years to build. Today with modern programming languages the same thing can be done in hours.

Beyond building a robot.

Even though building a robot is really fun for most, there are many that do not have the mechanical skills, tools or other things that are needed to build a working robot. This does not mean that they can not enjoy robotic. First you can have someone else build the robot for you. Most people know other people that have the tools and mechanical skills that can be used to help you. Another choice is to buy a kit. By searching the web you will find lots of resources there. Also consider building the virtual robots that I have mentioned. The greatest advantages to a virtual robot are that it requires no shop or tools, anyone that can write in Basic or other such language can make a virtual robot and virtual robots can be built modified and rebuilt with not parts needed. I have begun to write simulations again and am in the process of developing several tools to aid in this process. In the DOS days I had written much code that allowed me to do simple things. When windows came along I decided that it was too difficult to do what I wanted to do. Recently I have rediscovered that Windows can be used to develop good simulation tools.

 

Lets build a simulator.

I will begin by designing a simulation of something easy for a first demo. A few years ago while sitting in one of my psychology classes I had the little light go on. I was being taught about some of the basic emotions that all living things have. One of the most basic of these emotions is the Ego. The Ego is the little voice that says, "I want." That was it. I wondered if a robot could be programmed to act as a baby with the, "I want," function in full force.

 

In a real living thing these needs include wanting food and water, physical contact, and other things. I recently had the experience of being given a new puppy. This is a real living baby of sorts. I wondered what she would act like. She wanted to be fed and watered. She needed to be held. She also needed a great deal of physical contact. Huh! Thinking about this gave me an idea, can these type of needs be modeled into a program? If a physical robot were used the basic hunger is there in the form of needing recharged. I have seen robots that explore their environments in a similar way that a dog looks around its yard or house. My dog also needs to be touched and held. This I do not remember seeing. However since this is a work in progress I will possibly revisit this area later.

 

Feed Me!

All organisms require that they are feed in some way. Robots are no different in this way. They need to be feed with energy. In a living thing if food and water is not available a hunger since is triggered and little by little the need to eat and drink becomes an obsession. In most cases this obsession is gradual and builds. If as an example a child is playing the need to eat at a specific interval is not great enough to trigger looking for or asking for food. If food is made available then the child will stop and eat. Is not available and the hunger level is low then the child will continue to play. As the hunger level increases then the child may change his or her play to include looking for food. As this level increase the child will ask for food. At the highest levels of hunger the child will be very active in letting everyone know their needs.

Hungry is an emotion that everybody feels. It can be represented by a value that ranges from, "Not hungry," to "Extremely hungry." In a living thing we know that if food is withheld it will get week and eventually not be able to function. This type behavior can be easily modeled into the virtual robot. First we can create a value that represents the hunger level of the robot. Initially we can set this level to a level called, "Full." This would start our robot off fully charged. As the robot performs task like exploring its environment this level would slowly drop.

At this point it is easy to say let us just set a trip point where the robot would look for food when this point is reached. This is too simplistic and defeats the purpose of modeling. In a real live organism there are factor like, do you know where the food is, how interesting is the present task and can eating wait? There is also a discomfort factor. Part of the Ego process is the discomfort. Most people set specific times and choose specific places in which to eat. We know that when we eat we can only eat a certain amount of food at a single meal. We also know that there is an interval between meals. Thus we eat to a certain level and know that the next meal is going to occur at a pre-specified interval. However we were not born this way. We either learned these rules from others or by experimentation. Some people never learn.

The next variable in our robot simulator is now the discomfort level. Discomfort levels will be set to trigger an alertness process to perform a self examination of all the senses such as hunger. Discomfort can be set to a specific level. The things that feed the discomfort levels can be ranged to feed the proper levels to discomfort. Some things like hunger might have a higher multiplication factor than darkness or noise would.

Now we can not create hunger without providing food. We also must have a way of depleting the food that is gathered. The idea is to gather enough to operate and not too much as to cause discomfort. The hunger variable can be monitored and combined with other variables in ways that mimic living creature behavior. As an example a robot can be programmed to search and log interesting thing in its' environment. A low level hunger signal might tell the robot to seek food. This is not to terrible interesting since the robot only has to reach a certain level to break off what it was doing. Now consider adding an Interest variable. If the robot had ground something and is in the middle of investigating this thing than it has some interest in the thing. When hunger hits it is safe to say that the robot does not need to seek food right now. Several values such as knowing how far food is and making an estimate as to how much energy (the opposite to hunger) is needed. If the robot is interested in something this too can delay seeking out food. In real life things delay us from immediately seeking out food. Perhaps your robot eats on a fixed schedule. If the robot is hungry and it is not time to eat it can be made to wait. If, however, the robot is very hungry the hunger can be made to override all other input and quickly seek food.

Beside hunger there should be a Well Being setting. Well being means that everything is working. In our robot we could provide a built in diagnostic circuit. If the robot applies a signal to go a certain speed and the robot moves at a speed that is faster or slower than expected than exceeding this limit would trigger a Sickness threshold. If the problem is serious than it would go to its' home or other such designated area and report the problem. Simple problems could be just noted and monitored for reporting at a later time.

Mileage records are also important. Just as when using a car it is important to note how far the robot can go and what it can do and for how long. If a robot suddenly has too much loss in the system it can be given a checkup to find out what is wrong. The motor could be going bad or the drive might have picked a bit of dirt.

Master control.

As is the case of all robots the designer intends that they are completely controlled by their internal computers. However this does not mean that you need to be cut off completely. I think that it is important to periodically monitor the progress of what the robot is doing and how it solves problems. My idea is to have the robot have multiple levels of memory. Things like the efficiency records should be downloaded to another computer for storage and analysis. This can be done when the robot is eating (recharging). This can also be useful since most controllers have only a finite amount of memory. If the robot has camera's or other sensors this sensory data will need to be gathered stored and examined. After all you do not know if the robot is working properly if you never see this data. You could also upload new instructions of new programs to the robot at the same time.

 

How do we begin?

I think that one of the simplest things that a robot can be programmed to do is to search and map out the environment. A simple robot with a bump sensor and a distance counter can do a pretty good job of this. As mentioned earlier one of the memory levels can hold an environmental matrix. When an object is encountered that contact can be recorded into this matrix. When the robot revisits this area again and finds no object this could be logged in as an interesting thing that could be investigated or reported later. If this was a security robot the change could indicate that someone was here and moved or took something. This could signal an alert condition that things have changes and where. A maintenance robot might note a flickering or dark condition and report that maintenance should replace a light bulb.

"If a thing can be thought of, it can be simulated." David I. Day 2000

   

Drop me a line at:   dday100@yahoo.com