[Official 2007 Game Design] Autonomy And Other Technology Discussions

[Jherbie53]

If the field is as open as this years was, then during autonomous could there be a max Feet Per Second rule? The max FPS could be 8-10 FPS or something, but that all depends on the game and the field setup. I was watching web cast's of qualifying matches of Nationals and in three straight matches my teams robot was knocked over in autonomous. In the first two of those matches it looked like there should of been a high speed ramming called. Later, threw some communication with team members at Nationals, I found that anything goes in autonomous, even high speed ramming. I really haven't talked to anyone in person since before Nationals, so I might be interpreting it wrong and please correct me if I am. It's really hard for teams to stay encouraged when you tip over three straight matches.

[Lil' Lavery]

That sounds like it may be a center of gravity problem with the individual robot. Tipping/disabling/damage in autonomous was very limited from my expierience.
Also, I beleive there were still high speed ramming calls in auto (or there should have been), but there was a generic lack of them the whole season in both portions of the match.

[Donut]

I never saw a ramming penalty called once during any autonomous portion I saw of a match, but I also never saw any matches where I thought robots were moving fast enough to warrant it. As for a speed limit, I think that should only apply if you hit someone at that speed; there is no harm in charging at an opponent 20 ft/s if you slow down to 3 ft/s before you hit them.

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

[Lil' Lavery]

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.

Please, the topic of mentor vs. student lead teams has been beaten to death in multiple other threads, and this is just a small example of it. Each team is free to deal with programming how they so choose. The FIRST "big wigs" have made it clear every year that it is okay to be totally student led and it is also okay to be mentor driven, or anywhere in between.

[Steve Howland]

Two Ideas:
A)Multicolor lights:
Red, Blue, and possibly Green lights are randomly assigned at the beginning of autonomous. Suppose that there were 3 goals lined up and you had to use vision to determine your goal - otherwise you may score for the other team! The green could be either 0 or a lesser point value, or perhaps the green would always be in the same position so that teams that are unable to use the camera (due to weight/time/programmer experience) could still contribute to their alliance via dead reckoning or simply tracking the single color.

B)Reward for quick finish
Similar to Coopertition in that if your robot is able to complete the autonomous task quicker than another robot, possibly including a pressure pad to show that you have finished, then more points would be awarded. (Imagine points for placing a tetra on the center goal then returning to your home zone).

[Dave Scheck]

Originally Posted by Steve Howland

Suppose that there were 3 goals lined up and you had to use vision to determine your goal - otherwise you may score for the other team! The green could be either 0 or a lesser point value, or perhaps the green would always be in the same position so that teams that are unable to use the camera (due to weight/time/programmer experience) could still contribute to their alliance via dead reckoning or simply tracking the single color.

I like this idea because it has both a simple solution and a more complex one. To throw an additional twist in there...what if the red and blue goals switched after 8 seconds (assume 16 seconds of autonomous). This would force elegant solutions to not score for the other team. The only problem would be scoring...this year would've been tough because of the way that the balls had to be cleared from the goal by hand.

possibly including a pressure pad to show that you have finished, then more points would be awarded

I liike this too, but would need to be a stipulation of not getting the bonus unless the task was actually complete. Probably doable with a multiplier since not completing the task would result in 0 points.

[miketwalker]

Now, this requires some explanation... but it's purely a concept-based idea. I personally have been hoping for a manipulator-important multiplier/bonus for awhile. Some teams designed very interesting manipulators for the tetras, but it wasn't necessary. The concept below is based as an idea that could be used for a multiplier/bonus thing and/or a last-second finale (providing incentive for teams to have tall reaching manipulators that can also modify the scoring object). The main thing I would like to see though is a scoring object that can be manipulated in some form, where it can make a certain number of points without manipulation (to provide a simpler task for teams) or more points to create a manipulator to perform the higher-point task.


This example shows a square that has a hinge in the middle of it's top start. Teams would have to grab the object from a stand (similar to tetras) from the side of the field and then place them like those child-block toys into a goal hole on the wall. They can place it into the lower, non-manipulated hole for a lower bonus score or the higher goal in which the object must be pressed in to form a triangle to fit into the hole. Once you fill the hole though, you obviously can't put another one in. Thus, if a team is good at this they could technically fill both holes on their post for the low and high points. Retroreflective tape could assist robots in lining up the objects encouraging an automated method to do it. As for the material of the object, a number of things could be used, and I don't think it would be any harder for a team to assemble than a tetra.

Note: I wasn't sure which thread to put this in (sensors or scoring objects) because I think this would highly encourage sensors as well. I know this idea is pretty complex, but I'd love to see manipulated objects and this is just one idea to throw in the massive hat that becomes the GDC idea hat. Good luck GDC, can't wait to see what we get next year.

[Billfred]

I'm not sure if this one can be implemented cheaply enough to work in FRC, but after reading this thread, I was highly intrigued by some of the concepts in the video mentioned within.

Suppose that as part of the competition, teams could also (optionally) field a smaller, all-autonomous robot in addition to their regular robot. I imagine the robots being slightly bigger than an FVC robot in dimensions, and could possibly dip into the FRC kit motors if you were feeling frisky. (If you went this route, teams would still only have, say, two Fisher-Price motors for all of their combined robots.)

For example, imagine that a large supply of balls (or perhaps more valuable balls) was on the field in front of the player stations on each side of the field. A barrier to keep the FRC robots at bay would run across the full field, just at where the field gates are. Human players could introduce their team's autonomous robot into the blocked-off section to move the balls into their choice of position on the field. To keep with the safety mindset, robots would be required to have a two-second delay after being given instructions to start, to give human players time to push the button and get clear.

Hey, it could work, right?

[UCGL_Guy]

How about being able to find ferrous object hidden either underneath the carpet or hidden in boxes.
Keep the camera - maybe in a few more years we will be able to actually use it. We are getting closer.

[Andrew Blair]

Originally Posted by UCGL_Guy

How about being able to find ferrous object hidden either underneath the carpet or hidden in boxes.
Keep the camera - maybe in a few more years we will be able to actually use it. We are getting closer.

Thats a really good idea. Have scoring stands that have three doors on them. A release allows 1 object to be randomly placed between the three openings at a time. If you have an object detector, then you have ~ 100% chance of finding the object. However, if you don't, you may still obtain objects, but you have ~ a 30% chance of getting one.

I still thinks this puts a damper on the sheer volume of scoring we got to see this year though. That element of the game gave both drivers and spectators a treat, and I would love to see the next game include it as well.

[Zak698]

Originally Posted by dlavery

This thread is a spin-off of this discussion, and has been started to focus on suggestions for autonomous elements of the game, and other new technologies that could be introduced into the game or kit of parts. While autonomy need not be a part of a specific game, creative uses of autonomous components in any game are sought. For example, a discussion may be presented that proposes no dedicated autonomous time period during the game, but may require that a robot complete a certain function during the course of the game autonomously while other robots on the field are being controlled by their drivers. Alternately, ideas about new drive technologies (anyone know of a source for inexpensive CVTs?) or inter-robot communications may be reviewed.

-dave

Dave,
That is a grate idea! Our team and I have put a lot of thought into a better autonomous mode, much like what you are describing, using many sensors and other ways to input data and interrupt it, and also at the same time to ad void the action of other robots. I think this is a grate idea, the only problem would be for the rookie teams it a lot, but it would be a good challenge that requires lots of thought!

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