swarm_ros_bridge is a lightweight middle interface ROS package mainly based on ZeroMQ. It enables the specified ROS messages transmission among swarm robots through socket communication. The purpose of this package is to replace the traditional way of running ROS across multiple machines in ROS1, which has some drawbacks under swarm robots situation.
A example of two ROS robots communicating with each other through swarm_ros_bridge is shown below:
Robust: No need for central ROS master launching first. Each robot has its own ROS master and they can launch in a random sequence, connect with each other autonomously and reconnect if disconnected.
Flexible: You can choose the sending/receiving ROS topics rather than transferring all topics as ROS1 does.
Easy to use: Specify all the IPs and ROS topics in one configuration file.
This package is personally developed by Peixuan Shu (PhD, beihang university, China) on Jan. 2023. Any question/suggestion is welcomed at swarm_ros_bridge issue or shupeixuan@qq.com.
One thing that ROS does and that really isn’t good design for cross-network communication is that it repeats messages in full every time they are published, even when nothing or very little changes. Good examples of that are IMU messages of stationary robots. Does your package add any logic to avoid this?
You can choose the sending/receiving ROS topics rather than transferring all topics as ROS1 does.
That’s not really entirely correct. When a ros node subscribes to a topic it establishes individual connections to all publishers of that topic but none of the other nodes. So it will actually only receive/send messages of the topics that were explicitly requested by the receiver.
Does your ZeroMQ middle-layer correctly handle latched messages (called “retained” in MQTT)?
@chfritz Thanks for your interest. As for your concerns:
This package transfers all the specified ROS messages and does not handle repeated messages. But you can set a sending frequency limit in the configuration file.
In ROS1 multiple-machine communication mode, the topics of all the robots will appear in one robot despite not actually transferring these topic messages. The topic names of other robots may conflict with local topic names. A common way is to add prefixes to all topic names, which may be troublesome. In swarm_ros_bridge, you can choose which topic will appear in the rostopic list.
swarm_ros_bridge uses the ZeroMQ pub-sub mode, in which the publisher will discard messages if the subscriber does not receive them or the latched messages reached the high-water mark (this guarantees real-time data transmission). I am considering using the ZeroMQ push-pull mode for the transmission of ros messages that should not be discarded.
We did something similar with ROS1-ROS2 <–> ROS2-ROS1 based architecture for some of our multi robot use cases. This was in part inspired from the existing ROS1/2 bridge, but we needed finer control over QoS settings.
A detailed breakdown is here and herein lies the github repo
@ggupta nice work！You use ROS2 for inter-robot communication to replace the ROS1 multiple machine communication for ROS1 nodes, right?
swarm_ros_bridge use zeromq rather than ros2 dds.
Compared with ROS2 DDS communication, swarm_ros_bridge may have the following benefits:
Lightweight: It is a small ROS1 bridge node subscribing and sending remote ROS1 topics, so connecting with other ROS1 nodes is easy. ROS2 support of swarm_ros_bridge is in progress.
Reliable: It uses ZeroMQ socket communication based on TCP protocol while ROS2 is based on DDS, whose default protocol is UDP (unreliable). DDS is mainly designed for data exchange between native processes under wired communication rather than remote wireless communication？
@PeixuanShu - Yes, exactly that. In our case we are primarily using it to facilitate robot-server for multiple robots and one server but same can be used for robot-robot comm.
DDS allows the configuration of reliable transport mechanisms as well as best-effort. So it has been serving both the purposes for us (via UDP ofc). Sometimes we have used the slim_bridge to visualize point cloud and camera data too - for which best effort is in fact desirable since reliable comm results in wifi choking.
Kudos on the work however! I personally know some people who’d be happy with your ROS-ZeroMQ bridge, let alone the community at large.
