feat(commander): external modes setpoint types & reliability#27683
Conversation
436b382 to
1ec77b1
Compare
💡 Commit messages could be improvedNot blocking, but these commit messages could use some cleanup.
See the commit message convention for details. This comment will be automatically removed once the issues are resolved. |
🔎 FLASH Analysispx4_fmu-v5x [Total VM Diff: 880 byte (0.04 %)]px4_fmu-v6x [Total VM Diff: 848 byte (0.04 %)]Updated: 2026-06-30T08:30:59 |
would you consider having different QoS for different topics? |
That is what I tested, only setting some topics as reliable, but it affected all other topics too. |
Allows an external mode to check if the request got processed
Important for external modes in case a topic sample gets dropped.
1ec77b1 to
48e0d07
Compare
Switches from using VehicleControlMode to a specific setpoint type message with reply. Reasons: - in case a VehicleControlMode was dropped (e.g. when the mode switched setpoint type), no confirmation was returned, and resulting in wrong controller flags. - cleaner interface separation: external modes do not need to configure (or know) which controller to run for a certain setpoint - allows for external modes to check for compatibility: e.g. a mode using fixed-wing setpoint types can now be rejected on a multicopter. - allows for further extensions, like a setpoint timeout This makes it a bit more effort to add a new setpoint type. Specifically, setpoint_types.cpp needs to be extended when adding a new setpoint message. PX4 internal modes also make use of the setpoint types. The information flow is: nav_state -> setpoint type -> vehicle control mode flags It also adds a timeout to the setpoint config, but is not implemented yet. This changes the interface for external modes and thus the compatibility version is increased.
48e0d07 to
df468e7
Compare
|
@mrpollo do you want to hold off with merging this? |
|
Since it's ready to be merged I wouldn't hold off since it's a really good improvement and also solves some sporadic issues with setpoint reliability. @mrpollo - would appreciate if this could be in the 1.18 release |
|
I think this is fine to come in now for v1.18, the only thing I am now thinking is the Test Team doesn't currently have any test cards that include a companion computer and code running using the ROS 2 interface, we should likely have a test that does, even if its just a simple behavior API check that can be verified with a log. If anyone wants to help me describe how that would work I would make sure you get a proper dinner on me ;) |
|
@mrpollo sure! Happy to help |
|
Thanks everyone. I can also help. Probably the simplest is to run the goto example: https://github.com/Auterion/px4-ros2-interface-lib/tree/main/examples/cpp/modes/goto. |
Background
This started out with reliability issues: DDS topics do not use reliable transfer, which for most cases is fine as topics are regularly updated or checked for a reply. But there are some exceptions:
mode_completedsignallingWe started to see topic drops in very rare cases for modes that switch between setpoint types.
Solution
The cleanest solution would be to use reliable transfer for these topics.
I tried that in the past and it resulted in severe topic drops for all telemetry messages, making it unusable.
So this PR addresses the cases individually, there is a simple solution for each:
Setpoint types
This PR switches from using
VehicleControlModeto a specific setpoint type message with reply.Reasons:
VehicleControlModewas dropped (e.g. when the mode switched setpoint type), no confirmation was returned, and resulting in wrong controller flags.It also adds a timeout to the setpoint config, but is not implemented yet.
PX4 internal modes also make use of this (except they do not need to publish the topics as it's known at compile-time). So the new information flow is:
Apart from the added setpoint type compatibility check, the behavior is expected to be the same.
Adding a new setpoint type
When adding a new setpoint message, a new type needs to be added to
msg/versioned/SetpointConfig.msg, and handled insrc/modules/commander/ModeUtil/setpoint_types.cpp. Then it can be used for internal and/or external modes.Other changes
flag_control_acceleration_enabledThis depends on Auterion/px4-ros2-interface-lib#209
Note: it is a breaking API change for external modes and requires updating both sides. The API version is incremented and if there is a mismatch, an external mode raises an appropriate exception.