Date: Tue, 21 Mar 2006 22:35:19 -0600 (CST)
Subject: real time spaghetti code
X-UID: 153

My working pattern has shifted to short bursts of three or four hours. 
This was not a conscious decision. But it effectively means that I get 
more sleep. This is probably an adjustment to a higher level of 
concentration required for a kind of software I have no experience with.

The remote driving client hasn't changed too much. It has to read a 
gamepad with two analogue joysticks, a digital pad, a bunch of buttons, 
and send commands over WiFi/900 MHz radio to the robot. There's a thread 
that transmits the robot speed at least every 500 milliseconds. This is 
done so that if the radio connection is lost, the motor control board 
failsafe will kick in and shut the drive motors down. The robot does not 
control its speed independently for safety. It only keeps moving because 
of commands sent to it.

The server side software on the robot is changing a lot. It's making me 
think of the event/delay loop non-interrupt driven firmware for the AVR 
microcontroller on the motor control board. It's only about 600 lines now 
but is doing a lot of things at the same time. By design, there shouldn't 
be any jitter effects. That's a problem as the serial I/O between this 
software on one of the single board computers and the microcontroller on 
the motor control board does not use a UART. All serial is done with delay 
loop bit-banging.

So right now the server side is a single process with two threads locking 
the same mutex. One thread reads sensor data from the motor control board 
while the other waits on received commands to send to the motor control 
board. I haven't tested the latest modifications yet.

I used to think that console gamepads are abominations for aliens with 
three arms (I grew up with the Atari 2600 style digital joystick with one 
red button) but now they make sense. I'm using the left analogue stick for 
proportional steering based on the robot's rate gyro. The right analogue 
stick is for the drive motors, both forward and reverse. The digital pad 
is for direct manual control of steering. Two buttons on the top center 
are emergency stop for all motors. Two more buttons on the left side front 
turn the cruise mode (autonomous) on and off. Anyway, I'm rapidly using up 
all of the buttons. These gamepads are very intelligently designed. I have 
a $9 gamepad I picked up from Fry's. I've read the Logitech pads are 
better and may be worth it if they give better resolution.

The server code can be cross-compiled (not much of a cross-build as the 
target is x86 with uClibC) or built for the laptop. So I can do some 
testing without deploying onto the robot. Given the pretty massive changes 
tonight. I'm thinking that I really need more QA before testing this on 
the robot outdoors. However, I'm also aware of the twice per week testing 
schedule. I'm rapidly slipping the three day development/test cycle as I 
didn't drive tonight.

Once this more advanced remote driving system works, the next step is 
hooking the cruise (autonomous mode) into the picture. That will have to 
be running on the second single board computer and use the network camera. 
The rolling map with probabilistic occupancy grid appears to be the one 
concept that everyone who deploys real robots (not just vision research in 
the abstract) uses. So I will use it too. Basically, everything that the 
robot believes from sensors, internal maps, models, etc. is represented in 
a common occupancy grid.

What will be really interesting to discover is how much code is required 
to get this robot to cruise autonomously down a relatively straight road. 
Discounting libraries, it's looking as if only a few KLOCs may be enough 
to handle this limited case. Stanley is 100 KLOCs. So it's not 
unreasonable to expect that a robot with much lower performance 
requirements could get by with much less code.