[VTOL] Adaptive Quadchute is broken

[ThomasRigi]

Describe the bug The "loss of altitude" quadchute only triggers when it's already too late.

The problem seems to lie with the non-documented hard-coded conditions on TECS height rate which take too long to be set to true: https://github.com/PX4/Firmware/blob/6c16a29d26b2c79d63f1459be361c8972399d9ce/src/modules/vtol_att_control/vtol_type.cpp#L246-L249

To Reproduce I only tested with gazebo_standard_vtol, v1.11.0-beta2. Steps to reproduce the behavior: Version 1: (worst I found, quadchute has no possibility to recover the drone)

1. Disable the elevator in the sdf file, e.g. by setting the area of the elevator to 0 (you could also comment out the whole elevator block)
2. make px4_sitl gazebo_standard_vtol
3. Make sure VT_FW_ALT_ERR is set accordingly (in my logs 15m)
4. Launch a mission (or something else) that makes the drone transition to FW
5. In FW mode the drone will tip over and lose altitude
6. Observe how late the the quadchute is triggered

Version 2: (not as extremely late, drone still crashed though after quadchute)

1. Have the gazebo_standard_vtol model fly a normal mission with FW flight
2. Make sure VT_FW_ALT_ERR is set accordingly (in my logs 15m)
3. Disable the pusher motor (via motor failure plugin)
4. Watch the drone lose altitude and eventually trigger the quadchute (still late, but not as late as with Version 1)

Expected behavior Quadchute should activate as soon as you have lost VT_FW_ALT_ERR meters of altitude with respect to the altitude setpoint. I understand the idea behind also checking if the drone is falling to not trigger in situations where for example you ask for a steep climb that the drone can't immediately react to, but the current implementation clearly doesn't work well if it only triggers when the drone is falling out of the sky with more than 20m/s vertical speed with already more than 25m of altitude lost.

Log Files and Screenshots Version 1, disabled elevator: https://logs.px4.io/plot_app?log=5e45b915-3e91-4156-9d14-956cbffbc73e

Version 2, disabled pusher motor: https://logs.px4.io/plot_app?log=b3cf09c8-9b47-4832-98bf-b453ebd7cfa2

Drone (please complete the following information):

• Gazebo standard VTOL

Additional context (Part of) the reason why it triggers so late with Version 1 is that TECS first still needs to initialise after the front transition, but the drone is already dropping. It takes way too long until TECS actually asks for +1m/s height rate

@sfuhrer @RomanBapst I think some thoughts should be spent on how to best set the trigger logic.

[ThomasRigi]

Another let's call it interesting phenomenon is that after the quadchute is triggered in the second log is that the MC thrust oscillates between max and min and that the Z-velocity setpoint is positive, i.e. down. I guess this is linked to some jerk / acceleration limits of the MPC trajectory generation.

Would it make sense / be possible to not control position directly after a quadchute, but have something like stabilised / altitude control until the drone has more or less stabilised? I guess there are a few stumbling blocks with this though...

[sfuhrer]

@ThomasRigi thanks for the detailed report. I would propose we have another look in TECS initialization, not only for fixing this specific issue but also to have better altitude tracking in general during transitions. It currently initializes when the transition is finished, with the vehicle already at full speed - doesn't really make sense to me, it should be earlier. I had done some work around that a year ago, but it didn't make it in yet https://github.com/PX4/Firmware/pull/11729 I will try to give it another pass in the next couple of weeks. Part of it is also to clean up the parameters of the VTOL transition logic and make them consistent between the different VTOL types. If you'd have time to support me that would be very appreciated! I'll open a PR with all my ideas in, then you could help we with reviews/testing.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[UASOP]

Has adaptive quachute been tested before with working desired responses in previous firmware versions?

[sfuhrer]

Has adaptive quachute been tested before with working desired responses in previous firmware versions?

I guess so, but probably already quite some time ago. Let's put in some effort in fixing it now - would you be able to help @UASOP ?

[LorenzMeier]

@sfuhrer Where is this standing now?

[sfuhrer]

I lost track of that one. @ThomasRigi I assume we still have the same undesired behavior?

[ThomasRigi]

I haven't tested since. I also assume it's still the same. From what I recall the problem is that you rely on an averaged TECS setpoint and averaged descend rate to be high enough to actually trigger the quadchute but just after transition when TECS isn't yet completely / is just about initialised this doesn't really work. TECS can't have been asking for a significant averaged climb setpoint if it wasn't even initialised yet.

So either we already need to initialise TECS earlier (but probably doesn't help fully, as during transitions the altitude setpoint is flat anyway, so a weighted average will still take too much time) or we need to change the averaging, at least directly after a transition.