Quadchute Issues / Improvements

PX4 Autopilot VTOL šŸš
1

Hey there,

Over the last year the quadchute feature has saved a few of our drones from crashes, but we have also found some aspects of it that donā€™t work as expected and/or desired. In this post I group them together and would really appreciate all your feedback and thoughts on this.

1. Adaptive Quadchute

At times the adaptive quadchute triggers way too late. I already opened an issue on this: https://github.com/PX4/Firmware/issues/14947

2. Yaw after Quadchute

When analysing what happened after a pretty bad crash of a new drone after its first transition to FW (https://logs.px4.io/plot_app?log=40261bd0-f132-4019-8522-c1f35369f84c), I discovered that the yawrate setpoint was at its maximum after triggering the quadchute even though the drone was in Stabilized and the pilot asked for no yaw input. Itā€™s not the reason of the crash, so I didnā€™t pursue it with a lot of effort afterwards. All it did was to decrease the overall thrust the motors were outputting, but it didnā€™t really interfere with the pitch control signal. Still, it is clearly a bug, so Iā€™m mentioning it here again. On the master branch in SITL I wasnā€™t able to reliably reproduce the situation, so Iā€™m not sure if it has somehow been fixed in the meantime anyway.

The main reason why Iā€™m listing it here is that I think that independent of the flight mode that the quadchute is triggered in, the drone should not control yaw at all until things have settled. When trying to recover a drone in MC mode yaw is never a priority and especially on quadplanes the motors can really suffer when yawing hard. So in my opinion the yaw actuator controls should be set to zero for some time.

How exactly this is best implemented Iā€™m not entirely sure. The simplest method would be to just use a timeout during which yaw is not controlled, for example during the first 3s after the quadchute. All other options that I can think of such as checking the accelerations of the drone or the roll and pitch actuator controls or rates seem to be too complicated to implement reliably, so Iā€™d say simplicity is key.

3. Land after Quadchute instead of RTL

Similar to GF_ACTION, it would be nice to be able to choose the Failsafe reaction that gets triggered upon a quadchute.

Weā€™re targeting commercial long-distance delivery flights, and depending on the authorities they might prefer that we land straight away when we have a problem in FW flight rather than try to RTL.

Another option that could make sense for some people would be to enter hold mode for example and to wait for the pilot to take action.

4. RTL after quadchute: proceed directly to RTL position

Currently (v1.11.0-rc1), the drone first wants to move back to the position where the quadchute was triggered before moving on with the RTL. To me this does not make sense, the drone should directly climb to RTL altitude wherever it is and then proceed with RTL as usual. Hereā€™s an example log: https://logs.px4.io/plot_app?log=171a8daa-50df-483d-a41d-d1313eb74eae (also, the behaviour after the quadchute was really weird until it actually flied back to where quadchute was triggered. The thrust was oscillating between max and min and also pitch was oscillating a lot.)

5. Keep pusher activated after quadchute
Depending on the reason of the quadchute, I think it would make sense to keep the pusher activated after a quadchute. Typically if you quadchute because of low altitude you might have an issue with the pusher motor, so in these cases I understand that itā€™s more reasonable to have the pusher deactivated afterwards. But if you quadchute because of max pitch or roll angle it could also just be that you caught a bad gust of wind and then having to fly in high winds with no pusher assistance can be really problematic as well if it needs to return to home against the wind. Weā€™ve had one such occurrence that almost caused our drone get blown away. Had we had pusher assistance, the drone would have managed a lot better.

The hard thing here is that ideally you would know the cause of the quadchute before deciding whether or not to use pusher assistance, but thatā€™s complicated. But at least letting the user decide if he wants to keep using the pusher after max angle quadchutes would be nice I think.

6. Give quadchute command from offboard control
It would be nice to have a way to do an immediate transition to MC in offboard mode. Suppose you have some more complex diagnostics running on an onboard computer and you can detect a FW failure before actually hitting one of the normal quadchute conditions. We have only just started using offboard control, so maybe there already is such a thing and Iā€™m just not aware of it :wink:

@sfuhrer @tumbili

1 Like
2

Cool summary @TSt!

  1. letā€™s work together to fix that.
  2. we would need to think it through how to integrate this best in the current architecture, e.g. if it should be something that only a VTOL can, or maybe it could also be interesting for normal MCs. Though in my perspective this has some lower priority then some other points you mention, as I e.g. so far havenā€™t witnessed a VTOL struggling to stabilize itā€™s attitude after a quadchute.
  3. Yes, there should be a parametrized ā€œholdā€ time, in which the user can select to continue mission (in fixed wing), RTL or Land immediately (descend in hover at current position).
  4. Thatā€™s ideally something to be fixed, yes. Thought not that straight forward, as you would need to know when the vehicle has come to a stop, and then set that position as the new position waypoint (given we want to Hold there for a bit). The transition logic canā€™t be used to get this info, as itā€™s not executed (directly switched to MC from FW).
  5. Hmm for that we would need some way to distinguish ā€œdrive trainā€ and ā€œotherā€ quadchutes, and activate the pusher support only for the latter. If we assume that ā€œdrive trainā€ issues result in altitude losses only we could get away by just disabling it in that case.
  6. I wouldnā€™t know about it either.
1 Like
3

Hi @sfuhrer! Thanks for your reply and sorry that my follow-up is so late.

  1. I hope to get to it soon. I think in a first pass it would be easiest and most reasonable to try to find a fix that does not involve changing the transition to initialise TECS earlier, but to only focus on the condition(s) when the quadchute should trigger and make it as initialisation-independent as possible.
  2. I agree itā€™s not the most important on the list, but I still wouldnā€™t underestimate it. Excessive yaw setpoints can lead to one (or even two) MC motors spinning at max throttle for an increased amount of time, heating them up unnecessarily. Plus it lowers the overall thrust output, which is not great when you need to recover from a dive.
  3. The hold time is a good idea :+1:
  4. You could for example fix the position once below MPC_XY_VEL_MAX or MPC_XY_CRUISE. To slow down after the QC you could set velocity setpoints instead of position setpoints.
  5. If you lose the FW drive train, are you more likely to stall or to lose altitude? I guess it depends on your FW_T_SPDWEIGHT settings. If with normal settings stalling is unlikely due to drive train loss, I think you could indeed keep the pusher active after a max angle quadchute and only deactivate it on the altitude ones.
  6. The easiest way to get this functionality would be to add a ā€œforceā€ field to MAV_CMD_DO_VTOL_TRANSITION. Like this it would also be available for other GCS and not only offboard control.