Edge Robotics with Eclipse zenoh and ROS 2
The Robot Operating System 2 (ROS 2) is experiencing an incredible level of adoption across robotics applications, from autonomous vacuum cleaners to industrial and commercial autonomous vehicles. ROS 2 applications are also expanding to include:
- Robot swarms, where a group of resourceful robots coordinates among themselves and potentially a group of resource-constrained robots.
- Edge robotics, where an arbitrary collection of robot swarms can be monitored, managed, and controlled from the edge. In some cases, this reduces the need to include powerful hardware on the robot to enhance it with additional capabilities.
However, ROS 2 support for robot swarms and edge robotics has limitations. That’s where Eclipse zenoh comes into the picture.
Eclipse zenoh is an innovative protocol that allows robots to be easily monitored, managed, and controlled from anywhere on the internet. It supports use cases ranging from cloud to edge robotics so you can decide which data must be pushed, which should be pulled, and which should be stored and eventually queried. And it accomplishes all of this with a uniform and minimal set of abstraction operations while maintaining location transparency.
Before we get into more details about Eclipse zenoh and why it’s ideal for edge robotics, it’s important to understand how ROS 2 handles robot communications and why this leads to limitations.
ROS 2 Communications Were Not Designed for Wide Area or Wi-Fi Networks
ROS 2 applications are built as a collection of nodes that communicate through the Data Distribution Service (DDS). Eclipse Cyclone DDS is the rising star of DDS implementations in the ROS 2 ecosystem and is used for communications across nodes within the same robot as well as among robots. As a result, communications among ROS 2 nodes is peer-to-peer and makes extensive use of UDP/IP multicast techniques.
Figure 1: ROS 2 Applications Use DDS for Robot Communications
While DDS is extremely effective for supporting the node-to-node communications within and among robots on a wired LAN, its underlying protocol was not designed for wireless or to scale easily across a WAN. Challenges include discovering traffic and the nature of the reliability protocol. Using multicast on Wi-Fi networks is also problematic.
Eclipse zenoh Is an Incredibly Efficient Protocol
Eclipse zenoh blends leading research on named-data-networking with IoT publish/subscribe protocols to provide unified abstraction for data in movement and data at rest. It is designed to scale out, up, and down, and its routing infrastructure is designed to run at internet scale. We’ve proven that an Eclipse zenoh runtime requires as little as 300 bytes on an 8-bit Atmel microcontroller. Finally, the Eclipse zenoh protocol transparently supports peer-to-peer and routed communications and the protocol needs only a handful of bytes of wire overhead to do all of this.
Together, these capabilities make Eclipse zenoh the most wire-efficient protocol to date (Figure 2).
Key Abstractions and Primitives Enable Data Management
Eclipse zenoh defines four key abstractions:
- Resource: A named piece of data, such as a key value. For example: /company/cool-robot/42/battery-level, 0.25.
- Publisher: A spring of values for a key expression. For example, a robot publishing its position as the key /company/cool-robot/42/position.
- Subscriber: A sink of values for a key expression. For example, an application monitoring a robot’s position and subscribing to the key expression /company/cool-robot/*/position.
- Queryable: A well of values for a key expression. In other words, an entity available on the network that will answer queries matching the queryable key expression.
It’s worth noting that queryable can be used to model:
- A resource that can produce data on demand. For example, querying /company/cool-robot/42/battery-level returns the battery level for a specific robot, while /company/cool-robot/*/battery-level returns the battery level for all robots.
- A computation that is triggered as a result of the query.
- The read-side of geodistributed storage.
These fundamental abstractions can be natively combined to manage data in motion, data at rest, and remote computations. Publishers and subscribers are the natural abstraction to manage data in motion. Likewise, combining a subscriber with a queryable expression creates a model for distributed storage. Queryable can also be used to model distributed computations.
Along with abstractions, Eclipse zenoh provides the following primitives:
- scout: Performs a discovery, looking for other zenoh entities, such as routers or peers, on the network. Once an entity is discovered, a zenoh session can be established.
- open/close: Opens or closes an Eclipse zenoh session with an entity, such as a router or a peer.
- declare/undeclare: Declares or undeclares a resource, publisher, subscriber, or queryable entity.
- For subscribers, the declare primitive registers a user-provided call-back that’s triggered when data is available.
- For a queryable entity, the declare primitive registers a user-provided call-back that’s triggered when a query must be answered.
- write: Writes data for a key expression and can be viewed as the publish operation.
- pull: Pulls data for a pull subscriber. This allows the infrastructure to proactively move the data as close as possible to the subscriber so it is usually only one hop away when the pull request is issued.
- query: Issues a distributed query and returns a stream of results. The query target, coverage, and consolidation depend on configured policies.
Eclipse zenoh also provides a higher level API that combines core abstraction and primitives to provide key/value geodistributed storage and distributed computation abstraction. To support an unlimited number of storage backends, Eclipse zenoh’s storage abstraction uses a plug-in that integrates almost any database technology, including relational database management systems (RDBMSs), NoSQL, and time series databases.
In spite of the back-end technology, Eclipse zenoh provides uniform access to data. Stored values are retrieved by issuing a distributed query, and data encoding is transcoded as necessary to deal with different internal representations.
Edge Robotics with Eclipse zenoh
At this point, it should start to be clear why Eclipse zenoh plays a key role in enabling edge robotics. But, there is still one important question to answer: How does Eclipse zenoh support DDS data flows?
We’ve been working on a DDS plug-in for the Eclipse zenoh router and we expect to release it in the coming weeks. The plug-in is entirely built using Eclipse Foundation technologies, including Eclipse Cyclone DDS, for DDS communications (Figure 2).
Figure 2: Edge Robotics With Eclipse zenoh
As a result, it’s now possible to bridge DDS data on Eclipse zenoh. That means:
- Robot data can be streamed at internet scale with the Eclipse zenoh routing infrastructure.
- Robot data can be stored anywhere it makes sense on the Eclipse zenoh network — on the robot, on the edge infrastructure, in the cloud, or in all three. More importantly, the data can be queried from anywhere on the network using Eclipse zenoh’s distributed queries.
- Computation can be triggered on robots and the results can be collected anywhere on the network using a combination of the queryable abstraction and query primitive.
Get More Information
To learn more about Eclipse zenoh, visit the website.
To get involved in the Eclipse zenoh conversation on Gitter, click here.
For more information about the Eclipse Edge Native Working Group, click here.
About the Author
