[Bongle]

Originally Posted by Brandon Holley

I think FIRST would like to see more developed autonmous modes before they would consider moving the autonomous mode or adding another..

They'd see them if they were easier or worth more. As it is now, the payoff for spending another week building/practicing is more than the payoff for letting the programmers fiddle with the robot for a week, so teams won't do it. If you look at 2006, just about every team had at least a simple defensive autonomous mode, which is all an first-year endgame autonomous mode would require.

There would be way more variables to consider and way more obstacles to maneuver if it were at the end, along with the added danger of having robots possibly go where they are not supposed to.

But for now, I think that it is way to complicated to work with, and what if a robot flips over, or gets stuck in a situation..... You could seriously damage your robot, and other things....

I don't see how there are more out-of-control variables. You can control your robot's position at the end the match, so long as the driver knows where he/she should be. You can't control the positions of other robots, but you can't do that now. If your robot is entangled or will cause itself to become entangled, there is always the e-stop. Autonomous modes as they are now are capable of damaging the robot, I've done it a few times. The key is communication between the programming team and the drive team so they know what it will do and when to e-stop. Perhaps a change in rules so the drivers can carry the e-stop button behind the line with them would work, with a rule that any robots e-stopped DURING (not before) endgame autonomous score no points.

Here are the cliffs notes of my counterarguments. Note that I assume that the teleoperated period and the endgame autonomous would be seperated by 5-15 seconds of decision time for the drivers to decide whether or not to e-stop.

Someone: The robot might get damaged
Me: They can easily get damaged with the current autonomous mode. I have personally written modes that have damaged our robot.

Someone: The robot might get damaged in a noticeable way during the match, and running autonomous mode will hurt it further.
and Someone: The robot can get entangled or otherwise be in a nasty position
Me: Then e-stop it before the final autonomous section begins

Someone: The robot might get damaged during the match in an unnoticeable way that is inflamed by autonomous mode
Me: How could a robot get damaged in such a critical way that the driver will never inflame it, but the autonomous mode will? Wouldn't this inevitably either be inflamed by the driver? Sounds like a mean way to blame programmers

Someone: The robot can be ANYWHERE on the field when it starts
Me: If your autonomous mode can't handle that, then train your driver to place it where it needs to be, and if he can't, e-stop it before autonomous mode starts.

Someone: Other robots can be anywhere on the field when it starts
Me: With some limits, they can be anywhere on the field now, too. Fast robots could be on the other side of the rack in 5-10 seconds to abuse you. In 2006 when you only had to cross a field, you were getting purposely rammed by other robots almost immedietely.

Someone: But other robots might bump/ram us in their modes
Me: They do that now. In 2006 in particular, that was a widely-employed tactic in autonomous mode, with sometimes 2/3s of the robots playing a blocking or knocking role at high speed. Solution: don't drive quickly and build a robust robot with large bumpers.

Someone: The programming/sensing tools aren't there yet
Me: I feel confident saying that even now, the limiting factor in autonomous modes isn't the sensors, tools, and hardware, but rather the limited experience most HS students have programming robust code, which isn't going to improve given the 4 year churn inherent with a high school contest.