The speed controller suffers from kicking behavior when the set point changes.
Background
I noticed that a higher D gain causes higher overshoots when running step experiments, which is the opposite of what it is supposed to do.
Looking at the code both the speed and position controller uses error - previous_error when calculating the D term.
So when the set point changes quickly, the D term will become huge in the following calculation step, resulting in extremely aggressive output.
The effect of the kick is partially hidden by the D term filtering and ramping, but it was still noticeable when running experiments.
Suggested solution
The position controller have already implemented a fix for the kick by introducing a d_proc term, which uses the difference in states instead of the difference between errors.
I suggest the same is done for the speed controller (that is, if the current calculation can't be replaced entirely for compatibility reasons).
I could try to create a pull request that implements this fix if there is any interest.
The speed controller suffers from kicking behavior when the set point changes.
Background
I noticed that a higher D gain causes higher overshoots when running step experiments, which is the opposite of what it is supposed to do. Looking at the code both the speed and position controller uses
error - previous_error
when calculating the D term. So when the set point changes quickly, the D term will become huge in the following calculation step, resulting in extremely aggressive output. The effect of the kick is partially hidden by the D term filtering and ramping, but it was still noticeable when running experiments.Suggested solution
The position controller have already implemented a fix for the kick by introducing a
d_proc
term, which uses the difference in states instead of the difference between errors. I suggest the same is done for the speed controller (that is, if the current calculation can't be replaced entirely for compatibility reasons).I could try to create a pull request that implements this fix if there is any interest.
Also...
I noticed that the output calculations at https://github.com/vedderb/bldc/blob/19ce7ebe48718fce3a654eb5ced17a661ebaaf6f/motor/foc_math.c#L508 uses
lo_current_max
instead ofl_current_max
, sol_current_max_scale
is effectively applied twice to the output, but that's a separate issue.