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.

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

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

I guess you’ll just have to wait and find out…

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.

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.

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…

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

:confused:

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

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…

*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…

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

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…:wink:

*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. :smiley:

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. :smiley:

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

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

*Originally posted by kmcclary *
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!

Why go so low tech. They could put in a microwave GPS constellation :slight_smile:

*Originally posted by Don Reid *
**Why go so low tech. They could put in a microwave GPS constellation :slight_smile: **
<chuckle> Yea right… (BTW, even with differential GPS, it’s not fine enough.) Of course they COULD make “active transmitter posts” on different carrier frequencies, and we could use Doppler RDF (Radio Direction Finding) too… :wink:

Actually, the biggest problem a complex positioning system game would have is the cost for each team to simulate the field for testing. You really DO want to keep the field hardware “cheap”.

I’m SERIOUS about a retroreflector navigation game. Placing a retroreflector on three of the four corners of a VERY rectangular field (a 2:1 or better Length vs Width ratio) DOES allow for a SIMPLE self locating system by spinning a SINGLE retroreflector sensor, as long as there are NO visual blind spots on the field. The math is NOT that tough, and angles to three posts always yields a unique position within the boundaries.

However, the sensors we have now won’t hack it. Not enough range. You’d have to change them to the “laser pointer” types… The current RC math package wouldn’t hack it either. You want at least floating point & trig tables, or else a separate CPU to program for the sensor subsystem.

Maybe the kit could provide a subsystem “brick” for it… When shown the three known retroreflector angles, it tells the RC the X-Y field position and direction vector as three analog values, and YOU have to do something with that information like avoid known position colored carpet “pit” zones. Now THAT would be SWEET! :smiley: I THINK a high end single chip PIC micro would be good enough for the task, but I’ll think about that one AFTER this season is over! :slight_smile:

  • Keith

Another possibility:
the entire floor could be like one giant encoder pattern which could be read using pos-like barcode sensors. again, that would be hard for teams to recontruct. just a thought

*Originally posted by Rickertsen2 *
**Another possibility:
the entire floor could be like one giant encoder pattern which could be read using pos-like barcode sensors. again, that would be hard for teams to reconstruct. just a thought **
Food for thought…

How about color coding the tape stripes for X and Y “zones”? You pass across a Red/White pair, then a White/Green pair, etc… Different color sequences for X and Y. (Maybe some kind of crude compass sensor, too?) Call it “World Hurl” or some such thing :wink: The field’s “country” boundaries from a distance would look like a Hollywood Squares set of different box colors, though they may NOT be square boundaries.

Goal: You have to pass ONLY through “Friendly” or “Neutral” Countries to fetch and retrieve collectible resources, avoiding “Unfriendly” ones (Opponent Alliance). You both travel through “Neutral” ones. Different “country boundaries” could easily be discriminated with a simple color sensing retroreflector. You DON’T KNOW which colors will be YOURS until the match, so you’ll have to program both sets.

Anyway we’re drifting into “next year’s game design”… Let’s talk about THIS year’s strategy.

  • Keith

We’re using dead reckoning using 2 shaft encoders attached to the output shaft of our transmission. They’re already necessary, since we’re building a continuously variable transmission and need to sense acceleration before the gear assembly and on the output shaft itself.

The other trick we’re employing is a digital magnetic compass attached to an external stamp-2P.

We’re interfacing the external stamp using a few PWM lines from the RC to the 2P, and all 16 digital inputs to go from the 2P to the RC. The 2P will run all autonomous code, poll the shaft encoders, decode the input from the magnetic compass, and handle the CVT ‘automatically’ (The driver will never shift manually.)

So I guess it’s still technically dead reckoning, but with a bit more intelligence by employing shaft encoders and the compass.