[video] ThunderChickens 217 Auton REVEALED

[Uberbots]

That is some sheer speed!

works kinda like our autonomous mode, except we use a sonar sensor and a gyro in conjunction...
i like the encoder approach though... i assume your coprocessor is doing some fairly complex vector operations to get an angle out of the encoders?

[waialua359]

That is one impressive autonomous showing, especially the speed.
However, like in real life, a ferrari wouldn't look good fast and hitting a wall or another car. But also, like in real life, a good driver behind the wheel makes this robot a force at competition. Maybe it has some sensors that tells it to move and avoid other robots while moving fast.

[MasterChief 573]

How fast is that? We haven't tested ours on a course but it goes approx 15 ft/s. Just want to compare.

[Greg Marra]

Slick.

[petek]

That is a thing of beauty - besides the awesome speed, your rotation appears very smooth.

Memo to self: bring big hammers and johnson bars to straighten out the field.
Memo to drive teams: you may want to put extra velcro under your controls and bring ear plugs. This could get very loud.

[Alex Cormier]

er... stupid school blocking youtube... I want to see!

sounds like it's another great bot.

[SSMike]

Originally Posted by Alex Cormier

sounds like it's another great bot.

That it is.

You looked like you might have been able to do this so I'll ask: Have you guys considered not finishing the lap and trying to dislodge a ball from the overpass? It seems like you have a mechanism for doing so.

Other than that I have nothing more to say except that that was an amazing video.

[Paul Copioli]

Here is a link to one of three pictures that may answer some questions:

http://www.chiefdelphi.com/forums/sh...ad.php?t=64709

[Grant Cox]

Originally Posted by Uberbots

i like the encoder approach though... i assume your coprocessor is doing some fairly complex vector operations to get an angle out of the encoders?

I'm not on the programming team (I just wrote here what they told me to put), but I understand it is doing some serious error processing calculations to keep it straight (beyond that I couldn't tell ya).

To all asking about the speed, I'm not sure off the top of my head. I know it was calculated at 17fps (in design), I'll see if we can get a more accurate measurement today.

Originally Posted by CraigHickman

I notice your ball seems a little... flat?

If you look closely, you can see chunks of 06 poof ball being used as pseudobumpers on the corners

[tdlrali]

She made weight?

[Grant Cox]

Originally Posted by tdlrali

She made weight?

120.0 out the door, driving and fully functional =)

[tdlrali]

120.0 out the door, driving and fully functional =)

Engineered that way, or cheesehole'd that way?

[Mike Harrison]

We prefer to call it Jenny Craiged...

[Mike Copioli]

Originally Posted by Uberbots

i assume your coprocessor is doing some fairly complex vector operations to get an angle out of the encoders?

We use the co-processor as an interrupt driven encoder tick counter. It also performs all of the floating point math for calculating arc-length and theta. Arc length is simply the sum of the ticks of each encoder divided by 2. We then calculate the difference in arclenghth of each encoder. Since we know the distance between the two encoders (robot diameter) we can calculate theta. Using an external processor guarantees that no encoder ticks will be missed due to program flow latency or high priority interrupts like the ones used on the RC. We are using 128 bit quadrature encoders that are measured on both the rising and falling edge of each pulse. This gives an effective resolution of 256 ppr.