First, you need to acquire my software kit. You can click here to download a Stuffit archive of the kit. The software is a modification of that included with the original Rug Warrior kit. Thus, you might consider going back to the original sources to find out more about what the robot can do. However, this kit should be enough to get you started. Modifications include:
Some notes on IC:
Note that the robot's idea may not correspond with reality. The robot determines where he is by measuring the rotation of his wheels, and plotting his apparent path in 2-space. This can be confused by a mismeasurement of wheel diameters or the distance between wheels (which you are free to tune, see tuning.c), by wheel slip (bummer! try cleaning the rubber with alcohol), and by rolling on a rug. And after angular error is introduced, that error accumulates the farther the robot rolls.
My long-term solution to this at the robot competition was to use sonar to measure walls and corners, and compare those to a rough mental map of the building provided ahead of time. This could be used to correct gross errors, keeping the robot generally in the middle of a hallway. If you need to make corrections to the robot's idea of the world, see matrix.c, and perhaps ask jonh for a look at the competition code.
Another concern is latency. Currently, the odometry loop (which measures
the world and computes our new position in it) runs about once every 140ms.
Therefore, the get_* functions are actually telling you where you were
about 140ms ago. This is often not very useful -- a rolling robot can go
a long way in 140ms. If you need more precise information, try
Note that in addition to errors in the robot's idea of where it is, control faces an additional challenge: The robot might know where it is, but have a difficult time getting where it wants to go. The current libraries can stay within four or six inches of a goal path (and arrive within ten or twenty degrees of a goal angle, when turning). [This is much better than they could at competition time.] But you need to keep this error in mind. When you arrive at the goal, inspect get_position(). You won't be able to get right on the goal spot by go_ing again, (duh -- or you'd be there already!), but you may be able to use the information to adjust your behavior at the goal point in some useful way.
Surprisingly, you can almost always see corners, no matter what angle you are at. This was used to good effect at the competition, by being able to pinpoint the two posts of a doorframe fairly reliably by sweeping the sonar. The 7.5 degree sonar cone made the posts easy to recognize -- they left a flat signature (7.5 degrees wide) on the returned data.
It goes stinking, whizzing, wheel-bending, monitor-chipping, damage-causing, wire-cutting, parts-shearing, there's-no-way-you-could-ever-run-and-catch-up-with-it fast. :v) The bad news is, it sure could never compute fast enough to keep up with that kind of speed. In fact, you can't even keep up with it.
To avoid this sort of occurence, there are several safeguards in the code. The PWM code is carefully designed to turn the motors off in the default case. The bump switches automatically stop the robot. The speed control code detects speed integer overflows, and stops the robot. (You'll hear beeps when it decides to do this; if you request too high of a speed, it will frequently accelerate, beep, and slow back down. By the way, the speed at which it beeps is many, many, many times slower than its top speed. In case you were curious.)
To avoid disaster, all you need to do is only control the robot through the spd_* speed control functions. Never call motor() or set_pwm*() directly.
There is also a case where the board resets when the wheel motors receive power. This is caused by another hardware bug, wherein the chassis isn't at zero volts. It will manifest itself only if some logic ground is connected to the chassis. (This is why all components are separated from the chassis by at least a nylon fastener.) If you get this bug, talk to Jon.