View Single Post
  #5   Spotlight this post!  
Unread 23-05-2007, 20:11
artdutra04's Avatar
artdutra04 artdutra04 is offline
VEX Robotics Engineer
AKA: Arthur Dutra IV; NERD #18
FRC #0148 (Robowranglers)
Team Role: Engineer
 
Join Date: Mar 2005
Rookie Year: 2002
Location: Greenville, TX
Posts: 3,078
artdutra04 has a reputation beyond reputeartdutra04 has a reputation beyond reputeartdutra04 has a reputation beyond reputeartdutra04 has a reputation beyond reputeartdutra04 has a reputation beyond reputeartdutra04 has a reputation beyond reputeartdutra04 has a reputation beyond reputeartdutra04 has a reputation beyond reputeartdutra04 has a reputation beyond reputeartdutra04 has a reputation beyond reputeartdutra04 has a reputation beyond repute
Re: pic: GUS Team 228's 'Drive-by' Autonomous

Quote:
Originally Posted by JesseK View Post
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.
Quote:
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.
__________________
Art Dutra IV
Robotics Engineer, VEX Robotics, Inc., a subsidiary of Innovation First International (IFI)
Robowranglers Team 148 | GUS Robotics Team 228 (Alumni) | Rho Beta Epsilon (Alumni) | @arthurdutra

世上无难事,只怕有心人.
Reply With Quote