Quote:
Originally Posted by SuperBK
We want to implement a PID for velocity control of the left and right motors. We understand how a position PID works, but for a velocity control, when the motor reaches the desired velociy, the error will be zero, therefore, it will only have the I and D terms to keep it driving. Is that enough? In this case would the integral sum never be cleared?
About resolution: Right now we get around 1200 counts per second at full speed from the gear tooth sensors. If we wait for 100ms that will give us a speed range of 0-120. Should the PID calculation only run at the same rate? If the PID loop runs ever 26 ms, it will aleady have run three times before we have a speed update. Whats a good balance of PID loop time to data update time?
Is the 26.2ms main loop stable enough to run the PID in or should it have its own timer?
Thanks,
Brian
|
Brian, I'm referencing Kevin Watson's Navigation code that can be found at:
http://frc.kevin.org/frc/2005/. It includes both speed and velocity PID control routines. We've used these in the past with a good amount of success. They can provide a good reference for what you're doing.
The code samples the change in encoder pulses each 26ms cycle, and that's your PID input. The PID and speed updates are both done in the 26 ms cycle, and it appeared to be stable enough, as the main loop is timer driven as well. We used this with Grayhill encoders pulsing at under 2000pps at full speed, and got good velocity control.
Regarding "I," when we hit our desired velocity, the system overshot until negative error, and eventually our "I" term decayed. Under straight driving conditions, it wasn't really that noticeable, because the system reacts fast enough that a large I never really accumulates. This WAS really noticeable when we turned our robot about its axis. The system didn't react as fast because there is a lot more resistance turning on axis, than driving in a straight line, so "I" had the opportunity to wind up a lot more. This resulted in a lot of overshoot... uncontrollable overshoot.
Do you really need an "I" term at all in velocity control? Maybe
, because your system's characteristics change depending on whether you're going straight, or turning, or whether you're being pushed. "I" is a pretty good way of handling all those difference situations, except for the overshoot it causes.
You'll find that a lot of teams do talk about interesting ways to selectively use "I" in velocity control, but I'm definitely not the right person to be commenting about that!
-Shawn...