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 )
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
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.
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?
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.
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)
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…
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
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
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.
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.
*Originally posted by rwaliany * The reason being, the robot takes x amounts longer to load when it has more code to process.
What exactly are you talking about here? The time it takes to download the code from your laptop?
By removing and separating the programs into different files, we were able to speed up our auton from 5 seconds to 3 seconds.
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.
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:
auto_selection VAR tempvar3
auto_select VAR auto_selection.nib0
auto_bit1 VAR auto_selection.bit0
auto_bit2 VAR auto_selection.bit1
auto_bit3 VAR auto_selection.bit2
if active_button = 1 then
auto_bit1 = auto_select0
auto_bit2 = auto_select1
auto_bit3 = auto_select2
endif
if auto_button = 1 OR auton_mode = 1 then
select (auto_select)
case 0 'joy 1
run 2
case 1 'joy 2
run 3
case 2 'joy 3
run 4
case 3 'joy 4
run 5
case 4 'joy 5
run 2
case 5 'joy 6
run 3
case 6
run 4
case 7
'do nothing... just in case :-)
endselect
else
gosub operator_control
endif
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
*Originally posted by rwaliany * 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 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.
