Is there any ongoing work on alternative middleware support for native ROS2?

[habby1012]

Hi,

We have been looking into CARLA's native ROS2 implementation and noticed it's tightly coupled with Fast DDS. We are interested in making it possible to use other middleware (Zenoh, CycloneDDS, etc.) without relying on the ros-bridge.

We found some related discussions:

• #9294 — requesting alternative DDS support
• #7266 — discussion about rclcpp vs direct DDS API
• #7229 — a previous attempt to refactor the middleware layer, which seems to have stalled.

Is anyone currently working on this? And would the maintainers be open to contributions in this direction?

Would love to hear if there's been any progress or plans we might have missed.

[JesusAnaya]

Hi @habby1012, I've done a refactoring to decouple the current FastDDS structure in Carla and to create an interface for adding other DDS middleware. The initial goal is to add CycloneDDS as an alternative middleware. Adding other non-DDS middleware will require a subsequent phase of changes. For now, the short-term objective is to add more DDS vendors to Carla.

Originally, I did all the refactoring in a single commit, but it's too large to merge directly. I'm leaving it here for reference #9589. Now I'm working on decoupling it into several smaller pull requests that are easier to review. I hope this works so they can be merged into Carla and we can add more middleware to the simulator.

Here's the list of PRs I've managed to decouple so far:

1. feat(LibCarla/ros2): [1/7] add DDS middleware abstraction layer for multi-vendor support #9608
2. feat(LibCarla/ros2): [2/7] add POD message types, FastDDS conversions, and TypeMap specializations #9612
3. feat(LibCarla/ros2): [3/7] migrate publishers and subscribers to POD message types #9619
4. feat(LibCarla/ros2): [4/7] add CycloneDDS to middleware enum, factory, and tests #9620

There are still 4 more to go, but I'm currently away from home, so I won't have the entire series of PRs ready until the end of this week.

[habby1012]

Thanks for the update and for all the work on this!

I've been experimenting with a slightly different approach on my side — using rclcpp + rmw instead of a DDS-level abstraction. The idea is that it could also support non-DDS middleware like Zenoh. I have an early prototype working on the ue5-dev branch with some basic sensors verified.

I'm planning to open a draft PR soon to share it. Would love to hear thoughts from you and the maintainers on both approaches!