Hi,
I will be giving a workshop in January during the kickoff for the next round of competition at the Palmetto Regional. I will will be speaking on Autonomous modes and using the Dashboard.
I am interested in tabulating a list of lessons learned from all of you programmers who worked on this. Things like “it seemed easy in concept but it didn’t work that way in practice”, or “it works but I don’t know why” or “this really kicked my tail for days trying to figure it out.” Simple and moderately complex lessons learned would all be beneficial to my presentation.
Also, what have you done with the Dashboard regarding autonomous programming?
I am not a programmer but I do know that last year Infrared was a BIG problem. The was a ton of bouncing going on that most of us didn’t account for. Even the people I worked with at the events didn’t believe it tail I proved it with their test units. When building practice areas for IR remember that wood does not have the same reflective power as Plexiglas and Diamond plate.
Regarding IR, we spent two weeks with an IR sensor mounted to a servo. The servo would scan back and forth looking for any IR signal. We put the controller and servo with sensor on a cart and moved it around. The servo and sensor would look onto the IR source if the range was less than 5 feet.
We were so focused on trying to detect the IR sources from 20 plus feet away that we didn’t take advantage of this this short range capability. We could have moved in autonomous straight ahead until we were right next to the ball/trigger mechanism. This short range system would definitely have worked…but we didn’t think of it. Of course other teams did.
These Banner sensors have a couple of different part numbers. We had three on our bot…thought they were the same. Programming just didn’t make sense. We found at that two were detecting ‘light’ areas but the third would detect anything that could reflect. Can’t tell you how much code was rewritten over and over to figure this out. Check part numbers closely.
[font=Verdana]I found one team checked the autonomous bit to start a dead-reckoning timer, however, at the regional the autonomous bit was on while the pre-start disable bit was also on. If the match started quickly the robot would behave as if it were partway through the autonomous period. If the match start was delayed more than 15 seconds (what normally happened), then the robot would just sit there and they couldn’t figure out why.[/font]
Several teams also had a problem with autonomous in the back-to-back practice matches. They’d forget to turn off or reset their robot controller (because that nice backup battery keeps it running even if the main power is off) after the first practice match and if it didn’t get turned off their robot continued to think autonomous mode was over. That was fixed with a software reset on Disable.
Check to make sure that you compensate for different timings if they are.
My story: Our hand shut-down code (To keep the hand from smoking if it grabs something) requires over-current 5 runs in a row. However, this was based on the 20 hz (whatever) main loop. I wrote my auton to run in the fast loop. So now in auton, it requires 40.
Fix the bug in Main.c
I’ve outlined this once or twice, but anyway. In Main.c, when you enter auton, it will run Process_Data_From_Master_uP() one more time on null OI data. In that sub, there is code to put an OI value into a variable (which was the auton setup). What you need to do is put that before the call to Process_Data_From_Master_uP(). And put a check to make sure the data is valid. (I also believe this will fix the PWM reset problem IFI described in the second release of the default code.)
Get a dongle.
Just do it. Don’t argue.
Write code while
the robot is being built.
This is my big lesson. I had about 2 days to code (That’s regular code and auton). Auton never really worked for us…
Once you get your autonomous mode working, there is more work to do:
Try and detect obstructions to success, and drop out of an auto mode for which persistence might damage the robot. You can do this with time restrictions placed on completion of state changes.
Shut down mechanisms, such as a feed back loop controlling an arm, once the last state of the auto mode is achieved. There might be 10 seconds left with the arm hung up in part of the field, in this instance the frame around the balls to tip, and the arm might be blindly inflicting self damage while pinned on the obstruction. This is similar to the issue above, but in this instance the robot needs to do the right things to protect itself when it finishes the autonomous mode.
Sometimes it pays to code several auto modes selected with a set of switches on the robot. You select the strategy that you find to work more reliably in the actual competition.
A $5 limit switch can go a long ways to protect a $6000 robot.
KISS (Keep It Super Simple) is a good idea if it is your first time writing an autonomous mode program. For example, banner sensors are simple to use and program while IR or encoders tends to be more complex.
I setup a simple line following autonomous mode last year using 3 banner sensors. It was simple to build and program and when it was complete it was reliable. Now that experience has made me more prepared to write a much more ambitious encoder based autonomous mode this year.
Utterly stupid loop-counting state machines can and do work wonders; never, EVER use them.
In case you didn’t see 1024 (my team)'s autonomous last year, it was exactly that: a state machine coupled to a counter that incremented every program loop. Somehow we got the counter numbers nearly perfect, and our robot’s autonomous was a minor legend, zipping out and nailing the 10-pt ball in less than 5 seconds. Though it worked, it’s really too stupid, rigid, arbitrary (ours only worked so well by sheer luck and a little testing in the practice rounds at St. Louis), and moreover, dangerous to use again. Still, it worked…
If I were giving a workshop about autonomous, this would be priority #1 !!!
How many times did we hear teams at the competitions requesting them or requesting how to make them?
The biggest thing we learned is that the autonomous mode needs lots of testing. My team literally didn’t have a working robot until 30 minutes before we had to crate it up. Therefore, I had no opportunity to work on the autonomous mode before the practice rounds at the regional. Then, it took me all day before I had something that worked reasonably well. So here are some gotchas I ran into:
Test, test, test!
Be careful that you don’t rely solely on the IR sensor - remember, if the IR sensor is mounted in the center of your robot, it will try to drive through the wall to get to the beacon!
Be very careful with overheating/driving too fast. One robot had one goal in its autonomous mode: rush the other side, ram us from the front and push us backwards while we were driving forward. That killed our motors several times.
Simple is sometimes better. We scrapped the original IR-only design for a timed system that worked a bit better.
We had a cool way of setting our autonomous… it involved a copy cat program and i noticed a few other teams had it as well. Everbody who had this program forgot that if you change your drive train settings you have to re-record your movements in order to have a properly working autonomous program. This program was a huge advantage to have but also a pain if you can’t get time to use a practice field to re-record! (Especially if you have someone like team 25 coming after you everytime you play them! THANXS CORY!)
We used a many-position rotary switch wired up with a bunch of resistors, connected to one of the joystick inputs of the OI. We had 8 different autonomous modes defined (4 each for left and right side starting positions), plus a “no autonomous” position. There was also a secret unlabeled switch position that we used for development in the pits, so we wouldn’t have to worry about breaking a working autonomous program during competition.
We added a 4-bit BCD thumbwheel switch to the OI to set the autonomous program number. Its a mechanical switch that displays digits 0-9 with buttons to select the value. The value is sent to the robot while its disabled, so the operators can change the value right up to the start of the match. You need to be careful not to check the value during autonomous mode or it will always be zero.
We used jumpers on two discrete inputs to let us select from 4 autonomous (binary mode – no jumper, J1, J2, both) and a third input for starting right/left side.
Too confusing, and too easy to make a mistake during competition. This year we’ll take the time to wire in a rotary switch for autonomous and a toggle switch for starting side and clearly label both.
Hi,
I have a BCD thumbwheel that can convert a decimal value to a binary value. You could connect this to only three digital inputs. This would allow the operator to dial in a digit from 0 to 7…8 different modes. Or dial in a 0 to 3 (4 different modes like you say).
Regards,
ChuckB
