I have received quite a few e-mails over last weeks from team who were unable to program autonomous mode during the build season. To help them out, we, team 696, think it is a good idea to run an autonomous Programming Workshop at LA regional.
We have a dead reckoning code that I think is very adaptable. Since most of the teams who don’t have autonomous would probably run on dead reckoning, we’ll share our code with them since it is very easy to modify.
Because we only have 15 students in our team, I would appreciate if any other teams can help us with running this workshop. Since we’ll be running this workshop all day Thursday, Friday, and Saturday, please e-mail me, firstname.lastname@example.org, the personnel on your team who can assist and the time they can assist, so that I can make a schedule.
I think it’ll be great if we have more robots running autonomous in our regional than any other.
Please e-mail me ASAP.
Since you said your program works so well, I was just curious. How did you program it? I mean, is it dead reckoning or uses some mechanical device like sensors.
Also, if it is dead reckoning, did you user select command or count the loops.
I’ll really like to take a look at your program, and compare it to ours. We used a select command and counted loops to run autonomous.
My e-mail address is email@example.com
Please send me a copy of your code whenever you have time
I guess you could call our code dead reckoning… but not quite. What ours does is during practice or whenever we have the chance we have the operator run the robot in whatever way we want it to. While the operator is doing this, the program records all the movements that were made with the joystick. During autonomous mode, the program sends the recorded joystick movements to the robot and voila! we have a great autonomous run… and we got lucky last week at ypsi and recorded an excellent pattern to follow. We’ve been using it ever since.
Now as for how it works, we aren’t going to release that until after our last regional (next week) unless we make it into nationals in which case we’ll release it after then. Honestly, it really is quite simple to implement, and we can store up to 8 different programs at once. It is simliar to the “copycat” program in the white papers section, but ours is much simpler… mainly because it runs off our hardware timer (see below)
As for selection of user programs… we put 3 switches on our board that the operator selects, and the state of these switches is recorded every loop… until autonomous mode is activated at which point it stops recording the value since obviously it is invalid at that point… and runs the appropriate program.
if auto_button = 1 OR auton_mode = 1 then
case 0 'joy 1
case 1 'joy 2
case 2 'joy 3
case 3 'joy 4
case 4 'joy 5
case 5 'joy 6
case 6 'joy 7
'do nothing... just in case :-)
For all timing on our bot, we have a hardware pulse generator (a 555 timer) that generates a pulse every 1/5th second and we increment a counter at every transition, thus getting 1/10th second resolution. It really is so much easier to do than counting loops because it is consistant, and doesn’t vary according to how much code you write or if you have a really long branch of code or anything. It really makes things so much simpler. I am only aware of a few teams which have a device such as this actually. And everything on our bot is based off this timer… if it broke we would not be able to function really… which is why we built 3
But look for us to release our code (which is actually commented pretty good) next week if we dont get to go to nationals…
Another thing I forgot to mention is because of the presence of that timer… our code isn’t very easy to adapt to other robots…