@MaEtUgR @bkueng Would appreciate your advice and help to update the Developer > Concepts > Flight modes, and in particular the image highlighted by @mrpollo , which was last updated in PX4 v1.12

Before evaluating any page (or even looking at it) it is worth thinking about the purpose of the page - the audience and what you want them to be able to do after reading it. This is a concepts page for developers, so you probably want them to

• know what a flight mode is for, what flight modes exist,
• how modes relate to flight tasks
• how modes fit into the architecture, source tree, and the broader pipeline that turns various inputs into actuator outputs.
• What classes they derive from
• A good starting point for your own modes
• How offboard modes integrate, and when would you do that rather than an onboard mode.

Ultimately they might want to create their own flight mode - it would be useful to point them to the tools they need to do that. To find the related code and be able to work out how to glue their own.

Assuming it is somewhat useful and accurate, then I'd propose we add missing modes and update the diagram:

• What are _TH > _SW referring to in the diagram decision tree?
• When it says "can transition to" in the decision blocks, what are the conditions used there - I know they are like the mode requirements for ROS2 modes in https://github.com/Auterion/px4-ros2-interface-lib/blob/main/px4_ros2_cpp/include/px4_ros2/common/requirement_flags.hpp
• How would we add ROS2 modes to this?
• Can you update it - anything I do would be creative writing.

Assuming it is not useful, lets put together a proposal about what we'd like to achieve with the page.

The main point for the issue was that the diagram is obsolete and can be removed. There is no hierarchical evaluation anymore.
There are still switches for RTL, Loiter and Offboard. But now they are handled as one-time requests when the switch is activated.
The specific mode requirements are defined in here: https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/commander/ModeUtil/mode_requirements.cpp#L46

I did not intend to add ROS modes here, but now that you mention it, maybe add a link?

Thanks. As per discussion on slack, we should remove all the current content except perhaps links to the user-facing modes docs. The diagram is obsolete, but the mode information is both incomplete and adds nothing over our other user-facing mode docs. We should also add the link to ROS modes here.
We can do that now as a part way point to make this "not wrong".

We should then start again with something that explains

1. Ways to create modes - PX4 and ROS
2. Criteria for whether you select PX4 or ROS for creating your mode.
3. Pointers to how to create a PX4 mode:
   • link https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/commander/ModeUtil/mode_requirements.cpp#L46 - how do you decide which to set?
   • What classes do you derive from
   • Location in tree
   • Relationship between tasks and modes
   • What else do you need to know?

@bkueng @MaEtUgR Do you have a view on "2"?

@MaEtUgR Can you help me with "3"? We would

For 2. I would say these are some guidelines:

• if low-level access and or strict timing or high update rate requirements (e.g. direct motor controls on an MC) -> PX4
• if vehicle has no companion -> PX4
• if not want to or can use ROS for whatever reason -> PX4
• if safety-critical (like RTL) -> PX4 (but you might still want to have a fancier RTL replacement on the ROS side)
• for the rest: ROS. Specifically, reasons for ROS: easier to implement (no need to deal with low-level embedded constraints and requirements, like stack sizes). Easier to maintain (no need to rebase custom PX4 changes). Crashing the app does not crash the vehicle. High-level functionality is available (e.g. dynamic data structures, or many (ROS) libraries). More available compute to do more advanced processing (e.g. computer vision).