The message based control path is complete. The network joystick implementation is completely in the joysender program and out of the robot proper. The "planner" concept is obsolete. There is now simply a motor planner that responds to commands. All planning and control is assumed to operate in a separate process on or off the robot system.

Currently, the only way to control the robot or alter its behavior is by a script, pretend to be a joystick, or modify the robot program itself. All of which I have done as needed. I gets pretty tedious and frustrating to do interesting things when you have to modify and recompile a "working" robot program, each and every time, to do something different.

Therefor, what is being done is to scrap the "netstick" networked joystick and move it to a more generic message passing interface. The networked joystick will still work, but it will communicate through the new interface.

I am working on a "design guide" on how to build your own Linux PC Robot and I think something needs to be stated up front. This is not a "small robot." I have nothing against small robots like Lego NXT and Roombas, they are cool.

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));