ROS2 Bridge

[haixuanTao]

Context

As the current active community in robotic are mainly using ROS 2 for building robots. It's hard for them to switch entirely from ROS2. Building easy-to-use bridge for ROS 2 can help provide a simpler way to integrate and transition projects to dora. This also gives the possibility to easily integrate ROS2 sensor node that does not provide any other API.

Implementation

To implement this bridge we can look at the already implemented zenoh-plugin-dds that gives us the possibility to use Rust to receive ROS2 Messages sent through DDS.

One example implementation is the zenoh_carla_bridge that takes ROS2 messages and use the CARLA Rust API to send messages to the Carla Simulator. Therefore, we should be able to have a POC of communication with ROS 2 with :

• Forking zenoh_carla_bridge
• replacing the Carla API with the Dora Custom Node API
• Adding this custom node in dataflow that needs to support ROS 2

Future Challenges

In order for this bridge to be used in a bigger area than just Car simulation, we will probably also have to:

• have a way to easily integrate ROS 2 message types in the dora-ros2-bridge as the current zenoh_carla_bridge only support a definite set of message type.
• have a way to easily map Input_id <-> ROS message type as the current zenoh_carla_bridge use preset ROS message id that is well defined within Carla.

Test Harness

To test the bridge, we thought about using:

• rosbag to replay messages and see if we're able to receive messages.
• Use our current ROS 2 benchmark in Python to send messages from ROS2 and receive them in dora and measure the latency in order to make sure there is not too much overhead.

Special Thanks

This feature would not have been possible without ADLINK + NTU team:

• ChenYing @evshary
• Jerry @jerry73204
• William @william-wyliang
• Yuyuan Yuan @YuanYuYuan

We also thanks people from USTC:

• Clara Zhang @clarazhang
• zhuvkevkevsky @zhukevkesky
• hzhuangqiu @hzhuangqiu
• lry1991 @lry1991
• leiGong-USTC @LeiGong-USTC

Thanks for helping us making dora better! ❤️

[haixuanTao]

In the preparation of testing on real car, @bobd988 , can you make a list of :

• ROS 2 Message type you plan to use
• A mapping of Input_id <-> ROS message type

This way we can prepare in advance changes that requires to be done.

[haixuanTao]

We have opened https://github.com/dora-rs/dora-hardware/tree/main to document hardware specification

[haixuanTao]

Follow up discussion with academic people has raised the following requirements for the bridge: Make dora-rs support current ROS2 tooling.

ROS 2 tooling has been used for many years with many people already very familiar with it. It would make sense that dora-rs support those tools at first to not break the development environment that people are used too. The 2 mainly used tools are:

• Rosbag: Allows replaying messages
• RViz: Allows to visualize ros messages.

Supporting those tools means that we need to support:

• a larger set of inputs and dora-arrow to ros2 message type.
• convert not only ros message data but also ros message header. As, RViz also use ros2 message header information ( e.g. frame_id for velodyne_msg ) that we currently does not use. We should therefore

[haixuanTao]

After taking a second look at https://github.com/evshary/zenoh_carla_bridge it seems that it leverages https://github.com/sequenceplanner/r2r which seems to be slightly better than https://github.com/ros2-rust/ros2_rust as it offer a more complete API.

It should also gives us a way for rapidly dealing with std_msgs which include Headers and sensor_msgs which is the standard sensor message standard.

[jerry73204]

@haixuanTao The user experience is better with r2r compared to ros2_rust. It offers comprehensive examples and compete API documentation. I recently refined the codegen backend of r2r and the work is merged to upstream. The build is much faster and is adaptive to various ROS configurations. The ROS message definition is available on docs.rs, such as std_msg/msg/Header. It would provide a better development experience.

[phil-opp]

I did some research on the existing rust<->ros2 bindings:

• The ros2_rust project provides the rclrs library. It integrates tightly with the ROS2 build system and links directly to rcl and other libraries of ROS2. This way, many advanced ROS2 features can be supported too, e.g. loaned zero-copy messages. However, hooking directly to the ROS2 build system makes the setup quite complex and fragile.
• R2R also links to the ROS2 libraries, but does not hook into the ROS2 build system. Instead, it uses bindgen to generate FFI to the generated ROS2 C code. This way, building only requires sourcing the ROS2 setup files and running cargo build. *edit
• rclrust generates message types directly from the *.msg files in the AMENT_PREFIX_PATH directory. Like the former two projects, it links to the ROS2 libraries for all functionality (e.g. publish).
• ros2-client does not link to any ROS2 libraries. Instead, it uses the pure-Rust RustDDS project to communicate with ROS2. It does not provide message type generation. It's also still limited to basic features.

All of the above projects seems quite active.

EDIT: R2R might support loaned messages https://github.com/sequenceplanner/r2r/pull/42/files

[phil-opp]

For communicating with ROS2, there is also the zenoh-plugin-dds project that links to CycloneDDS. I'm not sure whether they support any kind of serialization/deserialization for messages.

[phil-opp]

In order to create a ros2<->dora bridge, we need to find a good way to support typed ROS2 messages. It probably also makes sense to tackle typed input/output support for dora at the same time, which we already planned for quite some time: https://github.com/orgs/dora-rs/discussions/70#discussioncomment-3416054

I started prototyping a ros2<->dora bridge in https://github.com/dora-rs/dora-ros2-bridge. I currently use the ros2-client crate for interacting with ROS2 because it does not link any ROS2 libraries and is thus very easy to set up. I also started creating a fork of the rclrust-msg-gen crate (part of the rclrust project) in https://github.com/dora-rs/dora-ros2-bridge/tree/main/msg-gen. The goal is to generate Rust message types from the *.msg files without linking to any additional libraries. The generated types all implement the serde::Serialize/serde::Deserialize traits to be usable in dora.

Note that the dora-ros2-bridge does not integrate with dora yet. But you can already control the turtle in the ROS2 turtlesim package by running using https://github.com/dora-rs/dora-ros2-bridge/blob/main/examples/random_turtle.rs .