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

[artdutra04]

loading photo ...

[Brandon Holley]

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

[JesseK]

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.

[vhcook]

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?

[artdutra04]

Originally Posted by JesseK

Dead reckoning auton?

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.

Originally Posted by vhcook

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?

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.