Like many teams this year, we are using a PID controller and a gyro to aim our robot at the high goal (after acquiring the target heading using our vision system).
Our PID controller has been tuned so that it is pretty consistent, but I would like to try to eliminate the small amount of error that is present when the robot stops moving, which causes us to sometimes miss shots.
This problem seems to be mainly caused by the mechanical deadband of the drive system (ie. the amount of throttle that is required before the robot actually starts to rotate). If I increase the I term enough to eliminate the error, the robot starts oscillating for a long time before it finally settles.
As a lot of teams have had to deal with this same situation, I was wondering if anyone had any tips or tricks to improve the automated turning performance of the robot.
This is a constant source of annoyance for doing precise turning with high-friction wheels. Some solutions that have worked for us in the past:
Figure out what the minimum required output is to get the robot to turn at all. If the PID output is less than this magnitude, output this magnitude (with the same sign as the PID output).
Instead of using your heading PID loop to generate PWM commands directly, use it to generate velocity commands that a second PID loop on each side of the drive will attempt to follow. Note that good velocity control at low speeds requires a really fast control loop and accurate velocity measurement. The CAN Talon SRX and CTRE Mag Encoder have impressed us in this regard.
Motion profiling can help (a bit) to ensure that the robot smoothly glides to its final heading, but this method works best in conjunction with 1 and/or 2.
Wouldn’t this cause oscillations, if the output switches between positive and negative of this magnitude?
As a related idea that I had, I wonder if it would make sense to find some magnitude where the robot almost turns (but is still stopped) and add it to the PID output. Maybe it would simulate low friction or something.
In practice you are typically moving so slowly at this minimum output that the oscillation shouldn’t be a problem (you probably have a small deadband around the setpoint at which point you say “good enough” and cut power).
Adding a minimum term to the output is also a totally valid approach that accomplishes the same thing and only differs in the details.