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
endif
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.
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…