# Communication Isolation For Multi-Robot Systems Using ROS2

Lucas Naury, Adam Gouguet, Guillaume Lozenguez, Luc Fabresse

► To cite this version:

Lucas Naury, Adam Gouguet, Guillaume Lozenguez, Luc Fabresse. Communication Isolation For Multi-Robot Systems Using ROS2. SAC '25: 40th ACM/SIGAPP Symposium on Applied Computing, Mar 2025, Catania International Airport Catania Italy, France. pp.850-858, 10.1145/3672608.3707889 . hal-05077809

HAL Id: hal-05077809

https://hal.science/hal-05077809v1

Submitted on 22 May 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Communication Isolation For Multi-Robot Systems Using ROS 2

### Lucas Naury

Institut Mines Telecom Nord Europe
Douai, Nord, France
lucas.naury@etu.imt-nord-europe.fr

### Guillaume Lozenguez

Institut Mines Telecom Nord Europe
Douai, Nord, France

guillaume.lozenguez@imt-nord-europe.fr

### Adam Gouguet

Institut Mines Telecom Nord Europe
Douai, Nord, France
adam.gouguet@imt-nord-europe.fr

### Luc Fabresse

Institut Mines Telecom Nord Europe
Douai, Nord, France

luc.fabresse@imt-nord-europe.fr

## ABSTRACT

This article examines how to design communication isolation in a fleet of robots using the Robot Operating System (ROS 2). A qualitative analysis and comparison of several communication methods is provided, based on various criteria (isolation granularity, isolation strength, network usage, etc.). A specific scenario is implemented for each communication method to demonstrate their feasibility and highlight some of their limitations. Finally, experimental results both simulations and real robots compare five communication strategies, providing guidelines to help select the best method depending on the project's requirements.

## CCS CONCEPTS

* Computer systems organization → Robotic components;

* Software and its engineering → Publish-subscribe / event-based architectures; Software design tradeoffs; * Networks → Network protocols.

## KEYWORDS

ROS 2, Communication, Protocol, Multi-robot, Swarm, Isolation, Coordination, Data Distribution Service, Zenoh

### ACM Reference Format:

Lucas Naury, Adam Gouguet, Guillaume Lozenguez, and Luc Fabresse. 2024. Communication Isolation For Multi-Robot Systems Using ROS 2. In *Proceedings of Intelligent Robotics and Multi-Agent Systems (SAC2025-IRMAS)*. ACM, New York, NY, USA, 9 pages. https://doi.org/XXXXXXX.XXXXXXX

## ACKNOWLEDGMENTS

Part of this work was funded by the French National Research Agency (ANR-22-PEFT-0007) as part of France 2030 and the NF-FITNESS project.

## 1 INTRODUCTION

As mobile robots become increasingly common, and therefore affordable, many industries start to consider using them as fleets. These robots can be used for material transportation, agriculture, healthcare and many more [1, 5, 19]. This leads to extensive research on how to coordinate robots to achieve complex tasks [4, 9]. The coordination of robots in such scenarios depends heavily on their ability to communicate, and communication in fleets of robots remains an active field of research to this day. [10, 18, 23, 25].

Despite the variety of software platforms available, ROS (Robot Operating System) [22] is one of the most popular robotics frameworks, especially in the mobile robots field. It features a set of software libraries and tools to help robot development by providing a modular architecture. Its completely redesigned version, ROS 2, was introduced to leverage the power of ROS while fixing the design flaws that it had [15]. Although slow at first, the transition from ROS 1 to ROS 2 is speeding up as the end of support for ROS Noetic approaches [21].

Both versions use the concept of **nodes**. They are system processes, that can be distributed across multiple machines. Nodes communicate together through **topics**. A node can **publish** to a topic, and another can **subscribe** to that topic to receive the data.

Without proper configuration, every topic and message is accessible from anyone in the network. That way, many problems can arise: topic collisions (messages from different robots but with the same name), network bottlenecks (too much messages on the network), time critical data delayed (when an undesired subscriber listens to the data it can introduce some delays).

Although multi-robot systems have been a research subject for many years now (late 80s [12, 26, 27]) and the official release of ROS 2 being in 2017¹, there is still no standard on **how to architect communication between multiple robots using ROS 2** to this date, despite it being a theme of discussion in the ROS 2 community for many years<fnref n="2" />.

The objective of this paper is to provide a qualitative and comparative analysis of ROS 2-based communication solutions that support isolation, highlighting their advantages and limitations. The focus is on existing libraries and tools, where "isolation" refers to a mechanism designed to prevent a robot's internal topics from interfering with those of other robots, while also limiting access to these topics to address bandwidth efficiency and security concerns.

<footnote>Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org.</footnote>

<footnote>SAC2025-IRMAS, March 31–April 04, 2025, Sicily, Italy</footnote>

<footnote>© 2024 Copyright held by the owner/author(s). Publication rights licensed to ACM.</footnote>

<footnote>ACM ISBN 978-1-4503-XXXX-X/18/06...$15.00</footnote>

<footnote>https://doi.org/XXXXXXX.XXXXXXX</footnote>

<footnote n="1">¹https://docs.ros.org/en/rolling/Releases.html</footnote>

<footnote n="2">²https://discourse.ros.org/t/restricting-communication-between-robots/2931</footnote>
This paper is organized as follows. Section 2 presents related work. Section 3 presents five different solutions that are available nowadays to achieve communication isolation in ROS 2-based multi-robot systems. Section 4 presents our selection of 10 criteria to compare of those communication solutions. Section 5 reports on our experiments and their results both in simulation and on real robots over a specific scenario. Section 6 concludes this study and gives general guidelines to follow, so that you can choose the method that best fits your project needs.

## 2 SELECTING ROS-BASED COMMUNICATION SOLUTIONS FOR ISOLATION

One of the key motivations for implementing ROS 2 over ROS 1 is to improve the management of nodes and topics distributed across multiple machines. ROS 1 was using a custom Publish/Subscribe protocol, whereas ROS 2 was designed to be protocol agnostic. The ROS MiddleWare (RMW) module of ROS 2 acts as a standard interface for different protocol implementing Publishing/Subscribing capabilities. The OMG's Data Distribution Service (DDS) [20] is an industry standard that has been chosen as the default middleware in ROS 2. eProsima's FastDDS implementation is the default implementation since ROS 2 Humble [6] but there are also other DDS implementations such as CycloneDDS<fnref n="3" />, Connext DDS<fnref n="4" />, etc.

**ROS 1 bridge-based solutions.** Some papers highlight the combined use of ROS 1 and ROS 2 using the ros1Bridge library. In these architectures, ROS 1 is often used as the framework on the robots (mainly because of legacy code in ROS 1), and ROS 2 is used for the communication between them (taking advantage of the DDS Discovery protocol), to achieve collaboration [8, 11, 13, 24]. This architecture allows developers to keep the ROS 1 messages on the robot, and choose through the configuration of the ros bridge which topics should be shared to the ROS 2 network across robots. Nevertheless, such hybrid ROS 1/ROS 2 architectures shouldn't be considered for new projects since ROS 1's end of life date is in 2025⁵.

**ROS 2-based solutions.** Since ROS 2 Iron, the ROS_AUTOMATIC_DISCOVERY_RANGE and ROS_STATIC_PEERS environment variables were introduced <fnref n="6" />. These variables enable to choose whether a node can be discovered from another computer, or if it is restricted only to localhost. However, these options can only be configured at the node level which is usually not enough compared to a topic or message granularity.

**RMW-compliant solutions.** ROS 2 is protocol agnostic thanks to the RMW layer. Nevertheless, RMW-based implementations might not be directly configurable at the ROS 2 level<fnref n="7" /> and may require developers to dive deeper into the underlying protocol configuration. Among the very few implementations of protocols other than DDS that are fully RMW-compliant, we can cite: RMW DPS and RMW Zenoh. RMW DPS misses QoS support, and has not been

updated since 2020. The RMW based on Eclipse's Zenoh<fnref n="8" />, a communication protocol based on the Publish/Subscribe mechanism, has an active support but is still missing some security features. RMW Zenoh has grown in popularity as a potential replacement for DDS in ROS 2 thanks to its reduced number of discovery messages [2, 14, 28].

**Ad hoc solutions.** Some papers suggest bypassing ROS 2 and RMW as a communication protocol between robots by using other protocols for shared communication, for example UDP/TCP sockets [3], or IoT protocols such as MQTT [17]. However, we also consider bad practice to have ROS nodes that are not agnostic of the underlying communication mechanisms (e.g., network protocols, deployment topology) as described in [16].

**Conclusion.** The study described in this paper focuses on pure ROS 2-based solutions for topics/messages isolation and targets applications involving multiple mobile robots. To the best of our knowledge, there is no existing comparative review of such ROS 2 solutions for isolating topics or messages. Our study involves all DDS-based solutions and Zenoh.

## 3 ROS 2 SOLUTIONS FOR ISOLATION

The paper investigates three types of isolation. First, at ROS 2 level, these solutions are the easiest to use and remain protocol agnostic. Second, we investigate the possibilities offered by the DDS standard which is the default RMW implementation. And third, we complete the study with an alternative to DDS: RMW Zenoh.

Here is the list of the different communication solutions that will be studied in this paper:

(1) Namespacing topics

(2) Domain ID bridges

(3) DDS Discovery servers

(4) DDS Partitions filtering

(5) Zenoh

### 3.1 Namespacing topics

Namespaces are ROS 2 prefixes to node names, topics, actions and services. They allow to have multiple elements with the same name but different prefix to prevent collision.

In a multi-robot scenario (cf. Figure 1), namespacing is the easiest solution to separate each robot with a unique namespace, for robots to not have name conflicts when running the same nodes and using the same topics. An example of this is to prefix the /cmd vel topic for robots (/wall-e/cmd vel and /r2d2/cmd vel), to prevent them from having the same velocity command. Namespacing allows to prevent conflict in message interpretation but without real isolation. Every node can see/read any topic of any robot.

### 3.2 Domain ID bridge

ROS 2's default protocol for communication (DDS) allows nodes to discover other nodes that are on the same network. To create different logical networks, DDS provides a feature called the **domain ID**. Each node is allowed to communicate to nodes that are on the same ID, but can't communicate with nodes on other domain IDs. ROS 2

<footnote n="3">³https://cyclonedds.io</footnote>

<footnote n="4">⁴https://community.rti.com/documentation</footnote>

<footnote n="5">⁵http://wiki.ros.org/Distributions</footnote>

<footnote n="6">⁶https://discourse.ros.org/t/proposed-changes-to-how-ros-performs-discovery-of-nodes/27640</footnote>

<footnote n="7">⁷https://discourse.ros.org/t/a-more-unified-and-standard-way-of-configuring-the-dds-layer/11372</footnote>

<footnote n="8">⁸https://zenoh.io/</footnote>
<figure><img src="image_2.png" /><figcaption>Figure 5: A FastDDS Discovery Server Architecture</figcaption></figure>

<figure><img src="image_3.png" /><figcaption>Figure 6: DDS partitions example, Publishers (DataWriter) and Subscribers ( Reader) of the same topic but in different partitions.</figcaption></figure>

https://community.rti.com/static/documentation/connext-dds/5.2.3/
doc/manuals/connext_dds/html_files/RTI_ConnextDDS_CoreLibraries_
UsersManual/Content/Resources/Images/Partitions.png

the robot’s “local” partition (e.g. "wall_e") and messages that need
to be shared across robots or with the operator would be published
in a common “shared” partition.

3.5 Zenoh

Zenoh is a Publish/Subscribe protocol that is growing in popularity.
It works by providing a Router, which acts as the only gateway for
discovery information, and connects to other Routers across net-
works to share the information about publishers and subscribers it
has access to. That way, Zenoh reduces the discovery traffic and then
uses standard direct TCP when communication is established [28].

Additionally, the Zenoh Router can be configured to restrict
certain publisher/subscriber discovery information to be shared to
other specific Routers, and even choose through which network
interface they should be available, making it a flexible isolation
solution.

<figure><img src="image_4.png" /><figcaption>Figure 7: A DDS Partition-based architecture.</figcaption></figure>

Zenoh provides 2 options to be integrated with ROS 2 that both
provide similar configurations: RMW Zenoh<sup>11</sup> and Zenoh bridge
ros2dds<sup>12</sup>. RMW Zenoh integrates Zenoh at the ROS 2 RMW level
and replaces entirely DDS. The nodes automatically connect to the
Router.

Whereas Zenoh bridge ros2dds works by creating a bridge process that consists of a ROS 2 node and a Zenoh Router. The ROS 2 node listens to the DDS traffic on the local machine, translates the received discovery messages and then send them via the Zenoh Router.

Figure 8 shows a multi-robot scenario using the *Zenoh bridge ros2dds* implementation. Publishers/Subscribers that should stay local are filtered by the bridge whereas those who need to be shared are allowed through. A bridge can also restrict the network interfaces used to further enforce the isolation.

<figure><img src="image_5.png" /><figcaption>Figure 8: A Zenoh bridge ros2dds architecture</figcaption></figure>

<footnote n="11">¹¹https://github.com/ros2/rmw_zenoh</footnote>

<footnote n="12">¹²https://github.com/eclipse-zenoh/zenoh-plugin-ros2dds</footnote>
# 4 COMPARISON

To compare the five selected communication solutions available in ROS 2, we propose the following ten criteria:

* **Dynamism:** Does the architecture allow to dynamically add a robot in the fleet? (dynamic identification)

* **Reliability:** Are Quality of Service (QoS) options preserved?

* **Isolation strength:** From outside of a robot, is it possible to see the list of nodes, topics and subscribe to them?

* **Isolation granularity:** How much control is possible over the information shared (configuration at the node, topic or message granularity)?

* **Computability:** Does the system require a lot of computing power (both on the robots and the operator)?

* **Ease of programming:** Does this architecture require the programmer to make a lot of configuration on each robot to allow them to communicate?

* **Ease of debugging:** Is it simple to see the list of nodes / topics on a specific robot, and listen to the data published?

* **Network usage:** How much data is transferred on the network?

* **Simulation:** How easy is it to reproduce this communication architecture in a simulation?

* **Real robots:** How easy is it to reproduce this communication architecture on real robots?

The rest of this section discusses those criteria and how the five selected communication solutions fulfill them or not (**Table 1** shows a full summary). This comparison relies on a collaborative multi-robot scenario based on a warehouse environment.

## 4.1 Scenario

Figure 9 shows a simple map of a warehouse. At random time intervals, packages arrive at the 2 arrival zones.

<figure><img src="image_6.png" /><figcaption>Figure 9: Warehouse map of the scenario</figcaption></figure>

The goal is to implement an automatic delivery system based on a fleet of collaborating robots. The fleet may be heterogeneous (e.g. robots from different vendors). The system achieves these 2 tasks:

* **Store:** When a package arrives at a "Package arrival" spot, a robot is selected to pick up the package, and carry it to the correct "Storage" zone according to its color.

* **Retrieve:** An operator can send a request to retrieve a package from a specific color. A robot will be selected to go to the correct "Storage" position, and bring back this package to the "Package retrieval" zone.

Our experiment involves a fleet of 3 robots, **coordinating**, to achieve these tasks in the most effective way possible. This coordination will be achieved thanks to an **auction/bid system** that assigns the task to the best robot (based on its position and its way-points queue). In this scenario, the auction system is centralized, with an entity that listens all the bids and selects the best one. We consider that each robot knows the map (e.g. online/offline SLAM) and can't abandon a task that it has been assigned to.

## 4.2 Dynamism

The dynamism can either be automatic (identifiers are automatically generated) or manual (the developer needs to make sure each identifier is unique).

All solutions require some manual configuration on a new robot such as its name or id. It is not set automatically and the developer has to make sure it is unique to prevent collisions.

Domain ID also supports a limited number of possible id values<fnref n="13" />. If the fleet is really big (more than 100 robots), domain ID collision between robots is possible.

For the DDS Discovery Server as well as Zenoh, the new robot must also be configured with the IP address, port and ID of the shared DDS Discovery Server/Zenoh bridge.

## 4.3 Reliability

The reliability can either be preserved (same QoS) or with loss (modification of QoS).

Our study shows that all solutions preserve quality of service options which ensures that data priority between messages remains as expected.

## 4.4 Isolation strength

We will be considering that an entity is trying to see and list to topics from outside a robot, without any specific configuration.

This criterion can be split into 2 sub-criteria:

* Visibility isolation: Topics can either be visible or invisible

* Subscription isolation: Topics that are visible can either be listened or not

With *Namespaces* and *DDS Partitions*, everything is shared to everyone on the network (other robots, the operator PC and any other PC), anyone can see the list of nodes and topics. Using *Namespaces* it is also possible to subscribe to any topics whereas it is not possible, by default, using *DDS Partitions*. This latter solution only supports subscriptions to topics in the default empty partition (""). Nevertheless, it is possible to configure which partitions

<footnote n="13">¹³https://docs.ros.org/en/iron/Concepts/About-Domain-ID.html#choosing-a-domain-id-long-version</footnote>
<table><caption>Table 1: Summary of the different criteria for each method</caption><thead><tr><th rowspan="2">Criteria</th><th colspan="5">Methods</th></tr><tr><th>Namespaces</th><th>Domain ID</th><th>Discovery servers</th><th>DDS partitions</th><th>Zenoh</th></tr></thead><tbody><tr><td>Dynamism</td><td>Manual name</td><td>Manual ID</td><td>Manual name, central IP</td><td>Manual name</td><td>Manual name, central IP</td></tr><tr><td>Reliability</td><td>Preserved</td><td>Preserved</td><td>Preserved</td><td>Preserved</td><td>Preserved</td></tr><tr><td>Visibility Isolation</td><td>Visible</td><td>Invisible</td><td>Invisible</td><td>Visible</td><td>Invisible</td></tr><tr><td>Subscription Isolation</td><td>Can listen</td><td>Can't listen</td><td>Can't listen</td><td>Can't listen</td><td>Can't listen</td></tr><tr><td>Isolation Granularity</td><td>Topic</td><td>Topic</td><td>Node</td><td>Topic</td><td>Topic, interface</td></tr><tr><td>Computability</td><td>Unaffected</td><td>Extra nodes</td><td>Extra process</td><td>Unaffected</td><td>Extra process</td></tr><tr><td>Programming</td><td>Easy</td><td>Medium (Basic YAML)</td><td>Complex launchfile</td><td>Medium (Basic XML)</td><td>Medium (Basic JSON)</td></tr><tr><td>Debugging</td><td>Very Easy</td><td>Easy (Env variable)</td><td>Medium (Config needed)</td><td>Complex (Config needed, misleading)</td><td>Medium (SSH)</td></tr><tr><td>Network Usage</td><td>Normal</td><td>Reduced</td><td>Greatly reduced</td><td>Normal</td><td>Minimal</td></tr><tr><td>Simulation</td><td>Easy</td><td>Medium (Config needed)</td><td>Complex (Manual bridges)</td><td>Medium (Config needed)</td><td>Medium (Config needed)</td></tr><tr><td>Real robots</td><td>Not working</td><td>Working</td><td>Not working</td><td>Not working</td><td>Working</td></tr></tbody></table>

a subscriber/publisher is allowed to listen/publish to using a specific XML configuration file. It is even possible to use a wildcard partition name ("*") to allow subscription to all available topics.

When utilizing *Domain ID* bridges, the nodes running on the robots will not be visible by default, nor will their topics be accessible for viewing or listening. Only topics published within the current Domain ID or those bridged to it will be available. However, by changing the *ROSDomain_ID* to match that of one of the robots, the nodes of that robot will become visible, and its topics can be accessed for listening.

When using *DDS Discovery Servers*, nodes and topics will not be visible or accessible by default. By setting an appropriate environment variable, it is possible to specify the server to which the system should connect, thereby enabling visibility of the nodes and topics associated with that server, as well as the ability to listen to them. However, DDS Discovery Servers cannot function as a standalone solution, as they do not fully isolate the system and may lead to naming conflicts.

Similarly, when using *Zenoh*, non-exported topics will remain confined to the local robots' computers by default. However, this behavior is configurable, allowing for the export of some topics if needed.

## 4.5 Isolation Granularity

The isolation granularity can be at the message, topic, and node scales.

*Namespaces* can be applied to both nodes and topics.

With *DDS Partitions*, it is possible to specify which topics are published to, and received from, which partitions by using an XML configuration file.

When using *Domain ID* bridges, it is possible to select which topics are bridged within the shared *ROSDomain_ID* by configuring a YAML file.

*Discovery servers* can be configured exclusively at the node level, rather than at the topic level. Each node is connected to a specified list of discovery servers, enabling the discovery of only those nodes that share a common discovery server.

The *Zenoh* configuration file allows the developer to choose which topics can be shared to the other machines.

## 4.6 Computability

The computability criterion can either be "Unaffected" (no additional process required) or "Extra" if another process is running.

*Namespaces* and *DDS Partitions* don't require additional processes for the communication contrary to *Domain ID* bridges, *DDS Discovery servers* and *Zenoh bridges*.

## 4.7 Ease of programming

As it is challenging to quantify this criterion, it was assessed using three levels: "Easy", "Medium", and "Complex", with a rationale provided for each.

*Namespaces* is the simplest method to implement, as the Push-RosNamespace function can be used in Python launch files to automatically apply the namespace to all nodes and components initiated within it.

*Domain IDs* require an appropriate environment variable to be set prior to launching the nodes in the launch file. It can be done using the *SetEnvironmentVariable* Python function in launch files. Additionally, the domain bridges need to be initiated within the same launch file, utilizing a specific YAML configuration file.

Similarly, when using *DDS Discovery Servers*, the *ROS_DISCOVERY_SERVER* environment variable must be set before launching the nodes in the launch file, depending on whether they need to communicate over the shared network. Configuring this environment variable can be complex, as it requires multiple lines and may lack readability. The IP address must be placed in the correct position within the list according to the server ID (e.g., `";:10.89.5.110:11811"` to connect to a server with ID=2).

In contrast, *DDS Partitions* require the creation of a specific configuration file (XML format) and set the path to this file in an environment variable before launching the nodes in the launch file.

Similarly, the *Zenoh bridge* requires a specific configuration file (in JSON format) when launching the bridge. Additionally, it is necessary to ensure that all DDS communication between nodes remains local, so that only *Zenoh* communication is transmitted across the network.

## 4.8 Ease of debugging

As it is challenging to quantify this criterion, it was assessed using four levels: "Very easy", "Easy", "Medium", and "Complex", with a rationale provided for each.
With *Namespaces*, developers can use regular ROS 2's tools (`rviz`, `rqt_graph`, `ros2 node list`, `ros2 topic list`, etc.) since everything is published in topics.

When using multiple *Domain IDs*, the developer must first export the `ROS DOMAIN ID` environment variable to match the robot's domain. Once this is set, ROS 2 tools can be used to debug the robot.

When using *DDS Discovery Servers*, the ROS 2 CLI cannot access any information by default, even if the `ROS_DISCOVERY_SERVER` environment variable is correctly configured. To enable functionality with the *DDS Discovery Server* architecture, ROS 2 must be configured as a “Super client,” allowing it to discover all entities on the network [7, §16.2.5]. This is achieved using an XML configuration file that specifies the IP addresses, ports, and IDs of the desired *DDS Discovery Servers*. Whenever this configuration is modified, the ROS 2 Daemon must be restarted for the changes to take effect.

When using *DDS Partitions*, the ROS 2 CLI, by default, can see the list of topics on the network (via `ros2 node list`). However, it will not be able to listen to any data published to partitions other than the default empty partition (`""`). To enable listening to other partitions, the developer must configure ROS 2 to subscribe to specific partitions by specifying them in the configuration. It is also possible to subscribe to all partitions, except the default one, by using a wildcard (`"*"`) in the configuration file. That way, it can be misleading because you see the list of topics but you don't know if you can subscribe to them.

When using the *Zenoh* bridge, it is necessary to SSH into the various computers to debug DDS communication. If topics intended for sharing exist in DDS but are not visible on other machines, the *Zenoh* bridge configuration might be at fault and need to be adjusted accordingly to ensure proper topic sharing across the network.

## 4.9 Network usage

The network traffic when using namespaces will be taken as the reference point, given that this is the default behavior for ROS 2. All other methods will be considered as falling into one of the following categories: reduced, greatly reduced or minimal.

For all methods, when no nodes are subscribed to a topic, data is not transmitted over the network. Therefore, only the network traffic overhead generated during the **discovery** of nodes is considered in this section. The discovery protocol refers to the automatic detection and matching of publishers and subscribers across nodes, enabling them to exchange data.

With *Namespaces* or *DDS partitions*, the (Simple Discovery protocol) generates significant network traffic due to the broadcast nature of its requests.

When using different *Domain IDs*, the number of nodes discovered during the Simple Participant Discovery is reduced, which in turn decreases the traffic during the Simple Endpoint Discovery.

*DDS Discovery Servers* help isolate discovery sub-networks, thereby reducing network traffic.

*Zenoh* is designed specifically to minimize network traffic. By allowing only selected topics to be published to the network and utilizing an efficient protocol, it achieves highly optimized network usage.

# 5 EXPERIMENTS

We fully implemented the scenario described in Section 4.1 both in simulation the ROS 2 Stage Simulator and on real robots and for all the five communication solutions described in Section 3. The simulation allows to conclude about the feasibility of the tested methods and the complexity to put it in practice. Real robot experiments highlight embedded and networking limits. **Table 1 summarizes the experimental results with the final two criteria: Simulation and Real robots.**

## 5.1 Set-up

All our code related to this work is publicly accessible on our git repository: https://github.com/imt-mobisyst/pkg-multibot/tree/lucas2024.

Stage is a simple but powerful multi-robot simulator, which provides an interface to be used with ROS 2. The simulator as well as all the control nodes were running on a single computer (Dell XPS 13 7390).

The robots used in this experiment were Kobuki robots, with a **Raspberry PI 3B** mounted on top and running the drivers (for the motors and the 2D Lidar). Each Raspberry PI is connected with an ethernet cable to a **controller PC** (Dell XPS 13 7390) running the high level control (the navigation stack nav2 including localization and planning, multi-robot communication, etc).

As *RMW Zenoh* does not provide binaries for the ARM architecture of the Raspberry PI, we used the *Zenoh bridge ros2dds* in our experiments. However, our conclusions on *Zenoh bridge ros2dds* should apply for *RMW Zenoh* since they only differ in term of ROS 2 integration.

In the following sections, RPI will refer to the Raspberry PI, and computer will refer to the controller PC.

## 5.2 Simulation

As it is challenging to quantify this criterion, it was assessed using three levels: "Easy", "Medium", and "Complex", with a rationale provided for each.

As a first conclusion, simulation highlights the fact that *Namespacing* is the easiest method to configure. It only requires to make sure your namespaces match the simulator's.

Simulators often provide a single ROS 2 interface, using only one node that publishes and listens to the topics of all robots. All of these topics exist only in the `ROS DOMAIN ID` of the simulator node.

That way, to isolate robots in different *Domain IDs*, the solution requires to create bridges for each robot's topics (scan,odom etc.) from the simulator's Domain ID to the domain IDs where they are controlled.

For the *DDS Discovery Servers* method, bridges have to be **manually** developed to send specific messages to the shared network. The lack of isolation creates conflicts that require to use namespaces.

The *DDS Partitions* method relies on a specific configuration file to tell which simulation topics should be published to which partitions for each robot to only be able to read its own topics.

By assigning a *Domain ID* to each robot on the simulation computer, you can prevent DDS communication between different robots' control nodes. That way, intra-robot communication would
<figure><img src="image_7.png" /><figcaption>Figure 10: Our warehouse experiment on real robots</figcaption></figure>

happen through DDS, and you could use Zenoh as a bridge for out-
side communication (towards the simulator, the operator or other
robots).

5.3 Real robots results

Figure 10 shows our warehouse setup involving 3 real robots. Con-
trary to the simulation, *Namespaces* and *DDS Partitions* methods
do not scale for more than one robot. Indeed, the nav2's stack gen-
erates many nodes, publishers and subscribers, which induces a
lot of (discovery) traffic that RPIs cannot handle correctly. Further
investigations show that sending ROS 2 String messages from a
computer to a RPI with FastDDS at 200Hz resulted in **only 74.9%**
**being received** (8984 of 11999).

The solution using FastDDS's Discovery Servers was not working properly neither. Indeed, creating a bridge between the two DDS sub-networks requires to create a node connected to both DDS Discovery servers. However, DDS sub-networks are defined during discovery and can't be updated later on. Therefore, it is not possible to dynamically select to which DDS sub-network each message should be sent to.

The only two solutions that worked flawlessly on real robots
were the Domain ID Bridge and the Zenoh bridge. Network traffic
measures were made during the Discovery process of nodes, pub-
lishers and subscribers, and show a **significant reduction of 97.7%**
**of network packets using the Zenoh bridge (291) compared**
**to the Domain ID Bridge (12753).**

Although the experiments were conducted with only 3 robots,
it's already enough to show the limitations of some of the solu-
tions, even in a small fleet. The transition to more robust computing
devices could potentially enable the operation of more than three
robots. Nevertheless, the DDS overhead would continue to rep-
resent an inefficient utilization of resources when compared to
alternative solutions, such as Zenoh.

6 CONCLUSION

This paper compared five communication solutions that provide
isolation in a multi-robot context. These solutions were evaluated

across ten criteria, using a multi-robot pick-and-place scenario,
implemented both in simulation and on real robots.

Each solution presents its own advantages and drawbacks, with
no single perfect solution emerging. However, the Namespacing
solution proves to be a good option when considering ease of setup
and effectiveness in preventing message collisions, provided that
isolation and network traffic are not critical concerns. It is our pre-
ferred choice for single-computer simulation architecture involving
multiple robots.

In contrast, for multi-computer setups with real robots, the Zenoh-
based solution offers better topic isolation and significantly reduces
network bandwidth compared to other solutions.

This study also revealed that using DDS as a communication
protocol can lead to excessive network traffic, which may cause
message drops, particularly when running on low-power devices
such as the Raspberry Pi 3. While DDS configurations with proper
isolation (e.g., Domain ID in this study) offer an acceptable solution,
they still generate considerable discovery traffic. Zenoh drastically
reduces the discovery traffic, while still offering a lot of configu-
ration options (topic filtering, network interfaces, topic priority
etc.).

Finally, while all the solutions discussed offer some level of iso-
lation, there remains the possibility that messages could be inter-
cepted by anyone with the appropriate configuration. This poses a
risk, especially in production environments, where sensitive data
may need to be fully restricted—either due to confidentiality con-
cerns or to prevent any impact on the frequency of message publi-
cation.

In future work, we aim to investigate the coordination of multi-
robot systems under intermittent wireless communication (e.g.,
Wi-Fi, 5G). Such unreliable communication is often encountered
even when using mobile ad-hoc networks (MANETs), because phys-
ical obstacles like walls can block or degrade signal quality between
robots. Which software architecture and communication mecha-
nisms can adapt gracefully in such environments?

Additionally, we plan to explore security and trust mechanisms to
ensure that sensitive data remains protected from unauthorized
access, which is critical in preventing potential eavesdropping and
safeguarding the integrity of communication in real-world applica-
tions. Ultimately, further experimentation could be conducted with
larger robotic fleets to ascertain the efficacy of Zenoh in managing
such large-scale systems.

REFERENCES

[1] Yue Bai, Yaqiong Lv, and Jiatong Zhang. 2023. Smart mobile robot fleet management based on hierarchical multi-agent deep Q network towards intelligent manufacturing. *Engineering Applications of Artificial Intelligence* 124 (2023), 106534. https://doi.org/10.1016/j.engappai.2023.106534

[2] Loick Pierre Chovet, Gabriel Manuel Garcia, Abhishek Bera, Antoine Richard, Kazuya Yoshida, and Miguel Angel Olivares-Mendez. 2024. Performance Comparison of ROS2 Middleware for Multi-robot Mesh Networks in Planetary Exploration. arXiv:2407.03091 [cs.RO] https://arxiv.org/abs/2407.03091

[3] Morten Melby Dahl. 2021. *Expanding the ROS2 communication architecture*. Master's thesis. Norges teknisk-naturvitenskapelige universitet.

[4] Rajesh Doriya, Siddharth Mishra, and Swati Gupta. 2015. A brief survey and analysis of multi-robot communication and coordination. In *International conference on computing, communication & automation*. IEEE, 1014–1021.

[5] Luis Emmi, Mariano Gonzalez-de Soto, Gonzalo Pajares, and Pablo Gonzalez-de Santos. 2014. New Trends in Robotics for Agriculture: Integration and Assessment of a Real Fleet of Robots. *The Scientific World Journal* 2014, 1 (2014), 404059. https://doi.org/10.1155/2014/404059
[6] eProsima. 2021. Fast DDS selected default RMW for next ROS 2. https://eprosima.com/index.php/company-all/news/250-fast-dds-default-rmw-ros-2

[7] eProsima. 2024. Use ROS 2 with Fast-DDS Discovery Server. https://fast-dds/docs.eprosima.com/en/v2.14.1/fastdds/ros2/discovery_server/ros2_discovery_server.html

[8] Endre Erős, Martin Dahl, Kristofer Bengtsson, Atieh Hanna, and Petter Falkman. 2019. A ROS2 based communication architecture for control in collaborative and intelligent automation systems. Procedia Manufacturing 38 (2019), 349–357. https://doi.org/10.1016/j.promfg.2020.01.045 29th International Conference on Flexible Automation and Intelligent Manufacturing (FAIM 2019), June 24-28, 2019, Limerick, Ireland.

[9] Paolo Forte, Anna Mannucci, Henrik Andreasson, and Federico Pecora. 2021. Online task assignment and coordination in multi-robot fleets. IEEE Robotics and Automation Letters 6, 3 (2021), 4584–4591.

[10] Jennifer Gielis, Ajay Shankar, and Amanda Prorok. 2022. A critical review of communications in multi-robot systems. Current robotics reports 3, 4 (2022), 213–225.

[11] Muhammad Fadhil Ginting, Kyohei Otsu, Jeffrey A Edlund, Jay Gao, and Ali-Akbar Agha-Mohammadi. 2021. CHORD: Distributed data-sharing via hybrid ROS 1 and 2 for multi-robot exploration of large-scale complex environments. IEEE Robotics and Automation Letters 6, 3 (2021), 5064–5071.

[12] Martin Herman and James Albus. 1987. Real-Time Hierarchical Planning for Multiple Mobile Robots. In Proceedings of the DARPA Knowledge-Based Planning Workshop, Austin, TX, USA. https://tsapps.nist.gov/publication/get pdf.cfm?pub_id=820187

[13] Yuke Li, Yu Xianguo, Xiangke Wang, and Jiayi Zheng. 2023. Design of UAV Swarm Simulation Platform Based on ROS1 and ROS2 Hybrid Architecture. In 2023 42nd Chinese Control Conference (CCC). 5810–5816. https://doi.org/10.23919/CCC58697.2023.10240740

[14] Wen-Yew Liang, Yuyuan Yuan, and Hsiang-Jui Lin. 2023. A performance study on the throughput and latency of zenoh, mqtt, kafka, and ddos. arXiv preprint arXiv:2303.09419 (2023).

[15] Steven Macenski, Tully Foote, Brian Gerkey, Chris Lalancette, and William Woodall. 2022. Robot Operating System 2: Design, architecture, and uses in the wild. Science Robotics 7, 66 (2022), eabm6074. https://doi.org/10.1126/scirobotics.abm6074

[16] Ivano Malavolta, Grace A. Lewis, Bradley R. Schmerl, Patricia Lago, and David Garlan. 2020. How do you Architect your Robots? State of the Practice and Guidelines for ROS-based Systems. 2020 IEEE/ACM 42nd International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP) (2020), 31–40. https://api.semanticscholar.org/CorpusID:221784734

[17] Munkenyi Mukhandi, David Portugal, Samuel Pereira, and Micael Couceiro. 2019. A novel solution for securing robot communications based on the MQTT protocol and ROS. In 2019 IEEE/SICE International Symposium on System Integrations (SII 2019). https://doi.org/10.1109/SII.2019.8700390

[18] Manu Nair and Sidney Givigi. 2019. The impact of communications considerations in multi-robot systems. In 2019 International Conference on Communications, Signal Processing, and their Applications (ICCSPA). IEEE, 1–6.

[19] Eduardo Guzmán Ortiz, Beatriz Andres, Francisco Fraile, Raul Poler, and Ángel Ortiz Bas. 2021. Fleet management system for mobile robots in healthcare environments. Journal of Industrial Engineering and Management (JIEM) 14, 1 (2021), 55–71. https://doi.org/10.3926/jiem.3284

[20] Gerardo Pardo-Castellote. 2003. OMG Data-Distribution Service: architectural overview. In Proceedings of 23rd International Conference on Distributed Computing Systems Workshops, Vol. 1. 242–247 Vol.1. https://doi.org/10.1109/MILCOM.2003.1290110

[21] David Portugal, Rui P. Rocha, and João P. Castilho. 2024. Inquiring the robot operating system community on the state of adoption of the ROS 2 robotics middleware. International Journal of Intelligent Robotics and Applications (Oct. 2024). https://doi.org/10.1007/s41315-024-00393-4

[22] Morgan Quigley, Brian Gerkey, Ken Conley, Josh Faust, Tully Foote, Jeremy Leibs, Eric Berger, Rob Wheeler, and Andrew Ng. 2009. ROS: an open-source Robot Operating System. In Proc. of the IEEE Intl. Conf. on Robotics and Automation (ICRA) Workshop on Open Source Robotics. Kobe, Japan.

[23] Kavan Singh Sikand, Logan Zartman, Sadegh Rabiee, and Joydeep Biswas. 2021. Robofleet: Open source communication and management for fleets of autonomous robots. In 2021 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS). IEEE, 406–412.

[24] Maira Saboia da Silva, Lillian Clark, Vivek Thangavelu, Jeffrey Edlund, Kyohei Otsu, Gustavo Correa, Vivek Varadharajan, Angel Santamaria, Thomas Touma, Amanda Bouman, Hovhannes Melikyan, Torkom Pailevanian, Sung-Kyun Kim, Avak Archanian, Tiago Vaquero, Giovanni Beltrame, N. Napp, Gustavo Pessin, and Ali-akbar Agha-mohammadi. 2022. ACHORD: Communication-Aware Multi-Robot Coordination With Intermittent Connectivity. IEEE Robotics and Automation Letters 7 (10 2022), 1–8. https://doi.org/10.1109/LRA.2022.3193240

[25] Aniruddha Singhal, Prasun Pallav, Nishant Kejriwal, Soumyadeep Choudhury, Swagat Kumar, and Rajesh Sinha. 2017. Managing a fleet of autonomous mobile

robots (AMR) using cloud robotics platform. In 2017 European conference on Mobile robots (ECMR). IEEE, 1–6.

[26] K. Sugihara and I. Suzuki. 1990. Distributed motion coordination of multiple mobile robots. In Proceedings. 5th IEEE International Symposium on Intelligent Control 1990. 138–143 vol.1. https://doi.org/10.1109/ISIC.1990.128452

[27] P. K. C. WANG. 1989. Interaction dynamics of multiple autonomous mobile robots in bounded spatial domains. Internat. J. Control 50, 6 (1989), 2109–2124. https://doi.org/10.1080/00207178908953488 arXiv:https://doi.org/10.1080/00207178908953488

[28] Jiaqiang Zhang, Xianjia Yu, Sier Ha, Jorge Pena Queralta, and Tomi Westerlund. 2023. Comparison of DDS, MQTT, and Zenoh in Edge-to-Edge and Edge-to-Cloud Communication for Distributed ROS 2 Systems. arXiv:2309.07496 [cs.RO] https://arxiv.org/abs/2309.07496