Date: Thu, 23 Mar 2006 23:41:49 -0600 (CST)
Subject: robot must drive itself
X-UID: 154
Content-Type: APPLICATION/OCTET-STREAM; NAME="design20060323.png"

Last night was a full night of sleep just because, honestly, it felt good. 
But in the morning, many design issues became clear.

The main point is that once there is a feedback control loop on the robot, 
the "dead radio" safety I'm now using can not work. The motor control 
board will shut down all motor control if it does not receive a good 
command in a one second interval. During previous driving, all commands 
originated from the laptop. So if the radio link failed, the robot would 
shutdown automatically in about one second just by design.

Feedback control moves a time sensitive loop in the robot. This loop 
generates commands independently of the radio link. That's why an explicit 
heartbeat thread is added. The picture shows what I wrote tonight 
(although I was thinking about it since yesterday). On the left is the 
laptop with one thread sending gamepad commands and the other sending 
heartbeats. On the right is the robot with three threads, one listening 
for commands, one running in a 70 Hz loop updating sensor data and 
controlling the motors, and one checking the other two every second to see 
if they are stuck.

This is a big change from what was used to drive last week. It's very 
different. But I think it is necessary. The code isn't very tight and is 
around 1500 lines of very C looking C++. If written better, that would 
shrink down to 500 to 1000 lines. All of the robot code runs on geode1, 
the upper soekris 4801 board that is connected to the radio and motor 
control board. The cruise/autonomous code which has yet to be written will 
run on geode2, the lower soekris 4801 board that is connected to the GPS 
receiver. Geode1 is the executive. It must not die. Geode2 is for vision, 
localization, and navigation, more compute intensive high level stuff.

Also, I won't have time to use MICO CORBA (which means figuring out 
cross-compile issues). I probably don't need it anyway. My approach is a 
single multithreaded process per uniprocessor. IPC is between the three 
computer hosts: the laptop, geode1, geode2. All communications fits in 
three octet frames which are by design often idempotent commands 
(receiving it once or many times has the same effect). This eliminates the 
need for retry attempts and priority queues. Everything flows through the 
system.