PDA

View Full Version : Autonomous Mode Strategy


Brian48216
01-15-2003, 03:22 PM
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
01-15-2003, 03:31 PM
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
01-15-2003, 03:41 PM
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
01-15-2003, 04:18 PM
I guess you'll just have to wait and find out....

EmilyM
01-15-2003, 10:25 PM
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
01-15-2003, 10:36 PM
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
01-16-2003, 04:49 AM
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
01-16-2003, 04:01 PM
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:

frumious
01-16-2003, 05:59 PM
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
01-16-2003, 06:10 PM
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
01-16-2003, 09:53 PM
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
01-16-2003, 10:09 PM
just think if we could use those radar distance sensors. That would be awesome.

John_Maniacs
01-16-2003, 10:35 PM
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
01-16-2003, 10:43 PM
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. :D

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

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
01-20-2003, 08:29 PM
they really expanding the role of programming this year. be sure to make ur driver controls durable. sorry personal experiance.

Don Reid
01-20-2003, 09:19 PM
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 :-)

kmcclary
01-20-2003, 11:13 PM
Originally posted by Don Reid
Why go so low tech. They could put in a microwave GPS constellation :-) <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... ;)

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

- Keith

Rickertsen2
01-20-2003, 11:24 PM
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

kmcclary
01-21-2003, 12:07 AM
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 ;) 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

Jeff McCune
01-21-2003, 09:55 AM
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.

kmcclary
01-21-2003, 12:15 PM
Originally posted by Jeff McCune
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. WOW! That's a project and a half right there!!! I'm impressed... That'd be a little ambitious for us to attempt THIS year, but might make a good summer "R&D project".

OOC, Which compass module are you using? The HMC1023? (Digikey pg 1045) Between the 2P and the compass, that's a good chunk of the entire electronics budget right there!

You better watch out for robots waving bar magnets at you... :ahh:

- Keith

Jeff McCune
01-21-2003, 12:37 PM
We originally looked at the CSMP03, which runs about $40 and has a 20ms response time and is accurate to within a few degrees. Unfortunately, we couldn't buy it from a dealer authorized by First, so we had to build our own.

I forget which part number we ended up buying, but basically it's a $20 2-axis magnetic sensor from digikey. We've got an ECE guy who wired up a nice circuit with some op-amps to condition the output from the senor (I'm CIS, so that stuff is beyond me a bit.). It outputs 2 pulse trains corresponding to the x and y magnitude (if you think about it on a cartesian plane) We're using the PULSIN basic stamp instruction to sample the pulse width of the two PWM signals and convert them to BRAD's (Binary Radians: 0-255 rather than 1-360 degrees) After that, it's a simple arctangent to get your cardinal direction, which the stamp provides with the ATN function. Pretty straightforward really.

The compass senseor + support circuit only ran about $40. The stamp-2P we bought is the most expensive part, just under $100.

It all works wonderfully at this point. We've got the RC sending joystick values down a couple of PWM lines to the 2P, which doesn't always get through perfectly, but they're joystick values so they can be a little fuzzy. The 2P has 32 general purpose I/O pins, so we just set 16 to output and wired those directly to rc_sw_A and rc_sw_B. We've then got 16 lines still available on the 2P for any sensors we need. Plus, since we're not doing serial in or out on the 2P it's main loop cycles MUCH faster than the main loop of the stamp on the RC. This faster cycle time allows us to do interesting stuff like implement soft interrupts on some of the extra I/O pins. (This is how we're doing our shaft encoders.)

Yes, it's very, very cool right now. But talk to me in 4 weeks. <g> It's going to take an enormous amount of time to fine tune our robot. Not to mention the nightmare of the continuously variable transmission that the ME's want taken care of entirely in software... *sigh*

Craig Morin
01-21-2003, 10:48 PM
Hey,
I'm the ECE that Jeff just mentioned. We purchased the HMC1052 magnetic sensor, which happens to be a 10-MSOP package. For prototyping purposes, we also got the 33010CA adapter (you haven't really lived until you've soldered a 10-MSOP package with a standard soldering iron).

The compass is based on the reference design for the HMC1052 at magneticsensors.com, with a few modifications. I recalculated the component values to work on 5v instead of 3v and replaced their surface mount components with DIP packages.

The circuit outputs 2 analog values that very like sine waves as your rotate through 360deg. As Jeff mentioned, the heading is derived by taking the arctangent of those analog values.

With the microcontroller, we chose to go with the 2p40 instead of the 2p24 ($20 difference) because we needed 16 digital lines to go directly to the robot controller. Now, normally, I would have chosen the 2p24 and used shift-registers, but in this case, there is a lot to be said for reducing development time. Shift registers are another thing to burn out or end up completely incompatible with the (horribly undocumented) robot controller.

In all, it took us on the order of like 2 days to build the electronics and now most of what is left is coding (Jeff's department). What is really neat is that all of our highschool students in controls understand the algorithms we are implementing, and in many cases, they have been integral in developing them. Now that we have the high-level design down, we are teaching them Pbasic, so they can code them as well. Expect to see a sweet autonomous robot with an automatic CVT come competition.

Good Luck to all.
-Craig

kmcclary
01-21-2003, 10:57 PM
Originally posted by Jeff McCune
We originally looked at the CSMP03, which runs about $40 and has a 20ms response time and is accurate to within a few degrees. Unfortunately, we couldn't buy it from a dealer authorized by First, so we had to build our own.Cool! <searches> Hmmm... No hits... Who makes it?

Originally posted by Jeff McCune
I forget which part number we ended up buying, but basically it's a $20 2-axis magnetic sensor from digikey. We've got an ECE guy who wired up a nice circuit with some op-amps to condition the output from the senor (I'm CIS, so that stuff is beyond me a bit.). It outputs (...) The compass sensor + support circuit only ran about $40. The stamp-2P we bought is the most expensive part, just under $100. Wow... That's nice! Boy, I wish I had a spare EE for some custom analog work! I'm an ECE myself, but I was sick for two weeks and now I'm coordinating about a hundred other things. We also lost a couple of people due to work/home situations. Our one college ECE student mentor who I was HOPING would take on the custom chip stuff has taken over teaching PBASIC to the students and monitoring software progress when we lost our original software mentor. (Thank goodness HE is still on board!) We figure that having a robot MOVE was a slightly higher priority than having REALLY wild electronics... :D

We'll be at the Buckeye, so you'll have to give me a tour of your system then.

OUR original plan was going the opposite route, the "workstation" vs "mainframe" philosophy. LOTS of $5 PICs each screaming along doing something trivial in short C code snatches, instead of blowing the budget trying to Kitchen Sink something in one (relatively much slower and more expensive) Interpretive Basic chip. We can throw 10 PICs at something for the price of one Stamp! By keeping the code short and one-tasked in each, we thought we could crank out a few PIC projects in time.

Unfortunately I'm swamped, and the PIC gurus I know with burners are all busy, so now we're back to kitchen sinking it too in HLL just to "get it out the door". :sigh: Should be cool though, IF we can pull it off. A few unusual items (which I'll outline later...) For now though, we're already stripping our "Big Plan" down to just the basics, and dropping to Plan B for the rest. Our original autonomous concept went with the PICs, so now we're doing something different.

(Of course... if there's a bored PIC Guru in the Ann Arbor MI area monitoring that wants to get involved in this contest, CALL ME TODAY! :) )

Originally posted by Jeff McCune
The 2P has 32 general purpose I/O pins, so we just set 16 to output and wired those directly to rc_sw_A and rc_sw_B. We've then got 16 lines still available on the 2P for any sensors we need. Are you getting bytes through reliably via parallel? I'm hearing a lot of horror stories about how since the I/O PIC and the RC are asynchronous, some people are getting funny values every so often because one nybble may be old data, and another the new one.

Originally posted by Jeff McCune
This faster cycle time allows us to do interesting stuff like implement soft interrupts on some of the extra I/O pins. (This is how we're doing our shaft encoders.) Hmmm... Maybe we'd better look into a 2P as well... Back to the spec sheets! Good luck to you!

- Keith

Craig Morin
01-21-2003, 11:24 PM
(link to digital compass mentioned in past posts) (http://www.robot-electronics.co.uk/shop/Compass_CMPS032004.htm)

One of the major factors in deciding upon the basic stamp over a PIC is that the highschool students can do most of the programming, and understand it. With PICs, even ones that can be programmed in C, we would be doing the development, and that is not compatible with the spirit of FIRST or of our team.

I would like to direct everyone to another post (http://www.chiefdelphi.com/forums/showthread.php?s=&postid=122752#post122752) with information on our encoders and stuff.

happy engineering.
-Craig

kmcclary
01-21-2003, 11:54 PM
Originally posted by Craig Morin
Hey,
I'm the ECE that Jeff just mentioned. We purchased the HMC1052 magnetic sensor, which happens to be a 10-MSOP package. For prototyping purposes, we also got the 33010CA adapter (you haven't really lived until you've soldered a 10-MSOP package with a standard soldering iron).

The compass is based on the reference design for the HMC1052 at magneticsensors.com, with a few modifications. I recalculated the component values to work on 5v instead of 3v and replaced their surface mount components with DIP packages. (...)

In all, it took us on the order of like 2 days to build the electronics and now most of what is left is coding (Jeff's department). What is really neat is that all of our highschool students in controls understand the algorithms we are implementing, and in many cases, they have been integral in developing them. Now that we have the high-level design down, we are teaching them Pbasic, so they can code them as well. Expect to see a sweet autonomous robot with an automatic CVT come competition. VERY COOL... :D (Been there, done that WRT SMD devices...)

Yea, I saw that app note and it crossed my mind too, but we thought for only 15 seconds of Autonomous time we didn't really need a compass. We know what we want to do and that won't be needed. Besides, we have other irons in the fire WRT custom circuits which are higher priority, we're short staffed, and we're not set up for SMD work at the shop (or home)... :D I thought that would be too much to teach our first year, and I wish the students to build the circuits themselves wherever possible.

You'll see what I mean later. I don't want to say it NOW just in case it either doesn't work as advertised, or gets pushed aside (you know how THAT goes...) but things are looking good so far.

We may not have a super shop this year, but I'm blessed to have a GREAT rookie team with enthusiasm, and SPACE. So we're building a FULL SCALE FIELD out of REAL materials, which should help debugging Autonomous Mode TREMENDOUSLY. We're still waiting for a few things to arrive for it, but we're hoping that'll be up within the week.

Our reasoning is that even if EVERY "fancy sense" and trick failed, with a full scale field and similar carpeting on hand we can at least hard code a useful Autonomous Activity as Plan D.

Originally posted by Craig Morin
One of the major factors in deciding upon the basic stamp over a PIC is that the high school students can do most of the programming, and understand it. With PICs, even ones that can be programmed in C, we would be doing the development, and that is not compatible with the spirit of FIRST or of our team. You'd be surprised at how many students know C++ now. That's taught at our school to the UNDERCLASSMEN. The Sophomores KNOW it! (That flipped me out!)

We did have a PIC C compiler available, and our original intent was to have a PIC guru take them through it. However, with the personnel attrition, we have no one to take them through embedded development, so I'll take whatever I can get at this point. They know C, but we now have to teach them PBASIC They're learning fast, though.

Besides, our team is also VERY young... We have NO Seniors, and I think ONE Junior. The REST are Freshmen and Sophomores. This is great for building a team long term, but it limits how much I can lean on their classwork. We're spending a lot of time teaching basic Physics and Trig, so I have to be a realist about how much they can absorb in one year. Since the same crew will be with us for TWO MORE YEARS, I have NO problem with Adults taking on SOME jobs this time. They'll get to do the REST over the next couple of years.

The school is also starting to integrate FIRST into its curriculum. By the time THIS batch graduates, I hope they'll be DESIGNING the custom circuits! :D

- Keith

Jeff McCune
01-22-2003, 08:50 AM
My bad. The original compass we were looking at is the CMPS03 Not the CSMP03. Sorry about that.

Are you getting bytes through reliably via parallel? I'm hearing a lot of horror stories about how since the I/O PIC and the RC are asynchronous, some people are getting funny values every so often because one nybble may be old data, and another the new one.

Yeah, we are. You just have to be smart about how you send data from your custom circuit to the RC. I ended up defining a word of memory on the Stamp-2P called bus, which logically represents the state of the bus between the 2P and the RC. I can muck around with the bus variable all I want, but I have a subroutine on the 2P called SENDPACKET, which takes the current state of bus, and outputs it to the 16 output pins wired to the RC all in one shot. I can very easily turn off interrupts at the begining of this subroutine, and re-enable them at the end, which will ensure our shaft encoders aren't constantly interrupting the communication between the 2P and the RC. Finally, I'm very careful about how often I call the SENDPACKET subroutine, as to not spend too much time with interrupts off.

Doing all that, it seems to work perfectly fine between the RC and the 2P. The only weird values I've gotten have been a result of my own stupidity. (Having outputs defined as inputs, etc...) <g>

kmcclary
01-23-2003, 01:47 PM
Originally posted by Jeff McCune -
(Reply to question "Are you getting bytes through reliably on the RC Digital Inputs") Yeah, we are. You just have to be smart about how you send data from your custom circuit to the RC. I ended up defining a word of memory on the Stamp-2P called bus, which logically represents the state of the bus between the 2P and the RC. [...] I have a subroutine on the 2P called SENDPACKET, which takes the current state of bus, and outputs it to the 16 output pins wired to the RC all in one shot. How does that overcome the "old/new nybble" problem? As I understand the problem, there are slivers of time where the data you receive in the robot program MAY have some nybbles fresher than others among the digital inputs.

This is acceptable if the digital inputs are being used as single bits because you'll simply see the rest in the next loop. But if you're expecting them to be a SET as in a bus application, you COULD see "hybrid" values which are worthless (or worse, seriously misleading!). Simply changing the 16 bits together doesn't fix that.

- Keith