[Andrew]

I have come to like autonomous mode. The difficulty for the past two years has been that we had to figure out how the controller would perform, especially with autonomous mode switching (which you couldn't really determine until you put your bot out on the field). By switching between pBASIC to C, we were thrown back to ground zero in both 2003 and 2004.

If FIRST sticks with a C programmable controller and maybe releases the timing diagram for auto mode switching, so that we can exactly match what the field system is doing, we should be able to make lots of advances in the off season, both through 2004 robots and the robo-edu-bot-vision-thing.

Teams are likely to start sharing knowledge over the summer, so, rookie teams and teams which did not accomplish much in 2004 should be able to quickly get up to speed.

What would make AUTO more effective...
MORE SENSORS!!!!!
We used the Analog Devices yaw rate sensor very effectively this past year. If we had gotten our encoders working properly, we could have done a go straight at contant (known) velocity for a known number of seconds. As it was, just feed back on the yaw rate sensor allowed us to go straight and turn to a fixed heading.

We could figure uses for ultrasonic sensors, touch sensors, and force sensors, if they were readily available and didn't blow the electronics budget.

We had a novel use for a strain gage. But, it was not allowable under the rules. If FIRST relaxes the electronics rules or makes specific sensor rules (ie you can buy a sensor from ANY supplier at ANY cost within the overall budget constraints) you will see a lot more creativity in AUTO mode.