With airspeed scaling applied (by turning on the ground minus wind based airspeed estimation), the ‘fluttering’ issue is now finally gone (rate overshooting and oscillating around the rate setpoint), which makes sense!
However, now I observed that there’s an (almost) bias / barrier between the rate setpoint vs achieved rate. As shown in screenshot below, the rate setpoint for roll is hardly ever reached.
From the fact that as soon as the ‘setpoint’ decreases, the rate follows that direction as well, I can now conclude that the controller is too overpowered with FF gain (hence, the ‘setpoint’ is basically driving the whole control, with no feedback).
You can notice that FF term is the majority of the PID-FF outputs are dominated by the FF gain in the PID component log that I added.
Notes
However, I noticed that integral value for roll barely changes when there’s constant rate error, and it is due to the following feature on reducing I-gain upon big rate error (as P or FF term should do that job)
Also, I’m not sure why the integral value for the rollspeed is ‘decreasing’ when there’s always a positive error (setpoitnt - current rate), for example throughout 9 ~ 14 seconds mark in the graph above
I can’t think of any reason how this could happen.
TODOs
So what I would do are:
Decrease FF gain to 0.05 or smaller (was 0.1 here)
