Date: Mon, 3 Apr 2006 23:43:47 -0500 (CDT)
Subject: no black magic for bit banging
X-UID: 158

The pictures are somewhat large so I uploaded them to the website.

http://golem5.org/robot1/images/img2864.jpg
http://golem5.org/robot1/images/img2865.jpg
http://golem5.org/robot1/images/img2867.jpg

It was hot on Sunday (over 90 F, most civilian grade electronics is rated 
to 95 F) so I didn't want to run the robot. However, I think that the 
boards are actually rated up to 50 degrees C. The laptop might not be able 
to handle high temperatures, though.

So I did get out today after work. The robot wasn't working.

Communications were good and stable, both WiFi and 900 MHz. I could see 
everything. But the bit banging with the motor control board was flaky. 
After playing around on the command line, the rate gyro started and I 
could see it. But the numbers coming back were garbage and intermittent. A 
few minutes later, they were clean. What happened?

I could drive the robot from the ssh command line. Note the right side 
angle drive unscrewed itself as a result. But whenever using the "boss" 
server, nothing would happen.

So I packed up the robot and then went to the store to get some stuff for 
a charity gift basket competition at work. This gave me time to think over 
the predicament - man, I've painted myself into a corner. It could be that 
I'm doomed.

Basically, the reason why the remote driving system worked before is that 
there was only one process running on the robot computer. The event loop 
was on my laptop. The robot was a pure automaton. It did nothing without a 
command from the laptop. So when the process on the robot was bit banging, 
that is all that was going on (outside of the usual system processes).

The design now is different. The robot has three processes (note that in 
Linux 2.6, threads are really processes to the kernel). One process 
handles communications with the laptop. One process actually drives the 
robot. One process does nothing but read commands from the driving process 
and bit bang serial commands to the motor control board.

Note that the bit bang child process is a classical UNIX pattern when 
scheduling resolution is too course and real time performance is required. 
HP-UX handled sound this way with a separate sound server process. Quake 3 
did the same thing. It's also interesting as I ended up using a pair of 
sockets between the parent and child processes. After shutdown of the 
server, this can leave a socket in TIME WAIT state for up to a minute or 
so. This would explain why Quake 3 would apologize and wait for about a 
minute while it was initializing sound. It must have been doing the same 
thing.

Anyway, after taking the robot back inside and powering it up, I found 
that it was still not working! This was good as it meant that the failure 
was not purely temperature related. I kept thinking that temperature might 
cause oscillators to drift and so alter the serial pulse timing. But I now 
think that the explanation is much simpler.

I was just lucky the first time. The whole thing with black magic is a 
bunch of hooey. When some guy starts waving black magic in front of you, 
don't believe it! The mysterious #includes of the locale_facets files, 
that was pure chance. The onboard computer was just in the right state 
that scheduling always worked out "just so" and bit banging worked.

The solution (won't really know until after more testing) is to add the 
following:

(VehicleControl.cpp)
   fdOutputPin = open( GPIO_OUTPUT_PIN , O_WRONLY | O_SYNC );
                                                    ^^^^^^

(boss.cpp)
       struct sched_param sp;
       sp.sched_priority = 99;
       if (! sched_setscheduler(0, SCHED_FIFO, &sp))

So basically I'm using the POSIX.1b hooks now. And it started working 
again. The above changes cause the process to block on write to the GPIO 
output pin device and make the process highest priority in FIFO real time 
scheduling. This means that once it acquires the processor, there are no 
time slices. It runs until it blocks on a read or explicitly yields the 
processor (dangerous).

I'm recharging batteries again for another test run tomorrow after work. I 
had wanted to see if the rate gyro feedback based steering works. But now 
I just want to see if I can drive the robot at all. The nice thing about 
using gyro feedback for steering is that it automatically compensates for 
speed. As the robot moves faster, wheel deflection adjusts to maintain the 
turn rate.

I've been thinking about how I could possibly drive the robot while 
driving my car. One possible way would be laser guidance. So I could take 
the good diode laser module I have and shine a spot in front of the robot. 
The robot could then have three modes: laser guided, full manual driving 
using a joystick, autonomous (ignore spot). The big advantage of laser 
guidance is that the robot can then become slaved to my car and follow it.