Compare commits

...

3 Commits

Author SHA1 Message Date
Beniamino Pozzan 4a295da95f docs(ROS 2): mention Zenoh middleware in main ROS 2 doc page
Signed-off-by: Beniamino Pozzan <beniamino.pozzan@gmail.com>
2026-03-15 16:23:56 +00:00
Beniamino Pozzan b4a811eb8b docs(uxrce): fix instructions for syncing px4 msgs
Signed-off-by: Beniamino Pozzan <beniamino.pozzan@gmail.com>
2026-03-15 15:29:53 +00:00
Beniamino Pozzan d0fe2f2410 docs(dds): mention ROS 2 message transition node in DDS middleware docs.
Signed-off-by: Beniamino Pozzan <beniamino.pozzan@gmail.com>
2026-03-15 15:11:58 +00:00
2 changed files with 19 additions and 9 deletions
+8 -3
View File
@@ -31,6 +31,8 @@ The [eProsima micro XRCE-DDS _agent_](https://github.com/eProsima/Micro-XRCE-DDS
The agent itself has no dependency on client-side code and can be built and/or installed independent of PX4 or ROS.
Code that wants to subscribe/publish to PX4 does have a dependency on client-side code; it requires uORB message definitions that match those used to create the PX4 uXRCE-DDS client so that it can interpret the messages.
An exception to the above rule is made by the _versioned_ PX4 msgs.
Please refer to the [PX4 ROS 2 Message Transition Node](../ros2/px4_ros2_msg_translation_node.md) to know more about it.
## Code Generation
@@ -385,11 +387,14 @@ Therefore,
- If you're using a main or release version of PX4 you can get the message definitions by cloning the interface package [PX4/px4_msgs](https://github.com/PX4/px4_msgs) into your workspace.
- If you're creating or modifying uORB messages you must manually update the messages in your workspace from your PX4 source tree.
Generally this means that you would update [dds_topics.yaml](https://github.com/PX4/PX4-Autopilot/blob/main/src/modules/uxrce_dds_client/dds_topics.yaml), clone the interface package, and then manually synchronize it by copying the new/modified message definitions from [PX4-Autopilot/msg](https://github.com/PX4/PX4-Autopilot/tree/main/msg) to its `msg` folders.
Assuming that PX4-Autopilot is in your home directory `~`, while `px4_msgs` is in `~/px4_ros_com/src/`, then the command might be:
Assuming that PX4-Autopilot is in your home directory `~`, while `px4_msgs` is in `~/ros2_px4_ws/src/`, then the command might be:
```sh
rm ~/px4_ros_com/src/px4_msgs/msg/*.msg
cp ~/PX4-Autopilot/msg/*.msg ~/px4_ros_com/src/px4_msgs/msg/
rm ~/ros2_px4_ws/src/px4_msgs/msg/*.msg
rm ~/ros2_px4_ws/src/px4_msgs/srv/*.srv
cp ~/PX4-Autopilot/msg/*.msg ~/ros2_px4_ws/src/px4_msgs/msg/
cp ~/PX4-Autopilot/msg/versioned/*.msg ~/ros2_px4_ws/src/px4_msgs/msg/
cp ~/PX4-Autopilot/srv/*.msg ~/ros2_px4_ws/src/px4_msgs/srv/
```
::: info
+11 -6
View File
@@ -15,17 +15,21 @@ It can be used, for example, for [computer vision](../computer_vision/index.md)
ROS 2 enables a very deep integration with PX4, to the extent that you can create flight modes in ROS 2 that are indistinguisable from internal PX4 modes, and directly read from and write to internal uORB topics at high rate.
It is recommended (in particular) for control and communication from a companion computer where low latency is important, when leveraging existing libraries from Linux, or when writing new high level flight modes.
Communication between ROS 2 and PX4 uses middleware that implements the [XRCE-DDS protocol](../middleware/uxrce_dds.md).
This middleware exposes PX4 [uORB messages](../msg_docs/index.md) as ROS 2 messages and types, effectively allowing direct access to PX4 from ROS 2 workflows and nodes.
The middleware uses uORB message definitions to generate code to serialise and deserialise the messages heading in and out of PX4.
Communication between ROS 2 and PX4 can leverage two independent middlewares:
- [XRCE-DDS protocol](../middleware/uxrce_dds.md) - more tested and included by default in most PX4 builds.
- [Zenoh protocol](../middleware/zenoh.md) - it needs to be manually enabled and added to PX4 builds.
The middlewares expose PX4 [uORB messages](../msg_docs/index.md) as ROS 2 messages and types, effectively allowing direct access to PX4 from ROS 2 workflows and nodes.
The middlewares use uORB message definitions to generate code to serialise and deserialise the messages heading in and out of PX4.
These same message definitions are used in ROS 2 applications to allow the messages to be interpreted.
::: info
ROS 2 can also connect with PX4 using [MAVROS](https://github.com/mavlink/mavros/tree/ros2/mavros) instead of XRCE-DDS.
ROS 2 can also connect with PX4 using [MAVROS](https://github.com/mavlink/mavros/tree/ros2/mavros) instead of XRCE-DDS / Zenoh.
This option is supported by the MAVROS project (it is not documented here).
:::
To use the [ROS 2](../ros2/user_guide.md) over XRCE-DDS effectively, you must (at time of writing) have a reasonable understanding of the PX4 internal architecture and conventions, which differ from those used by ROS.
To use the [ROS 2](../ros2/user_guide.md) over XRCE-DDS / Zenoh effectively, you must (at time of writing) have a reasonable understanding of the PX4 internal architecture and conventions, which differ from those used by ROS.
In the near term future we plan to provide ROS 2 APIs to abstract PX4 conventions, along with examples demonstrating their use.
## Topics
@@ -41,4 +45,5 @@ The main topics in this section are:
## Further Information
- [XRCE-DDS (PX4-ROS 2/DDS Bridge)](../middleware/uxrce_dds.md): PX4 middleware for connecting to ROS 2.
- [XRCE-DDS (PX4-ROS 2/DDS Bridge)](../middleware/uxrce_dds.md): PX4 middleware leveranging micro XRCE-DDS for connecting to ROS 2.
- [Zenoh (PX4 ROS 2)](../middleware/zenoh.md): PX4 middleware leveraging Zenoh pico for connecting to ROS 2.