Date: Tue, 4 Apr 2006 21:31:44 -0500 (CDT)
Subject: all good, works better than expected
X-UID: 159

Driving the robot is buttery smooth now. It works!

http://golem5.org/robot1/video/mvi2869.mpg

I would have driven it more but the right side chuck unscrewed.

http://golem5.org/robot1/images/img2870.jpg

I didn't bother to loctite it yesterday as I knew it would hold long 
enough to test the control system. I just didn't want to mess with it and 
add more variables.

The short story is that I think everything is working. It's funny how this 
project seems to swing from disaster to flying high in the span of a few 
days. What I'm learning from this is - don't panic immediately.

The steering controller minimizes error between joystick deflection and 
the gyro rate of turn. It's a pulse mode rate gyro so outputs a train of 
pulses between 1 and 2 milliseconds in width 50 to 75 times a second. 1.5 
milliseconds is nominal center, as standard for servo technology.

So the control system first primes the gyro to start it up. From that 
point, the gyro outputs a steady pulse train. By sending periodic input 
pulses, drift is controlled although I've found in practice drift is 
usually very slow (on the order of hours).

The microcontroller can't use A/D conversion to know the gyro output so 
must count in a tight loop to figure out the pulse width. This is trickier 
than you might think as it must be careful not to slice a pulse. After a 
pulse has been measured, the reading is sent to one of the onboard 
computers. This computer is using bit banging to read the serial frames 
from the microcontroller. Basically, it's doing what a UART would do but 
in software.

What makes this complicated is that the same computer (a 266 MHz Pentium) 
is also bit banging commands to the microcontroller, receiving radio 
communications, and driving the robot at the same time. Bit banging 
requires precise timing that usually is not associated with a general 
purpose operating system. This is not so surprising when you think about 
it - if people can write device drivers to implement IP over a parallel 
cable and other strange things like that, then you can pretty do much 
anything you need to if you can afford to burn up CPU cycles. I'm starting 
to see why Linux is a pretty good soft RTOS.

Anyway, all of my interest earlier in Kalman filters really doesn't apply 
as the jitter noise is not Gaussian. I just applied a simple heuristic of 
throwing away any reading that was crazy (too big or too small). I'm 
assuming that the robot is never spinning like a top as it would in a 
collision - in which case the rotation rate of the gyro is exceeded and 
the reading has saturated. So in the end, the simplest solution is 
probably very close to optimal.

The last 7 gyro readings are averaged and compared with the joystick 
deflection with a small dead zone. Motor control is bang-bang, full duty 
cycle left or right deflection, on the front wheels. This appears to work 
perfectly. There's no hunting. Wheels slew right to position and hold. As 
the gyro turn rate is controlled, as the robot moves faster, the wheels 
turn less. In practice, this makes the robot much easier to drive. I think 
it's much more difficult to roll the robot as the control system now 
compensates and fights it. Earlier with direct control over the wheels, 
control was precarious and required a lot of concentration.

My guess is that the steering controller is a proportional-integral type. 
In my control systems book, I know that some motor control problems are 
stable (eigenvalues are in the right places) with a PI controller. But 
basically, I have no mathematical analysis. I just know that it works.

Now comes the harder part. The robot must start using the cameras and 
demonstrate some autonomous capability. At this point, the robot is 
basically a giant scale RC toy except with a fully digital control system.