Cut motor thrust permanently after a tumble

[ntamas]

This PR is related to #258 and the discussion therein. It extends the current tumble detector such that:

• it stops the high-level commander from sending setpoints
• it preserves the "tumbled" situation until the operator explicitly marks it as resolved by resetting the state of the tumble detector with a designated parameter

I'm not fully satisfied with the PR yet; the current implementation would also detect a tumble if you hold the Crazyflie upside down for a while before takeoff, and would block the takeoff itself. I'm not sure what the best way would be to address it - we could either extend the tumble detector in sitAwTuTest() to also require significant motor thrust (not only a significant roll / pitch angle), or check the motor thrust in sitAwPreThrustUpdateCallOut() and don't set the sitAwMotorThrustCut flag if the motors are not running. Suggestions are appreciated.

[krichardsson]

What about keeping this functionality passive until taking off and activating it when leaving the ground?
Not sure how to detect that we are flying though. One suggestions could be to look at the thrust to the motors as is done in the kalman estimator https://github.com/bitcraze/crazyflie-firmware/blob/master/src/modules/src/estimator_kalman.c#L300.

[whoenig]

1. I think it might be better to actually use the existing flag for an emergency here, rather than adding a new one: https://github.com/bitcraze/crazyflie-firmware/blob/master/src/modules/src/stabilizer.c#L303. This way we can deal consistently with resetting from various emergencies. There is currently no CRTP packet to reset the emergency, but that could be added in the future, or we can simply expose it as parameter.

2. As for the flight detection, I think in this case you can check if the current controller output is non-zero, as suggested. One could either pass in the current control-struct pointer to the sitAw framework (similar to the kalman filter), or use pointers to existing logging variables (similar to the led-ring deck).

3. (slight sidetrack from this issue). I found that the current tumble detector does not work reliably when using the EKF, because it relies on the current state estimate, which in case of a crash might or might not reflect the "upside-down" state. I suggest that we change the current check, or add another condition, that checks for sensorData->acc.z < -0.5f instead. We use this check in the crazyswarm firmware (in a hacky way, see https://github.com/USC-ACTLab/crazyflie-firmware/blob/crazyswarm-next/src/modules/src/stabilizer.c#L308-L317), and it has prevented many permanent motor/prop damages after crashes.

[krichardsson]

Closing since this was implemented in PR #482
Thanks @ntamas for your effort!

[ntamas]

Thanks and sorry for the lack of response; I would have needed some more time to finish this off, but I'm glad that there's a proper solution now!

(For the record, @krichardsson meant PR #481, not PR #482).