Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fw_att_ctrl: integrator output is not scaled with IAS^2 and FF not with TAS #15041

Closed
CarlOlsson opened this issue Jun 5, 2020 · 7 comments
Closed
Assignees

Comments

@CarlOlsson
Copy link
Contributor

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
@hamishwillee
Copy link
Contributor

@bresch Can you comment on this - ie do we need to amend the docs?

@bresch
Copy link
Member

bresch commented Jun 11, 2020

@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.

@CarlOlsson
Copy link
Contributor Author

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.

image

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.

@bresch
Copy link
Member

bresch commented Jul 3, 2020

@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.

@CarlOlsson
Copy link
Contributor Author

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.

@supergra
Copy link
Contributor

supergra commented Jul 4, 2020

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 #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%.

@supergra
Copy link
Contributor

I suggest closing this.

  1. IAS^2 integration is fixed in FW attitude control scaling fixes and cleanup #15256
  2. TAS scaling for FF is already tracked here: Fixedwing: implement TAS output scaling for FF #11975

@bresch bresch closed this as completed Jul 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants