Autonomous Longer????

[cziggy343]

i wouldn't b in support of it. i say that because from what i have seen, only a small percentage of people take advantage of the autonomous mode. adding a couple of seconds would only add time to the "staring competition" that takes place at the begining of most of the matches.

[Not2B]

I guess I don't understand why more teams don't do... SOMETHING in auto mode.

No one said you had to try and score.

If you have a arm all folded up, why don't more people just unfold the arm and get ready for human play. Or move forward onto the field. Maybe you don't have the time to perfect a camera based auto mode - but it's not as hard to "get ready" for game play.

Maybe alot of teams never really thought about it...

hmmm....... I never really thought about it before now.......

[Bongle]

Originally Posted by Not2B

If you have a arm all folded up, why don't more people just unfold the arm and get ready for human play. Or move forward onto the field. Maybe you don't have the time to perfect a camera based auto mode - but it's not as hard to "get ready" for game play.

Why not arm unfolding? Because you can do that in the time it takes your human player to run forward and toss the first ringer

Why not move forward? Risk of ringer-ing yourself or an alliance member ringer-ing you on the first toss. You're safer in the 'shadow' of the driver wall.

Why not move across the field and prepare to defend? I saw a few teams get tangled on the rack trying this. In order to avoid entangling yourself, you need the gyros and accelerometers as well as the programming skill to use them, which is nearly as hard as the camera.

I agree it is the skill of the programmer, but also it is the skill of hardware team. We have a very successful auto because we got the robot over a week before shipping date. They set goals to finish early and kept to it. so we had time to work on this hard autonomous game.

Totally agree with this. You CANNOT make an effective autonomous mode from scratch at the competition, unless you have a godlike hardware team. At the competition, there will always be repairs to be done, bolts to be tightened, kajiggers to be lubed and polished. The programming team only gets robot access when all those things are done, which is never. You need substantial alone time with the robot during the build period in order to develop and test autonomous mode, which requires a fast hardware team.

[PhilBot]

Originally Posted by Bongle

The programming team only gets robot access when all those things are done, which is never. You need substantial alone time with the robot during the build period in order to develop and test autonomous mode, which requires a fast hardware team.

As an embedded computing veteran, I can assure you that what you've described happens a LOT in the real world too, and it's often the downfall of any new system. Software is always placed at the end if the "critical path" for robot designs, mainly because programmers are not pro-active enough during the initial design stages. They often let themselves be back-burnered because they like working in isolation.

Unfortunately, these days you can't say "hey, we really don't need autonomous mode" because it's going to be more and more critical to future "real-world" robots.

So it's important that guys like me, teach young programmers the importance of being an active part of the design process, establishing software requirements early, and learning how to be an asset during the build so they get the required "face time" with the robot.

I've learned that if the programmers allows themselves to be put off till the end of the build, the overall team will suffer (and I'm not just talking FRC here). It happens all the time in industry.

So, I beleive that Autonomous doesn't need to be longer, it just needs to be more integral with the game (like in Aim High). The whole team needs to see the benefit to a good auto mode so that the programmers get to be involved in the design process early. It shouldn't be so easy for the mechanical guys to say "we don't need auto, we can push any robot".

If each aspect is seen as important (mech, elec, software) the design groups will learn better habits for the real world.

Phil.

[nuggetsyl]

I think 15 sec auto is long enough. I would like to see auto in the last 15 secs instead of the first 15.

[Dan Richardson]

This years autonomous mode is quite the challenge, It takes a solid mechanical bot and a extraordinary programming team. I'm not under the impression however that an additional 5 seconds will do anything to help out the process. There are very few teams that are " Just Missing " consistently, don't get me wrong they are out there.. but there aren't too many. If you add 5 seconds there are still gonna be those just misses.

With the extra 5 seconds I believe all you are going to be adding is an additional 5 seconds of announcers making things up to say. The task was difficult this year and the problem is, unlike last year, there is no simple task to complete. If you could not find the target last year you could just do guess work, point your bot at the target and shoot. If you were a low ball scorer it was even better. Just a drive straight code for 5 seconds and release your balls.

I believe we really just need more effective preparation for the season. Teams need to have in their repertoire built and tested code for each one of the sensor packages, so that what ever may be the most important for that particular year and your particular robot. A programming team needs as much time if not more than a mechanical team. Robotics is a programming intensive field, and thats hard to say for a Mechanical Engineer in training who has a desire to go into a Robotics Field. The beauty of it is that you can bench test most of these sensors without even needing the huge robot. You can get your team to use vex, or the practice bot or even just a piece of cardboard with wheels and a motor attached to the cpu and your able to build the code. After 5 weeks playing with vex robots, the mechanical team handed our programmers the bot and in just about 2 day ( 1 day of calibrating sensors, and 1 day of actual programing ) they had the bot running autonomous.

I know its hard for this to happen, and it seems like mostly only larger teams who are even able to cap in autonomous effectively, the same argument is always made from the Mechanical End " Well they build at GM, or they build at NASA, of they have 1231232 CNC Machines. " But programming is the area where the mediocre robot can make up in their competitiveness. I know I know, this years autonomous may be not worth as much or some people think its " too short " but what about autonomous sub routines, or ease of driver use by pre-programmed positions, all of these things are extraordinary successes from a programming point of view.

So in conclusion I don't believe autonomous needs to be longer, If your drive team can cap a tube that it starts with in under 15 seconds, your robot should autonomously be able to as well. In fact I'm of the impression and will make the argument that your robot should quite possibly even do it faster/more efficiently than your drive team. Hehe I know this would rarely happen but I'd love to see this competition get to that point. If your robot can't cap under 15 seconds well than, maybe in your case 5 extra seconds is a valid argument from a purely programming point of view. Otherwise, work on it and develop it, just because it may not happen during the season, that does not mean its not a success. Success, at least within the realm of this competition, comes when you complete the challenge, and if you can learn to complete a challenge as hard as this one, I guarantee you'll be able to complete nearly anything thrown your way throughout your academic and your professional career.

[meatmanek]

Originally Posted by Bongle

Why not arm unfolding? Because you can do that in the time it takes your human player to run forward and toss the first ringer

Why not move forward? Risk of ringer-ing yourself or an alliance member ringer-ing you on the first toss. You're safer in the 'shadow' of the driver wall.

Why not move across the field and prepare to defend? I saw a few teams get tangled on the rack trying this. In order to avoid entangling yourself, you need the gyros and accelerometers as well as the programming skill to use them, which is nearly as hard as the camera.

Totally agree with this. You CANNOT make an effective autonomous mode from scratch at the competition, unless you have a godlike hardware team. At the competition, there will always be repairs to be done, bolts to be tightened, kajiggers to be lubed and polished. The programming team only gets robot access when all those things are done, which is never. You need substantial alone time with the robot during the build period in order to develop and test autonomous mode, which requires a fast hardware team.

If you put sensors on your arm like you _REALLY SHOULD_, and have the PID code already tuned for it, unfolding your arm is not difficult. We only had to write 2 extra lines of code to set up our arm.

Even if you have a godlike hardware team (or really good luck, in our case) and your robot is working properly and doesn't require any hardware adjustments between matches, it's very difficult to write a proper autonomous mode. We abstained from making an autonomous mode simply because our robot was working well enough that we didn't want to make any changes at all.

I agree with a lot of the people on this thread - autonomous mode isn't worth nearly as much as it could be. Yes, it could mean a lot of points, but it's one tube. Even the spoiler factor isn't worth all that much. In a row of 7, if the keeper is placed in the center, if you spoil one spot off center, that row is still dropped to 20. We focused on improving our teleoperated mode code enough that it would help us score at least one more tube. It worked.

[Tom Line]

I would support Autonomous being longer if there was actually something more to do.

As it is, 15 seconds is more than long enough to score on the front light or either side light. Since picking up another ringer is all but impossible in auton, we've got all the time to do what they expected us to do.

We even wrote in a part of the routine that backs the robot up so that a tube can get thrown in front of it - but that got too dangerous because if one lands on your flag you're stuck.

In the end, auton this year stinks. It isn't valuable enough to be worth it (even though we did it). I wish it was worth more, because it sure seems that in the world of robotics, auton is the part you should be focused on.

Perhaps this year they should hold an "auton olympics" where the robots that can do auton do it and are scored. Perhaps a seperate award for it as well. I'm a little stunned that "best auton mode operation" isn't an award already.

[Cooley744]

ummmm. a short auto is good, cuz that's what makes it bonus. short time period and takes a lot of time to get make it and get it right, but if you do...ur amazing lol.

[efoote868]

I wholeheartedly welcome it. This year I'm leading programming/electronics, and this is the second year in a row in which we have more than 4 programmers. This means that we can effectively give people specific tasks.

This year, the programmers will also be given their own drive base. This will allow us to test and tweak a huge amount more, instead of the typical 3 days from ship, "Get it done!".

With easyC becoming a viable option for many new teams, I don't think a longer autonomous with better goals, more points, etc. will tip the teams more, in fact, it'll make it more equal. I don't know, lets wait and see what FIRST churns out.

[Laaba 80]

Originally Posted by efoote868

With easyC becoming a viable option for many new teams

Have you used EasyC on an FRC bot? I tried it on a VEX bot, and i wasnt very impressed with the things it could do. I didn't spend a whole lot of time looking at it though, so I may have missed something.

[TheOtherGuy]

Originally Posted by Laaba 80

Have you used EasyC on an FRC bot? I tried it on a VEX bot, and i wasnt very impressed with the things it could do. I didn't spend a whole lot of time looking at it though, so I may have missed something.

EasyC is mostly advantageous when it comes to sensors and simplicity. The way the program handles the routines is hidden from the user and you therefore only have to worry about what you want to do in the program and not how the heck to do it. (take the camera for example. We didn't have an autonomous mode during the FRC season because we just couldn't get the camera to work right in MPLab. Once I got a hold of EasyC Pro, it was within an hour that I got that camera tracking spot-on!)

[bear24rw]

Originally Posted by TheOtherGuy

you therefore only have to worry about what you want to do in the program and not how the heck to do it.

I still hate the fact that you don't know how it's doing it.. i like to be in complete control of the code were writing and the hidden routines kinda bug me