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.
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.
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 :yikes:.
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.
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
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
In Triple Play, you could use dead reckoning to get the hanging tetra and/or use the one tetra the alliance was given to cap a goal. Yes, getting the vision tetra involved, well, vision.
The problem with auton in Triple Play was that the rewards were not enough. 26 points were theoretically possible - drop both hanging tetras, get the vision tetra on the goal in the middle of the field, and cap the center home-row goal to generate a row. But how many vision tetra cappings were there all season? In reality, your alliance was doing good to get 5 points in auton, a rather insignificant number in the whole game.
Aim High had a very meaningful auton reward - not only the 10 point bonus, but playing defense first. Winning auton put you in a very good position to win the match. Maybe the pendulum swung too far this year, but it certainly made auton an important feature in the game. And there were multiple things to do - high goal via either camera or dead reckoning, low goal, play defense.
We need an autonomous mode with real rewards for the teams that master it. There also has to be something for those with lesser programming skills to do. IMO, this year’s game provided more of those kinds of options than Triple Play did. Hopefully future games will continue the trend.
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.
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.
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. Our team has a limited interest in programing (most people want to build, its more exciting than sitting at the computer) but we use the opportunity to teach the interested students about the basics of programing, why its important, etc. Our students do write code for the robot but autonomous would be difficult without engineer involvement. Not to mention, it gives the engineers an opportunity to show why they went to college, what they have learned and how it applies to our jobs.
I just like to see the students do as much as they possibly can, and then push them for just a little more.