View Single Post
  #3   Spotlight this post!  
Unread 26-03-2011, 23:04
davidthefat davidthefat is offline
Alumni
AKA: David Yoon
FRC #0589 (Falkons)
Team Role: Alumni
 
Join Date: Jan 2011
Rookie Year: 2010
Location: California
Posts: 792
davidthefat has much to be proud ofdavidthefat has much to be proud ofdavidthefat has much to be proud ofdavidthefat has much to be proud ofdavidthefat has much to be proud ofdavidthefat has much to be proud ofdavidthefat has much to be proud ofdavidthefat has much to be proud ofdavidthefat has much to be proud of
Re: The Hardest Drive System To Program:

Quote:
Originally Posted by basicxman View Post
> Failure checking (state machine, redundancies)
If a sensor relating to your drive system fails, what is going to happen to your robot? A lot of teams run a separate task on the cRio that monitors for failures and then triggers a state change when a failure occurs. For instance let's say a gyro stops reading values, rather than making the robot spin in circles, the drive system would ignore gyro values.

Redundancies being increased reliability of a drive system, http://en.wikipedia.org/wiki/Redundancy_(engineering)


> Human error correction
How much money would you put on the fact that your driver can hold two joysticks at 50% throttle precisely? Probably not a lot.

> Mechanical error correction
Motors aren't made equal. Two motors of the same model will rarely go at the same speed. Using encoders and other techniques to correct this.

"Safe Mode": If triggers, switches to bare bone drive code.
Multiple sensors to "check" each other

We just used dead zones for the human error part

We didn't use the encoders because there was too much noise that I did not trust them enough to use it.
__________________
Do not say what can or cannot be done, but, instead, say what must be done for the task at hand must be accomplished.