Removing connectivity constraints in robots; ZettaScale chats to IoT Insider
ZettaScale focuses on “removing the connectivity constraints that exist today,” according to Angelo Corsaro, CEO of the company who spoke to IoT Insider about facilitating the growth of mobile robotics through the development of their protocol, Zenoh.
Mobile robotics versus fixed
The constraints to which Corsaro referred to, in his opinion, is the current situation companies find themselves in when deploying mobile robotics – which is having to integrate two to three protocols. “This is quite problematic,” said Corsaro. “On top of that, there are problems that lead back to the fact that many of the protocols in use today were designed 20 to 30 years ago, and the requirements of today’s systems are different to those 20 to 30 years ago.”
One such standard, Data Distribution Service (DDS) is the commonly used communication middleware for mobile robotics. Corsaro sees this as ill-suited to mobile robotics: “We could already foresee that the limitation this protocol would have when applied to a robot that would move, and as such, have to communicate over wireless networks.” He explained that robotics have, historically, been fixed, like a robot arm that performs pick and place tasks.
“You don’t have any power issues because there’s a power line and you have a fixed network … Communicating over a fixed network versus communicating over a wireless network like Wi-Fi, or 4G, 5G, is a different story.”
Corsaro said that the challenges faced by mobile robotics relying on wireless networks to operate while fixed robots use fixed networks, is due to the issue of “protocol ossification,” which refers to the loss of flexibility and evolvability of network protocols.
ZettaScale developing their own protocol
The big question of why companies have not invested into developing a protocol that, with the exception of Zenoh, can allow mobile robotics to communicate over wireless networks with ease, is down to the possibility they would have to invest in a new technology that may “kill” the former technology. “[This is] a hard call,” explained Corsaro.
“If we were to design a protocol today that needs to support the system, from the microcontroller to the data centre, how would we do it?” This wasn’t the only aspect they were looking at, he explained. “Moving data around is very important … At some point, data needs to be stored in a database. One of the big challenges that exists in this kind of system is that as soon as you store the data in a database, you need to know the location in order to issue a query.”
Expanding on this further, Corsaro said: “The problem is if I want to keep the data in it stored in a decentralised manner so it’s closer to the robots, how do I keep track of where the data was stored? Current technology doesn’t work like this.”
ZettaScale began work on the Zenoh protocol late 2015, early 2016. “I wrote the first implementation of the protocol and eventually the team grew,” said Corsaro. “The purpose of growing our team was to validate the use of this protocol in 5G network base stations, because they’re the problem of both white, large scale data distribution as well as distributed queries.”
The protocol itself has evolved, as four years ago ZettaScale decided to make the technology open source and started this project at the Eclipse Foundation – a European Open Source foundation, which Corsaro said they decided to incorporate into because it meant they had to comply with EU export rules, rather than the US.
“We decided to rewrite the protocol in Rust because of security [reasons],” he added. “We wanted a programming language that had a low overhead, a very high performance and was safe. Whenever you do communication protocols, security is very important. 70% of security attacks come from memory-related issues that by construction, are cancelled out when using rust.”
Zenoh 1.0.0
In September the company will be releasing the latest version of its protocol, Zenoh 1.0.0. When asked about this, Corsaro said: “Why are we releasing this version only now? We didn’t want to commit to backward compatibility. We think that it’s very important for a product to live and breathe for a few years and drive sufficient miles.”
Interoperability runs throughout their protocol, whether they’re releasing 1.0.0 or 1.7, it’s baked in. “This is one of the most important things we will guarantee with this version, interoperability from 1.0.0. Upwards.”
One of the distinguishing features of the new version include a new shared memory infrastructure designed to be certified at the highest level for the automotive industry, which Corsaro saw as “convergent” with robotics. “This version integrates a few requirements that came from the automotive industry,” he explained.
In his closing remarks, Corsaro alluded to the fact that he thought there were issues within the robotics industry and the IoT industry which were overlooked; namely energy.
“If you have an AMR (autonomous mobile robot) working in a warehouse, the architecture used for communications is Cloud-centric. This introduces a few problems like latency, which people understand, but the problem they underestimate is energy consumption,” he emphasised. “Most of the energy is consumed by communications, not computation … Enabling two robots to communicate directly leads to better energy consumption and lower costs.”
There’s plenty of other editorial on our sister site, Electronic Specifier! Or you can always join in the conversation by commenting below or visiting our LinkedIn page.
