Yaw feedforward improvements for 4.6 #13576
Conversation
|
Do you want to test this code? You can flash it directly from Betaflight Configurator:
WARNING: It may be unstable. Use only for testing! |
|
This image shows my standard test quad, configured with normal props and my standard tune, with three different values for feedforward on yaw: 40, 80, and 132. Lower values result in lag, overshoot and bounce-back, with significant iTerm accumulation Higher values result in almost no iTerm accumulation, net neutral P, and no bounce-back. There is a short overshoot spike at the start. In practice this is of no consequence. It's not difficult to adjust the FF from this PR. There is zero iterm leak configured. 
|
ctzsnooze
requested review from
ledvinap,
KarateBrot and
McGiverGim
and removed request for
KarateBrot
|
This image is from a quad with limited yaw authority and a high requested yaw spin rate. This reliably hits pidSum limit at the start of a yaw spin, but not the stop. With my standard PIDs - yaw feedforward at 130 - there is moderate iTerm accumulation, in the direction of the spin, and after the spin is completed, some slow late bounce-back as iTerm dissipates. With yaw feedforward increased until iTerm doesn't accumulate as much at the end, ie around 170, there is almost no discernible bounce back, since there is very accumulated iTerm to remove. 
|
|
I_FF.txt |
|
@mituritsyn Thanks for testing! Flight is perfect - very grateful! |
|
@ctzsnooze It was more than a week ago, I don't remember the feeling from the flight) from the video there was something like a bounce back a few times, but from the log I can see that it was a command from the sticks. actually I am confused by the fact that on acceleration the quad from some point stops following the setpoint, but on braking it doesn't happen. Maybe it's due to uneven weight distribution with the camera that creates a parasitic non symmetric momentum |
Many thanks to der_V / RubberQuads for his original idea to add a sustained element to yaw feedforward, based on an exponentially decreasing 'set point' value.
This PR implements the idea by applying a simple high-pass filter over yaw setpoint, which returns a feedforward value with an initial fast rise and then an exponential decay which is added to the 'normal' feedforward on yaw.
In this PR these changes are applied over the
iterm_windupchanges from PR #13543, because I anticipate that #13543 will be merged before this PR. The two are, in a sense, complementary, and both seek to improve yaw performance.The decay rate and the relative contribution of this element are currently fixed, but could be opened up to the CLI if necessary.
With this we get very significant reductions in the amount of iTerm accumulation, leading to reduced lag, and excellent setpoint tracking. Bounce-back after stopping fast yaw spins is almost non-existent.
The relevant code changes are entirely done in rc.c. Because the value is based on setpoint, and not on a derivative, it is less noisy than normal feedforward, and requires less filtering and smoothing. Jitter reduction cannot be applied since that would zero the sustained element out while sticks are still, but jitter reduction is not required since the setpoint factor does not respond aggressively to noise, as does the derivative and the second derivative elements in normal feedforward.
Since the yaw setpoint value is the integral of the basic feedforward element, this factor could be considered equivalent to a strongly leaky integral of feedforward. In fact part of the concept of using a highness to provide the exponential decay came from the 'leaky iterm' idea in PR #13574.
This graphic shows the typical feedforward curve that we get, when we do a rapid yaw spin, with standard feedforward on the left, with the 'leaky iterm' to limit bounce back, vs the stronger feedforward in this PR with the exponential decay from the setpoint factor. This is on a special low authority quad, a 5in build with 3in props. Note how, on the right, there is much less iTerm buildup, and that less P is required. PIDS are close to 'normal' tune for this build - yaw P is 45, I is 80, and FF 130 - in both cases.
If the user has too much feedforward, the quad will tend to overshoot the target at the start, and get immediate fast overshoot and return at the end. If there is too little, there will be lag and then iTerm builds up a lot, and we get under-shoot and bounce back.
The default values are pretty good for standard builds, most users don't need to change anything. No special debugging is needed because standard logging provides all the needed information.
By not adding new debugs, and with the removal of
iterm_limitand some of the olderiterm_windupcode, as well as some small refactoring changes in feedforward.c, the net effect of this PR is to save 72 bytes of ITCM flash compared to master.