[WIP] Failure detector / Parachute triggering

[bresch]

This PR enables failsafe parachute triggering capabilities for an autopilot with or without IO processor.

Any kind of failure detection can be made using the FailureDetector class, which is instantiated in Commander. At the moment, a simple attitude check is made and sets its internal flags to true if roll or pitch exceed some defined parameters (VT_FW_QC_P/R).
Note: these parameters are used since this check are the same as for VTOL "Quadchute" and this failure detector will replace the quadchute logic as well; the parameters will then be replaced.
Commander then sets a parachute_failsafe flag (added to the actuator_armed message) to the FMU driver and to the IO chip (if available).

If the autopilot has an IO chip, one can set the parachute pin to an IO pin and IO will also then be able to trigger the parachute if FMU dies (through a timeout check).

The only way to reset the parachute triggering state is to unpower/repower the autopilot.

The objective is also to do different check and to have different behaviors if the vehicle is a fixed-wing, a multicopter, a VTOL or a rover. FailureDetector will then be a base class for FWFailureDetector, MCFailureDetector, etc.

Test data / coverage
Bench tests only, with a servo connected to IO and FMU pins.
Arm/disarm triggers tests
Attitude roll/pitch triggers
FMU timeout tests
Parameters update

Tested on a PixHawk4 and a Pixracer

Warning
This has never been tested in flight and could potentially kill the vehicle in air.
Known corner case: if the autopilot is armed and the reboot command is sent, IO sees that as a FMU loss and triggers the parachute.

How to use it
Mandatory:

• set PWM_CHUTE_OUT to the desired output:

Disabled = 0,
IO1 = 1,
IO2 = 2,
IO3 = 3,
IO4 = 4,
IO5 = 5,
IO6 = 6,
IO7 = 7,
IO8 = 8,
FMU1 = 9,
FMU2 = 10,
FMU3 = 11,
FMU4 = 12,
FMU5 = 13,
FMU6 = 14,
FMU7 = 15,
FMU8 = 16

• set PWM_CHUTE_OFF to the value for which the servo doesn't trigger the parachute
• set PWM_CHUTE_ON to the value required to trigger the parachute
• arm the vehicle

Optional:

• set VT_FW_QC_P or/and VT_FW_QC_R (0 disables the check) to some maximum roll/pitch values (in degrees)

Tasks

• Low-pass the attitude data in the Failure Detector
• Add manual parachute trigger mapping to RC switch
• Test a lot in simulation and test on real drone with disabled logic (PWM_CHUTE_OUT = 0). The flag parachute_failsafe is set even if the logic is disabled but doesn't trigger the parachute.
• Replace quadchute logic for VTOL (use VTOLFailureDector class)

FYI @bkueng @RomanBapst @dagar

[dagar]

On my phone so I've only skimmed so far, but my first question is how is this expected to interact with existing mixers?

[bresch]

@dagar The parachute will be removed from the mixers and a manual trigger will be mapped similarly to the kill switch.

[dagar]

Preventing an existing mixer from touching the same output is what I'm wondering about. I think there are several functions where it would be nice to configure directly via parameter rather than mixer (parachute, landing gear, gimbal, maybe flaps), but we need to at least block out mixer usage of those particular outputs. A simple error would also be nice.

We should also parameterize it generically rather than referring to IO or FMU pins. What do you think about something like setting it as a special function per PWM_MAIN or PWM_AUX?

[LorenzMeier]

@bresch Unfortunately it looks like there was some miscommunication on the approach. I meant literally to use the failsafe PWM values and the force_failsafe flag. I wouldn't know why introducing another failsafe flag and another set of PWM values would be necessary and I believe it makes the system unnecessarily complex.

Run pwm info and pwm help to check how those are set and how you can set them.

It might be best to start from scratch, only apply your commander changes and use the force_failsafe flag.

Can you please also raise a PR against the PX4 docs in parallel so we avoid any confusion in the future? The root cause of the miscommunication here is that the failsafe values were not properly documented.

[bresch]

@LorenzMeier I was considering the force_failsafe approach at the beginning, however, after brainstorming with @bkueng we came to the conclusion that using that flag is not always appropriate.

Take for example the case of fixedwing aircraft with a parachute: force_failsafe can be set for data link loss or RC loss. The user might want to trigger force_failsafe, go into loiter and not always deploy the parachute.
Furthermore, the failsafe pwm strategy has been designed to move control surfaces to some safe positions, stop a motor (i.e.: non-dangerous, disarming tasks) and not to trigger an explosive - pyrotechnic or spring loaded device. With a new parachute_failsafe flag, its usage can be assigned to a single sensitive task, it is much easier to find corner cases that could potentially injure someone and modularity is preserved.