Added PerformanceModel for fixed wing

[RomanBapst]

Solved Problem

Replaces #22049 and #22045

• moved performance related calculations and compensations out of fixed wing position controller and into separate class
• added compensation for weight and density of max climbrate and min sinkrate
• added compensation for weight of trim airspeed (goal is to keep alpha constant)
• added compensation for weight of minimum airspeed

Changelog Entry

For release notes:

Feature/Bugfix XYZ
New parameter: FW_S_CEILING
Documentation: Defines the alttitude MSL in standard atmosphere at which the vehicle can still achieve a climbrate of 0.5m/s at trim airspeed and maximum throttle.
Feature: Compensate TECS minimum sink speed for weight ratio and air density.
Feature: Compensate TECS maximum climb speed for weight ratio and air density.
Feature: Compensate calibrated trim airspeed for increased load factor due to weight.
Feature: Compensate calibrated minimum airspeed for increased load factor due to weight.
Documentation: Need to clarify TECS tuning.

Test coverage

• ?

Followup PRs

• user guide docs for performance model
• update FW_THR_TRIM description to indicate that this is an calibrated throttle value. We need to back calculate from the density flown during tuning to sea level. -- include how-to in docs
  • idea: just log the calibrated_throttle anyway for whole flight, advise users to see this value for param

[tstastny]

nice.

[tstastny]

still some tests failing - but otherwise looking ok to me

[sfuhrer]

I like the separation into the dedicated performance model, makes it more readable. Let's give it a bit more testing, especially let's try to fine tune a vehicle flying with different weights and in different air densities.
Also, please adapt the PR description, the current one is missing a lot of things (eg the changelog only speaks about the new density param, but this Pr does much more).

[tstastny]

@RomanBapst Looking pretty nice! I have no functional changes, only some last documentation and sanity checks that would be good to put in.. then I'd be good to merge.

Also .. we will definitely need to get docs up on this soon. As there are implications here on how people tune their aircraft model. I was thinking it may even make sense to make a special section under the fixed-wing umbrella for "performance model" to explain what's happening.

[tstastny]

@RomanBapst thanks for all the revisions. looks like it will need another rebase before we get it in. But otherwise - how are the docs coming along for this? do you need support? main thing we need to be on top of is making sure that those using these new params aren't doing so blindly - i.e. outlining what it takes to use the param properly, and discourage otherwise

@dagar made a comment on in future if we can separate hobbiest level "i just want to plug in and let this thing fly" param sets from "i actually have a product and know what im doing for this extra performance"). happy to chat more on this - latter part here we can think about post this PR

[RomanBapst]

@tstastny I started with documentation here. PX4/PX4-user_guide#2842

The main thing I am missing is to explain how to cope with initial tuning not done close to sea level conditions. This is actually not just a problem related to this PR but it has always been a problem. Just need a nice way for the user to either back calculate or tell them to do the tuning near sea level.

[RomanBapst]

@dagar @tstastny

made a comment on in future if we can separate hobbiest level "i just want to plug in and let this thing fly" param sets from "i actually have a product and know what im doing for this extra performance"). happy to chat more on this - latter part here we can think about post this PR

By default these advanced params are all disabled, so this PR should not add any additional complexity for the user. Advanced user who really care can read the docs and set the params accordingly. At least that's the idea.

[tstastny]

The main thing I am missing is to explain how to cope with initial tuning not done close to sea level conditions. This is actually not just a problem related to this PR but it has always been a problem. Just need a nice way for the user to either back calculate or tell them to do the tuning near sea level.

right - we've been ignoring it for a while. let's take this discussion onto your user-guide pr then to figure out how we provide an easy way for people to back calculate.

[tstastny]

@RomanBapst can you post the flight test results you have here? Then if you're happy with them - just need a rebase and we should merge this one.

I'll start going through the user guide pr

[RomanBapst]

@tstastny @sfuhrer After looking at the test flights conducted at different altitudes (3000m and 400m) I noticed that the trim throttle compensation is completely off. I think there might be 2 reasons:

1. There is a scaling according to the weight ratio going on which I can't remember why I put it. It might just be wrong. We do already compensate the calibrated trim airspeed for weight and there is the mapping between airspeed and trim throttle, which might just be enough.

2. I am unsure if the mapping from air density to trim throttle is correct. I'll try to show the derivation and argue it's currently incorrect, at least by itself.

$J = {V \over n d}$ where $J$ is the prop advance ratio, $n$ the propeller rpm (1/sec) and $d$ the propeller diameter
$T = { \rho n^2 d^4 C_T }$ where $T$ is the thrust produced by the propeller $\rho$ is the air density, $C_T$ is the propeller thrust coefficient
Experimentally, you can see that $C_T$ decreases linearly with $J$ as long as no part of the propeller blade is stalled.
https://m-selig.ae.illinois.edu/props/propDB.html
image
Therefore,
$C_T = { k (J_{max} - J) }$ where $J_{max}$ is the advance ratio at which the propeller produces zero thrust and $k$ is a constant.
The drag $D$ acting on the vehicle can be written as:
$D = { {1 \over 2} \rho K_D V^2 }$ where $K_D$ is the product of drag coefficient and the drag area which we assume constant due to constant angle of attack. V is the true airspeed!
If we set $D = T$ which is true during cruise flight then
$k( J_{max} - {V \over n d} ) \rho n^2 d^4 = {1 \over 2} \rho K_{D} V^2$

The right side of the equation is the drag and we assume it to be constant if we fly at constant equivalent airspeed!
This means that the left side also has to be constant. We can write the left side as

$k( J_{max} - {V_{eq} \over n d \rho_0} ) \sqrt{\rho} n^2 d^4$

We can see that the thrust is a function of the square root of air density (which is how we currently compensate). But there is also a non-trivial relationship with rpm which needs to be taken into account, which could explain why only compensating for air density overestimates the trim throttle.

Ok, now let's get to actual data. I am comparing two flights from the same vehicle with almost the same weight in the same configuration flown at different altitudes (500m vs 3000m). The vehicle at 3000m is about 200g heavier and flying at a slightly higher indicated airspeed. Both would suggest that it's trim throttle is slightly higher than it should be.

Flight at 500m

• air density is 1.05
• estimated trim throttle is 0.46 (calculated both via trim throttle - throttle integ and by visually inspecting the throttle output)
  

Flight at 3000m

• air density is 0.801
• trim throttle is about 0.5 (calculated both via trim throttle - throttle integ and by visually inspecting the throttle output)
  

The trim throttle ratio is thus 1.08 and the square root of the air density ratio is 1.14.
It thus seems like we are indeed overcompensating (also be reminded that the setup at higher altitude was heavier and flew a bit faster, so it's true trim throttle could even have been lower). This could be related to the rpm dependency in the formula. Adding another square root due to the fact that rpm is squared, we would arrive at a factor of 1.07 but this needs to be verified.

[sfuhrer]

$T = { \rho n^2 d^4 C_T }$ and $D = { {1 \over 2} \rho K_D V^2 }$ --> doesn't that already imply that air density has no direct effect on trim throttle, as it's equally contributing to reduced drag and reduced throttle in increasing altitude?

And then the only effect we would need to keep modelling is that the true airspeed (TAS) is higher when flying higher, for which then the we should change getTrimThrottleForAirspeed() to not take the CAS as input but TAS.

[RomanBapst]

@sfuhrer

doesn't that already imply that air density has no direct effect on trim throttle, as it's equally contributing to reduced drag and reduced throttle in increasing altitude?

I assume you are saying that because air density appears linearly in both equations? I think the problem is then that the right side is not constant anymore (it's then drag scaled by air density) and then you can't make the argument that the left side should be constant as well. Does that make sense?

[RomanBapst]

@sfuhrer

And then the only effect we would need to keep modelling is that the true airspeed (TAS) is higher when flying higher, for which then the we should change getTrimThrottleForAirspeed() to not take the CAS as input but TAS.

I think we are speaking of the same thing. The CAS to TAS relation is the one that currently gives the square root air density relation. I think that part is correct, just that we also have the rpm square relation which could basically nullify or at least reduce this effect.

[sfuhrer]

If it all boils down to have an accurate airspeed (TAS) to throttle mapping, then I would extend the current functionality around that, where we approximate it through a linear slope above and below trim airspeed. That I have found to be the most accurate way of doing it, and it only requires to set two airspeed/throttle pairs (see #21345). We now would need to figure out how to do it for TAS.

[RomanBapst]

@tstastny I removed the weight scale for trim airspeed and added logging for the calibrated throttle.

[sfuhrer]

@RomanBapst From what I understand from your comments you removed the weight-->trim throttle scaling. But we want to keep the density-->trim throttle scaling? Wasn't it that part that caused the issues in the high altitude flight test we did?

As a side note: please don't do rabases of large PRs when they are in the middle of the reviewing phase, I now have to go through the whole thing again to understand what has changed since I reviewed on Monday.

[ryanjAA]

This is awesome! Thanks for putting all this work in :) !!

[RomanBapst]

@sfuhrer @tstastny I addressed the remaining concerns.

[RomanBapst]

@ryanjAA Are you planning to go fly near the service ceiling of your vehicle in the near future? :-)

[RomanBapst]

@tstastny @sfuhrer Ah sorry, I forgot about the change for logging eas2tas, will do that as well.

[RomanBapst]

@tstastny @sfuhrer I added logging of eas2tas in the VehicleAirData topic. I think it makes sense in there rather than TecsStatus.

[tstastny]

great - if there are no more concerns for first iteration .. let's get it in? @sfuhrer @RomanBapst

[ryanjAA]

@ryanjAA Are you planning to go fly near the service ceiling of your vehicle in the near future? :-)

Haha. I just saw this a year late... yes, going to fly at 3300m agl and 4500m.

The concern is cruise speed needs to be increased (which is fine) because min speed at those altitude is essentially close to cruise.

Wouldn't it make sense to also compensate for that here as well? As a percentage makes sense if you don't know baseline since that's universal.