|
|
|
![]() |
|
|||||||
|
||||||||
|
|
Thread Tools | Rate Thread | Display Modes |
|
#1
|
|||
|
|||
|
Velocity PID(F) Best Practices - To Integrate, or Not To Integrate?
There seems to be a general lack of agreement about the best way to handle velocity PID loops.
In particular, in comparison to position PID loops, velocity PID loops present us with a problem: In a position PID loop, there is a natural integrator between the loop output (motor voltage, which corresponds roughly to velocity) and the setpoint, since the position is the integral of velocity. On the other hand, in a velocity loop, there is no such integrator. Thus, the two loops behave, at a fundamental level, extremely differently. This much is known to basically anyone who has ever used a velocity PID loop. One solution to this, currently employed by WPILib, is to integrate the output of a velocity loop (save for the feedforward term, for obvious reasons). This serves to make the relationship between the loop output and the setpoint more closely resemble that of a position loop. Effectively, this is the same as turning the 'p' term into what was, pre-integration, the 'i' term, and turning the 'd' term into the 'p' term (since, per the fundamental theorem of calculus, the integral of the derivative of the error is simply the error itself). However, I've also heard many teams state that, with use of a feedforward term, there is no need to do this and simply using a non-integrated loop predominantly tuned with the P term suffices. I, myself, am not quite sure what to make of this, for several reasons: For the first method, the 'd' term in an integrated velocity loop (i.e. the 'p' term in a non-integrated loop) really doesn't behave entirely like the 'd' term in a position loop; the aforementioned fundamental-theorem-of-calculus argument only indicates that their effect on the endpoint behaves similarly up to some constant offset - and this constant may be nonzero, depending on how 'd' responds to changes in setpoint (e.g. if my setpoint is 1, and my measured endpoint is 0 and has not yet started to change, the resulting 'd' term of an integrated velocity loop will be some positive constant, but the 'd' term of a position loop would be 0 - only the effects of the changes to the two terms from this point are analogous). Moreover, motor voltage does not precisely correspond to velocity (if it did, we'd have no need of a control loop!), and so this causes differences in behavior, as well. However, for the second method, the 'p' term of a non-integrated velocity loop certainly does not behave like the 'p' term of a position loop, so tuning around 'p' in a non-integrated loop (even in the presence of a feedforward term) has never made much sense to me. I can totally believe that it works, but it does seem like it would be closer (but, as per the previous paragraph, not analogous) to tuning around the the 'd' term of a position loop rather than the 'p' term, and that is confusing. I know many teams (including mine) tune around the 'p' term of an integrated loop (i.e. the 'i' term of a non-integrated loop), even when using feedforward. This seems to work very well for us, but I've seen many teams say that they do not use this term at all for their velocity loops. So, is there any consensus about this, at all? Last edited by Oblarg : 17-11-2016 at 17:15. |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|