leaky iTerm on yaw

[ctzsnooze]

This PR adds a small re-centering factor to yaw iTerm. The rate of re-centring is proportional to the amount if iTerm on yaw, and can be adjusted using the iterm_leak CLI value.

A value 10-15 can be useful for very small but persistent bounce-backs, with little or no apparent change in overall flight behaviour. A value much over 60 causes quite substantial pull back towards zero, with more obvious loss of bounce-back, and perhaps some decrease in heading stability when attempting to fly straight ahead or on very gentle arcs.

The leak helps to attenuated bounce-back after fast yaw moves, which tend to accumulate a lot of iTerm.

If set too high, it may have negative effects on the ability of the quad to accurately maintain heading, since iTerm will continually be recentered, rather than accumulating to control small persistent errors.

I am not 100 sure that this is needed, but it definitely can help with some yaw iTerm bounce back behaviours.

A much better proposal is in the companion PR which modifies feedforward on yaw. This minimises the root cause of the excessive iTerm growth during fast yaw inputs, making a 'leak' in yaw iTerm less important than otherwise.

[github-actions[bot]]

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

• Simply put #13574 (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!

[ledvinap]

@ctzsnooze : Leaky iterm is in fact lowpass filter. Above filter cutoff, it behaves as integrator. So it may be better to express leak factor in term of cutoff frequency, or, in this case, filter time constant.

(edited)

[ctzsnooze]

I've done a lot of LOS testing and logging. The PR needs a LOT of general testing on low authority builds. Behaviour when motors saturate should be improved. Much of the change will be quite subtle, I think.

This image shows a special low-authority quad (3in props on a 5in) where I do some yaws. P is 55 and I 130 for these flights. Master on left, this PR with leak of zero, then on the right, with a leak setting of 80. No change between master and this PR unless the leak is added. When the leak is added, the tendency to overshoot and bounce back is gone.

This image shows the outcome when P is 55 and I is 80, at values for leak of 0, 20 and 50. Cursor is set on maximum bounce-back point, which is -14, -7 and +3 deg/s respectively. Note the yaw P trace which tracks error. There is a reverse P trace at the end of the yaw spin on both of the two left curves, indicating P opposing excess iTerm. To the right this does not happen. The optimal leak value for this build, with these values, is likely somewhere around 30-35.

It may seem like all the 'leak' does is 'diminish iTerm'. It's not quite so simple. Here I compare I of 65, with no leak, vs I of 80, with a leak of 50. The peak amount of iTerm is very similar, but there is significant bounce back when there is no leak.

[ctzsnooze]

This is an example where I set motor_output_limit low enough that yaw spins cause motor saturation. Note that iterm_windup fails in master because the pidsum_limit_yaw of 400 prevents full motor saturation in master. Hence both master and this PR appear very similar.

Note the characteristic and abrupt decrease in yaw rate acquisition when motors saturate.

In master there is some bounce-back but not really bad. With (probably a little too much) leak (80), there is no bounce back and a tendency to under-shoot.

[ctzsnooze]

@ledvinap - yes, I agree, if this goes ahead, it would be best to implement it with a time constant or cutoff frequency. I am hoping that the feedforward changes will make it unnecessary.