Autonomous end game

[Brandon Holley]

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

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.

I love the idea, but I think we need to see a consistent attempt at autonmous modes from a lot more teams before we'll see the auto mode at the end.

[robostangs548]

It sounds like a good idea maybe in a few years, but for now, I think that there needs to be some more development in the programming field, and the programming technology. Look at the difference from 2001 to 2007 and how much more advanced not only the robot controller is, but also the sensors and cameras. These things have become more affordable, and I think by 2009 the programming technology will be advanced enough to complete that task. 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 definitely think that this would need some development, but I can definitely see this happening in years to come, just not now.... (Please not now!)

[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.

[Richard Wallace]

I'd like to see matches begin and end with autonomous operation. That would motivate teams to think. Thinking is good.

[dtengineering]

I say lets give the most dramatic moments of the competition over to the programmers. I am confident that the GDC can develop a game that addresses much of the concern listed here... however there are ways of adding to the importance of sensors and programming other than just changing the auto mode.

For instance consider a game where you are trying to put objects into four different goals. At various times in the game an IR beacon would turn on over top of one of the goals, thus doubling the value of any balls deposited during that period. Drivers would not be able to tell which goal was being doubled and when unless the robot told them. Or perhaps the goals only open at certain times and the IR beacon goes on 10-15 seconds ahead of the goal opening so that robots that sense IR can get lined up to score... or defend... first.

Or perhaps a game that involves a great number of very small game pieces.... coloured golf balls for instance... that need to be sorted in order to receive maximum bonus points. There would be so many pieces that there would be no way the drivers could sort them fast enough, so it would have to be done autonomously on-board the robot in order to have a dominant machine.

If there is sufficient incentive to develop a good auto mode, then teams will allocate their resources to making it happen. I know this year had we decided to focus on auto we could have easily dropped mecanum drive for a repeat of our quite successful 6wd platform from last year and gained at least a week of build time for programming and testing auto, rather than drive code.

The last big change to the game format was going from two to three robots. I think it is time for another change... or changes (how about a slightly larger playing field) to shake things up a bit.

Jason

[ericand]

Originally Posted by dtengineering

I say lets give the most dramatic moments of the competition over to the programmers. I am confident that the GDC can develop a game that addresses much of the concern listed here... however there are ways of adding to the importance of sensors and programming other than just changing the auto mode.

For instance consider a game where you are trying to put objects into four different goals. At various times in the game an IR beacon would turn on over top of one of the goals, thus doubling the value of any balls deposited during that period. Drivers would not be able to tell which goal was being doubled and when unless the robot told them. Or perhaps the goals only open at certain times and the IR beacon goes on 10-15 seconds ahead of the goal opening so that robots that sense IR can get lined up to score... or defend... first.

Or perhaps a game that involves a great number of very small game pieces.... coloured golf balls for instance... that need to be sorted in order to receive maximum bonus points. There would be so many pieces that there would be no way the drivers could sort them fast enough, so it would have to be done autonomously on-board the robot in order to have a dominant machine.

If there is sufficient incentive to develop a good auto mode, then teams will allocate their resources to making it happen. I know this year had we decided to focus on auto we could have easily dropped mecanum drive for a repeat of our quite successful 6wd platform from last year and gained at least a week of build time for programming and testing auto, rather than drive code.

The last big change to the game format was going from two to three robots. I think it is time for another change... or changes (how about a slightly larger playing field) to shake things up a bit.

Jason

I think automatic functions (i.e. internal ball sorting) is a great thing to encourage. For game change though, I think changing the starting conditions could be interesting. Have the game be 3 on 3, but have one member of each alliance start at the far end.

[Ericgehrken]

This year you could have no autonomous mode and still win the match because there was so little you could do. If the autonomous mode was at the end of the game more of an emphasis would be placed on it and it would make the game far more interesting for this reason.

[ericand]

I think auto at the end would be great, but I think you would need something like the endzone rules we had this year to give teams a chance to setup to perform the auto task.

To answer the question about various levels of skill in auto-mode programming, I would like to see multiple options (like the start of the tetra game 2 years ago). Alternatively, an autonomous task could be created that would allow a capable robot assist an incapable robot (an example could be having a good auto mode robot could tow a non auto mode robot home to an end zone).