ROS publishers using dds types and not ros messages.

[pravinkmr26]

I was trying to enable ROS2 in LibCarla and CarlaUE4 package and check how sensor data can be directly published over ros2 topics (say PointCloud) and so I was looking at the code found that the Ros publishers use dds types instead of ROS types. I would like to understand how the subscriber would use this data. I was hoping that the data would be published to ROS types. can you direct me to some design docs so that I can understand how publishing over ROS would work from a high level. (publisher&subscriber flow)

[pravinkmr26]

Hey team, can someone help me understand this stuff?

[xavisolesoft]

Hi Pravin,

I'm sorry, but we do not have ROS2 native design diagrams. Fastdds library is the implementation of one of the protocols used by ROS2 to comunicate with external agents like CARLA.
For CARLA implementation, currently we are directly using fastdds without ROS2 middleware. If you want to share some improvement proposals, we will be glad to listen it as our ROS2 native implementation is recent and still not perfect, even though is working properly. Consider also that middleware could add time overhead in the simulator tick, so our purpose with this implementation was getting the maximum performance as CARLA is a real time system. Anyway, we can consider if the overhead of the ROS2 middleware will be significant compared to the benefit of using a simpler interface.

I share here a link with explanation about fastdds in ROS2.
https://fast-dds.docs.eprosima.com/en/latest/fastdds/ros2/ros2.html

Best Regards

[pravinkmr26]

Hi @xavisolesoft, thanks for clarifying. Sorry I couldn't spend a lot time for coming up with a POC for this. however I found a paper (https://arxiv.org/pdf/2101.02074) that explains latency with respect to ros rmw implementation, middleware stack (like FastRtps), dds delay. these are my observations,

• It was interesting to see that the actual delay between ros rmw and dds was considerably minimal when publishing
• but there's a considerable delay in subscription flow when using rmw implementation (considering the rclcpp notification delay explained in the paper)
• The latency decreases when the frequency of the data increases (for data with size <= 100KB)
• Number of nodes also has a minimal impact with respect to rmw_impl

by using the ros rmw stack,

• will be able to reduce the amount of code (for dss/ros) that we have in CarlaUe4 and libcarla packages
• will be able to re-use some of the ros idl defs (.msg files)
• less/no effort for carla-ros-bridge

Please share your thoughts, would love to contribute if needed. thanks.

[xavisolesoft]

Interesting analysis, thank you for sharing.

Currently, there is a big rework proposal PR on ROS2 that adds new publishers and services and also uses ROS middleware. This PR is under discussion and I suggest you to take a look before start working on changes about CARLA ROS2 native because you may have conflicts or implement the same features:
https://github.com/carla-simulator/carla/pull/7229/files

This PR also contains a PowerPoint with some Design diagram from ROS2 Native and the old ROS2 bridge.

[pravinkmr26]

Great, thanks for sharing, but I couldn't find the Power point design doc. please help me find that.

[xavisolesoft]

Here you have the Power Point link:

https://github.com/carla-simulator/carla/files/14539728/CARLA-ROS2-Integration.pptx