Describe the bug
The devguide has excellent documentation of the required airspeed scaling for fixed wings
https://dev.px4.io/master/en/flight_stack/controller_diagrams.html#airspeed-scaling
However, the implementation does not follow this
1) The output of the integral controller is not scaled with airspeed at all
2) The output of the FF term is scaled with IAS instead of TAS
@bresch Can you comment on this - ie do we need to amend the docs?
@hamishwillee It's only wrong in the code, we verified the equations in the docs recently, so we don't need to change anything in the docs.
I have been thinking about this a bit more and now I believe that the code might be correct but the dev guide wrong regarding the integrator part.

The integrator part is mainly there to compensate for Cm0, going through the math gives the value as delta_e = -Cm0/Cm_delta_e, for Cm_alpha=0, q=0 and M=0, which is independent of airspeed.
@CarlOlsson Yes, that makes sense if the purpose of the integrator is to compensate for Cm0 only. In my derivation I assumed that P and I were used to produce a constant torque, regardless of the airspeed; this is why the integrator is scaled like the proportional term, with IAS^2.
As you mentioned in your derivation: delta_e_trim = -Cm0/Cm_delta_e is a constant value that can be set by the operator during the trimming phase.
I think both interpretations make sense, whether you want to use the integrator as an "auto-trim" or to reduce the tracking offset during maneuvers.
Okey thanks for the clarification. Maybe having both could actually make sense. We only have a slow integrator, not scaled with airspeed and initialized to the mean value from the last flight. This makes it possible to learn aircraft differences both directly from production and over time.
But as you said, a faster integrator scaled with airspeed would also improve the tracking during maneuvers.
1. The output of the integral controller is not scaled with airspeed at all
To be clear, the roll and pitch integrators _do_ currently include the scale _when accumulating_ (although the scale was IAS instead of IAS^2, which I fixed in https://github.com/PX4/Firmware/pull/15256). They just don't apply the airspeed scaling to the final integrated output.
I would argue strongly that the current behavior is best. When using relatively high FW_YR_IMAX (allowing the integrated term to grow large):
1) changes in airspeed lead to large fluctuations in the control. (The yaw controller actually applies the scale after accumulating, and we saw big problems with it on our aircraft.)
2) The FW_YR_IMAX value is not respected. If you set it to 0.5, and then your airspeed scale goes to 1.5, it will suddenly permit the integral term to deflect the control surface by 75%.
I suggest closing this.
1) IAS^2 integration is fixed in https://github.com/PX4/Firmware/pull/15256
2) TAS scaling for FF is already tracked here: https://github.com/PX4/Firmware/issues/11975
Most helpful comment
@hamishwillee It's only wrong in the code, we verified the equations in the docs recently, so we don't need to change anything in the docs.