Blog /

Native Networks: Rapyuta’s solution to the challenges faced in multi robot communication with ROS 1

Date: 04 Nov 2021
Category: engineering

Robot Operating System or ROS is a set of tools that help you build distributed robotic applications. Let’s consider a scenario wherein we have a warehouse with multiple AMR-type robots serving orders. Communication between these robots is essential to schedule orders and to plan their navigation.

Let’s explore some strategies to build such a system.

Strategy 1 : Using a Shared Central ROS Master

Assuming that all the robots belong to the same Local Area Network, a single ROS master reachable by every robot can be set up on a dedicated machine. Then the ROS Nodes on each robot can be configured to use the same ROS_MASTER_URI thereby enabling communication between ROS nodes on any of the robots.

Although this works in theory, in the real world a variety of factors including bugs, network failure or hardware failure can cause your distributed ROS application to fail due to one of the following scenarios:

  • Single point of failure: The shared ROS master stores registration information  about the ROS nodes connected to it, this information includes the ROS Graph, that is, new nodes, topics, services etc. When the shared master goes down this information is lost. The new nodes cannot register themselves or receive information from any other nodes nor can the existing nodes register any new topics/services. 
  • ROS Nodes don’t handle master failure gracefully
    A ROS node can be initialised only once, during initialization it registers its XMLRPC endpoint address with the configured ROS Master. Assume the ROS master fails and restarts, the ROS nodes have no idea about the ROS master failure nor can they re-register themselves with the ROS master more than once. 

In addition to the above mentioned failures, you may face the following challenges: 

  • As the ROS Master is shared, the resources are also shared and accessible to all the robots, a misconfiguration can easily lead to erratic behavior because a topic such as pose/cmd_vel gets mixed up. Therefore you must rely on explicit namespaces, topic remaps and parameterized launch files. This gets further complicated when the launch files start  invoking other third party launch files. 
  • Performance overhead: Due to a lot of data being broadcast over the network, there will be a significant amount of data that might not be required by nodes external to the robot. This overwhelms the network and causes performance issues as there will be unnecessary CPU cycles consumed to process the incoming data. To overcome this you may need to additionally whitelist the topics and thereby control the information flow.
  • Cumbersome setup: Besides setting up the ROS environment, the operators need to configure and potentially hard-code the IP address for the ROS Master on all the robots. It is hard to re-configure it later, especially when the number of robots increase.It also requires additional network configuration of assigning static IP to the ROS master which might be impossible at times.

Strategy 2: ROS Multimaster

The open-source Multimaster FKIE offers an interesting solution to the  aforementioned problems. Here each robot gets its own local ROS master and all the ROS nodes running on that robot only interact with it. The multimaster solution enables discovery of all the ROS masters running in your LAN and they sync their ROS graph (nodes, topics, services etc.). Thereby enabling ROS nodes on different robots to communicate with each other.

Although ROS Multimaster provides a solution to the Shared central ROS master, you may have to deal with the following hassle:

  • This setup relies on multicast and the network admins often disable this due to security reasons.
  • Additional  IP address as well as configuration of the service discovery mechanism like avahi is required on each robot.
  • Requires you to maintain two versions(with and without multimaster) of launch files.

Solution: Native Network

Native Networks is a managed Multimaster FKIE offering of which just works. It is available for both the Cloud and Device environments. Explore’s Native Network for hassle free communication between your robots. The following image describes the communication between robots using’s Native Networks.

Note: It works only if the ROS nodes are able to reach each other. That is, the devices need to be on the same network.

To build more complex distributed applications that require ROS nodes to communicate across multiple client sites or the cloud, please check out’s Routed Network offering. 

Recent Articles

/ 25 May 2022
Media Coverage_Mergermarket
Following our Series C fundraising, Rapyuta Robotics has been featured in Mergermarket on our future financial strategy.
read me
corporate, press release
/ 20 Apr 2022
Rapyuta Robotics secures USD 51 Million in Series C funding led by Goldman Sachs
Rapyuta Robotics, a leading developer of collaborative pick-assist robots (Rapyuta PA-AMR), or warehouse robots, and pioneers of Cloud Robotics, today announced USD $51 Million (JPY6.4 billion) in Series C funding led by Goldman Sachs Asset Management to accelerate expansion of robotics solutions and artificial intelligence technologies.
read me
/ 15 Mar 2022
ROS Noetic Support on platform now supports ROS Noetic - the 13th ROS distribution, exclusively targeted for Python3. ROS Noetic is primarily targeted for the Ubuntu focal 20.04 release.
read me
/ 08 Dec 2021
Deploying a Live Robot Demo in the Cloud
This is the story of how we deployed a 6DOF arm robot on cloud platform – with full access to a “robot command station” in JupyterLab! We’re using the Niryo One robot here, but you could do this with any similar robot. Introducing the Cloud! is a platform to run…
read me
Share on linkedin
Share on twitter
Share on facebook