[jimfortytwo]

To take a different tack... Every year I think FIRST has to get "harder" to stay interesting. No mentor wants to do basically the same thing over the course of a decade, and even in my experience students loose interest in things once they "master" them. I think Autonomous mode is very important in that it gives veteran teams and student seniors an interesting and difficult goal... but rookie teams who write it off really won't be penalized at all. I am very happy that autonomous has been added to FIRST in my time with the program—without it I'm not sure my last year in FIRST would have been half an interesting. This isn't to say I don't have some beef with this year's autonomous task. Mastering the camera alone turned out to be a messy business, and 15 seconds really isn't long enough to give most teams a fair shake at capping the center goal. Even with a human driver, I can't see completing the task in much less than 10 seconds. Adding 5 seconds to autonomous wouldn’t so much "emphasize" autonomous as just make things more possible, this year at least. Of course changing something like that mid-year is a bad idea.

Speaking as a student preparing to leave for college, I would contend that anyone who believes that you can justify having mentors do a majority of the work under the premise of "inspiring" students is doing their students a huge disservice. I understand that in many cases students don't have the skills required to make their building the robot practical, but in those situations I feel like the primary objective of the mentor is to give the students those skills as quickly as possible. I think FIRST has a duel purpose. When Dean talks about "inspiration" he is talking about changing the culture, and that means what happens outside of the bounds of our own team members. Internally we should be preparing kids to jump right in as college freshman with skills for doing real research and working internships.

I don't believe that programming is that big a hurdle, even in terms of autonomous. I don't have any formal schooling in c. I'm one of our lead programmers, and I designed the algorithms for our autonomous modes and for our macro arm functions. All that is required to be successful is literacy: understand if statements, case statements, #defines, and where you stick your function definitions. The default code might not be documented quite as clearly as it could be, but basically I see no reason why all teams can't build the dozen lines of code needed for an array-based dead-reckoning autonomous mode. The biggest hurdle, it seems to me, is getting the programmer to understand what he needs to do to make the robot drive forwards for 5 seconds and then stop. Once you can do that, everything else is now within reach. Unfortunately to that end, chiefdelphi and our whitepapers seems much more helpful than the actual documentation of the code students are working on.

What I personally would like to see is more teams taking advantage of the power of autonomous functions during human control. The top articulation of our arm features a leveling function that reacts to the motion of the bottom articulation. Additionally, the driver has a set of buttons that bring the arm to specific locations for completing tasks with only one click. Perhaps instead of focusing on pure autonomous, FIRST games could encourage that type of human-autonomous cooperation during normal play. I can see game tasks that might require more delicacy than the drive can easily handle, or are completed around semi-blind corners from the driver's station. That might be cool.