Refactor FMU: move mixer handling into a library

[bkueng]

Currently all actuator output drivers handle mixer loading, mixer parameters and actuator controls subscriptions with everything around that themselves, leading to duplicated code with minor differences.
This PR is a step towards improving that by pulling these parts out of fmu into a library that can be used by other modules.
It is a pure refactoring, except for:

• removal of PX4FMU::write (9c84251). I don't see it being used anywhere.
• mixer loading is now thread-safe (418021b)

Testing

I tested:

• normal pwm on Pixhawk 4, including safety button
• Pixracer, including an ESC calibration
• oneshot on omnibus
• mixer param changes

@Igor-Misic this serves as preparation for DShot.
I tend towards adding it as a new module (as opposed to integrate into fmu), as the fmu driver contains various things we won't need. On the other hand however, in the current form we would lose input capture pin configuration and the safety button.

@dagar one problem I found with the actuator_controls uORB scheduling is that you can end up your module not being scheduled at all. For example with an RC passthrough mixer and no RC connected. If the module wants to do other tasks as well we need to ensure it's run periodically even w/o uORB updates.

A careful review is appreciated.

[dagar]

@dagar one problem I found with the actuator_controls uORB scheduling is that you can end up your module not being scheduled at all. For example with an RC passthrough mixer and no RC connected. If the module wants to do other tasks as well we need to ensure it's run periodically even w/o uORB updates.

We should get those other tasks removed from fmu. #10119

[dagar]

We should think of a different way to handle this eventually. Seeing the "Multicopter Attitude Control" param group on a plane deeply bothers me.

[bkueng]

Agreed. Maybe just move the param to a mixer group?

[dagar]

How do you see this working in cases like uavcan? I'm wondering if having the uORB subscription callbacks in mixer_module is going to be too restrictive for things like uavcan.

[bkueng]

How do you see this working in cases like uavcan? I'm wondering if having the uORB subscription callbacks in mixer_module is going to be too restrictive for things like uavcan.

So far I see these options:

• poll only on actuator groups 0 (or 1), and if not used/published run at a fixed rate
• moving the subscription callbacks out of the library back into the module, but that again leads to more duplication.
• Independently schedule MixingOutput by making it a separate work item. But this leads to more overhead and complexity (switching work queues for example), so I tend towards the first option.

[jlecoeur]

I think this goes in the right direction, although I have not reviewed carefully.
I would tend towards the second option (i.e. to not impose callback or scheduling in the library). And later, remove the duplicated uses of this library by centralizing mixing in one module running on FMU.

[bkueng]

Rebased.

I would tend towards the second option (i.e. to not impose callback or scheduling in the library). And later, remove the duplicated uses of this library by centralizing mixing in one module running on FMU.

I made it configurable now so the user of the library can decide.

[dagar]

• Independently schedule MixingOutput by making it a separate work item. But this leads to more overhead and complexity (switching work queues for example), so I tend towards the first option.

One of the motivations for the PX4 WQ was to be able to afford to carve these things into separate little modules. Possibly splitting out mixing entirely from the output driver is something I'd like to consider down the road if we can wrap out heads around the current configuration mess.

[dagar]

@PX4/testflights could you please give this a try on one or more of the following flight controllers?

• pixhawk 4 mini
• cuav v5 nano
• pixracer
• nxphlite

Thanks!

[dannyfpv]

Tested on Pixracer v4 f-450

Modes Tested
Position Mode: Good.
Altitude Mode: Good.
Stabilized Mode: Good.
Mission Plan Mode (Automated): Good.
RTL: Good.

log:
https://review.px4.io/plot_app?log=2f472b7e-9716-432f-849d-f429d9bc41f7

Tested on Pixhawk4 mini v5 f-450

Modes Tested
Position Mode: Good.
Altitude Mode: Good.
Stabilized Mode: Good.
Mission Plan Mode (Automated): Good.
RTL: Good.

log:
https://review.px4.io/plot_app?log=bed1b711-4fa2-4379-aef2-6b66fe699d00

[jorge789]

Tested on NXP FMUK66 V3
Modes Tested

Position Mode: Good.
Altitude Mode: Good.
Stabilized Mode: Good.
Mission Plan Mode (Automated): Good.
RTL: Good.

- Procedure
Arm and Take off in position mode, after flying for approximately one minute, switched to altitude then stabilized mode proceed to switch to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoin activate RTL and see landing behaviour.

Notes:
No issues noted, good flight in general.

Log:
https://review.px4.io/plot_app?log=63165b52-49d0-45af-9c80-451bdc0374cd

[jorge789]

Tested on CUAV Nano V5:
Modes Tested

Position Mode: Good.
Altitude Mode: Good.
Stabilized Mode: Good.
Mission Plan Mode (Automated): Good.
RTL: Good.

- Procedure
Arm and Takeoff in position mode, after flying for approximately one minute, switched to altitude then stabilized mode proceeds to switch to mission plan mode then make sure that vehicle follows all waypoints as shown in QGC, once completed all waypoint activate RTL and see landing behavior.

Notes:
The height of the vehicle and what QGC said did not coincide. In the mission, the height was 35 meters and the height of the actual vehicle was approximately 25 meters. The error was only visible in Altitude, stabilized and mission, in position the error could not be seen, position height seemed accurate.

Log:
https://review.px4.io/plot_app?log=6e6f1be3-5f78-4e7e-9281-777aa912329c