Autonomous Mode Strategy

I was just curious about what you other programmers are gonna try to do in the autonomous mode. I think our team is going to try to line track until it goes up the ramp and topple the boxes on our side.

[Jeremy_Mc]

we're doing dead reckoning just so we KNOW we'll have ONE program (in case we wouldn't get done with the sensor programs)...

then we're making subsequent programs for line tracking and box seeking so if we want to use it we can.

*jeremy

[Mr. Ivey]

We are working on something real unique. Right now our only problem is that we may not have enought time to write the code. The inital idea came when one of the mentors said that there are limits to what you can do programing wise, but I came up with an idea that is theoretically possible, but due to time i don't know if it's possible. Don't want to let our secret out quite yet, but if we can do it, it will be insane.
Mr. Ivey

[ChrisA]

I guess you'll just have to wait and find out....

[EmilyM]

We're doing dead-reckoning. It seems like it's going to be a race to the top of the ramp, so we thought dead-reckoning would get us there fastest.

[Todd Derbyshire]

I'll say this what we have done in five seconds will win the game. I'm not being cocky just telling you the truth. The key to design is to think one step ahead of the others.

[MrB]

I'm not a programmer, but I am hoping that our programming team will create a program for each of those strategies.

Maybe be able to switch between them for different matches..

I think versitility will be key this year...

[bigqueue]

When people say dead-reconing, are they talking about simple "timing" of moves and turns, or are you talking about having wheel encoders and such.

Big difference....

I was wondering what sort of other sensors people were employing?

We are making some of our own sensors for various things....and buying a sensor for another job.

(How do I turn this post into a programming post!!!!?????!!!!)

[frumious]

right now, we're planning dead reckoning for turning/getting up the ramp, and using the yaw sensor to tell us when we're there, along with the possibility of having a tracking thing with the optical sensors at some later point

Tyson

[MrB]

using an encoding wheel is still dead reckoning. It is far more accurate than raw timing, but both are still susceptible to loosing their bearings on the field.

I know we are set on line tracking (FIRST just posted some code for this to everyone, if you didn't get it running on your own).

So investing time in wheel encoding isn't really worth the effort to get up the ramp. (our strategy.) If you have other plans for the autonomous mode, wheel encoding is probably the BEST dead reckoning method..

[FotoPlasma]

Originally posted by bigqueue
When people say dead-reconing, are they talking about simple "timing" of moves and turns, or are you talking about having wheel encoders and such.

Big difference....

I was wondering what sort of other sensors people were employing?

I was poking around in the DigiKey online catalog, last night, and stumbled upon some Hall Effect / Reed Geartooth Speed Sensors, Industrial Optical Rotary Encoders...

DigiKey has a lot of interesting stuff. It's too bad that some of the most interesting things they have are more than $100...

[Rickertsen2]

just think if we could use those radar distance sensors. That would be awesome.

[John_Maniacs]

We're also thinking of something a little different. As was said previously, the key is thinking 1 or 2 steps ahead of everyone else...;-)

[kmcclary]

Originally posted by bigqueue
When people say dead-reconing, are they talking about simple "timing" of moves and turns, or are you talking about having wheel encoders and such.

Big difference....

Dead Reckoning is ANY method to keep track of your position that uses INTERNAL knowledge of where you started plus knowledge of your actions instead of an EXTERNAL location reference source.

This can be accomplished by watching wheel revolutions, integrating each motor's speed over time, watching an internal "inertial guidance reference" brick, etc... And yes, this IS a programming problem!

ALL Dead Reckoning systems have drift problems over long distances, long times, or number of moves. Errors accumulate. The advantage is low cost.

The question boils down to "is it good ENOUGH for what I want to do"? Over short distances, times, and moves, Dead Reckoning is pretty good. But cruise the arena long enough, spin your tires once, be shifted by hitting an opponent, wall, or unexpected object, wait too long and your reference drifts, or add up too long a list and your resolution errors accumulate, and you no longer have a CLUE as to where you are.

BTW, as a piece of trivia, "Dead Reckoning" actually evolved from the homonym "Ded. Reckoning", which in turn was the abbreviation of "Deductive Reckoning". Deductive Reckoning is the ORIGINAL term for the method of "deductively computing" where your sailing ship at sea was at when you couldn't see the stars as an external reference. You'd use your compass, and every so often toss out a knotted rope and counted "knots" unreeled to a timepiece. That gave you your heading and speed. (Hence the nautical term for speed is in "knots"...) You integrated it in your logbook over time to estimate your position, until you could see stars or sun again. The spelling simply mutated over time from people hearing sailors speaking the abbreviation.

Some day, I think it would be GREAT if FIRST put coded retroreflectors in the corners of the field and we had enough parts and CPU crunch to have an EXTERNAL navigation reference for the autonomous phase!

- Keith

[Quentinfool]

they really expanding the role of programming this year. be sure to make ur driver controls durable. sorry personal experiance.