Position publish disarmed attitude

[MaEtUgR]

Describe problem solved by this pull request
Smooth takeoff issues were only hotfixed but the root cause never solved.

• Issue VTOL thrust bug on takeoff still existent #12171 was just hotfixed with VTOL: apply multicopter takeoff hotfix also for vtol #12250
• Issue 【Vtol】The left and right ailerons have a large output when they are stationary on the ground. #13167 was just hotfixed with VTOL: Only Reset Thrust but not Attitude when Disarmed #13198
  These are all side effects of the position controller not running when disarmed.
  This also has other negative side effects like:
• Raising CPU load when arming
• Flaps of VTOL in multicopter mode cannot be checked by sticks when not armed

Describe your solution
I start the flight task, run the position controller and publish the attitude setpoint as soon as the navigation state is set by the commander also when disarmed. In navigation states where no flight task is running the position controller is still not run and nothing published e.g. stabilized mode since #10805, offboard if the attitude setpoint is coming via MAVLink or when flying fixed wing.

Describe possible alternatives
What's still missing is that the Attitude controller can handle invalid setpoints e.g. timeouts, NAN values and so on.

Test data / coverage
SITL gazebo
Still open tests:

• Smooth takeoff for MC and VTOL in SITL
• VTOL at least bench
  • Flaps check using RC in multicopter stabilized when disarmed
  • Flaps check using RC in multicopter altitude when disarmed (unsolved)
  • VTOL outdoor
• Offboard with attitude setpoints
• Outdoor multicopter test with Stabilized and Altitude, Position, Takeoffs (covered by in depth VTOL multicopter mode tested)
• @xdwgood 's tailsitter setup from 【Vtol】The left and right ailerons have a large output when they are stationary on the ground. #13167

[dagar]

Side note - if you name your branches with a pr- prefix then the PR will also run on the hardware test rack. This can be a useful/lazy way to get a sense of cpu load before and after across a range of boards.

[MaEtUgR]

if you name your branches with a pr- prefix then the PR will also run on the hardware test

Very good hint, I should adapt my naming scheme then 👍

[MaEtUgR]

I rebased since @sfuhrer is doing VTOL testing. I might be able to add this to the testing.

[sfuhrer]

@MaEtUgR testflown on a standard VTOL: https://review.px4.io/plot_app?log=0122c386-8af6-4a24-8bb2-36a23a00938e

I had some airspeed measurement issues on the flight, can't image them to be related to this PR though. Beside that, everything functioned as it should (tested in STAB, ALT/POS, both MC and FW).

[sfuhrer]

@MaEtUgR second testflight: https://review.px4.io/plot_app?log=4db9ffd5-1e1d-4e37-96ba-5217dcd9683f

[xdwgood]

I tested this PR on the tailsitter of the two motors, which solved the problem here:
https://logs.px4.io/plot_app?log=8c7b8d4e-42b7-4fa9-9ed7-5d364a133f19
（not arm but produced huge actuator output）

[LorenzMeier]

@MaEtUgR @sfuhrer Can we get this in?

[sfuhrer]

@MaEtUgR @sfuhrer Can we get this in?

From my side yes. I think @MaEtUgR wanted still to test in offboard though.

[MaEtUgR]

Yeah, I really want to get it in. I just didn't get through to do the offboard test. Passing the MAVSDK attitude offboard test should be enough and then it's ready to merge.

[MaEtUgR]

I successfully ran the MAVSDK offboard test on SITL:
https://logs.px4.io/plot_app?log=643baa12-f9aa-4561-bec1-b4c4be310b66

I realized one thing though: The warnings likely reveal another race condition between the flight stack modules. When GPS fusion starts and it switches to Hold there are the messages

WARN  [mc_pos_control] Auto activation failed with error: Activation Failed
WARN  [mc_pos_control] Position-Ctrl activation failed with error: Activation Failed
WARN  [mc_pos_control] Altitude-Ctrl activation failed with error: Activation Failed

These do not show on master since to flight task is running and therefore noone cares if the data is not even available in the first loop iteration after switching the mode.

[MaEtUgR]

Indeed the commander switches to hold when global position is valid, the position controller starts the task, it expects valid triplets and doesn't find any so reports based on the check here: https://github.com/PX4/Firmware/blob/99a7491cdef655cefdd7aef66ea4a9ec97906db7/src/lib/flight_tasks/tasks/Auto/FlightTaskAuto.cpp#L139

The others are the fallback because there's no way to autonomously stay in air but there's also no RC connected in my example so it continues and ends up in the failsafe task for this one loop iteration where the data is missing.

It's nothing caused by this pr and it's also not unsafe it's just not nice and gets revealed by the warnings.

[MaEtUgR]

I rebased to be ready for merging again. The only conflict was the line https://github.com/PX4/Firmware/pull/12650/files#diff-81c4f50bdf837c4183b5d3cb81eb40eaL359-L360 close to my change was removed but it doesn't interfere.

[MaEtUgR]

Updated again. Any reviews?
From my side it's ready including real world, simulation and offboard tests.