From my previous research on this issue there is a bug; and from what you say it has not been fixed:
A safety concern about throttle changes lead to a change in:
flight/libraries/math/pid.c
and my quick research indicates that caused the issue.
It would be a great help if you are building next that you make this change and see if it fixes it for you. In the file:
flight/libraries/math/pid.c
You are looking for the line (probably exactly line 222, there is only one line like this in the file):
pid->I = 0.0f;
and replacing it with:
// pid->I = 0.0f;
// whether ki is zero or non-zero, when doing 'reconfigure' we start with setpoint==actual
pid->I = (pid->u0 - pid->va) / pid->vb;
// if ki is non-zero
if (pid->bi > 5e-7f) {
// then the output can wind up/down to get rid of a difference between setpoint and actual
// so we can generate the full bumpless transfer here
// else leave off the part that can vary due to difference between setpoint and actual
// so that it is repeatable (for tuning purposes at least)
pid->I -= pid->kp * (pid->beta * r - y);
}
[/color]
Programmer notes:
Here is what I believe is the offending line in my oldish version of next:
(from git blame fb5f9034 (Eric Price 2017-03-09 18:48:36 +0100 222) pid->I = 0.0f;)
// pid->I = (pid->u0 - pid->va) / pid->vb - pid->kp * (pid->beta * r - y);
// this is dangerous, if pid->I starts nonzero with very low or zero kI, then
// it will never settle!
pid->I = 0.0f;
In my personal version I previously noted and fixed it like this which does not have this issue:
// pid->I = (pid->u0 - pid->va) / pid->vb - pid->kp * (pid->beta * r - y);
// cliff changed this to avoid initing a windup that will never unwind if ki is zero
// damn
// (FYI: after pid2_configure(), the next call to pid2_apply() causes 'reconfigure'
// where the following happens while making the transition "bumpless"...)
// the difference between neutral and I term unwind center generates a positive offset for output (not useful)
// the difference between setpoint and actual generates a negative offset to exactly counteract the new P value
// recall that P is generated from this difference times the constant Kp
// these tweaks get put in the I term
// the problem is that if ki is zero, the I term will never wind up or down,
// so you are stuck with the offset you had when you entered that mode
// and that offset could be high or low, positive or negative,
// depending on what you did with the stick just before entering the new mode
// example: thrust: falling toward ground you give full throttle but it is currently still falling
// solution is to ignore the part of this I term offset that comes from the difference between setpoint and actual
// whether ki is zero or non-zero, when doing 'reconfigure' we start with setpoint==actual
pid->I = (pid->u0 - pid->va) / pid->vb;
// if ki is non-zero
if (pid->bi > 5e-7f) {
// then the output can wind up/down to get rid of a difference between setpoint and actual
// so we can generate the full bumpless transfer here
// else leave off the part that can vary due to difference between setpoint and actual
// so that it is repeatable (for tuning purposes at least)
pid->I -= pid->kp * (pid->beta * r - y);
}
I really need to write up some of these issues I have documented...