Date: Fri, 10 Mar 2006 06:15:05 -0600 (CST)
Subject: network camera mounted
X-UID: 146
Content-Type: IMAGE/JPEG; name="img2769.jpg"
Content-Type: IMAGE/JPEG; name="img2770.jpg"

The network camera is hung from the aluminum rectangle to which the stereo
webcams, gyro, and IR distance sensors are also mounted. This feels right
aesthetically. The robot looks "dense". It maintains a compact design.

I had considered a removable mounting bracket that extended above the
carry handle. This would have been very inconvenient as then the robot
would not fit in the trunk of my car when the camera was mounted. I'm more
aware of logistics now. Ease of deployment is important.

Performance would probably be better if the cameras were higher and angled
downwards. But it's good enough until I figure out how to use the cameras.
Note that I'm following the Berkeley pattern of low framerate stereo
cameras for obstacle avoidance and a high framerate camera for
road/terrain following. So long as obstacles aren't moving very quickly,
this works. The robot spends most of its time looking on the road just
ahead and glances up with the stereo cameras periodically to see if there
are any obstacles. Of course, the relationship between the two visual
modalities will be more complicated than this. But essentially the high
framerate mono camera is more important than the stereo cameras.

I didn't want to take all of the sensors off of the bar so just taped over
the sensitive areas to keep out metal chips when drilling. It would have
added another 30 minutes to take everything off and get it back on and
reasonably aligned. I slept from about 9 pm until midnight yesterday and
worked until now. So I'm tired and pressed for time (have to shower and go
to work after sending this email). I had planned on finishing all hardware
upgrades by this morning so this evening can be spent entirely on
software. Well, it won't happen.

There is a good solution for the rear wheel locknuts. I milled out a slot
in which square nuts fit. Now the wheel will remain locked to the
driveshaft so long as the Lock-tite holds. If it doesn't hold, then I'll
switch to a proper permanent cyanoacrylate instead of the blue Lock-tite I
have. I'll have a picture of this rear wheel solution in the next update
after I get the wheels back on the robot and fully assemble it.

I've found that by attending the Dallas robot club, conceptual progress
occurs perhaps 2x to 3x as quickly as when I was working in complete
isolation. It's very strange. But there is great power in social aspects
of technology development and engineering. This is the first time I've
ever done any technical work in a social context outside of a job (which
unfortunately has never been something I truly loved but rather something
that had to be done).

The most valuable thing for me is conversation and observation. In casual
discussion come the seeds of ideas and solutions. Little things can make a
big difference. During a conversation, I'm trying to form theories about
what is being said and connecting it to other knowledge. So I'm an active
listener.

Another example is an email a coworker sent me yesterday. It's about NASA
open source software. I'm going to look at their mission control toolkit.
But the most interesting project to me is some kind of fault detection
engine for flight systems. The machines that are sent into space are so
complicated that detecting faults by inference is necessary. This is also
true of autonomous robots. Many of the DARPA Grand Challenge robots were
taken out of the race due to system failures. It is probably necessary
that autonomous machines be able to understand how "self" works and so be
able to compensate and continue with degraded operation when damaged.

The package uses MICO, an open source CORBA implementation. That just
clicked. I need to use CORBA. I've been so focused on high speed and
"embedded" that I became blind to the quickly mounting system complexity.
Autonomous robots are much more like large "enterprise software" systems
than optimized applications software. There is a point beyond which
complexity management requires approaches that are less efficient. If you
try to make it hyper efficient, then it will never be made.

So I'm not going to use UDP with a homebrewed reliability layer. That's
crazy. I've worked on that before and it's not trivial to do. There are so
many problems to tackle that spending time writing the equivalent of the
TIBCO middleware is nuts.

Besides, every job I've had since leaving graduate school has used CORBA.
So while I'm not an expert, I've been working with systems built on CORBA
middleware for about nine years now. It's familiar. It's also about the
right technology tradeoff. XML over HTTP is too heavy. In our experience
at work, there is about an order of magnitude (10x) increase in network
data throughput required with XML protocols as compared with unstructured
ASCII7 EDI (electronic data interchange). CORBA is probably about as fast
as it can be and still provide type safe interfaces.

So this email about NASA open source software led to a major architectural
decision. If I were in an isolated box, the obvious solution would have
taken much longer to uncover.