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 rapyuta.io which just works. It is available for both the Cloud and Device environments. Explore rapyuta.io’s Native Network for hassle free communication between your robots. The following image describes the communication between robots using rapyuta.io’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 rapyuta.io’s Routed Network offering.
