[Mark McLeod]

Essentially, if the DS and robot began communicating with each other before the FMS exerted control (takes a second or two), then it would start operating enabled just like at home. Either auto/enabled or teleop/enabled depending on how your DS switch was set.

This bug was discovered during the early events and was the reason for the team startup procedure of:
1) making sure your DS switch was set to Teleop,
2) waiting for the Field Preset,
3) connecting the Driver Station and waiting for FMS to recognize the DS,
4) powering up the robot.

For next year, to solve this, FIRST is looking at a firmware change that forces both the DS and cRIO to connect to FMS before being allowed to connect to each other.

The window was small, but the robots could twitch dangerously (threatening the team & field crew), and of course if you used an auto state machine or a timer then your auto would likely be messed up.
For programmers this means always resetting any required startup states during auto/disable or teleop/disable. In the early days of autonomous in 2003/2004 we had similar learning experiences where the modes could be mixed and not the progression you'd expect: 1)auto/disabled, 2)auto/enabled, 3)teleop/disabled. 4)teleop/enabled, 5)teleop/disabled.
You might see a similar issue during the usual back-to-back practice matches run on Thursday.
Don't design your code to depend on these exact steps. Design it to work at home if the Teleop/Auto switch is toggled randomly.

We found at SBPLI we could safely stagger the startup procedure, but we made sure the FMS was in control of the DS before the robot cRIO's finished booting.