pic: GUS Team 228's 'Drive-by' Autonomous

How do you score a keeper on the rack in autonomous without stopping? Do a drive-by!

Our current autonomous mode allows us to score keepers on either side of the rack on the middle row, without stopping, at about 5-6 ft/sec. We drive past the spider leg, snag the tube on the spider, let go of the keeper, and keep on driving.

Sensors used for autonomous include drive train encoders (for gauging distance and drift correction), a gyro on the arm that rotates sideways, and an IR sensor to get the elevator to the right height. Except for the drift correction (which is currently just the “P”), everything else is PID control loops.

If it’s successful, our robot swings around the rack and can also block robots from the opposing alliance from scoring theirs. If not, it just drops the tube and drives out and stops right next to the tubes on the far side of the field, ready to pick up one as soon as autonomous is over.

(Note: this particular run of our autonomous was not successful, but it’s the only one that wasn’t blurry from the speed of our 'bot.) :stuck_out_tongue:

this auto mode is really awesome when it works…

one match they went out, scored the keeper, went around the rack and knocked the keeper out of another teams grasp i think it was 69…pretty awesome

Dead reckoning auton?

Ambitious plans nontheless, looks like you had everything necessary to be successful most of the time. Big ideas and simple designs, good job.

Brilliant! You’ve managed to come up with a package that does something useful in all situations, even if the primary goal fails - potential auto score, auto defense if needed, and a good setup for manual mode. That’s excellent design.

Just out of curiosity, how frequently did it score?

Not really, everything is controlled by sensors. We didn’t use the CMUcam, but we used nearly every other sensor imaginable, and the code was written to make full use of them.

Actually, Beantown Blitz was the first competition of the year we attempted this autonomous routine. We wrote the main framework before the event, but we literally ran it for the first time ever in our first practice match. We had to tweak all the PID loops, sensor distances, etc. at the event. In case anyone was wondering, we’re using WPIlib (e.g. the backbone of EasyC but without the graphical interface) for all our coding.

We scored the keeper successfully once, and a few other times we came --><-- close. We still have a few things to tweak in the code (right now the PID loop for the elevator is running a tad bit slow, which would sometimes cause us to be a few inches below the spider leg because the elevator had not quite gotten to the right height when the robot drove past the spider leg.

We’ll probably work on trying to improve it for BattleCry@WPI over the next few weeks. I’m tempted to try and see if I could use an IR or ultrasonic sensor to pick up the bottom diamond plate of the rack, so if the rack is moved a ton before the match and the robot is too far away during the drive-by, it could back-up, turn closer, and try again.

We’ll also probably work on implementing a accelerometer/gyro combo as a “safety valve” for autonomous: basically if the robot sees any sudden, unexpected spikes in acceleration/turning during autonomous, the robot can assume something is wrong (e.g. was hit by another robot), and it will instantly kill the rest of autonomous mode. (Because we use encoders on the wheels for gauging much sequence of events for autonomous, if the robot is stalled against another robot in auto mode, we don’t want stall current going to our drive train for the remaining time.)

Otherwise, it works like a charm. If you look in this picture, we’re already scoring on the rack in auto well before teams who use the CMUcam have even found the target lights, which works great for an score-the-keeper, get-in-their-way, then-park-next-to-ringers autonomous. :cool: