My auto is better than yours.. lol
 

Hahaha! We shall rule the world! Our auto mode is so superior to yours! Bwahahaha!

Eh.. ok, probably not.

Ok, my automatic code probably doesn't work as well as yours does. But, what kind of automatic programs is everyone using? I've seen so many good ideas (some of which I've borrowed.. naturally!) so let's see.. here's what my team has:

line tracking (4 "agression" settings)
dead reckoning using timer (4 seperate times)
Operator stored paths (8 stored paths)

We only had the line tracking and timer-based programs working before we shipped, and out of them the line tracking one was the fastest with a 4.8 second time to the top of the ramp as the fastest we had.. and that was because we have to have a .3-.5 second delay to switch into high gear..

To select all of these nice proggies, we hooked up 4 switches to the OI and they can be pre-selected before a match all the way to the human player period at which time you're not allowed to touch the OI (d-oh!)

Now, out of the 3 different types of proggies we have, the stored paths program is by far the most accurate, with line tracking fairly accurate and the dead reckoning being very unpredictable (although I think its cuz our wheels kept spinning on the invisible carpet we had:D )

So.. what kind of results has everyone else had?

Our robot has 3 toggle switches to decide which autonomous mode program to use (2^3 = 8 possible programs).

We use a magnetic sensor with a custom circuit to use it to record wheel counts and reset them as necessary.

We have two different programs to go over the ramp using DR (one for being on the left side of the ramp, the other for being on the right side of the ramp),

two that go over the ramp repeatedly to knock any boxes that may have been already knocked down onto our side (also one for each side of the ramp),

a program that uses two of the banner sensors to find stacks of a certain height and move toward them,

and one that goes in a very ... unexpected manner. that's all you're getting on that one :p

All of our programs rely upon the wheel counter to keep track of position.

Edit:

I forgot to mention that the other program "slots" have been left empty for some expandability once we reach the competition.

we ran out of digital inputs so we ended up using a pot with different ranges for each program:)
and a switch to select left and right.

Our robot has a toggle switch also. We flirted with the idea of using senors but ended up using dead reackoning.

Our team is using dead reckoning since it is the easiest and fastest way to do what you want to get done. We are using mostly dead reckoning by timer but we also have a couple of sensors to make sure we get the desired results. For those who went to the UTC competition at suffield you probably got to see out robot go up the ramp and knock the totes over. But we have added 6 other programs since to cover all aspects of the game possible.

Is there anyone else using dead reckoning with sensors for their auto mode?

our code
 

weve got 2 toggle switches(which code and lft or right) so 5 auton codes 3 work 2 are in testing still well have to profect them at regionals

WORKS:
going under the bar on either sidegoing up the ramp from the ritght side
going up the ramp from the left side

ALMOST DONE:
clearing out stacks in opponents zone from right side

NOT STRATED BUT EXPECTED TO BE DONE WHILE AT REGIONAL:
clearing out stacks in opponents zone from left side

robots gone wild
 

truth be told, our autonomous code runs much better now than it did before our regional, but I figured it was time to share these with the world.

http://filebox.vt.edu/users/scenglan...he%20races.mov

http://filebox.vt.edu/users/scenglan...ndofitsown.mov

http://filebox.vt.edu/users/scenglan...sign/crash.mov
(ouch)

Anyone else have some good 'robots gone wild' during the autonomous phase pictures or videos?

Well I'm sorry about not having a picture from the match, but we have a pretty funny story. The first practice match our robot went in full reverse into the bar and just kept pushing. It lifted the entire ramp off the ground as well as our half of the arena. It was the coolest thing we did the whole competition I think.

As for autonomous programs, I think our final one is very nice. We did not use a switch or anything, ours was just turning using right turns and then going up the ramp. Unfortanetly we didn't get it working until the last match.. but it is very effective. Not very spectacular, but it works.

Team 68's auto
 

Weve got space for some 16 programs, we use a cool retro 70's tv looking box for our switch board. We use light sensors to count rotations on out output shaft of our transmissions, so , its umm...not quite dead reckoning. It works quite well (now that all the bugs are out of the system)

thank you Mr. Smith!!!

Well during our auto testing, our test bot went berserker and knocked the leg out under a table saw, then proceeded to get knocked offline by the falling table. Another time it started whipped around and tore the power cable out of OI and stopped dead. Methinks it didn't like us.....:-(

One word:

gyro

Aaaaaaaaaaaaaaaaa!!! Gyro! Where? Let me smash it!! Ugh! I hate those so much!

But we use one:D

It was a pain in the butt to figure out how to get it to work correctl and integrate it with our line tracking.. but it works rather well last I checked.. hopefully it will continue to work thursday.

Actually.. even though our line tracker gets us to the top in 5 seconds.. I think we aren't going to use that.. gonna use our other program because its more reliable.. maybe faster, maybe slower :D

List of special gadgets I made my team make/install for me:

Gyro (ugh!)
Pulse generator (hardware timer)
Wheel revolution counter
Sensors
Sign that pops up and says they owe me big.. lol :D

Well, our team only has 8ft of ramp, and only on half of the ramp is, err, ramped. So, we set up our bit of carpet and I played around with the timing on our dead reckoning. So, we stack a bunch of boxes on top of the ramp and let the robot go using our auton dongle. The problem is, the people who are helping me, mostly to reset the field, forget to watch out for the robot going off the other side of the ramp. So, it gets to the top, has some forward momentum and just letting go of the auton dongle doesn't stop it in time so it falls off. So, about 100 pounds of robot falling from 2 feet smacking straight into the front plate usually isn't a good thing. The funny thing was nothing broke except for the rotating light that was in the back of the robot. I think we were laughing because we were all afraid we'd completely screwed our entire team.

dead reckoning baby! We back up and do ~45 degree v-turn. Consistently gets us to the top in a bit under 3 seconds.

multiple switches
 

Multiple switches isn't a good idea. We had 4 switches, however, we decided to separate the different programs into different files and only use the switch for left and right, which simply reverses the pwms. The reason being, the robot takes x amounts longer to load when it has more code to process. By removing and separating the programs into different files, we were able to speed up our auton from 5 seconds to 3 seconds.

- Ryan

Re: multiple switches
 

What exactly are you talking about here? The time it takes to download the code from your laptop?
Separating code into multiple files shouldn't have any effect on the time it takes your robot to drive to the top. If it does then something isn't right with the way you structured your program.

I digress.

Switches can be an effective way to implement autonomous mode if you are storing your multiple autonomous programs in multiple program slots. This is how we do it:

And really, it works quite efficently :)

Okay, Everytime your robot loads for the competition. IT takes time for the RC to read and interpret/tokenize the code. When I use to have four autonomous programs in the same program, it took two seconds longer to tokenize during the loading period like turning it on time.

it was structured rather similar to randomperson's

- Ryan

It will take longer to tokenize on the host computer and longer time to download to the robot controller. It will not take any longer on when you power the robot on or when it's executing code.

it wont? it DID, im only arguing what happened and happens to me

Yeah, what he said.

Actually, by loading all of your programs at once you save time because you don't have to recompile and re-load everything at run time.. all you have to do is flip a switch and voila, new program! No loading and crap.. lol, we didn't really use our laptop very much this weekend at all because of this :)

Idea: post your code so we can see :)

Then like I said, there must be a bug or design defect in your code. The code on the robot controller does not 'load' like a program that you run on your home computer. Programs on a microcontroller like the BASIC Stamp are stored in FLASH and execute directly from that FLASH memory.

If you'd like to post the section of your code that was deciding which program to execute maybe we can help pinpoint the problem.

The code is identical to randomperson's pretty much word for word.

if it's a certain auton program (rc digital bits) then it runs x from the initialization program

I don't know, whatever. I'm just saying from experience, it runs faster for me using less slots and code (auton programs). I see your argument. I see the absurdity in it running slower. But I also see it happening to me.

Did your code seem to execute faster after you changed, or did it start executing your autonomous sooner?

Slower execution would probably have been due to debug statements left in the code. Depending on how efficient your debug statements are they will make your code start to miss program cycles after 2 or 3 of them.

Just a thought that might help.

executed auton faster

If you still have the old code around you might try monitoring delta_t to see if it is greater than 0 while the auto code is executing. It would be easiest to simply save the greatest value delta_t reaches during loops and then either use the OI user_display_mode or a debug statement outside the auto loop after the auto finishes (so the debug slowdown isn't an issue) to display the high value.

From your description of the symptoms it sounds like the separate slot definitely had an additional delay for some reason and the new implementation doesn't have that delay.