One of the key features of ROS is the ability to pass around information in a structured way between programs. In ROS 1, this was facilitated by a ROS-specific middleware, or system to allow for Inter-Process Communications (IPC). ROS 2 is designed around commercial middleware instead. It’s essentially meant to wrap existing middlewares with a ROS Middleware (RMW) interface.
By default, ROS 2 uses Data Distribution Service (DDS), an open standard for middleware designed for things like naval vessels, where there’s a lot of computers which need to talk to each other. ROS uses the eProsima Fast DDS implementation by default, and supports Eclipse Cyclone DDS, RTI Connext DDS, and GurumDDS. Sometimes there are issues with an implementation, and switching can help alleviate the issues. Unfortunately, the different RMWs are not always compatible with each other.
Zenoh is an up-and-coming middleware that was designed to overcome limitations in DDS for smart-city use cases, and is quickly gaining popularity.
When developing our vehicles, we had issues with multicast running over a mesh network. Switching to Cyclone with unicast enabled the network to function, but the limitation to unicast has made initial boot-up of a multi-robot system incredibly slow.
One possible approach to help in the discovery phase is to use a centralized discovery server.
Zenoh may also have better configuration options than DDS for our use case.