Date: Thu, 9 Mar 2006 06:27:02 -0600 (CST)
Subject: demo driven development
X-UID: 145
Content-Type: IMAGE/JPEG; name="img2761.jpg"

A coworker related this observation yesterday:

"Any sufficiently advanced technology is
  indistinguishable from a rigged demo."

I wondered if the converse is true:

"Any sufficiently rigged demo is
  indistinguishable from advanced technology."

The original is from Arthur C. Clarke:

"Any sufficiently advanced technology is
  indistinguishable from magic."

So now that there are two evenings left before a demo on Saturday, I've
made some decisions based on making the robot look cool and showing off
capability that most other amateur built robots do not have, especially
these four:

1. optical cameras
2. true onboard computers running a full operating system
3. wireless communications
4. high power and speed

However, I think they have lasting value. Basically, the demo has forced
me to make some decisions about the outstanding issue of poor webcam
performance. The robot needs higher video framerates.

Last night, I picked up a $100 network camera from Fry's. It's a Sony
SNC-M1. Network cameras are basically small single board computers with a
camera and framegrabber all in one. Instead of an analogue or high speed
serial interface, they have network interfaces (RJ-45 jack or WiFi radio).

With this camera, I now have true 30 fps over a network interface which is
the one I/O modality the soekris single board computers are optimized for
(they are embedded router boards). So I should have good performance.

The camera outputs either a MPEG-4 or M-JPEG stream. I've had great
difficulty (only did it once) displaying the M-JPEG stream so have been
using the MPEG-4 stream. The surprise is about 1 second of lag between the
real world and what I can see in the mplayer window. That's huge and quite
a surprise.

I think what's going on is that there's about 100 to 300 milliseconds of
lag introduced by the network camera as it encodes what it sees into
MPEG-4. Then there's another half second or so of buffering by mplayer as
it decodes the stream. I've twiddled with image size and bit rates. The
lag is not due to network or compute performance. It's a buffering
pipeline on the network camera, laptop, or both.

The solution will be to use M-JPEG which is a series of JPEGs. So there
shouldn't be a need to buffer when decoding. Each frame is complete and
standalone. I don't have time to figure this out before Saturday so will
have to make do with the lagged video.

For the demo, I'll use roadmap to show the robot's position in a vector
map. It will be pointed at the GPS receiver on the robot. Then mplayer
will show video from the Sony network camera (not sure where I'll mount it
- not sure if the "Eye of Sauron" look is good or not - the vision system
team leader on the Stanford team dubbed the custom gimbal and gyro
stabilized laser scanner on the CMU robots with this moniker). I'll also
make liberal use of ssh and http to upload software and teleoperate the
robot. It will be like a "Big Trak" on steroids (the "Bigger Trak").

The SNC-M1 is specified as requiring 2.9 watts at 5 volts. That's about
right given what it is - a webcam and a single board computer with a
framegrabber. The GPS, Maxstream radio, two webcams, rate gyro, IR
distance sensors, and steering potentiometer are already drawing over 500
milliamps. Most of this is powered by one of the onboard computers. Given
that each of these computers has an absolute maximum budget of 5 watts for
the mainboard and 10 watts for everything else, it should be o.k. to power
everything from the 5 volt switching supply on the onboard computers.
However, I know that when devices power up, they often draw quite a bit
more current before they settle down. I'm afraid of connecting the network
camera to the same circuit as everything else. Mostly, it is the huge size
of the Sony camera. Even if it conforms to specification, it would
increase current tapped off the computer mainboards to near 1 amp at 5
volts which is quite a lot. So I'm going to strap another battery pack to
the camera for power. This has one nice advantage. The network camera then
becomes stand-alone so I can mount it on a tripod in the car and drive
around with a laptop for vision experiments.

Control systems stuff is fascinating. In general, it seems that control is
an underconstrained problem. There are many solutions that can work. So
it's not as if there is a unique or optimal solution. There are too many
variables, accuracy of the model being one of them. Unfortunately, I
probably won't have enough time to implement any of this for the demo on
Saturday. There's not enough time for testing so the risk of the robot
going crazy is too high.