Enable Orbit Flight Mode

[MaEtUgR]

Orbit
Fly a perfect circle with a multicopter which is not achievable with waypoints. The circle can be commanded and controlled in center position size and speed using the MAVLink command also speed and size can be adjusted using the remote sticks if they are present. Maximum total acceleration is limited for feasibility resons. The vehicle currently always yaws such that the front "looks at" the center point.

History

• Orbit was first test and example flight task already in first step FlightTasks incremental introduction #8933
• MAVLink command Add vehicle command for Orbit mavlink/mavlink#924
• Improved and proper command handling in FlightTaskOrbit: Improvements #9434
• QGC support Mavlink Orbit support mavlink/qgroundcontrol#6608
• First try to enable in commander Flight task custom #10199
• MAVLink telemetry common: add orbit execution telemetry message mavlink/mavlink#1006 (will asap be filled in a pr EDIT: Orbit: Send telemetry for the UI #10989)

Describe problem solved by the proposed pull request
The first try to enable orbit by at the same time relieving the commander of certain duties and growing totally uncontrolled with #10199 failed. I discussed the novel principle of hirarchical command and error handling e.g. by flight tasks handling their respective commands and reporting problems/failsafes to commander with @julianoes, @Stifael, @ChristophTobler. But #10199 was rejected

This isn't safe, it ignores nearly all failsafes and current system conditions.

After lengthy discussions with @dagar and no follow up on my side due to time constraints I'm giving up and am just adding an orbit commander state. I'm not blaming @dagar, he might very well be right and I imagined the solution too easy. Still we should improve the commander situation, I'm happy to join the discussion again. Bottom line of this pr is: Orbit doesn't have to wait anymore for any architecture changes.

Describe your preferred solution
There is a commander main and vehicle navigation state now specifically for orbit. The command DO_ORBIT does just switch to the orbit main state because switching the flight task and applying the parameters was already implemented a long time ago in the flight task architecture.

Test data / coverage
Windows SITL

FYI @DonLakeFlyer (asked when Firmware will finally support what the UI promises)

EDIT: CI problems seem to be unrelated...

[dagar]

CI problems appear to be docker hub connectivity issues. Restarting individual jobs for now. @lamping7 I wonder if this is another case we can catch and retry.

[Stifael]

Orbit is a good example where the flag_control_-flags breaks

[MaEtUgR]

Yes, I totally agree. I certainly want to iterate on this. It's not too late to change this state to the custom flight task state that covers multiple features in the classic commander structure with feedback on feasability of the tasks themselves. But as of right now I want orbit to get usable without loosing too much extra time, it's waiting for too long.

[MaEtUgR]

rebased and fixed the failsafe handling more based on loiter requirements. I tested correct data link loss reaction.

@dagar Could you rereview?

[dagar]

Looks good. Would it be safer for now to also require manual?

[MaEtUgR]

It's not required in terms of the flight mode. It will continue the orbit like before with 0 or no RC input. There's a verified timeout check in flight tasks here https://github.com/PX4/Firmware/blob/master/src/lib/FlightTasks/tasks/Manual/FlightTaskManual.cpp#L75 which means it will not apply unupdated RC values. The most important thing for safety is not RC but that the pilot can stop via switching mode.

[dagar]

Actually it looks like we should be covered by the existing logic copied from loiter. RC loss is still respected if data link loss isn't configured.

[MaEtUgR]

@PX4/testflights To test the orbit:

• Have an up to date QGC that supports the command (was introduced ~July/August this year).
• Takeoff with a multicopter that has GPS and hover in an open area e.g. Position or Hold mode.
• Press on the map in QGC like you want to command a go to action
• Choose Orbit at the spot from the popup menu
• You see a circle on the map (with default radius 30m)
• Drag and resize the circle to where there are no obstacles
• Adjust the altitude on the right side bar if necessary
• Swipe on the bottom to start
• It will go as fast as possible to the commanded circle and do a slow (1m/s) Orbit exactly on the planned circle looking always with the front to the center
  To stop just switch to another flight mode again using RC or QGC
  You can influence the Orbit altitude, radius, speed and direction with the RC sticks
  Left stick: up/down for altitude change like in position mode
  Right stick: right/left is more/less speed counter-/clockwise, up down is radius smaller/bigger
  Be gentle with the right stick input maximum velocity is limited by the radius, maximum radius is 100m

Telemetry to show the current, maybe adjusted commanded circle on the map is on its way, only command is working until now.

[Avysuarez]

@MaEtUgR
The PR does not work, does not initialize the ESC's and does not recognize the radio

[santiago3dr]

needs to be rebased due to #10983

[mrpollo]

What are your thoughts on getting this in for v1.9 @MaEtUgR ?

[MaEtUgR]

@santiago3dr Thanks for the hint, I rebased without conflicts.
@mrpollo I would include it. More context in PX4/PX4-user_guide#397 (comment).

[Avysuarez]

Tested on pixhawk 4, pixhawk 4 mini and pixracer. good flight, no issues.
pixhawk 4 mini.
https://review.px4.io/plot_app?log=502235d4-9e11-4869-b19d-ac8a1b20a5df
pixhawk 4
https://review.px4.io/plot_app?log=e730f53a-9e6f-4023-8298-5a17b189a92a
Pixracer.
https://review.px4.io/plot_app?log=f6d651d4-0b67-4d56-8357-3e8f13d96eb4

[MaEtUgR]

Nice tests, thanks!!