Should We Program Autonomous For the Y?

[MagiChau]

Originally Posted by WizenedEE

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.

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.

[ATH1RSTYM00SE]

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

[Robby Unruh]

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.

[tr6scott]

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.

[mwtidd]

Originally Posted by tr6scott

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.

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.

[WizenedEE]

Originally Posted by lineskier

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.

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

[mwtidd]

Originally Posted by WizenedEE

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

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.

[George Nishimura]

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.

[archaopteryx]

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.

[George Nishimura]

Originally Posted by archaopteryx

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.

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.

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]

Originally Posted by SuperNerd256

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.

[apalrd]

Originally Posted by lineskier

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

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.

[mwtidd]

Originally Posted by apalrd

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.

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!