Date: Mon, 20 Feb 2006 21:52:48 -0600 (CST)
Subject: plan for software development
X-UID: 137
Content-Type: IMAGE/JPEG; NAME="img2725.jpg"

Attached is a photo of the three motors in the robot.

The small one is the modified Black and Decker cordless screwdriver. Since 
last week, it has been sawed down in size and made reliable (before it was 
big and unreliable). The wires are soldered directly on the motor 
terminals and the clutch tightly taped into position. Before, a zip tie 
held down the trigger and the clutch held in place with the click detent. 
The problem is the entire screwdriver was twisting around. In some 
positions, the zip tie would deform and release the trigger. Also, the 
clutch would slip and lock the motor. This explains why the steering was 
so gamey before. It would work and they mysteriously stop or stick. This 
should not happen now.

The two bigger motors are from the Panasonic drills. I fiddled with the 
gearbox of the one marked with "L". Hopefully, this fixes the high gear 
problem. Although...the lesson is that even in high gear, these motors 
have more than enough torque to move the robot. I may wish to leave both 
motors in high gear all the time.

About six months ago, I laid out plans for the mechanical and electronic 
aspects of the robot. Now that software is the prime concern, here is how 
I see it. It's still kind of pie-in-the-sky until it comes down to code 
that works, I know.

Virtually all autonomous robots must operate with full-time manual 
override. Remote control is always present to varying degrees. Autonomous 
capability and manual override must coexist. As the robot gains 
capability, less supervision is required. All practical robots are both 
autonomous and teleoperated at the same time. This is my theory now. It's 
a mistake to think of robots as either completely dumb or so smart they 
don't need people. It's like how hybrid cars will rule for a long while 
before fully electric or fuel cell cars become practical. There is a 
bridge between extremes of technology.

There is constant data collection from sensors according to a mission 
profile. All of this is recorded for offline processing and analysis. Any 
discoveries or theories find their way into the next iteration of onboard 
software. Hopefully, this leads to greater autonomous capability over 
time.

I've found that most of the suggestions people reading this have given me 
are close to dead on accurate. So in light of past experience, I'm 
learning to trust them and go with the wisdom of the group.

A reader advised me to use 4GL style interpreted numerical software (e.g. 
MATLAB) before worrying about optimization. This is the right way. In 
school, the very low performance of this kind did severly limit the 
computational space you could visualize. But when that happens, that means 
you need to write some software.

I know that many of the engineers reading this are really down on science 
fiction like my favorite, Ghost in the Shell. But I think that many of the 
high level systems issues have been well thought out with their robot 
Fuchi/Tachi-koma. Japanese science fiction often has incredible levels of 
detail from careful analysis. In this world, the robots are always 
semi-autonomous. They can be directly operated by people or sent off to 
operate autonomously. They are kept on a very short leash. They are 
designed to function in a group with people and other robots. And every 
night they are shutdown for offline processing of what's happened during 
the last day. Then all of the robots are reprogrammed and resynced for the 
next days mission.