PIDController: setSetpoint causes onTarget to be false #29
|
Actually, we only need to keep a buffer of inputs. Here's some math: a, b, c, and d are inputs. s is the setpoint. "s - a" is the error with respect to a. Currently, we average the errors in GetAvgError(): Therefore, GetAvgError() could instead return the current setpoint minus the input average. This would make anything using GetAvgError(), like OnTarget(), more robust to setpoint changes. |
|
This was closed in #138, which was reverted... so I presume that this bug still exists? This should be reopened in that case. |
|
How should we go about fixing it this time? Apparently using doubles in a large FIR filter (moving average) causes rounding errors due to so many additions. We could approximate it with an IIR filter and avoid that problem. Using a cutoff frequency isn't necessarily intuitive, but it provides more tuning hints than the size of the FIR filter does. Teams would probably tune both by guessing and checking anyway. |
The core of the problem is that
onTargetis calculated using theerrbuffer, which gets cleared when a new setpoint is set. This behavior is incorrect --onTargetshould not depend on the history of the setpoints (which is how error is calculated), but instead it should only depend on the history of the inputs as that's really the question a user is asking when calling onTarget: "is the input [history] close to where I want it to be?"To that end, I propose that a buffer of inputs is kept in addition to a buffer of errors, and use the inputs to calculate
onTargetinstead. This buffer would only be cleared when the PIDController is disabled.