Date: Mon, 13 Mar 2006 23:23:39 -0600 (CST)
Subject: need reactive development
X-UID: 148

Images are posted to the website as they are too large for polite email
attachment.

http://golem5.org/robot1/images/img2795.jpg
http://golem5.org/robot1/images/img2796.jpg
http://golem5.org/robot1/images/img2797.jpg
http://golem5.org/robot1/images/img2798.jpg

I picked up two 3/32" steel dowel pins from the hardware store and a
cobalt drill which was necessary for drilling through the stainless
threaded rod. This went quite well. The square nuts are pinned in place
now. They are pretty small looking compared to the huge wheels so I won't
be surprised if they shear off or something else rips apart.

Note the first image. The epoxy wedges potting the wheels studs are
pulling out of the hub. I knocked them back in with a mallet. I think
they'll hold up for a few good runs. But eventually the epoxy will crack
apart and fail completely. The only thing that saves me at this point is
that I am a lot faster fixing mechanical stuff when it breaks. I think I
could rebuild this entire robot in under three months if I had to
(although I wouldn't as the design is wrong).

What's interesting is how much stuff is breaking already - and the robot
has not really been under any significant stress. It is a lot harder to
make a durable vehicle than I expected. This is probably why Thrun had his
motto of reliability. Better to have low performing systems that work
reliably rather than high performance solutions that are flaky.

I also added another bungie cord to the front wheel assembly. I decided
that instead of any significant change, I'm going with it and see if it
can be made to work acceptably. One robot club member pointed out that the
reversed Pitman arms actually causes the outer wheel to turn more than the
inner. It's not Ackermann. I think that what happens is that steering
always has a toe-in with this configuration. Some RC car racers use
reversed Pitman arms for this effect for the altered handling it gives.

Here are the two ideas in my head tonight.

1. The robot must have a test drive at least once per week. This defines a
    weekly iterative cycle. From experience, it seems that nothing I can do
    in design or planning is able to predicate success or failure. Only by
    testing does it become known what solutions don't work. I lack the
    experience to explore the design space in any other way.

2. I need to treat this robot as disposable. I need to be aggressive and
    take risks with it in the sense of getting as much experience and test
    data out of it as I can. It's value diminishes with every week as
    technology advances. There are already substantially improved single
    board computer options available today compared to a year ago (smaller
    size, lower power consumption, higher performance). It's kind of
    shocking to realize that just as the mechanical construction is
    finished, the hardware is already obsolete.

At work, because I don't have my heart invested in it, I can be more
cynical and switch between black and white box views, divide and conquer,
etc. These are all strategies to find a solution to a problem quickly
without necessarily having a completely formed theory of what is going on.
It's the engineering equivalent of solving the Gordian knot by cutting it
with a sword instead of unraveling it.

It's already into March and I'm still fiddling with mechanical problems.
More significantly, I haven't done any significant software development.
This may have been a necessary analysis phase, sort of how it took me a
year studying electronics and embedded Linux issues before I even started
on the robot.

The hardware was just a long grind of fabricating one thing after another
with partial assembly along the way. There were no iterations. I don't
know if this is how hardware is normally done. But I have the impression
that the iterative cost in hardware is much higher in the short term than
for software. So hardware is something you try to cut right the first
time.

What defines a software project are the deliverables (is this true of
hardware too?). There is usually a schedule, realistic or not, with some
defined integration points, demos, and milestones. Where I work, for many
years they had a weekly iterative cycle with production pushes every week.
It was almost purely reactive. There wasn't so much planning as running to
wherever the fire was.

I think that the last month has demonstrated that I need to be reactive.
The nature of this robot project requires a reactive development style
with short iterations. The high overhead is ok as visibility is more
important than just about anything else. And whether it is good or not,
the bulk of my industrial experience has been under reactive management.
So it's probably what I'm best at.

I'll drive the robot tomorrow night at the DPRG warehouse location in
Garland. If the wheel pins and steering hold up, then I can start evolving
an n-tier CORBA based system. Control systems study must proceed in the
background as I think the feedback loops will become necessary soon.