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