The transition from tethered machines to autonomous and mobile robots introduces distinct communication challenges. The shift towards wireless communication is indispensable for the operation of modern robot communication and their interaction in fleets and with connected equipment.
This paradigm shift brings with it the complexities of ensuring reliable and efficient communication for tele-operation, exacerbated by the inherent instability and constraints associated with wireless technologies but also Internet connectivity in general.
In this article, we will explore how communication protocols work in robotic systems and how the Zenoh protocol can overcome the challenges faced in this field.
The Imperatives for Communication Protocols in Robotic
The essence of robotic communication requires robust, adaptable protocols for various scenarios and technologies.
With remote control and analytics, robotics systems are increasingly becoming microcontrollers-to-cloud systems.
This is crucial for seamless operation across diverse robotic platforms and auxiliary systems. Protocols must exhibit:
- Lightweight and efficient design to minimize bandwidth and latency issues.
- Flexibility across networking technologies like WiFi, 4G, 5G, and Bluetooth.
- Agility in deployment for dynamic robotic environments, from point-to-point to complex networks.
- Comprehensive communication patterns, including service invocations, action triggering, and publication/subscription models.
- Security considerations to protect against cyber threats with measures like TLS and fine-grained access control.
- Tunability of communication for optimized performance by adjusting message frequency, size, and prioritizing critical data.
- Ease of integration with other digital ecosystems, requiring compatibility with legacy protocols like MQTT or OPC-UA.
In-Robot Communication Needs
Robotic systems involve multiple software components for functions like navigation, hardware interfacing, and environmental mapping.
These modules must communicate effectively within a single robot, often in high-speed environments where traditional networking may be inadequate.
For intra-robot communication, shared memory offers the highest efficiency. Alternatives like Unix pipes or direct memory access (DMA) are viable but have trade-offs in speed and complexity.
Outbound Robot Communication Optimising Robot-to-Anything
While internal communications are vital, interactions between robots and external controllers are equally critical.
Managing connections within each software component is suboptimal due to overhead and resource contention.
A more efficient approach involves a communication router within the robot to handle all external communications.
This reduces the burden on individual components, lowers the risk of packet collisions, prevents network bloat with irrelevant data, simplifies security configurations, and minimizes attack surfaces.
The Case of Communications in the Robotic Operating System
ROS (Robot Operating System) is an open-source ecosystem providing software libraries and tools for robotic applications.
It allows developers to build applications as nodes, which control one or multiple robots.
ROS 2 introduces a modular design with an abstract middleware interface, allowing communication stack changes.
By default, ROS 2 uses the Data Distribution Service (DDS) middleware for inter-node communications, eliminating the need for a master node.
Nodes discover each other via UDP multicast and communicate peer-to-peer via UDP unicast or multicast. While ROS 2 resolves the single point of failure issue in ROS 1, it introduces new challenges:
- Scalability Issues: Peer-to-peer communication requires nodes to be aware of all other nodes, causing scalability problems.
- Heavyweight Discovery Protocol: DDS requires complete discovery of remote nodes, leading to resource-intensive startup and network flooding.
- Security Concerns: Each node has an open UDP port, increasing the attack surface. Configuring secure communication for each node is complex.
- Inefficiency in Request/Reply Pattern: Using publication/subscription for requests and replies doubles topics and requires clients to filter irrelevant replies.
Transitioning from ROS 1 to ROS 2 improves modularity and reliability but presents challenges in scalability, discovery protocol overhead, security, and communication inefficiencies.
Understanding these issues is essential for optimizing robotic systems with ROS 2. By focusing on these aspects, developers can create more robust and efficient robotic applications.
How Zenoh protocol overcome these challenges
In July 2023, a survey conducted among ROS users aimed to understand the challenges they face with robotic communications and to explore alternatives to DDS as middleware for ROS.
The survey’s comparative analysis of potential alternatives identified Eclipse Zenoh as the most promising middleware for ROS (read the survey here).
As a result, in May 2024, a new release of ROS 2, named Jazzy Jalisco, introduced the option for developers to experiment with Zenoh as a middleware.
This release provides initial support, and is intended for the community to experiment, provide feedback and help maturing it.
A Zenoh router in the robot provides several benefits
By default, Zenoh in ROS 2 overcomes challenges from previous versions of ROS.
- Rendez-vous Router: Each node connects to the router over the loopback interface. The router shares minimal discovery information, enabling peer-to-peer connectivity within the robot.
- Resilient Peer-to-Peer Communications: Once established, peer-to-peer communications continue even if the router stops, allowing configuration changes without restarting nodes.
- Boundary Controller: The router mediates between internal nodes and external systems, routing necessary traffic and downsampling data.
- Security Enhancement: The router minimizes the attack surface and simplifies security configuration by serving as a unique entry point for external communication.
- Flexible Transport Support: Zenoh supports various transports, allowing easy adaptation to communication constraints. Internal communications can use TCP, shared memory, or vsock, while external communications can use TLS, QUIC, or WebSockets.
- Plug-ins: The Zenoh router supports plugins for interoperability with other protocols (e.g., MQTT, DDS) and databases (e.g., InfluxDB, RocksDB).
- Rest API: A REST API plugin enables browser communication with the robot via HTTP.
- Internet Connectivity: Deploy interconnected Zenoh routers from robots to the cloud for secure, global access without complex NAT or firewall configurations.
Zenoh middleware in ROS 2 significantly advances communication in robotic systems, offering improved flexibility, security, and resilience.
Conclusion
The advancement of robotic technologies and their increasing reliance on wireless communications present significant challenges but also opportunities for innovation in communication protocols.
By adopting Zenoh, you can have your robots work and scale on wireless networks, and can leverage a single protocol from the smallest microcontroller on your robot up to the cloud across any network.