Encoder Front Page
SRS Home | Front Page | Monthly Issue | Index
Google
Search WWW Search seattlerobotics.org

DocBot

Gary Livick, glivick@pacbell.net

image_1.jpg (35943 bytes)

This article will eventually be about my latest project called "DocBot." But in thinking about how to put what DocBot is down on paper, I found myself drawn off to what may be a better story for many who will read this. It's a good place to start.

I discovered the Encoder via an Internet search one Sunday afternoon while trying to figure out how to get PC-Bug to work on a Motorola MC68HC11E1-based single board computer. The information was there, and before long an LED that I had connected to an output port was seen to blink. After hours of work, this simple effect made it a wonderful day. Most other robot designers, professional or just hobbyists, started out as simply. That this is true can be reassuring to those who hesitantly ask on our list server, "How can I get an LED to light on pin six of port A?" The most senior roboticist has been there.

Aside from LED's and how to make them light up without 1. frying the LED or 2. blowing an output port, there are more things to learn. Really, an amazing array of things is there for discovery. DocBot, as we'll see later, is a very simple little guy. The elegance of it, be there any, is in the simplicity. The KISS rule (keep it simple, stupid) reinvented. Relearn, reinvent, that is what hobby roboticists do. And it is incredible the kinds of things that we learn so we can do our robots. It is just as incredible who does it.

DocBot gets his name by virtue of who owns s/n 001. I have a friend who loves robotics, and is quite skilled in electronics and programming. But without the facilities to build his own base, he was working with Lego's. His robots tended not to stay together, and generally suffered mechanically. So I built him a small base in my shop. He happens to be a physician, so I called his robot DocBot.

Now, what is a doctor doing playing with robots? The technology would seem outside the range of a physician. Wrong. The hobby is actually filled with participants with lots of different backgrounds. Some are high school kids, some are college students, some are PhD's, some are housewives, some are engineers, and some are truck drivers. Some are surgeons. Some are 15, and at least one I know is 75.

Well, if we were talking about golf, this wouldn't be remarkable. But this is robotics, technically complex in the extreme. And the hobby is, in almost every case, self-taught. The range of subjects that become understood as the roboticist seeks to add to his skills set this hobby apart from any other I know. I don't think very many who start out building robots at the kitchen table are aware of the depth of understanding they will eventually acquire.

Even if the hobby starts off with a kit, it isn't long before the practitioner is learning about topics in engineering mechanics such as torque, acceleration, Ackerman steering and centers of gravity. Then into electronics, Ohms law is discovered, as it is found that the latest LED is drawing too much current and crashing the processor. Why some wires can be 26 gauge and others must be 20 gauge suddenly is clear. Pulse Width Modulation becomes something you discuss with your other roboticist friends. Stepper motors are interesting. Computer architecture is learned as you find out what an ALU is, what an offset register is, what a reset vector is, how to use interrupts and output-compare ports. Servo motors are no longer a mystery. Near infrared and far infrared phenomena are not only understood, but used. Sonar is not only for bats and submarines.

Practically from the first day, computer programming is learned and used. Programming in assembly language, C, C++, Basic, and Forth is studied at the kitchen table as the parakeet looks on. Proficiencies are established in the chosen languages that far exceed the capabilities of most graduate engineers.

Control theory is studied. Open and closed loop, P, PI and PID algorithms are developed and modified for control of systems aboard LUCY, the family robot.

Fundamentals of trigonometry are used to triangulate position from fixed terrain features or calculate position from odometry. Taylor Series expansions are programmed to calculate non-library functions.

Other interesting things happen early in your roboting experiences. To your surprise, you discover that Radio Shack is not a very good place to shop for robot stuff. You find out about Mouser and DigiKey. Your bookshelf becomes a conversation piece for your family and friends when you aren't around. You find out that you cannot discuss "artificial programming" with non-roboticists. You understand "Pathfinder."

As time goes by, you find that your knowledge base has increased dramatically. You are conversant on the processor you were weaned on, and can quote from memory its clock speed, its type and quantity of memory, the systems which run in the background, its port diversity, and just which internet sites have the best support. You can also argue at length why your processor is better than all the others around, none of which you have ever used.

You become very well versed on the types of sensors available for small robots. You have already settled in on the type of bump sensor you prefer, you know all about pyro sensors, near infrared sensors, IR object detection and IR ranging, SONAR, how and why to use optoisolators, were electronic compasses will work, why GPS is not the answer, voice recognition systems, rate gyros and why they are not the answer, low voltage sensing networks, current sensors and wheel encoders.

You also know how to establish communication between your robot and the outside world. You can do LED's, LCD's, piezo buzzers, spoken word systems and RF links. RS-232 is second nature.

You deliberately drive bipolar transistors into saturation. You not only know what MOSFET means, you have a favorite.

You are becoming able to implement both active and reactive programming architecture. You prefer interrupts to polling, parallel processing to one big loop.

The point to all this is; if you are new at this, don't be intimidated by it, and don't give up because you fail at your first efforts. Study, ponder, research, experiment, and communicate with others. Learn. Whatever problem you are working on, beat on it until it gives up. That hard-earned first step by your robot is just the threshold of a huge, rewarding experience.

Now, on to DocBot.

THE GOAL:

DocBot is small. I have a much bigger, very impressive-looking (to me anyway) robot named Max. See him in the gallery at http://www.acroname.com. He can do all kinds of things, and he would be able to do what DocBot is made for if I took the time to program him. But the problem with Max is that he is just too big for the way I do things. I work on robots either in my office after work, or at home, and I need to cart the robot around with me. Max weighs about 30 pounds, and takes up a lot of space in the car. He isn't easy to transport. What I want to do with DocBot can be easily translated to Max later when the methods are perfected. So, I'm working with DocBot.

What DocBot is going to do is navigate. Max, my big robot, explores in his current configuration, but has no idea where he is at any given time, and does not navigate per se. DocBot will know not only where he is, but also where he's going. Sounds so easy.

THE HARDWARE:

 

Docbot is 8" wide by about the same long, semi-triangular in shape. He uses differential steering, and has an idler caster in the front. The drive wheels are 4" diameter aluminum, and the drive surfaces are knurled for traction. The platform is 1/4" thick aluminum plate, ideal for tapping holes into.

The motors are DC geared head motors I got from Acroname at http://www.acroname.com . They have a lot of torque, but run rather slowly when powered from a 12 volt source. The large diameter wheels help recover some speed. I chose these motors not so much for their suitability, but because they are what I know. They are available, and the price was right. As amateur roboticists, many of our design choices are made on such rationalizations. Works for me.

The power supply for DocBot is a 2.2 ah, 12V sealed lead acid battery. Batteries like this you can get from McMaster-Carr, the Sears Roebuck of the manufacturing industry. I chose this particular battery because it was the only one that would fit underslung from DocBot, sort of like a torpedo. It doesn't take up valuable component mounting real estate down there, but it makes the ground clearance so negligible that it won't run on anything thicker than indoor-outdoor carpeting.

I use a .5 amp plug-in charger to charge the battery. Somebody told me that's too much current. I'll have to study up on that.

Even though DocBot is just a development platform for Max, I couldn't help but put some extra effort into making it look sharp. I spent at least three hours polishing the aluminum from which it is made to a high luster, took some pains to locate things on it in a pleasing way, and made it look indestructible. Not much bigger than a tea saucer, it weighs 7 pounds.

THE SENSORS:

Since DocBot is going to be out on his own, one could think of a whole array of sensors that should be on board for his protection. Bumpers at the least, IR obstacle detection, maybe even sonar. But in experimenting with a new class of sensor, I have found that an IR ranging module can replace all three of those things. The only sensors aboard DocBot are shaft encoders and an IR ranging module.

image_6.jpg (86580 bytes)

IR Ranging Module

The shaft encoders are QRB 1114 emitter/detector pairs from Quality Industries. The are discussed in the Handy Board literature at http://el.www.media.mit.edu/groups/el/projects/handy-board/index.html. They look and work well, and are easy to interface. I use stripes on the inside surfaces of the drive wheels for the encoders to pick up. The are photocopied onto paper-thin clear plastic with one sticky side, and attached to the wheels.

The IR ranging module is the Sharp GP2D12. These little guys are just a little over $10, run off 5 volts, and provide an analog voltage indication of range. I've found them to operate well from about 4.5" out to about 30", and even though they provide an inverted, non-linear signal that must be dealt with in software, they couldn't be nicer to work with. A big advantage of these sensors is that they have a very narrow detection zone, reportedly 4 or so. This pencil beam is ideal in both map building and obstacle detection. Using a servo to pan the sensor back and forth, taking readings at known relative azimuth, tells the robot just what is out there, where it is, and how far away it is. Since the beam is so narrow, however, it is possible to run right into obstacles that are below its beam or above it in the decapitation zone. To solve this problem, the sensor is mounted on a tilt servo, which is then mounted to the pan servo. Lookdown, shoot down. Cool. And, no bumpers. I hate bumpers.

THE COMPUTER:

image_16.jpg (85526 bytes)

I use a microcontroller board based on the Motorola MC68HC11A1FN. There are lots of choices for this type of controller board around, including the Rug Warrior board, the Handy Board, the BotBoard II, and a host of others. I have a Handy Board and a Rug Warrior board, and know all about them. Although I don't have one, I've reviewed the BotBoard II schematics and it seems like a fine platform, but without all the bells and whistles that come on the other two I mentioned. But instead of one of these, I settled on a tiny board from Ray's Robotic Racers called a Super T-Comp. See http://www.teleport.com/~raybutts/. This is the smallest expanded HC11 package that I know of. I’ll bet there are larger postage stamps. It is a basic system with 32k of battery backed RAM, low voltage reset, and voltage regulation. It also has an L293D motor driver chip and RS232 communications on board. All the signals are nicely brought out to header pins. I added an LCD so the board can talk to me when it has info I want.

THE SOFTWARE:

I program in Interactive C (also called IC), or assembly. I have an ANSI C compiler from ImageCraft, but with all the support and libraries available for the HC11 that are written in IC, it is very convenient to use for a project like this. An added feature is that IC is multitasking.

Interactive C is not really very fast for reasons beyond the scope of this article, but it works for just about everything anyway. When speed is an overriding concern, assembly programs can be embedded in the file system of IC, and called at will.

THE TASK:

The goal of this robot is to go from point A to point B by use of its two sets of sensors. It must get there as precisely as possible, or at the very least successfully, without getting lost. It will plan and execute the shortest route. Encountering unexpected obstacles, it will remember them so as to plan around them the next time through. With each new encounter, the robot will replan the route, and go around the obstacle. Once having reached point B, the robot will turn around and go back to point A.

Points A and B are 40 feet apart, and the path passes through three cluttered offices and two doorways.

DISCUSSION:

There are a lot of systems and techniques involved in this project. To quote a reliable source, the implementation of the stated task is "not trivial." However, it has been done before. But not by me, and not by this robot. As stated above somewhere, discovering what has been done before, learning it, reinventing it, and applying it to your own work is what hobby robotics is all about. Only on rare occasion will you be required to extend the art.

Given the task, and the hardware described, there are a number of obvious software systems to develop. These are tools that the robot will use, along with its hardware and sensors, to execute the assigned task.

Control system: Robot control programming comes in two forms, active and reactive. Reactive control programming is seen quite commonly in hobby robotics. This is the type of software used when a robot has no clear task (assuming that "wander" is not considered a task). It is discussed prominently and used extensively in the book, "Mobile Robots, From

Inspiration to Implementation," by Joseph Jones, et al. An efficient form of program organization is used in reactive control called "subsumption architecture." In this fascinating system, levels of activities are supported in a (pseudo) parallel-processing environment where tasks are executed in accordance of their priority. The idea of a programmable cat gives an easy parallel. The feline activity with the least priority is sleeping. Absent any other drive, the cat naps. If the cat gets hungry, its Programmer has provided it with a higher priority behavior called eat. To eat, however, a behavior with even higher priority is first called into play: hunt. Once completed satisfactorily, this activity terminates and the furry robot drops back to the eat behavior, and loops until the activity is satisfactorily terminated. Then the cat settles back into its lowest level activity -- sleep.

Robots with sonar, bumpers, sound sensors, IR sensors and the like are often programmed to go straight ahead (wander) until either sensing or contacting objects, and then reacting to the sensor input with a higher level of activity appropriate for the sensor providing the signal. These activities are stratified, with bump sensors usually having the highest priority. A bumper strike will subsume all other activities while the robot extricates itself from this most compelling difficulty. Absent any input, the purely reactive robot will continue in a straight line forever until the batteries give out.

Active control is task-oriented control. With this kind of control system, the robot will finish what it is doing, and then either repeat the task, or stop completely. Pick and place robots, doing assembly in factories, are under active control. They do the same thing over and over again all day long. The programs in purely active control systems in tightly structured environments are sequential, running in one big loop.

Since DocBot has a task to perform, the control system should therefore be active if the explanations just given are accepted. But in review of the peripheral issues that arise from robot operation in a semi-structured environment, it is obvious that there are reactive elements that must be accommodated. For instance, if someone were to absent-mindedly place a box in the path of the robot, the robot would need to react, not just run into the box. One of the problems to be worked out for DocBot is how to integrate a base layer of active control into a larger reactive control system.

Navigation: the primary means by which DocBot will keep track of absolute position is by dead reckoning. By counting clicks on the wheels as he moves, and knowing both his drive wheel diameter and spacing, the robot can calculate x and y positions with respect to a world model, as well as its orientation (theta) to the global x axis. However, the

Resolution of the encoders is only 128 per wheel revolution, the most that could be implemented without going to extremes, impacting the knowledge of absolute wheel position. Further errors come into play, called "systematic" errors, due to the difference in measured and effective wheel diameters and spacing. Considering the range of travel of DocBot in performing his task, perhaps as much as 40 feet in one direction, and considering that an orientation error of only 1 will produce a position error of 8" in 40 feet, the need for maximal precision in wheel control is obvious.

Motor control: The two motors on DocBot are geared DC, with a large drive reduction. The mass of the armatures are sufficient to carry the robot another whole inch after the current to them is cut off. To complicate matters, I have one motor that has something machined off-center so that it runs fast for part of its revolution and slow for the other part, although on average it runs faster than the other motor. A good PID control system might be able handle this situation, probably faced to some degree by all wheeled robots. One of the software tools that needs to be developed is a system that will manage the motors so as to maintain the tightest possible control. A command to turn 90 must produce a turn

of exactly 90 within the resolution of the encoders, and the wheels must turn in 1:1 synchronicity while traversing straight runs. This sounds difficult, and so far has turned out to be.

IR ranging control: The dead reckoning errors that come into play, systematic errors due to the difference in measured and effective wheel diameters and spacing, as well as limitations in wheel rotation resolution and slop in motor control algorithms, and "non-systematic" errors due to bumps in the carpet, etc., are inevitable. The best robots have alternative means to check on and update position. Aboard DocBot, the sole means of checking position is with the IR ranging module. Since the robot will live in a fixed environment with some permanent landmarks, it is possible to stop while within IR range from them and see if we are where we think we are. Depending on where the observations are made, corrections in x, y or theta can be made, and sometimes two or all three at once can be evaluated and corrected.

Having the IR ranging sensor mounted on a model aircraft servomotor controlled by the robot facilitates orientation and position correction. By taking two measurements of a flat surface such as a wall, at two different directions away from the robot, the angle of the surface detected with respect to the robot axis can be calculated. By sweeping and finding the shortest distance to the object, a correction in x or y can be made if the surface is oriented in one of the cardinal directions. The math for this is in any trig book. The standard library for IC has trig functions for most of what needs to be done. The one thing missing is the ARCSINE function, and a way must be found to do it in software.

Route planning: DocBot knows initially were he is, where he needs to go, were the fixed borders are, and has some more or less current information on obstacles. After that, he is on his own. He needs to plan the shortest possible route, and go there. He will use his IR ranging abilities to update position and orientation when within range of known landmarks along his planned route. IR ranging will also be used to detect and map unexpected obstacles.

A grid-based navigation technique will be adapted for mapping and planning. In grid-based navigation, the robot's world is represented as a group of contiguous squares. Generally, the programmer draws the office or kitchen (or planet) surface to scale, and then overlaid with a square grid of, say, 1 foot squares. Each square has a x and y position on the grid, and the x-axis coincides with one edge of the grid, and the y-axis is perpendicular to the x. Occupied squares, which represent borders and obstacles, listed in the program as "full." Grid-based planners use large arrays, taking up lots of RAM. Part of the problem will be to squeeze adequate detail into the limited RAM space available.

Control executive: once these and other software tools have been developed, it will be necessary to write the main control program that will use the tools to accomplish the required task. This will be an integrated active/subsumptive system, which, if the tools are properly done, should be easy to implement.

So there is the project. There are other substantially more impressive robots around, and certainly much more difficult tasks that robots can do than what is attempted here. But still, I think that a lot is happening with DocBot considering that there are just two sensors. It will be (I hope) an adaptive, learning, electroneurologic existence. Shiny, too. And if it only impresses some of us, well, it’s the best I can do at this point in my hobby. That's where we all are with our projects.

Next time: the circuits, the code, and the results.