Quote:
Originally Posted by Jaci
The reason for the delay is the state transition the robots go through.
Robots don't go from auto straight to teleop, instead, they go from auto -> disabled, then a delay (~1 second), then from disabled -> teleop.
There are a few reasons I can think of for this delay:
1) Allow robots to finish code execution in the disabledInit() method, i.e. resetting states or variables or whatever.
2) Allow field elements (e.g. the scoring counters) to count any game elements still inside the field element (i.e. balls rolling through)
3) Stop robots from browning out or falling over. Disabled mode stops all actuators on the robot (i.e. motors). If a driver steps forward immediately and goes full throttle in the reverse direction to the robot's current movement, you could easily be the victim of inertia and cause a brownout. (see: robots that keep moving after they're disabled)
4) Even the playing field for everyone stepping up to the driver station. Some teams like to play more cautious than others, that is, stepping forward when the buzzer starts rather when the counter reaches zero. I'm one of these people, since I don't want to get card'd by a ref that wasn't watching the clock.
5) To give the buzzer more authority / warning. Think about it, waiting until the end of the buzzer to start moving sounds like a pretty good thing.
|
You are correct, but to be more specific, the robot goes from Autonomous Enabled to Autonomous Disabled to Teleop Disabled to Teleop Enabled.
This year there was a 1.5 second (IIRC) delay between the end of autonomous and the beginning of teleop.