Autonomous Code From Experience

I just got back from the VCU regionals today and I must say - WOW!!! We(Oakton High School) are technically not a rookie team, but being that seniors are usually the only one’s working on the bot, we have new people pretty much ever year, and this year, not a single person worked on last year’s robot.

I would first like to give a half apology/recant. I was arguing before in the “Overcomplicated Autonomous Code” thread that dead reckoning would be too unreliable to run with. During our matches at the VCU regionals, the only realy robot contenders during the autonomous period were dead reckoning. Those that curved and went up the ramp had the highest success rate. Also those robots that had wide areas to knock down boxes worked extremely well(for obvious reason).

I will explain what happened to our autonomous code as we progressed to hopefully help some other teams get it right sooner than us. In the beginning, we had line tracking code running, supposedly with two down looking sensors, you could try to keep the line between the sensors and have the robot make to the top of the ramp and go fowards. That was very flawed for several reasons. First, the big thing we overlooked was sensor placement. Our robot fowards had kept switching before this regional and the sensors were considerably behind the drive wheels and our center of rotation and when we did hit a line, there was no way to turn and keep the line between sensors. Also, the line never seemed to trigger anything for a few runs. But after changing our automous code a few times, we scapped line tracking and had it go fowards until ANY sensor was hit, and then it would stop. After we saw that work we decided to get our human player in good position right after autonomous mode to start. So we decided, after we hit that single sensor, lets turn in a predefined arc (dead-reckoning based) and get generally up the ramp. That worked sensationally well, but now it came down to going forwards after a certain amount of time to go through the ramp. Of course that would require timing.

I will still say that existing counting code that is supposed to use seconds in the match is too complicated and possibly unreliable. We added a simple counter in terms of program cycles to time our robot. Since we don’t have a dashboard program we used switches to run our autonomous mode and stop it at a certain point to see if we were over a certain number of cycles. Using a binary search type method we centered in on about 200 cycles(that was moving relatively slow compared to any other working autonomous code and it only our code speed) Using that number we had the robot go fowards after the arc.

If you want to use such a counter you have to consider two things - if you want to go over 254 you need to use your own logic and do something like:

counter = counter + 1
if counter = 254
counter1 = 0
counter2 = counter2 + 1

I don’t want to explain too much but this would basically allow you go count up to 2^16. Also the timing only matters for the time up until autonomous mode starts turningstarts. Basically, if you are counting every loop in your program anyways, you need to reset it, the first time autonomous starts, and the first time a sensor is triggered or else you will have already reached your count while your team is placing your robot on the field(already on). Keep in mind that your program is running as long as the robot is on, and is therefore looping.

I’d like to end saying that our team competed very well. We had a first match and placed 27th(out of 61), then our next match we score 155 and moved up to about 17th. After our next few wins, we moved up to 3/4th after 1 day of competition. At the beginning of the next day we were moved up to first and maintained it for a good amount of time, but after the normal rounds were over we were in 4th. We got that far with practically no autonomous mode because our robot could drive and we knew what had to be done in order to win. What I’m implying is that a lot of teams don’t have autonomous code and even those with it WONT knock down all of the boxes. The game is still largely decided upon what happens under human player control. I’ll stop here because I’ve gone too far under the general game and that should go under another forum.

If you have any questions about other team’s successful autonomous code/what worked and failed with ours feel free to ask.

Congratulations on your standing, and on your programming (all done at the match ?). and thanks for explaining it so well. It looks like line following is a slow business.

we still have two weeks before our first – ypsi – and im still confident in our auto line tracking skillz… mainly cuz they’re so sloppy :slight_smile: but, our line tracking was a dead reckoning of sorts, and we had a gyro to figure out when we hit the ramp :-)… so we’re cool with that idea. And then, after our robot shipped, i noticed the idea about storing a path in EEPROM here on the forums and implemented it… and that really works quite well with our prototype! so nothing for me to worry about right now…

Oh yeah… one thing i keep telling people… hardware timers make it easier! :smiley:

I definitely feel that external timers would be a step up from loop counting. We are loop counters and we got our code working fairly well (for our treads and the carpets in our test arena). Then I noticed that we did not have code to turn on the air compressor in our auto-code. Our other programmer copied it in from his human player code and then EVERYTHING messed up. The new lines of code were executed every loop and altered the timing.

My second reason for feeling this way is because the arena surfaces and the traction/tension of our track drive system are all variables that are not measured in code. I think one of the greatest equalizers would be a tool that would measure the rotations of wheels or gears in the drive train. Knowing how far you have traveled in wheel rotations is a far cry better than knowing how long you have been heating a wire!

Oakton, congratulations on your success in coding it out!


Well, from a team that did very poorly in autonomous code, let me share a few tips with you guys to help you out.

  1. Keep it simple:
    We originally went for the curved approach, in an attempt to follow the line (without sensors…) and we had a lot of problems getting the timing right. I reccomend going for a square turn if you don’t have a lot of time to test.

  2. Get it working early:
    As far as excuses go, the problems for our team (769) were not all the fault of the programmers, but rather the mentors who did not see evidence of the autonomous code helping us in the practice matches (and therefore did not let us run it for 2 matches…which is understandable). We did not have any testing prior to the competition so we were winging it, but I hope you guys have better luck than we did. Showing other teams that you have a useful autonomous code will also be big factor in the choice of alliance partners for the finals, so I stress that you have it working for the whole competition.

After helping a few folks at Cleveland fixup their auton code, here are the problems i noticed:

  1. Program Flow issues, meaning people not
    seperating auton from human mode.
    This included not understanding how program slots work and the need to initialize things

  2. Testing Issues, meaning people didn’t have time to checkout the timing of the path the robot
    would take on a real field… we had this issue a little bit also, especially after swapping drill motors. (stupid brushes fell out)

  3. Multiple programmer messes…
    On our team: I wrote the Auton Code, someone else wrote the human code.
    It was all Heavily commented so either of
    us could understand what each section did of
    any block. I also broke it down into 5 program
    slots to keep it all neat.

Just my $0.03

One idea that we had but that we never pursued was putting a piece of reflective tape on the inside of one of the wheels, and then mounting a sensor nearby. That seemed to be the easiest way to count rotations.

*Originally posted by EbonySeraphim *

If you want to use such a counter you have to consider two things - if you want to go over 254 you need to use your own logic and do something like:

counter = counter + 1
if counter = 254
counter1 = 0
counter2 = counter2 + 1

I don’t want to explain too much but this would basically allow you go count up to 2^16… **

PBasic supports word size variables which would let you hold 2^16 without adding extra code. Our code worked something like this:

Time VAR word

Time = Time + 1

Hope this helps.