VTOL: Control architecture limitation for tailsitters

[RomanBapst]

Tailsitters are the least supported vehicles in PX4. There are two main problems that make it difficult to support and maintain various Tailsitter types.

Let me start by explaining why other VTOL types have shown to be easier to support.
For other vtol types (standard VTOL aka Quadplane and Tiltrotors) we can clearly assign a set of actuators to either MC or FW (attitude) control modules.
E.g. in the case of the quad-plane the MC controllers will always control the multirotor motors and the FW controllers will always control the control surfaces and the pusher.
Furthermore, the MC and FW controllers use the same attitude reference.
This makes the transitions between hover and forward flight relatively easy because the MC and FW attitude controller can be fed the same attitude and both of them actuate separate sets of actuators.

In the case of tailsitter types this is a different story. First of all we are not using the same attitude reference for MC and FW. This means that you can never run the MC and FW attitude controller at the same time because their attitude references are shifted by PI / 2.
A further difficulty comes with the fact that actuator sets are not always clearly assigned to MC and FW controllers.

Let's take the duorotor tailsitter as an example:

• in hover the MC attitude controller controls the motors AND the elevons (for pitch and yaw)
• in fixed wing mode the FW attitude controller controls the elevons and the motors (mainly for thrust)
• in transition mode we have no choice but to run either the FW or the MC attitude controller

Letting the MC attitude controller do the transition is problematic without doing gain scheduling. As soon as the vehicle picks up speed you will see massive oscillations in pitch.
In this case it would actually be more suitable to let the FW rate controller actuate the elevons.

Conclusion:

• our rate controllers are currently tied to the attitude controllers. we cannot run the MC attitude controller and feed the resulting desired body rates to the FW rate controller.
• unlike for quadplanes and tiltrotors we cannot run both attitude controllers at the same time because they use different frames of reference. additionally, the FW attitude controller uses a euler angle interface which is not suited for the flight regime required by a tailsitter.

Solutions:
If we can untie the rate controllers from the attitude controllers we will have more freedom to control transitions for tailsitters.
Currently the can only run a rate controller by using the corresponding attitude controller which is problematic in the case of a tailsitter in the current architecture.
I will follow up with a simplified control flow diagram which should help with discussion.

[dagar]

Actually I don't think it's necessarily that bad to get the FW rate controller only running within the attitude controller. Ideally I'd still like to get them completely separated later though.

Here's an old branch: https://github.com/dagar/Firmware/commits/pr-vtol_rates

The only additional vtol specific logic the fixed wing attitude controller needs is a few lines to tell it to disable flag_control_attitude_enabled and flag_control_manual_enabled when vtol and rotary wing. That puts the fixedwing attitude controller in a mode where only the rate controller is running and only listening to rate setpoint publications (coming from the multicopter attitude controller).

[RomanBapst]

@dagar I'll start by looking what you have in that branch.

[thomasgubler]

@RomanBapst merged a PR for this