[Official 2007 Game Design] Autonomy And Other Technology Discussions

[skimoose]

Originally Posted by dlavery

Uhhh, says who?

I am poking at this one intentionally to see if people have really thought through the implications of limiting the construction of the robot to just students, or engineers, or both, and what that really means in terms of the technologies that can be introduced into the game/KitOfParts. I will attempt to keep this discussion on topic by pointing out that based on who you think will be building the robot, the technologies most needed/interesting/challenging will be different.

Put yourself in the position of the people on your team that build your robot, and ask yourself "what technologies can they handle?" Then try and take the viewpoint of a team that does it exactly the opposite way from your team, and ask the same question. What would be most helpful to either group? What capabilities did you really wish you had last year? What technologies would be particularly challenging (and I note that "challenging" is often a very good thing)?

-dave

(by the way, FIRST has been quite clear about the role of engineers and mentors in the development of the robot - read the transcripts of some of Dean's speeches at the early kick-off meetings)

Don't get me wrong Dave. If mentors didn't get directly involved with building the robot, there wouldn't be nearly as many engineers volunteering to help teams. We have fun building too, and I'm all for being challenged. That's what keeps me coming back each year. I just like to see the students do as much as they possibly can, and then push them for just a little more.

You made a valid point. Teams with a high level of technological resources will certainly want or need different items in the KOP, than teams with a lower level of technological resources. My point was that there has been a lot of effort on the mechanical side to make rookie teams, or teams with low machining capabilities, competitive. Some of that needs to translate to the software/sensor side. I would rather see teams have the choice of grabbing a KOP sensor package, using a KOTS sensor, or custom solution. Each choice has its pros and cons, and each can get the job done. It just becomes another FIRST lesson in allocating limited resources. We used the KOP transmissions last year, but we chose to go with semi-custom trannys this year, but it was our choice to make, thanks to FIRST .

Now if you'll excuse me, I've got a Vex robot and some KOP sensors to play with!

[Donut]

As has already been suggested, I would like to see the return of multiple autonomous tracking methods. To keep from having too many tracking things for a single target, there could be "easier" tracking objects for less points and "harder" tracking objects for more points (for example, a line to follow only leads to a 1 point goal, while a light to track leads to a 2 point goal).

If an autonomous bonus is awarded again next year, it should be cut down some (probably 5 points instead), especially if there is a tactical advantage like this year. The 10 point bonus could often be overcome in the playoff type matches, but in matches where teams were struggling to end the score 17-12 the one alliance who got lucky and happened to get one ball in the corner goal pretty much instantly won.

I actually thought the software support was far above anything in the past this year, and more than enough for our team at least (we were lucky enough to have 2 programming mentors and a 7 man programming team though). The only thing that could be made better for next year is to have a sensor version of the default code which contains all of the sensor code written by Kevin in one project where they are already integrated to work together. Having done all of the combining of projects and files for our team, I know that teams with only one or two programmers would have a heck of a time trying to get all that sensor code to work in one project.

I do love the support we get though. Nothing beats being able to change the camera search parameters, especially when a year ago we were using default search patterns that we had trouble understanding what it was doing.

[Tetraman]

I like the idea of a section of the field that is Auto-mode only. With the exception of putting your robot out of auto-mode for a small penalty, because if the robot goes off the track it should, it might not come back without manual control.

[ptrautwein]

I agree that this autonomous mode is the thing that separates authentic programming with RC robots. I would like to see more autonomous time maybe up to 20 or 25 seconds.

I have now started my second team and to see a new set of Rookies reminds me of the basic programming struggles. Three things that we need to remember and help Rookies and young teams are these:

Rookie teams have a lot of reading to do and need to be pointed toward good information and given directions and how it can be applied. The code should have a lot of obvious and descriptive notes embedded into it.

Rookie teams need to see old code, with explanations of how and why it worked and what it did. These could be codes shared by teams with details and pictures of their robot. Gracious Professionalism should weigh more than secrecy of code.

Rookie Kits should get a Dongle. Yes it is simple to make, but Rookies are too busy catching up that they don't realize how important it is to be able to practice that autonomous code, and how to do it at home safely.

We don't need to give all the answers but we do need to provide Rookies and young teams with the resources that allow them to know what questions to ask.

[Kristian Calhoun]

Originally Posted by ptrautwein

I agree that this autonomous mode is the thing that separates authentic programming with RC robots. I would like to see more autonomous time maybe up to 20 or 25 seconds.

Rookie Kits should get a Dongle. Yes it is simple to make, but Rookies are too busy catching up that they don't realize how important it is to be able to practice that autonomous code, and how to do it at home safely.

First off, welcome to ChiefDelphi!

Moving on though, I agree with you in that the autonomous mode should be something meaningful. Also, a longer autonomous mode would be awesome, however, it all depends on the type of challenge that is being presented during the autonomous period.

I remember that at some of the 2005 off-season events which I attended, rarely any teams (if at all) used the ENTIRE 15 seconds of autonomous (usually it was only 10 seconds at max). And at kickoff this past year, when they announced that there whould be only a 10 second auto. mode in which the winning alliance won a ten point bonus AND was able to go into their defensive period first, many of us thought that 10 seconds was too short. But everyone took up the challenge, and it turned out to be a very viable time frame in which to either play defense, or drive towards the the goal, shoot and score. A large amount of teams created successful autonomous modes, and the autonomous period in Aim High turned out to be one of the most exciting (and crucial) periods of play.

So if there should be a 20-25 second auton. period, I believe that that task at hand should probably be more complex and take a longer time to complete.

I also agree with your idea to put a dongle into Rookie kits (or all kits if they want) because even though they are pretty easy to make, as you mentioned, many teams do not make them. I cannot tell you how many teams asked to borrow our dongle at the LV regional this year. But it would be a nice addition, and hopefully encourage more rookie teams who might not normally program their robot autonomously to do so.

[=Martin=Taylor=]

Give a wieight bonus (30%?) to teams that build a "true" walker.

This means that robots that walk, without the use of rotating cams or wheels (that touch the floor), can wiegh a total of 156 lbs.

This would be a cool rule because it would encourage innovation in the drive train, which for many teams has gone virtualy unchanged since the creation of FIRST.

It would also spawn a wide range of unique designs never before seen or imagined.

[lukevanoort]

^ I really like this idea, but I'd be worried that the walking system would eat up that additional 30% and much more, without much of a benefit. So, there wouldn't be much of a motivation. Maybe a game too that gave walkers an advantage along with it would work nicely.

[Peter Matteson]

I would like to see two to three completely different possible scoring methods for auton.

One that any team can easily do with dead reckoning. This would be the low hanging fruit that any team should be able toreach and worth the least points.

One that requires a level of sensor feedback to accomplish worth a moderate amount of points. This should be attainable with software out of the box so that teams who put the effort in can accomplish this.

The third should be a pie in the sky real challenge that has a corresponding bonus to make it worth the effort for the teams to do this.

I know that first has tried to do some of this over the last few years but I like the idea of challenging the veterans but still keeping things accessible to the rookies and mid-level teams. This tiered objective system would allow teams to work towards a goal if they saw it recur over a few years. Also you could illuminate each with a different color vision target like we saw on Einstien this year.

[Dave Scheck]

Adding on to what Pete brought up...what if there were 3 seperate start times? Maybe give the hard task 20 seconds to work with, the middle 10 seconds, and the easy 5 seconds? You could even penalize for interacting with the other scoring opportunities before your task is complete.

[Donut]

Originally Posted by Dave Scheck

Adding on to what Pete brought up...what if there were 3 seperate start times? Maybe give the hard task 20 seconds to work with, the middle 10 seconds, and the easy 5 seconds? You could even penalize for interacting with the other scoring opportunities before your task is complete.

Why not do it in reverse, and force the teams going after the harder task to do it in less time? Sounds like a better challenge to me.

I think FIRST has hit a good point with autonomous this year; namely that it matters in the game. Autonomous could help you get a few extra points the past few years, but truthfully 90%+ of all matches were completely unaffected by what happened in autonomous mode. Games have gone from "oh, we don't need to worry about autonomous, we won't be down by more than 3 points" to "we need someone to try to block them or we'll be starting down 15 points and they'll get to start on defense". Autonomous may have actually had too large a bonus attached to it this year, but I think it's much easier to lower the bonus a little than to continue trying to increase the importance of it and hoping it will finally affect the outcome of the game.

Autonomous is forcing teams to look at even more of an all around robot; you need good drivers, a well built robot, good programming, and some good alliance partners to win.

[Dave Scheck]

Originally Posted by Donut

Why not do it in reverse, and force the teams going after the harder task to do it in less time? Sounds like a better challenge to me.

I disagree...Let's apply some examples of a staggered start system to Triple Play.

I would make the easy task scoring the hanging tetra (either knocking it down or placing it on top). This is a relatively easy task that doesn't need a whole lot of time to accomplish. Look back to when the game was played, and you'll remember that there was quite a bit of downtime after teams hit the hanging tetra.

I would make the medium task be pick up off the autoloader (1 or 2) and score on the side goal. This is more complex than the previous task, but it can be done without fany vision/sonar/etc... systems. Everything you're trying to accomplish is at known positions on the field.

I would make the hard task to score the randomly placed vision tetra on the center goal. This would require some form of sensory system to seek out the vision tetra. Once it collects the tetra, the robot is in a semi-known position. The goal is in a known absolute position, but that would have to be combined with the current position, to determine where to drive next. This makes it more complex.

I would allot 20 second to the hard, 15 seconds to the medium and 5 (maybe 10) seconds to the easy. I think this cuts down on the amount of downtime in the match. Maybe you could go so far as to skip the first 5 seconds if nobody's attempting the hard task.

If you flip that around, you would have a robot that was halfway to picking up the vision tetra at the end of autonomous, and a robot that knocked the hanging tetra down and sat there for 15 seconds. I definitely think that the harder skill would need to be allocated more time.

I think FIRST has hit a good point with autonomous this year; namely that it matters in the game.

I definitely agree with this. Not only that, but large movement was required to accomplish the task, keeping things interesting. Triple Play's hanging tetras required such little movement to accomplish that sometimes you couldn't even tell that the robots even moved.

[Donut]

I don't think downtime is going to really be removed by that; sure some robots will start later, but you still have 15 or 20 seconds for the whole autonomous to run (and forcing teams to announce what they will be doing before autonomous will give away their goal, not something I want my opponent to know for their defensive autonomous).

If you keep them the same time then the difficult tasks are more difficult because it's more to do in the same time; by increasing the time for harder tasks you remove a large part of the difficulty from them (time is usually the biggest problem in autonomous mode).

[Dave Scheck]

Originally Posted by Donut

...and forcing teams to announce what they will be doing before autonomous will give away their goal, not something I want my opponent to know for their defensive autonomous.

Who said there was defense? The only reason that defense was so prominent this year is because the field was wide open and it was possible to have robot interaction. 2005 didn't have defense because robots couldn't interact (with maybe the exception of somebody blocking a middle row goal). 2004 didn't have defense because the task at hand was inherently offensive. 2003 was the same way...the only real way to defend other than to drive under the bar or chase stacks was to get to the stack first.

If you keep them the same time then the difficult tasks are more difficult because it's more to do in the same time; by increasing the time for harder tasks you remove a large part of the difficulty from them (time is usually the biggest problem in autonomous mode).

I agree that time is usually the problem, but why not allot just enough time for teams to actually succeed at the task at hand? In 2005, if there were another 2 or 3 seconds, I think that there would have been some center goal capping. I would much rather watch a game where teams are successful at doing something autonomously than watching a game where they almost get it done.

[Matt H.]

Originally Posted by skimoose

Don't get me wrong Dave. If mentors didn't get directly involved with building the robot, there wouldn't be nearly as many engineers volunteering to help teams. We have fun building too, and I'm all for being challenged. That's what keeps me coming back each year. I just like to see the students do as much as they possibly can, and then push them for just a little more.

Originally Posted by Mike Shaul

I think that limiting it only to students could hurt FIRST. Some teams have different resources. Some schools don't have any programing classes or students interested in programing.

Both of these statements worry me. I see not having students interested in programming as a challenge to overcome, not a challenge to circumvent. As a student programmer I find the idea of a mentor doing the programming sickening. I'm decent at programing and I've put much time and effort into doing the best I can. However, I've done this under the assumption that I would be competing with other students not mentors. I believed that my skills would be put to the test based on the skills of other teams not their mentors. This is my first year of FIRST, but I have already put in large amounts of off season time towards the programming side of things. I would hope that my efforts are not in vain because I am competing with adults.

To return to topic I feel that auto should be both longer and more competitive. This year I felt it was simply a matter of unloading ten balls with the greatest accuracy possible and perhaps a small amount of movement. That was all ten seconds allowed. I would like to see 40 seconds or more of auto mode just to incorporate wider aspects of programming. For example a team after unloading its ten balls might have went into a roving pattern to pick up more balls or returned to reloading distance of its team. As a programmer it saddens me to see auto taking up only a small portion of the game.

[lukevanoort]

Originally Posted by Matt H.

Both of these statements worry me. I see not having students interested in programming as a challenge to overcome, not a challenge to circumvent. As a student programmer I find the idea of a mentor doing the programming sickening. I'm decent at programing and I've put much time and effort into doing the best I can. However, I've done this under the assumption that I would be competing with other students not mentors. I believed that my skills would be put to the test based on the skills of other teams not their mentors. This is my first year of FIRST, but I have already put in large amounts of off season time towards the programming side of things. I would hope that my efforts are not in vain because I am competing with adults.

Don't worry about it. Since '04 our robot has been programmed by a professional software engineer, we've never had anything impressive, and it was an uphill battle to get any code changes. Remember, adults are also often busy, reducing the time they can program. He would often say something to the tune of "We don't need that" when a new bit of code was requested. And it was full of errors, plus his code had no comments. It was still useful that he did it, which freed students to try and finish building the robot on time, but his code easn't superior in any way, shape, or form to the other robots this year, most of whom, I assume, were student programmed.

As for autonomy, I would like to see three wildly different starting areas to make teams come up with either a brilliant all-purpose autonomous, or multiple ones.