I have given presentations about this robot several times over the last few years. From IEEE conferences to USENIX, including a 1st grade class in Milton, Massachusetts. I have mostly been focusing about the "why" and history of the Linux PC Robot (LPCR) and only tangentially touching on the technical details.

While the Arduino is a slick little environment, it lacks one thing: a background processing paradigm. When you read an analog sensor, delay, or wait for the serial port to finish transmitting data, you effectively waste time. This is fine if you are doing basically simple control tasks, but if you want to do something a little more complex, you need to restructure your code to do multiple things simultaneously.

Well, in computers, old things often become new again. Back in the late 1980s and early 1990s most computers ran some form of Microsoft DOS. Oddly enough, the Arduino processor has basic similarities to the old Intel 8088 and the single task environment is similar as well. The tricks we did in DOS translate easily to the Arduinio.

One of the more popular techniques was to break down tasks into their various states and create a state machine. The state machine can be called periodically to do a little bit of processing each time and return. Each successive step in the state machine progresses the overall process. Its like a thread, but no thread context is needed.

The Arduino software has a very "one job" perspective. For instance, if you want to read an A/D value, this could take about 100us. Sure, that isn't much, unless you also want to take an ultrasonic reading. Most timing in the system simply spins and waits. You should be able to do something else whilst you are just waiting.

Take, for instance, reading the A/D converter. The code looks like this:

        // ADSC is cleared when the conversion finishes
        while (bit_is_set(ADCSRA, ADSC));

The TS601 Ultrasonic Range Finder is a common and cheap sonar based system, at about $15.00 its a pretty good bargain. It's interface is simple, a single pin. You apply a digital pulse for a little bit more than 5us, then wait for a pulse who's width represents the time it takes the sound to hit an object and bounce back.

The initial implementation is complete and reports the response in millimetres.

A sample Arduino test program looks like this:

#include "Arduino.h"
void setup (){}
void loop ()
{
    while(1){
        pinMode(7, OUTPUT);
        digitalWrite(7, 1);

Since the Technology Upgrade of the LPCR, moving from I/O board and PS/2 mouse to unified Arduino project, I am reminded of some old problems. One such problem is accuracy. You don't have any.

The LPCR defines the dimensions of the wheels, axle, and the number of encoder ticks per revolution of the wheel. You know what? Its, at best, a ball park estimate. Each wheel is 5 cm wide. The circumference of each wheel is 63.5 cm. It is 8640 encoder pulses per revolution. So each encoder tick is 0.007349537 cm. With these numbers, all we need is a pen, and we are a plotter, right?

I recently read that someone at google compared today's state of robotics with the PC industry of the late 70's early 80's. I can understand that analysis, and while I differ a bit with why it is being said, I somewhat agree.