(This is a saga, in that I'm appending what I'm learning as I go. So it may not make sense if you think I wrote it all at once. --jonh 5/6/96) Our robot is equipped with shaft encoders, an IR emitter-detector pair at each wheel pointed at a disc of alternating radial stripes attached to the wheel. The encoders accumulate "clicks" in a CPU register with each passing stripe.

I have been working on some SE(2) (translation plus rotation) matrix manipulation routines which attempt to track the path of the robot through 2-space based on the shaft encoder clicks, as well as the known direction that each wheel is being driven by its motor.

This technique has been successful in improving the usefulness of the shaft-encoder odometry, but it still needs work. In the diagram below, I asked Killer to move to the point (0,70), and then to (70,70). As you can see, the robot and the simulator (both of which share the same matrix code) don't even agree on the path taken by the robot.

I'm hoping to get the odometry to be reliable enough that it at least gives a rough estimation of position and orientation, which when coupled with sonar information, should help Killer determine his location on an internal map.


So it turned out that the problem was an incorrectly implemented FDIV (floating point divide) routine in the software floating point routines. I found an updated version of the code, and patched it into the on-board interpretter. Now the robot does a much better job of reaching its target:

As you can see, the robot at least thought he made it to his assigned destinations. In reality, the coarse grain of the shaft encoders on the wheels (16 ticks per revolution) accumulated a lot of error throughout each turn manuever, so that the robot actually followed a path something like the yellow one shown. (Drawn from memory.)

But, it's sure an improvement! In case you're wondering, some better robots use shaft encoders with 2000 ticks per revolution. So it's understandable that there's some error.

And probably a lot of that error comes from the twisty contortions he traverses at each vertex. This is due to our correction algorithm, which wanders along, thinking everything's okay, then suddenly at the last minute, realizes how far off-course he is, and swoops in for the turn.

This behavior will be corrected in three ways: