View Single Post
  #7   Spotlight this post!  
Unread 22-05-2014, 21:53
AustinSchuh AustinSchuh is offline
Registered User
FRC #0971 (Spartan Robotics) #254 (The Cheesy Poofs)
Team Role: Engineer
 
Join Date: Feb 2005
Rookie Year: 1999
Location: Los Altos, CA
Posts: 802
AustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond reputeAustinSchuh has a reputation beyond repute
Re: 971's Control System

Quote:
Originally Posted by billbo911 View Post
I'm inviting Austin Schuh, and anyone else associated with 971, to "open the Kimono" a little and let the rest of CD learn from their innovative approach to controlling a robot.
We do a couple of things that are unique to 971, at least among the teams that we interact with frequently. We only use encoders, because we can get significantly lower noise and more accurate signals from encoders. The noise in a potentiometer and the noise in the ADC is comparable to the angle that we adjust the claw for shots. If you work out the math, moving the ball down by 4”, 20 feet back is 0.015 radians. That isn’t very much when you move your claw close to 5.5 radians. We can also pull out a cleaner velocity estimate from an encoder, and use that to tighten our loops up. Using encoders does mean that we don’t have an absolute sensor, so we don’t know what ‘zero’ is until we go through a homing sequence. We choose to use hall effect sensors for this purpose, and to register interrupt routines which capture the encoder value on the rising edge of the hall effect sensor. We were seeing somewhere about 0.001 radians of repeatability this year using hall effect sensors. We use the same trick for calibrating the pusher in our shooter.

After 2011, we haven’t had a single mechanical sensor on our robot since. We only use optical sensors, sonar sensors, hall effect sensors, encoders, and potentiometers. We were finding that the sensors were being triggered by vibration, and that was causing us lots of problems.

Every match, we log somewhere around ~100 MB of data on the BBB. This lets us do lots of post match failure analysis. If our driver tells us that when he did X, 35 seconds into the match, or right at the end of the match, or …, the robot did Y instead of what it should have, we can go back in the logs and figure out exactly why it was misbehaving. This also means that most times when the robot misbehaves, we only have to observe the failure once before we have a pretty good idea about what happened and can deploy a fix to prevent it from happening again. This has saved us many times.
Reply With Quote