Multicopter Controllers Muxing

This thread will capture the relevant discussions regarding the PR

A configurable low-level control chain
The objective for this WIP PR is to modularize the low-level control chain so that it is easier to integrate different controllers for rate / attitude / position on multicopters. The framework shall be extendable to other systems afterwards, but I will start with these. We hope that this makes it easier for everyone to incorporate novel controllers into the stack, as well as provide researchers with an easy way into PX4 to test their own control approaches.

Describe your solution
The solution as discussed with @dagar and with @MaEtUgR will be a muxing of which low-level controllers are active for a specific flight. The user selects (or doesn’t, hence leaving default) the controllers for MC Position, MC Attitude and MC Rate that he wishes to use on a given flight, before the vehicle is armed. For all runs, the default PX4 controllers are initiated and ready, but are not running in parallel - they stay dormant until a FAILSAFE requests their use despite the users intention. The information flow would be:

User Setpoint ->{pos alg 1, pos alg 2, …, 0} -> {att ctl 1, att ctl 2, … , 0} -> {rate ctl 1, rate ctl 2, …, 0} -> Mixers

This means that, for a given flight, a user might want to set:
User Setpoint -> {0} -> {my own att ctl}->{px4 rate ctl} -> Mixers
… meaning that the user wishes to not run the position controller, to run its own attitude controller and to run the default PX4 mixer. This means that neither the PX4 Position Controller or PX4 Attitude Controller will be updated, unless a FAILSAFE is triggered - in which case the default controllers take over.

In a FAILSAFE scenario, all non-default controllers are disable and the information flow resumes its default path through PX4 default controllers. This change shall be as seamless as possible.

On the one hand, this allows for sandboxing of controllers under test, providing a safer environment to test new research. On the other hand, I will also provide basic templates that will allow for anyone to implement their own control laws on the low-level system and test them in SITL.

Meeting 1:

Topic: PX4 - Control Muxing
Time: Nov 10, 2020 06:00 PM Stockholm

Join Zoom Meeting


  1. Architecture of the information path selection
  2. Items to be muxed: position, attitude, rate, mixer modules
  3. Failsafe recovery to standard behavior with onboard PX4 controllers
  4. Preliminary timeline


Meeting Minutes:

  1. Granularity of PX4 Default Controllers vs Custom controllers -> moves to the existing OFFBOARD mode, where the OFFBOARD model specifies which which controllers are enabled or disabled (like the current position and attitude setpoints that disable specific controllers);
  2. Provide meaningful examples where it is clear what triggers the FAILSAFE. Examples of the above functionality, for each of the cases ( position override @Jaeyoung-Lim , attitude override @Pedro-Roque );
  3. Quoting @dagar: β€œIf you want to do a Wrench, do whatever you want” -> as in, be sure that you want to go with that extra effort. Use the body rates and force instead (most likely you can do this anyways), @lowjunen;
    4.EXTRA BUT IMPORTANT:* Clean the OFFBOARD mode (BIG BIG task: @dagar , please refer to specific components that we should be careful with and that we should start cleaning)