VTOL Anti-Stall behaviour

[TSt]

Hi,

I’ve been thinking about the possibility to add MC support on standard VTOLs (quadplanes and similar) in FW flight when the FW attitude controller isn’t working well. For example if a gust of wind risks to topple the drone over or if the airspeed sensor is badly calibrated and the drone is flying too close to stall speed. E.g. in situations where currently it’s likely to see a Quadchute. We’re flying long range missions and if the drone quadchutes in the middle of the route we have no way of getting it to the designated landing spot and also rallypoints only give us limited options. So we’d prefer to not quadchute at all by having the MC part helping in stabilizing the drone in FW flight if performance is degraded. Of course, when this happens the user should be notified with a warning message.

I would like to add such a feature to PX4, but I still have some implementation questions. First off, do you think that the idea in principle makes sense?

In the introductory paragraph I write vaguely about “if FW attitude controller isn’t working well”, but I find it not easy to put down exact criteria of how we would detect that in all cases.

The first option that comes to my mind is to set a max pitch and roll angle threshold somewhere between FW_MAN_R_MAX and VT_FW_QC_R (same for pitch, obviously). If above this threshold, activate MC rate control until back below FW_MAN_R_MAX. I think this should protect well against high winds and other one-off stalls (climbing too hard, flying too slow etc), but it could become a trap if it’s a broken servo that causes the drone to always tip over and you could end up flying in some bad circle (for example roll above 45° → MC support brings it back to 30°. When MC support stops roll will increase again up to 45° until MC kicks in again and so forth). To get around this trap we’d need a monitoring mechanism that decides if it happens too often either use MC actuation all the time or trigger a quadchute to fall back to MC. I’m thinking of some sort of leaky integrator or simply a counter / timer that measures how long you’ve been in this mode throughout the flight.

In order to more accurately characterize the FW attitude controller performance there are system identification procedures to get the rise time, overshoot and delay, but I think this is a bit too complicated to have it working reliably for all different sorts of models (many parameters, real time execution…), so I think this is a dead-end in PX4. Could be done on a companion computer on a case-per-case basis.

On the implementation side, if I’m not mistaken the MC rate controller already runs all the time and continuously publishes actuator_controls_virtual_mc also in FW mode, so they could be used in void Standard::fill_actuator_outputs(). I reckon Airmode would have to be active so that the MC outputs can actually create the required differential thrust without having a MC thrust setpoint. And probably you also need to use set_all_motor_state(motor_state::ENABLED); to activate the MC motors in FW flight.

Looking forward to hearing your thoughts!

[JohnSnowball1]

Not that hard.

1. Criteria is maximum attitude& low airspeed, for a fixed-wing plane, when attitude and airspeed are good, usually nothing is wrong. Also, the height error and extremely high airspeed can be considered as secondary criteria;
2. Let MC rotors pull the plane to level, hold for a few seconds, then do a front-transition, normally this could be safe;
3. Set a max time for this anti-stall behavior, if exceeded, your plane might have some un-recoverable problem in air, then make a MC-RTL;

I think this could solve most stall problems, however you need to set your criteria carefully according to your own plane, otherwise new algorithm could lead to new problem.

[TSt]

Thanks for replying.

1. Low airspeed is an interesting criterion. If you know that the drone is close to stall speed then it would indeed be good to use MC support, probably already before you end up above a max attitude. But this requires that the airspeed sensor functions properly. If it indicates cruise airspeed, say 16m/s, when in reality you’re flying at 12m/s it will not trigger MC support even though it would be required. And the other way around, if the airspeed sensor measures 12m/s but you’re actually flying at 16m/s it would trigger but not be required. But these are corner cases, assuming a well functioning airspeed sensor it would indeed be sensible to use this information.

2. This already implies that the drone has switched to MC mode if you hold and then retransition. That’s the case I want to prevent. But it is a valid operational mitigation if the drone still stalls in order to continue the mission or go to a RP in FW mode.

3. The devil lies in the detail. Would you put a threshold for continuous activation of anti-stall, or for total duration? For example, consider a threshold of 5s and the case where the drone would stall once due to high wind, and the anti-stall is activated for 3s. Then it continues fine for 5min before it activates another time, for 3s again. Should it trigger a quadchute and MC-RTL? or do you consider them separate events, and as each of them was below the threshold you continue as normal? If they’re 5min apart I’d say the drone should have “forgotten” about the first one, but if there is only a 20s interval between the two occurrences then it points more towards a real issue on the drone, so a switch to MC is probably advised. I think a leaky integrator would make most sense.