Apply iterm_windup per-axis by limiting iTerm based on pidSum

[ctzsnooze]

This PR 're-purposes' iTerm windup, setting per-axis limits on iTerm based on pidSum for the axis, rather than limiting iTerm on all axes at once when motorMix is high. The old iterm_limit value is removed from the CLI, as is the old iterm_windup code that was based on motorMix.

It is a simpler PR that can probably be considered a bug fix for 4.5.

Probably won't make much difference in flight for most quads, but may be a bit more stable after minor impacts and should accumulate a little bit less iTerm on yaw on low authority builds. iTerm windup will have a stronger effect than before when constraining iTerm.

It replaces #13506, which I've closed. It is a companion PR to: PR #13576, which improves the feedforward element for yaw, over the top of this PR

This new feedforward method for yaw solves many of the issues related to iTerm accumulation on yaw by driving the yaw almost entirely from feedforward.

Instead of using MotorMix to constrain iTerm growth, on all axes, when motors approach saturation, this PR calculates an iTermLimit value for each axis based on the product of the user's iterm_windup and pidSumLimit / pidSumLimitYaw values.

In contrast, previously, if any one axis caused MotorMix to reach 100%, iTerm growth on all axes was prevented. The argument in favour of this was that iTerm might grow inappropriately on the other axes because control could not be normal with motors maxing out. However iTerm is the primary factor in the return to the previous heading after an uncommanded disturbance. It is more likely to return to the correct heading, on a given axis if iTerm can accumulate and de-accumulate normally. For example, a roll on a quad with a centre of gravity issue, fast enough to cause motors to max out on roll, is often associated with a transient pitch error. The quad would be more likely to return to the previous pitch attitude, at the end of the roll, if iTerm on pitch accumulated normally despite the motors being maxed out due to Roll. This PR will keep pitch iTerm accumulation independent of roll, and do the same for yaw, so that at the end of a wonky roll, the quad should return to the previous heading and pitch angle.

iTerm limiting in this PR happens when pidSum gets close to a value which, for that axis, would max out the motors. How close it gets can be adjusted using the iterm_windup parameter.

For example, with a default value for pidSumLimit of 500, and the new default iterm_windup value of 80, the limit on iTerm for Roll and Pitch will be 400. This is the same as the old iterm_limit value of 400. This will not allow iTerm to take more than 80% of the available pidSum space for a given axis.

A lower than default iterm_windup would, in this PR, limit iTerm earlier in situations where the quad was unable to achieve a requested target yaw rate.

Yaw has a default pidsum_limit_yaw value of 400, and hence yaw iTerm will be limited to 80% of 400, or 320. Previously the yaw iTerm limit would have been the same 400 value as per pitch and roll, so this is a little bit less than previously.

In the unlikely event that more iTerm on yaw is required, the user can increase the overall pidsum_limit_yaw value. However, high iTerm on yaw, like other axes, tends to lead to overshoot and bounce-back. The new feedforward proposed for yaw greatly diminishes the need for high Term on yaw, and fits well with these changes.

Note that previously it was possible for iTerm to grow on yaw to 400, even though the Pid Sum on yaw was limited to 400. This reduced the ability of yaw P to adjust yaw until iTerm fell considerably below 400. Now there is room for some P activity even when iTerm is at its limit, on yaw as well as on the other axes.

[github-actions]

Do you want to test this code? You can flash it directly from Betaflight Configurator:

• Simply put #13543 (this pull request number) in the Select commit field of the Configurator firmware flasher tab (you need to Enable expert mode, Show release candidates and Development).

WARNING: It may be unstable. Use only for testing!

[ctzsnooze]

These images demonstrate the altered iTerm Windup behaviour.

All are from a yaw-challenged quad, with smaller than normal props, targeting a high yaw spin rate. The quad requests pidSum values greater than the pidSum limits.

First image.... On the left, this PR with iterm_windup at default 80, vs Master on the right, with default iterm_windup of 85. pidsum_limit and `pidsum_limit_yaw are at default in both. The axis being displayed is yaw.

Note that the final motor outcome, lag and bounce-back is similar in both cases. The old motorMix method sort of slows down the iTerm accumulation at the start, since the limit is gradual, and doesn't hit 100% limiting unless motors hit 100%, and they aren't doing that. This PR, on the other hand, absolutely limits iTerm growth at the limit.

Second image.... This ompares master on the left to this PR in the middle, both with iTermWindup at 50%. The PR variant definitely constrains iTerm harder, such that it cannot exceed 200. This results in a period of iTerm-limited lag. But there is significantly less bounce-back, due to diminished iTerm accumulation, and once the pidSum limit is no longer reached, control is back to normal.

The image on the right shows this PR plus the new feedforward, with default itermWindup of 80%, in the same yaw limited quad. iTerm is limited to 320. We see the same lag period at the start once pidSumYaw hits its limit of 400. Iterm grows more than when the limit is 50. There is some slow, late bounce-back caused by the need to get rid of the accumulated iTerm. Stronger feedforward on this yaw limited quad would push harder at the end of the spin, where pidSumLimitYaw is not reached, and would attenuate it.