Angelo Corsaro

Small, uncrewed vehicles with limited computing resources that also operate in edge networks need communications systems that impose a minimum of overhead, and with the Zenoh protocol now available for the ROS 2 operating system they now have that option. (Image courtesy of US DoD)
Small, uncrewed vehicles with limited computing resources that also operate in edge networks need communications systems that impose a minimum of overhead, and with the Zenoh protocol now available for the ROS 2 operating system they now have that option. (Image courtesy of US DoD)

ZettaScale’s CEO tells Peter Donaldson how Zenoh is taking off in the world of robotics

Deploying multiple types of uncrewed vehicle systems at scale and managing them from remote facilities over diverse wireless networks creates some knotty communications problems. Chief among them is the overhead associated with protocols originally developed for wired networks – protocols such as the Data Distribution Service (DDS), for example, which serves as the communications middleware in the popular open-source Robot Operating System, ROS 2.

Overhead is all the data that must be sent over a network to ensure the information that the sender and recipient want to exchange (the payload) gets to the right place. Clearly, some overhead is essential, but too much can slow communications and increase energy consumption significantly.

‘Zero network overhead’

To solve this problem, Angelo Corsaro and three colleagues – Julien Enoch, Olivier Hecart and Eric Boasson – began creating a new and fundamentally different protocol, called Zenoh, and set up the ZettaScale Technology company to develop it. Thanks to their efforts, and of those who have joined the team since, the company and adoption of the protocol have grown rapidly.

It was recently announced that the developers of ROS 2 decided to adopt Zenoh as the core communications software after testing showed this will reduce the energy required for data transfer within the system by 60-90%. The name Zenoh comes from ‘zero network overhead’, which is not meant literally.

Corsaro had been involved with the standardisation of DDS from the early 2000s, serving as co-chair of the DDS Working Group until 2015, when he resigned over what he calls a “divergence of perspectives” on issues such as overhead, which spurred his efforts to develop Zenoh.

“I felt that I was the only one who cared about solving the problems we had, and the others just didn’t want to talk about the problems so as not to scare customers or users. But, for me, the point was that engineers are supposed to solve problems, and before long you will be hit by what you have hidden from users,” he says.

Zenoh is designed to be topology agnostic, enabling people to use any network topology that best suits their communications needs, including brokered, routed and direct peer-to-peer (Image courtesy of ZettaScale)
Zenoh is designed to be topology agnostic, enabling people to use any network topology that best suits their communications needs, including brokered, routed and direct peer-to-peer (Image courtesy of ZettaScale)

All in the flow

The initial work on Zenoh stemmed from experience gained from early work on smart cities that involved fog computing, which provides a layer of computing functionality between devices at the edge of the network and the cloud. One of these smart city projects was Connected Boulevard in Nice, which monitored rubbish bins at parking spots.

“We were already being faced with challenges in trying to make sure data could flow from a tiny battery-powered microcontroller embedded in the roadside and running on a proprietary low-power network,” says Consaro. DDS simply could not run on a microcontroller on such a constrained network.

“It was just too heavyweight,” he explains. Getting the data to flow involved stitching different protocols together, creating what he calls a digital Frankenstein. “The only winners there are systems integrators, because that is how they make money,” he adds.

Zenoh is designed to run above a data link, network or transport layer in a software stack, and it imposes a minimal overhead of just 5 bytes per data exchange (Image courtesy of ZettaScale)
Zenoh is designed to run above a data link, network or transport layer in a software stack, and it imposes a minimal overhead of just 5 bytes per data exchange (Image courtesy of ZettaScale)

Defining fog

In the 2013-14 timeframe there was some wrangling over the definition of fog computing, with some considering it an extension of the cloud and others regarding it as a synonym for edge computing, Corsaro recalls. The Fog Consortium’s definition now characterises it as the continuum between the data centre and the device in which there has to be computing, communications and storage.

The challenges lie in the stitching together of protocols to enable data to flow, where to store the data and, if it is stored at the edge, how to find it.

“My primary objective was to come up with a protocol able to run from the microcontroller up to the data centre. At that time there was no such protocol because they had all been designed for one segment; a reflection of systems that were siloed. The other objective was to keep data decentralised and query it from anywhere,” says Corsaro.

New protocols

He describes the start of roughly simultaneous initiatives in Europe and the US to conceive the Next Generation Internet (NGI) as a fortunate accident, as they coalesced around a new family of protocols based on the Named Data Networking (NDN) concept. Sometimes referred to as Intent Centric Networking (ICN), NDN represents a paradigm shift in how data is found, Corsaro explains.

“Today, the internet is built on top of IP, and IP, despite being a packet-switched protocol, always communicates between two end points, and so you need to know the IP address of a machine in order to do something useful with that machine. But this is not how we use the internet. Our use is data-centric; when you want to read The Guardian, The New York Times, or whatever, you don’t care that there is a machine with an IP server that eventually will serve you those pages. You care about given named data,” he says.

“NDN proponents were saying, ‘what if we create protocols that instead of routing addresses route data?’ Imagine a file system path such as Guardian/news/politics, for example. If you had a network that could route information based on this name, where this information is doesn’t matter anymore.

“You give me a name, and based on that name, I decide – as the network – where the best place is to get the data for you. All of a sudden, fault tolerance is trivial, load balancing is trivial, supporting multiple regions is trivial, and as far as I can duplicate content the network supports it. The catch is that to do voice-over IP on this kind of protocol, while not impossible, is difficult because they are intended to query internet-scale data,” Corsaro adds.

ZettaScale has used a TurtleBot4 like this to demonstrate the ease of teleoperating and monitoring a robot over wi-fi with its new Zenoh bridge for ROS 2 (Image courtesy of Clearpath Robotics)
ZettaScale has used a TurtleBot4 like this to demonstrate the ease of teleoperating and monitoring a robot over wi-fi with its new Zenoh bridge for ROS 2
(Image courtesy of Clearpath Robotics)

NDN-compatible

ZettaScale has put Zenoh forward as an NDN-compatible protocol. “What we managed to do, essentially, was to come up with a protocol that puts together a publish-subscribe set of primitives that are able to run on very constrained hardware and networks, imposing minimal overhead (5 bytes), and still deliver incredible performance on a 100 GB network and blend it with NDN,” says Corsaro.

Zenoh can perform diffusion and distributed query operations, and it includes a “queryable” that acts rather like an oracle in that it tells the network that anyone looking for a particular type of information should “come to me”. The queryable is integrated with third-party databases, while the routing algorithm uses the name of the data that the user is looking for and their location to work out where to go to fetch the data, he explains.

“With a very simple, nimble and efficient protocol, you have data in motion. And you have what you need for data at rest – such as sensor data – so you can sort it wherever you want, and query from wherever you want, and perform computations on it. And those are the three elements you need to build a distributed system that have never been satisfied before.”

While Zenoh’s first adopter was in the telecoms business, it has really started taking off in robotics, Corsaro says, and particularly in robots that run on ROS. “Why? Because the protocol they were using was DDS,” he explains. “DDS works well on fixed networks, but it doesn’t work at all well on wireless networks. The main issue is the way in which it does discovery – it completely overloads your network.”

Discovery is the process by which computers and other devices on a network find each other, and it relies on set theory.

“What DDS does when applications discover each other to share ‘interest’ is literally what a young kid would do to denote a set – it tells you all the elements that are in that set. What Zenoh does instead is give you a closed-form expression. All of a sudden, there is a ridiculous difference in the amount of discovery traffic – it’s reduced by 90-99%,” says Corsaro.

Just come to me

This reduction is because the model in Zenoh makes smarter use of set theory, exploiting intersection and generalisation, he says.

“Suppose I’m a robot, and I produce information such as ‘robot one lidar’, ‘robot one video’, ‘robot one odometry’. In DDS, you would have to enumerate all these, one by one. Zenoh figures out that they all belong to the set called robot one ‘star star’ and tells you ‘if you’re looking for something for robot one ‘star star’, just come to me’,” Corsaro says.

The same method is used in routing, he says, comparing it with route planning for driving, which starts by simply identifying a few major roads, with all the detail in the last two or three miles before the destination. In this analogy, DDS would give the driver every turn-by-turn instruction at once, subjecting them to information overload.

While input-output (IO) is responsible for the lion’s share of energy consumption within an operating system such as ROS, communication incurs a large share of the operating costs of a network of robots, so a more efficient protocol saves both energy and money.

Talking directly

Corsaro says there are three aspects that really matter: how efficiently the protocol uses the CPU, wire efficiency and routing efficiency. To improve the latter, Zenoh allows two robots on the same network to communicate directly, peer-to-peer, while others, such as MQTT, require them to go via the cloud.

Because Zenoh messages are so small, compared with DDS messages, with overhead of 5 bytes for an individual message, communication costs are much lower. Further, when sending data more frequently, it can be packaged more efficiently, so the overhead drops to 3 bytes per megabyte. DDS imposes a minimum of 568 bytes.

In a comparison of communication costs over a satellite link, Corsaro assumes 24/7 communication over a year and relatively small payload packets, resulting in 1.8 GB of overhead with DDS and 157 MB with Zenoh, and respective costs of $14,400 and $1200.

In a 2022 study, Open Robotics assessed about 28 protocols as candidates to replace DDS as the communications middleware in ROS 2, followed by a poll of ROS users. Zenoh came out on top. Late last year, it was announced that the next long-term release of ROS 2 would run its communications on Zenoh. It has also been selected by the European initiative on software-defined vehicles, known as Eclipse SDV.

“You can think of protocols as being like the nervous system of the body, and I want to make our protocols the nervous system of robotics and automotive,” Corsaro says.

“The team is super committed to making that happen. We really see it as our mission.”

Angelo Corsaro
Angelo Corsaro

Angelo Corsaro

Angelo Corsaro, 48, describes himself as a Sicilian “by blood”, even though he was born in Bergamo, a town close to Milan and Lake Como in Northern Italy, where his father worked after graduating. When he was aged six or seven, his parents returned with him to Catania in Sicily to care for his ailing grandmother, to whom he became very close.

Corsaro’s grandparents lost almost everything during the Second World War, and he credits their efforts to rebuild the family’s fortunes with instilling a strong work ethic in him.

Growing up in Catania, Corsaro discovered a talent for maths and physics at school, got into computer science at an early age, and also took up music. He remains a bass player. Until he sustained a serious injury at 17, he played football at a high level.

“I never thought that I was going to be a football player because I really wanted to be an engineer,” he recalls.

He regards the timing of the injury as fortunate, as it allowed him to focus more on his studies when he went to university in Catania to study for a degree in telecoms engineering, which he followed with a master’s in computer engineering from the same institution, and then a PhD in computer science from Washington University in St Louis, USA.

Sicily has a strong physics tradition, and early 20th-century theoretical physicist Ettore Majorana is among Corsaro’s heroes. “He was born two blocks away from my grandmother’s house.”

While regarding himself as temperamentally unsuited to being mentored, Corsaro expresses great admiration for his PhD advisers Doug Schmidt and Ron Citron, and his late calculus professor, Filippo Clarenza.

A career in software followed at companies including Selex, PrismTech and Adlink Technology, overlapping with work at the not-for-profit Object Management Group Standards Development Organisation (OMG SDO), where he served on the board of directors. He started ZettaScale Technology in January 2022.

UPCOMING EVENTS