Plane: Use accurate roll limits if airspd. sensor

[rubenp02]

Aerodynamic load factor-based roll demand limits were only applied down to ±25º to keep the aircraft maneuverable with a bad airspeed estimate. However, with the addition of the AIRSPEED_STALL parameter, this is unsafe if the aircraft is actually flying very close to its stall speed, and can result in a spin (this has actually happened to us in a real flight flying with a bit of wind and turbulence with the airspeed target set to AIRSPEED_MIN).

This PR makes it possible for the roll demand limits to go all the way down to 0º if an airspeed sensor is fitted and in use and the AIRSPEED_STALL parameter is set, as under these conditions, the airspeed estimate is accurate and there is very little bank angle overhead to prevent a stall.

[IamPete1]

In general limiting to 0 is a bad idea because it will result in no navigation and thus a flyaway. We use LEVEL_ROLL_LIMIT for this in in a few places (takeoff, landing, RTL initial climb). The idea being that there is still some navigation so the vehicle will at least make some progress in the desired direction and give the user time to figure out what is going on (eg a airspeed failure).

[rubenp02]

In general limiting to 0 is a bad idea because it will result in no navigation and thus a flyaway. We use LEVEL_ROLL_LIMIT for this in in a few places (takeoff, landing, RTL initial climb). The idea being that there is still some navigation so the vehicle will at least make some progress in the desired direction and give the user time to figure out what is going on (eg a airspeed failure).

Makes sense, I remember thinking of using that but I ended up forgetting about it. Since that would imply that the aircraft must be able to maintain flight at a bank angle of LEVEL_ROLL_LIMIT when flying at AIRSPEED_STALL, should that perhaps be included somewhere in the documentation/param. description?

[rubenp02]

@IamPete1 What do you think about this now?

[LupusTheCanine]

AIRSPEED_MIN should be set to >1.25 V_Stall, this gives you 56% margin and 25° bank requires 10% (1.1 load factor).

See https://ardupilot.org/plane/docs/airspeed-parameters-setup.html.

Maybe we should add a note to the description that the parameter MUST NOT be set to less than V_Stall*1.05+appropriate gust resilience margin).

[rubenp02]

AIRSPEED_MIN should be set to >1.25 V_Stall, this gives you 56% margin and 25° bank requires 10% (1.1 load factor).

See https://ardupilot.org/plane/docs/airspeed-parameters-setup.html.

Maybe we should add a note to the description that the parameter MUST NOT be set to less than V_Stall*1.05+appropriate gust resilience margin).

I disagree a bit. Firstly, IMO it's handy for AIRSPEED_MIN/MAX to simply be the airspeed range for navigation, instead of also having performance/flight envelope considerations. There's AIRSPEED_STALL for that. Secondly, only relying on speed safety margins to always keep a 25º roll margin isn't enough, because if there's an issue with speed control and the aircraft goes below AIRSPEED_MIN and into AIRSPEED_STALL, then it definitely should not command any roll because it will stall. There should be safety margins, but also defensive logic.

[LupusTheCanine]

I disagree a bit. Firstly, IMO it's handy for AIRSPEED_MIN/MAX to simply be the airspeed range for navigation, instead of also having performance/flight envelope considerations.

AIRSPEED_MIN/MAX is primarily TECS envelope configuration parameter. IIRC the behaviour is that unless AIRSPEED_STALL is set, AIRSPEED_MIN is used as a base for roll limit so with stricter stall protection and AIRSPEED_STALL not set you would get no navigation at AIRSPEED_MIN (which is really bad). We can't assume users are so stupid to set AIRSPEED_MIN below actual stall speed.

There's AIRSPEED_STALL for that. Secondly, only relying on speed safety margins to always keep a 25º roll margin isn't enough, because if there's an issue with speed control and the aircraft goes below AIRSPEED_MIN and into AIRSPEED_STALL, then it definitely should not command any roll because it will stall. There should be safety margins, but also defensive logic.

Defensive logic should be such that we never knowingly decelerate below AIRSPEED_MIN in airspeed controlled modes. Though that would cause undesirable unconstrained descent in the case of certain airspeed sensor failures, rectifiable only by switching to FBWA and lower or disabling airspeed sensor.
I don't think we have enough incident data to identify more likely failure mode between propulsion and airspeed sensor which would be necessary to decide which protection is more important, altitude or airspeed.

PS
Presence of bad descent protection logic in TECS indicates that historically enough aircraft were lost to bad descents (caused by erroneous underspeed condition) to warrant potentially stalling while trying to recover with maximum commanded thrust climb if the engine failure was the cause of failure to maintain airspeed.