[Official 2007 Game Design] Autonomy And Other Technology Discussions

[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

[Freddy Schurr]

Change the way AUTO is play. For two years, we had to programmed our camera to find a green color/light. I personally don't like the camera/light use in autonomous or throughout the entire match. Lets see what other items can be use in Autonomous.

[=Martin=Taylor=]

As I see it, the whole concept behind robots is that they are meant to be labor saving devices. They are supposed to mow your lawn, serve you drinks, and clean your house. They are supposed to be largely autonomous and capable of simple thought.

Notice I didn't say anything about "remote control". After all, what good is your butler-bot if it needs someone to operate it .

I would like to see more autonomy in future FIRST games. Adding more autonomy would put more emphasis on the 'robot' part of the game.



Now of course the problem with adding more autonomy is that many rookie teams would not be able to compete. The solution to this is to give bonus points for scoring autonomously.

An appealing idea to me is to have a special "No-Man's-Land" in the middle of the playing field. When robots enter this zone the remote control is immediately turned off and robots must score autonomously. Teams unable to score autonomously could score in other non-autonomous portions of the field.

[Ryan Foley]

My thoughts on autonomous:
1) keep it at the beginning, as to allow for the "big finish" ending
2) don't let it become the main focus, incorperating the driver mode is what seperates FIRST from most other robot competitions
3) allow teams to continue using automous behavior during driver mode
example: this year, some teams used the CMU cam to track the target the whole match, so the drivers wouldnt have to aim the bot.
example 2: in 2001, some teams used the gyro to automatically balance on the teeter totter
4) allow for multiple options, not just the CMUcam so teams can choose which technology to use in autonomous instead of only having one option
a) bring back IR (multiple beacons, so teams can use it to determine position)
b) bring back line following

[Conor Ryan]

Once in awhile when I'm bored in the offseason, I find a battle-bot type TV show to watch, hey it's not FRC, but it fixes my robot crave. The type of robots on that show that always get my attention are the smaller robots that come out of a "Mothership" if we could ever have a game/technology that would allow for that to happen it'd make for a very intresting season no matter what type of task you threw at us. Drive teams would need to be expanded so more and more people can get involved with the operation of the robot instead of the traditional 4 man drive team (Possibly would help for a lot more of students getting involved, even in smaller schools).

The biggest obstical in trying that out would be in getting the technology in the KOP that would allow for it. If that ever happened, it'd be a fantastic season, maybe Vex Equipment could be used for the Daughter bots, only the GDC would know the answer to that question.

[Katie Reynolds]

Originally Posted by Hachiban VIII

Now of course the problem with adding more autonomy is that many rookie teams would not be able to compete. The solution to this is to give bonus points for scoring autonomously.

Not just rookie teams - we're going into our fifth year and haven't been able to do much with autonomy, at least not consistantly. I like the way autonomous was this year - keep it short, in the beginning and reward the teams who can do it.

[Jherbie53]

How about an area of the field thats autonomous only. It could be an extension of the field, if there is room for it at the regionals. It could start at one end of the field and have obstacles in it. Some obstacles could be ramps, speed bumps, going under something, moving something out of your way, or grabbing an object and scoring in along the way. You would enter the starting area and hit a button or switch that starts autonomous. If you finish it without having to take over with human driving to get unstuck, you would get bonus points. Strategy could come into play with another team trying to block from starting at the other end of this "mini" course.

[Kyle Love]

I think the overall automode points need to stay in control and not make an alliance lose a match because a team can go out and score 70 points in auton. It would be nice to see it like a 2004 automode but with the camera with red, green and blue lights, ofcourse.

[Andrew Blair]

The beautiful thing about autonomous this year, and in years prior, is that you didn't *have* to use the camera, or other sensor if you didn't want to or didn't have the resources.
You could always dead-reckon it if you had to, and I think that needs to stay. I love the advanced sytem autonomous points, but we should keep an easy couple of points in there for the rest of the teams.

[skimoose]

The main problem I see with Auton is the lack of true plug and play sensors and software. This years KOP sensor pack is a great start. What it needs now is simple bolt-on software routines. After all, we want students, not professionals, programming. Our team doesn't have a dedicated software mentor, so it becomes very difficult to get the students working on their own while we're busying with other tasks. EasyC might be the answer, but we didn't have time to investigate it this year.

I think a more useful software option for MPLabs would be more thoroughly commented form of bolt-in software routines, not entire work spaces. Kevin's code was good this year, but the students had trouble integrating his camera code with some of his sensor code by themselves. Any software and sensors should be presented in such a way that students can pick them up and start using them with very little guidance, including students with limited programming experience. Most commercial software packages, like AutoCad, Inventor, Word, etc, have GUI interfaces which make them much more intuitive for novice users.

The mechanical side of the game has become fairly balanced, now its time to start to balance the programming side. Without some improvements here, Auton will continue to be an unbalanced part of the game, not just for rookie teams, but for teams without a lot of programming help, too.

[Phalanx]

I believe autonomous should be lengthened a little with more options and opportunities than a single task or two. Allow for multiple different challenges some harder than others, requiring the use of different sensors or combinations of different sensors to meet the challenge.

This way teams that don't yet posse they knowledge and skills for the more complex tasks have a chance to learn those skills and succeed through the simpler ones.

This program in my opinion is designed to enhance and challenge the students. Not everything should be made easy, simple or plug n play. It's the learning, the challenge, the knowledge gain and the creativity that comes from it that is important.

[dlavery]

Originally Posted by skimoose

After all, we want students, not professionals, programming.

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)

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