Auto mode woes.

In 2004, we had an autonomous mode which would drive out, grab the multiplier ball, then knock over the bonus ball trigger.

In 2005, we had an autonomous mode which would score one tetra on the top of the close middle goal, then grab the hanging tetra and score it on top of the corner goal.

In 2006, we had an autonomous mode that did very little.

In 2007, we had an autonomous mode that did nothing.

In all cases we felt it was worth doing an autonomous mode, but other factors limited us. Prior to '06, you were allowed to do some amount of software development outside of the fix-it windows. For '06 and '07, you were not allowed to do any. In '04 and '05, we spent significant amounts of time working on software on our practice robot, which helped the drivers during the teleoperated period, and which ran during the autonomous mode. In '06 and '07, we focused the limited amount of software time available during the fix-it windows on functionality which covered 87.5% of the game time, rather than on functionality which only covered 12.5% of the game time, though really much of what we worked on would help out for the whole game (tracking the light, ensuring our ball launcher wheels maintained a constant speed, holding the arm steady at a fixed height, running a complex arm sequence to deploy ramps, driving in a straight line, etc).

From my personal perspective, both the '06 and '07 autonomous modes have been disappointing, not so much because of how they impact the game, but because of how little time we’ve been able to spend working on them, due to the reduced software development time and our mechanical aspects not being completed early enough to make up the difference.

Many people have pointed out that teams should be able to do most of their software development even without a mechanically completed robot, so that they know how to use the sensors, etc. While this is partially true, it is misleading. Teams can learn how to use sensors, but things like tuning PID gains can only be done once the mechanics are complete. Changing the weight of an arm, the size of a wheel, or the motor used all require retuning that code, which takes time.

For my team, I would like to see more time allocated to software. Maybe this means bring back software development outside of fix-it windows; maybe it means actually getting the robot done more than a day before ship. I would also like to see the game designed such that it is completely obvious to everyone that good autonomous operation is required. Maybe this means a larger autonomous bonus(*); maybe this means a significantly longer autonomous period (like half the game?).

(*)I know some argue that this year has the largest autonomous bonus yet, but I counter that it is not obviously so, as demonstrated by discussions here on CD.


To me, “robotics” is the intersection where mechanical engineering, electrical engineering, and computer science all meet. Even during the “RC” portion of the competition, you still have all three disciplines in the mix.


Here’s an example of the fun you can have targeting the green light (courtesy of Team 968, last year):

Aim for the Green Light!

I like the “Oops” comment at the end…