I'm not 100% sure, but it seems like that's their way of guarding against integral windup.
In case you (or another reader) isn't familiar with integrator windup,
From
this website
Quote:
|
Integrator windup is a condition that results when integral action saturates a controller without the controller driving the error signal toward zero. If the integrator does not have saturation, then it can increase without bound, and without leading to faster system response.
|
I think that by dividing by pid_time, your integral term gets progressively smaller and thus prevents integrator windup.
By not resetting your integral term it seems like you're basically saying "I've been trying to reach my target for a long time, and therefore applying extra power" even though you're now moving to a new target. It feels like this should mess up your first cycle with a new target. It should correct itself on the second time through the loop when you recalculate your integral term, but it seems like you could have a huge overshoot on the first cycle.
Consider this example.
Code:
* Using Kp = 1, Ki = 1 for the sake of argument
* Ignoring the pid_time division
* Assume some scaling of output
Set Point 200 200 70
Current Pos 50 60 70
Error 150 140 0
-------------------------------------------------------------
P term 150 150 0
I term 150 290 290
-------------------------------------------------------------
P*Kp + I*Ki 300 440 290
This shows that even though you are at your setpoint, your output is still 290. Subsequent loops would decrease your I term, but it would still have to make its way back down to 0 and most likely a negative value to counteract the overshoot. With a more reasonable Ki this shouldn't be as bad, but it is still present.
Can somebody with a better understanding chime in to help explain?