Robot Construction Project 2

Ben FrantzDale  Stephen Friedman  Paul Paradise

For this project we will be creating a Lego robot using the Handy Board.

Within an hour of starting this project we had progressed farther than we ever did with the palm robot project; within minutes we had communication with the board:

The Handy Board runs Interactive C. This appears to be a very viable language for this sort of development, particularly in contrast with TEA, the C-like language on which our previous project depended.

From the beginning, we were able to easily got the robot to work. The Linux program we used had extremely good directions. It included a photo with every step of the wizard as shown here:

Within minutes of reading the instructions we had motors working. This code was all it took:
fd(0); // Turn the motor on
off(0);//turn the motor off.
The result is shown in this video.

Robot Construction

Stephen has had significant experience with a Lego base for robots. In particular he discovered in a previous project that Lego motors are not very reliable in terms of speed making a conventional differential drive difficult to control.

The problem in general with basic DC motors is that given the same voltage, they will run at slightly different speeds. If you use two motors to drive two wheels of a robot to give you differential steering, you will find that if you supply the same voltage to both motors, your robot will veer off to one side. Thus, the chassis design we used has one motor to drive both wheels. The wheels are separated by a differential; that differential is connected to a steering motor such that the wheels will turn in sync if the steering motor is stopped, or a turning differential proportional to the steering motor speed will be added to the wheel axles. In the original design, a pair of gears was misaligned such that moving in reverse would cause them to slip, and an attempt to fix that was included in this version.

A closeup of the differential:

The original chassis (right) and the incomplete improved version (left):


At one point we considered using a third motor to collect the debris on the table, not unlike brushes on a vacuum. While the results were entertaining, the idea proved to be impractical for the time being. In the process of testing this we had the brush motor hooked up to the turning motor's proportional control. Thus, when the robot was trying to turn, the brush would spin, but the wheels could be turned by hand and would act as a throttle for the brush. Simple things amuse simple minds; all minds are simple at 4AM.

Encoder Issues

We discovered that not all of the Lego rotation sensors are created equal. In particular, we had originally thought that they were 16 ticks/revolution, but then it turned out that one of ours was reading 8 and the other was reading about 6. This became very problematic when we tried to determine where the robot was.

We implemented a process that ran through the Handyboard's multitasking extensions in Interactive C to keep an x-y position based on frequent updates of the robot's wheel encoders. Oddly, going in a straight line gave somewhat random, cyclical results for the x and y values. We eventually determined that the heading was drifting due to the difference in encoder resolution, making the robot think it was turning in circles instead of driving straight.

Light Sensors

The Lego rotation and light sensors give analog readings in a format that is not readily understandable by all the Handyboard analog inputs. Specifically, they need a 10K pullup resistor instead of the 47K resistor of the rest of the Handyboard. The Handyboard expansion unit provides 4 Lego-compatible sensor ports, to which we hooked up our light and angle sensors.

Interestingly, this library uses a very different way of accessing these 4 sensor values. Rather than call analog(port_num), the values are “magically” available as the global variables lego0lego3, and updated at 250Hz. This made reading from these ports syntactically different from handling any other sensor, but it worked just fine.

To make the Lego light sensors work with the Handy Board an additional library was needed. The library is comes zipped as The relevant files and must be included with #use and they must be in the same directory as the source that includes it. The file we used was explego.icb so our code has the line #use explego.icb. Here are the light sensors:

Wall/Edge Following

The edge following code worked perfectly on the very first try — not a common occurrence in robotics. Unfortunately the bump sensors, even with whiskers attached, did not have the necessary characteristics to follow walls. The bump sensors would catch on the wall, then the robot would try to turn away but get stuck or even push itself harder against the wall. IR range finders or sonar would probably work just fine.


Originally, we wanted to be able to have a grid to keep track of cleared space, and keep track of where the robot was in order to be able to ensure we clear the entire space. Eventually we decided that this approach required too much localization and navigation capabilities. We did successfully set up the two encoders to keep track of the robot's approximate position and heading, but at the end of the third week we decided upon the following algorithm: go until you hit a wall (turn and continue if you hit an edge first). We further improved this by having the robot be in one of two states: wall seeking or edge seeking. The idea is that in wall seeking mode, it will bump of walls, pushing around the debris on the table top. Then, in edge seeking mode, it will follow the table edge, where it is more likely to push the debris off. This way we have slightly pushed the probability in favor of pushing trash off the table, so eventually it should be cleaned off.

Platform/Implementation Issues

We discovered that initializing global variables apparently crashes the interactive C program running on Windows; the error message is not at all useful. Also, the lack of certain Lego pieces hampered our ability to build a stable base.


The Handy Board was generally a joy to use. Essentially none of our problems were due to it. This is in contrast with our previous with the BrainStem on a Palm-powered robot where all of our problems were with the architecture.

Lessons Learned

Links: and