Should We Program Autonomous For the Y?
 

I can either spend a few hours with the robot on a Sunday and possibly get it working or just go with the straight line.

What do you guys think? Will enough teams be doing autonomous to make the Y reasonable, or should we not bother?

Re: Should We Program Autonomous For the Y?
 

It's really up to you. I mean I know we are not worrying about it just because we know that we are just going to be happy with a working auton.

Re: Should We Program Autonomous For the Y?
 

I would say don't go for the Y as of now. Get a reliable straight autonomous first so you have a means to consistently get points before you get more complicated. It should be fairly possible to have an entire alliance score just by going forward.

Re: Should We Program Autonomous For the Y?
 

I can foresee it being useful for Championships, but for Regionals it is too unlikely that all three of your alliance members will have autonomous that unless you're positive that you can get it consistently and quickly, it might not be worth the effort. Even in Eliminations, with the focus on defensive bots as the 3rd pick, I can't imagine all three will have scoring autonomous.

Re: Should We Program Autonomous For the Y?
 

In the finals at FLR 217 and 2056 hung side by side in a straight line no problem, could have had a 3rd team use a 3rd peg at the far end of the rack no problem (1518 was until they got penalised during auton)

From my POV there is no need to use the Y since theres enough space to have straight line code use adjacent pegs

Re: Should We Program Autonomous For the Y?
 

Wow. Pessimists :)

In all seriousness, I can definitely agree with the sentiment of not wanting to add more on your plate, but if your robot is working (programming wise) then I see no reason not to try if you can.

I would ensure that you keep a copy of the working code set aside for matches, until you get some time on the practice field to verify your code.

If you have other things that need to be done, then obviously you should put those ahead of the Y, since it really probably isn't a big deal as mentioned above.

Good luck,
Matt

Re: Should We Program Autonomous For the Y?
 

Don't forget, Y code will stand out in scouting. of course, if you have working Y code, you are probably not too worried about getting picked...

Re: Should We Program Autonomous For the Y?
 

Hmm, that's a good point. Even if it doesn't matter to the alliance, saying "We can hang anywhere in autonomous!" sounds much more impressive than "Well, we can only score on the outer pegs..."

I guess I'll at least try, especially since I already have something that will theoretically work, the main problem being sensing the Y, and the lack of a great testing area.

Re: Should We Program Autonomous For the Y?
 

Maybe some code that turns the robot when the outer light sensors detect the line but middle doesn't. I don't know what spacing you used.

Re: Should We Program Autonomous For the Y?
 

with experience from a week 1 regional, i can say for sure that you should DEFINITELY do a y autonomous. i believe that there was only 1 team in trenton that had it and everybody was impressed. Even though they weren't seeded high, they were picked for an alliance because it would give the alliance the ability to hang all 3 uber tubes. i say go for it for sure because teams will be way more interested in you. plus autonomous fail stories are fun.
Hope this inspired you:)

Re: Should We Program Autonomous For the Y?
 

In my honest opinion, Y is a little overhyped on the programming side. I didn't think it was very hard to program at all, the hard part was setting the tape at the right angle, which we never really did get done. But it should work, and my team and I will find out during the practice matches/on mock fields.

Re: Should We Program Autonomous For the Y?
 

As we get to the later regionals, and your 2nd regionals, I believe that most teams will have straight auto working, and a "Y" will be a huge advantage.

Week 1 we were 17/18 on the straight, we had a working "Y" but never had the need to actually use it. In the finals we were paired with the Bee's and they needed us to do the straight, as they were putting up two.

I imagine that we will not be paired with another 2 uber team... so the working Y will be a good asset.

After seeing the Bees, our lead mentor said we have to program a 3 uber tube auto, but not change the code at ALL. :)

Re: Should We Program Autonomous For the Y?
 

3 uber tube would be very hard to accomplish using a line tracker. Also 33 relies on encoders, which limits how fast they can accomplish it. I think to accomplish a 3 tube autonomous reliably you would have to incorporate a different strategy. The way I forsaw it was 2 cameras... one front and back.
front looks for pegs, back looks for tubes. With 2 cameras and a rangefinder it is definitely possible... But you would need a sub 3 second cap... which is insanely fast. (separate threads for each mechanism... good 2 speed trans... and a crazy good claw.)

I would focus on the straight line.... get that to 100%. If you get that to 100% on thursday then start thinking about the Y.

Re: Should We Program Autonomous For the Y?
 

You could also just have a kicker instead of an arm xD

It's looking like I'll be able to get to the Y, since we have a practice bot that's doing pretty well.

At the competition, I'll have to calibrate the accelerometers and the PID loops, and then make sure the arm angles are the same.. Lots of work to do :)

Re: Should We Program Autonomous For the Y?
 

how much luck have you had with the accelerometers? How do you use them?

That's one sensor i've been meaning to try out but never have.

If you have the practice bot tracking on the line well, then it would definitely be worth getting the Y working with your practice bot.

Re: Should We Program Autonomous For the Y?
 

We used line-tracking, it wasn't too difficult to program the Y autonomous code after getting the straight line to work. Just add a state that recognise the Y(true-false-true).

If your are using accelerometers, gyros and/or encoders, you could just have a half diagonal one that will score no matter where you start, and then work on trying to get the double ubertube.

Re: Should We Program Autonomous For the Y?
 

We could run faster (we are running our first tube at 3.5 ft/sec, mostly limited by the elevator and our fear of overrunning the elevator).
We choose not to.
It's not the encoders. We run closed-loop control all the time (controlling wheel velocity, and a few other calculations to control machine dynamics while driving) and have no encoder issues at full 13fps.

If anything, the camera would be a much more limiting sensor, as there is a lot of system lag in general while using it (everything must stop while processing images because of the processor overload), and if the image is processed on the laptop to increase speed of calculations then there is network lag returning the results (not much, but when trying to run with +-1 degree rotational error at 13 feet per second, everything is an issue).

You know exactly where the tubes are. You know exactly where the pegs are. The largest source of error is human error on lineup (which generally isn't much) and error compounding from multiple actions (each turn, each drive, etc). The easiest way to do more complex tasks is to reduce the error in each step, then rely on the remaining error to be constant (for example, if I tell my turn command to turn 30 degrees, it might turn 28, but if I know that it will always turn 28 degrees instead of 30, then I can tell it to turn 32 and it will do a perfect 30 degree turn.)

We already had the encoders, and were using them for closed-loop speed control. We already had the gyro, we were attempting to use it for a few special pieces of software (push-through and drive straight) but later abandoned its use in favor of a purely encoder-based solution. The autonomous code relies only on sensors which already existed, adding no weight to the machine. When you weigh in at 119.6 and have another 2 pounds of stuff you want to add, that 1 pound of sensors (2 cameras + wiring) is a lot.

Re: Should We Program Autonomous For the Y?
 

At the WPI regional, when there were robots on both the Y and the straight lines, they tended to interfere with each other so that neither could get their ubertubes on.

Re: Should We Program Autonomous For the Y?
 

Thanks for your insights!

Regarding the camera, yes if you used the camera as the lead sensor, you would be prohibitive. However there are ways around this. With strafe capability, that slight adjustment to center on the peg can make all the difference in making or missing that cap. I think to do a consistent 3 tube cap consistently the camera would have to be utilized and utilized correctly. For example, as you approach the pegs for the second tube, even having one frame from the camera could help to get that to 75%.

Again my opinions were based on the 3 tube autonomous. Which a 2 degree error x 5 turns, and accounting for misalignment would be a prohibiting factor in reaching a 75% accuracy with 3 tubes even ignoring the 15 second limit.

I have never used encoders myself, and after seeing your success I am very curious about them. Also, don't get me wrong... the double cap is amazing, and its awesome that it can be done simply with encoders and a gyro.

75% has always been my metric for success... unfortunately I failed this year. I'm glad to see you guys succeeded!

Re: Should We Program Autonomous For the Y?
 

Happened to us twice. Make sure you plan your autonomous strategy well. Also, if you do straight line, back up quickly after placing the tube.

Re: Should We Program Autonomous For the Y?
 

At the KC Regional, very few (if any) robots did the Y. I'd go for it if you could. Our team's experimental Y support should be 100% by the time we go to Midwest. (We just need special conditions for the joints =/ )

~David

Re: Should We Program Autonomous For the Y?
 

My philosophy regarding autonomy: do not do it if you are not doing real time calculations. I personally do not consider those "drive forward 10 feet and score" autonomy real autonomy. They are pre-written instructions; where is the autonomy in that? Consider getting a job and a written step by step instructions on how to do that job. Would you consider that an autonomous action? No I would not.

So the autonomy should be a challenge for the programmers to breathe some life into the robot, allowing it to make choices on its own.

The ideal autonomy should use cameras, I plan on using a camera, the photosensors and possibly the encoders.

Re: Should We Program Autonomous For the Y?
 

I prefer to follow KISS. If it can be done simply and consistently, it should be done as such. A camera is not simple nor is it as reliable as other means of completing autonomous.

Re: Should We Program Autonomous For the Y?
 

The ideal autonomy is one which reliably scores the most points for your alliance. Whether it uses time-based motor control, encoders for position sensing, clockwork cogs, ultrasonic rangefinders, cameras, or telekinesis is not really important.

Re: Should We Program Autonomous For the Y?
 

How much math is there in a "drive forward 10 feet and score"?

In my code:
The autonomous script would have a command "DRIVE_STRAIGHT 120 6" to drive the 120 inches at 6 ft/sec
The beescript interpreter would find and call the Drive Straight function (drive_straight.vi)
The Drive Straight function would:
Reset the encoders
Calculate the remaining distance to the target plus an overshoot constant
Determine the desired average output speed using a proportional controller
Limit it to the 6 ft/sec
Determine drift by using the differential of the two encoder distances
Determine how much to compensate using another proportional controller
Add the two and take the remainder of the larger number and subtract it from the smaller (so the difference in the motor output is always the number specified by the second P controller)
Ramp the output to prevent lurching (which can cause twisting and innacuracy)
Feed the speed, which is passed to the drive thread which actually drives (closed loop is turned off during auto since auto does its own calculations).

The score would also include:
Setting the elevator state to be fed to the state machine
The state machine would pickup the state request (back in its thread) and lookup the position
The position would be run through the state machine which would see if it is trying to crossover backwards or handle a special sequence. Since it isn't, I'll skip that.
The resulting position would be checked against the active tube color, and if it's a circle (or if it's an ubertube and we're pretending ubertubes are circles) it will add the white tube bump for the current score state
The resulting position will be fed through the P controller to determine power of the elevator and wrist
The gain scheduler will modify the gains above based on several parameters (such as the sine of the angle of the wrist).
The resulting power will be fed through the limits VI which will bring it into range
The resulting power will be fed to the motor if the state machine has been initialized (set) since last exiting disabled (safety feature - no movement after exiting disabled until commanded)

Lots and lots of math.

Re: Should We Program Autonomous For the Y?
 

Can your robot actually tell the color of the tube its holding and keep track of score?

I didn't really understand this part...

Re: Should We Program Autonomous For the Y?
 

They might be using a camera that checks for a color range to determine which tube it is.

Re: Should We Program Autonomous For the Y?
 

No, it's set in software based on button input. (but we did actually attempt to use an NXT color sensor, but the claw didn't have any good place to put it).

I have an auto command to set the tube color.

Re: Should We Program Autonomous For the Y?
 

Yeah, I was just curious if the elevator know's exactly what height to go to based on the tube :) That would be pretty killer ;)


Oh okay, it would be pretty sweet to use the camera this way.
Also the frame rate wouldn't be a problem

Re: Should We Program Autonomous For the Y?
 

IF you tell it you have a white tube, it will go to the correct height. It dosen't know what tube it has, but asks you (there's a button to set white, when you set state it will set red). Red and Blue are the same, white has a height bump.

During auto, the set state command sets the state without setting color, and another function sets color.

The code does exist to read and use the NXT color sensor, but we decided it didn't work well enough to use it (mostly because there is no place in the claw where the tube is an exact distance from the sensor, and the sensor relied heavily on scanning distance). Another issue was I2C cable length, as the run up to the elevator is something like 10 feet from the digital sidecar.

Re: Should We Program Autonomous For the Y?
 

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.

Re: Should We Program Autonomous For the Y?
 

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

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

Re: Should We Program Autonomous For the Y?
 

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.

Re: Should We Program Autonomous For the Y?
 

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

Re: Should We Program Autonomous For the Y?
 

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.

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?