Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   General Forum (http://www.chiefdelphi.com/forums/forumdisplay.php?f=16)
-   -   Should We Program Autonomous For the Y? (http://www.chiefdelphi.com/forums/showthread.php?t=93427)

davidalln 13-03-2011 22:31

Re: Should We Program Autonomous For the Y?
 
Quote:

Originally Posted by davidthefat (Post 1038766)
The ideal autonomy should use cameras, I plan on using a camera, the photosensors and possibly the encoders.

DO NOT USE A CAMERA!

You're over-complicating the problem. Especially if you're going straight, your drivers should be able to line up the robot relatively straight. You can use line sensors to make slight adjustments (if you're going straight; if you go Y you're going to need to take in effect the sharp turn left or right, but that isn't too difficult a problem), or use a gyro or encoders of any combination of the three. Remember, the ubertube has the biggest hole of all the tubes, and thus is the most forgiving for error.

Like Alan said, our job as programmers for autonomous is to score. As cool as it would be, don't let pride interfere with missing an opportunity to put up big points. There's always time in the offseason for playtime, now is your time to do well for your team.

davidthefat 13-03-2011 22:41

Re: Should We Program Autonomous For the Y?
 
Quote:

Originally Posted by davidalln (Post 1038922)
DO NOT USE A CAMERA!

You're over-complicating the problem. Especially if you're going straight, your drivers should be able to line up the robot relatively straight. You can use line sensors to make slight adjustments (if you're going straight; if you go Y you're going to need to take in effect the sharp turn left or right, but that isn't too difficult a problem), or use a gyro or encoders of any combination of the three. Remember, the ubertube has the biggest hole of all the tubes, and thus is the most forgiving for error.

Like Alan said, our job as programmers for autonomous is to score. As cool as it would be, don't let pride interfere with missing an opportunity to put up big points. There's always time in the offseason for playtime, now is your time to do well for your team.

Now, you do have a good point. The sake of the team > my personal challenges. Then autonomy would be very easy IMHO. It would be a lot of trial an error to find the right constants

Andrew Lawrence 13-03-2011 22:58

Re: Should We Program Autonomous For the Y?
 
Our team is going to go on the Y and on the straight, but we can only go on the outer peg (not the highest). Of what I've seen, this is a lot more than most teams are doing. Most teams are only doing the straights. Now, this doesn't mean that there won't be teams doing the highest peg, or all three, but like I said, of what I've seen, most teams will attempt to do the straights. This year is a tough one for autonomous (tougher than the other years).

mwtidd 13-03-2011 23:00

Re: Should We Program Autonomous For the Y?
 
Quote:

Originally Posted by davidalln (Post 1038922)
DO NOT USE A CAMERA!

You're over-complicating the problem. Especially if you're going straight, your drivers should be able to line up the robot relatively straight. You can use line sensors to make slight adjustments (if you're going straight; if you go Y you're going to need to take in effect the sharp turn left or right, but that isn't too difficult a problem), or use a gyro or encoders of any combination of the three. Remember, the ubertube has the biggest hole of all the tubes, and thus is the most forgiving for error.

Like Alan said, our job as programmers for autonomous is to score. As cool as it would be, don't let pride interfere with missing an opportunity to put up big points. There's always time in the offseason for playtime, now is your time to do well for your team.

From watching the matches, it seems as though many drivers have a tough time lining up just right. This is something that is very easy for the camera to do, the camera is awesome for centering the peg, and a rangefinder is awesome for knowing the distance to the goal.

So yes, if you only plan on using an autocap type function for the first 15 seconds, don't use the camera. But if you want to create reusable code which will increase the # of caps you may be able to pull off in a match, you may want to consider it.

If your robot has the ability to strafe, even more reason to use the camera. I'm just saying, the camera really isn't as difficult as its made out to be. I'd actually say if you use the camera correctly, its easier than using encoders.

mwtidd 13-03-2011 23:01

Re: Should We Program Autonomous For the Y?
 
Quote:

Originally Posted by SuperNerd256 (Post 1038950)
Our team is going to go on the Y and on the straight, but we can only go on the outer peg (not the highest). Of what I've seen, this is a lot more than most teams are doing. Most teams are only doing the straights. Now, this doesn't mean that there won't be teams doing the highest peg, or all three, but like I said, of what I've seen, most teams will attempt to do the straights. This year is a tough one for autonomous (tougher than the other years).

I hope realize the straight lines go to the highest peg.

davidalln 14-03-2011 00:19

Re: Should We Program Autonomous For the Y?
 
Quote:

Originally Posted by lineskier (Post 1038952)
From watching the matches, it seems as though many drivers have a tough time lining up just right. This is something that is very easy for the camera to do, the camera is awesome for centering the peg, and a rangefinder is awesome for knowing the distance to the goal.

It is my and our team's mentality that automation during teleop should only exist to improve speed of particular tasks. For example, we have buttons to raise the lift to all 6 possible positions, because that's an arbitrary task that will be consistent every single time. We have a button that "autoscores" a tube because it requires running the gripper, lift, and arm all at the same time, which is too difficult for one drive to do on his own quickly.

Such fine tuning is a driver issue. The driver should, with practice, be able to line himself up while moving towards the pegs. I understand that it won't be perfect every time, but if this is a consistent problem where the camera is necessary for fine tuning, then it should be on the drivers to get lined up better, not the code. Never fix driver mistakes in code.

This is how we approach it, and other teams do it differently. I've fallen under the trap of worrying about how "cool" a feature is over how functional the past three years of FIRST, and I think (read: hope) that I've nailed that sweet spot of functionality and simplicity my senior year.

WizenedEE 14-03-2011 23:54

Re: Should We Program Autonomous For the Y?
 
I don't see why it's not a good idea to have autonomous functions for things that will let the drivers get worse and worse. If we could make a failproof robot, we could get lots of PR points by having kids drive it around (with supervision, of course).

For those wondering how far we got, I managed to get both the Y code and the straight code working reliably. When we get our real robot back in Seattle, I'll have to check all the motor directions, PID gains, and make sure the lengths of the arm of the same (Yes, they're probably different...), but I'm confident we'll score in the first qualification match.

What are other teams thinking about how they'll do in the first fifteen seconds? It's a potential for an extra 12 points, and when else can you get a point and half every two seconds?

Also, would it be worth it to either have a third option for autonomous that would push the ubertube into the feeder lane to block teams that can't floor load or program it and hand it out to teams that don't have anything?

What's the general view on sharing autonomous programs? Has it been done before in any volume?


All times are GMT -5. The time now is 16:12.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi