Restore original idea + enhance: command -> failsafe -> actuator

[dewagter]

A) There are several types of commands: see #3180 #3203

• outputs of controllers (e.g. pitch/roll of direct actuator commands)
• outputs of modules (e.g. camera)
• RC-commands: e.g. pan-tilt
• Virtual commands (e.g. one-loop control has internal commands that do not go to any actuator)

B) These commands then go through safety

• rotors/motors should be protected in e.g. KILL mode
• aerodynamic actuators or helicopter tail-rotor pitch should not be protected (now done with defines)

C) Commands become actuators in the end

• simulator needs unified deflections while drivers need specific ranges: see also actuators[ ] array of structs with pprz units and driver units #3205
• modern drones have redundant communication lines: several signals for the same actuator

[dewagter]

Actuators:

• only 1 actuator index visible in code (except within an actuators driver) Hide actuator driver number from code #3206
• store actuator values in unified values since this is needed for simulation actuators[ ] array of structs with pprz units and driver units #3205
• link the simulation actuator sequence to the actuator sequence: auto-generate NPS_ACTUATOR_NAMES ?

Commands:

• accept removing unused commands: Remove command_pitch and command_roll and command_yaw #3208
• put the output of controllers back in command[ ] in all cases even when driving actuators: Remove actuators_pprz #3203 (remove the need for actuators_pprz)
• solve the difficulty: controllers now write in stabilization_cmd which should be copied to command but not overwrite the module-commands, rc-commands: e.g. using a define in all controller's code: STABILIZATION_CMD_NB
• simulator NPS_COMMANDS_NB must be >= INDI_OUTPUTS while <= ACTUATORS_NB while it is set to: #ifndef MOTOR_MIXING_NB_MOTOR or COMMANDS_NB

Safety:

• add type to servos: "servo,motor,system" -> handle motors_on depending on type instead of ROTORCRAFT_COMMANDS_YAW_ALWAYS_ENABLED etc

Harmonize:

• rename servo to actuator?

[gautierhattenberger]

Instead of replacing servo with actuator + type, maybe we could add new types directly, like motor. This way, it will be easier to have adapted attributes (min/max/neutral for servos, stop/idle/max for motors).

I also agree that the safety part should be between command and actuator and independent. Specific attributes could also be used to apply specific conditions for in_flight or motors_on status.

As you said, one of may issue to fill correctly the command vector. We need something like the "mux" block of Simulink, but it doesn't look so simple here. Otherwise, we have to think of a "deterministic" way to fill the array (first copy from stab, then apply module et rc commands, etc).

[gautierhattenberger]

As a side note, I would like to make a stable release by the end of the week, so I would prefer not to break configuration files before that. After that, we could start a 7 series, with the possibility to break some backward compatibility if needed.

https://github.com/paparazzi/paparazzi/milestone/20

[dewagter]

I'm fine with doing this in v7.0