Hiroz (High-performance Interoperable Robotics on Zenoh) is a project by ZettaScale Technology, the company supporting Eclipse Zenoh — and the new name for what was previously known as ROS-Z.
Hiroz is a robotics stack built on top of Zenoh, implemented in pure Rust. The core idea is to provide full ROS 2 compatibility while enabling roboticists to go beyond what the ROS architecture allows — with less coupling to ROS internals, faster iteration, and a foundation for enriching ROS itself.
Relationship with ROS 2 and rmw_zenoh
Hiroz is not a replacement for rmw_zenoh. It is a distinct layer that sits on top of Zenoh directly:
rmw_zenoh is a Tier-1 RMW implementation based on Zenoh and using it with specific key expressions and encoding (CDR). It can be used as a shared library via the ROS 2 rcl, rclcpp, rclpy and rcl-rs API
Hiroz is a Zenoh-native platform — not bound to the RMW interface, but still interoperable with ROS 2 by using the same key expressions and encoding
Both can coexist and communicate over the same Zenoh infrastructure, meaning you can mix your regular ROS 2 Nodes with enhanced Hiroz Nodes in a same system.
Features extending beyond ROS
Multiple serialization formats: CDR (ROS-compatible), Protobuf, and more to come
Multiple language bindings: Rust (native), Python, and Go (Go bindings sponsored by Dexory)
Zero-copy and GPU memory support: Zenoh’s buffer-aware pub/sub enables CPU and CUDA memory backends coming soon
Full-Rust stack: memory safety and predictable performance by design; fits naturally into AI-assisted development workflows
Framework interoperability: communicate between ROS 2 nodes and non-ROS systems over the same Zenoh infrastructure
Feedback, questions, and contributions are welcome. If you have been following ROS-Z, everything carries over — just under the new name.
At ZettaScale, we are committed to keep supporting rmw_zenoh and also to evolving Hiroz in close collaboration with partners and customers. If you have specific needs — performance, interoperability, custom transports, new language bindings — feel free to reach out.
The documentation doesn’t mention microcontroller support anywhere, and I am assuming that Hiroz isn’t no_std and just doesn’t really consider microcontrollers.
In my opinion, that makes sense given what they are attempting to do. Without having access to any data, I would assume that microros use is extremely small as compared to ROS use on like Ubuntu.
I’m assuming ZettaScale would point out that Zeno itself has great support for microcontrollers via zenohpico.
No, the underlying zenoh implementation is eclipse-zenoh/zenoh. That said, if anybody wanted to have a pure rust stack from microcontroller it wouldn’t be hard to do what PICO-ROS has done for zenoh-pico over zenoh-nostd. Or else, you could just use native zenoh-nostd and deal with the proper mapping.
Can you elaborate on this ?
Is this feasible, or this theoretically possible ?
The reason I ask is that I am currently working on a defence project where we have seen real improvements from porting existing C code to Rust.
Defence contractors are increasingly preferring Rust over C, driven both by the current momentum around Rust and by its tangible technical benefits. The DARPA TRACTOR program has made Rust adoption in governmental/defence areas more acceptable, and we feel the impact even though we are not from the US.
We are actively porting existing systems while also developing new frameworks and architectures for collecting data from sensors and moving it all the way to the cloud.
At the moment, I am building prototypes and proof-of-concepts using Zenoh to explore whether this can be done within a single stack using Rust.
First of all, congratulations on the launch of HIROZ! Building a pure Rust, Zenoh-native robotics stack that natively decouples the transport and serialization layers is a massive leap forward for the robotics ecosystem.
I was particularly excited to read your Protobuf Serialization Guide Protobuf Serialization - HIROZ and see first-class support for ProtobufSerdes alongside CDR.
In your documentation, you noted the current ecosystem reality:
“Warning: Protobuf-serialized messages are not compatible with standard ROS 2 nodes using CDR. Use protobuf when you control both ends of the communication…”
Over on the C++ / ROS 2 side, we’ve been tackling this exact same pain point with protoros2 Announcing protoros2: use protobuf in ros2 without compromise (announced recently), aiming to bring zero-intrusive Protobuf support to standard ROS 2 C++ nodes without modifying ros2core or RMWs.
Seeing HIROZ’s Rust implementation, it feels like an intriguing complementary puzzle:
HIROZ tackles the Rust + Zenoh side with hiroz_msgs::proto::* and ProtobufSerdes.
protoros2 tackles the C++ / ROS 2 side, providing .proto SSOT workflows, TypeAdapter bridges, and serialized buffer pass-throughs.
I noticed that HIROZ structures its namespaces as hiroz_msgs::* vs hiroz_msgs::proto::*, while protoros2 currently uses a mirrored .msg.pb convention with ROS 2 TypeAdapter bindings. There are likely subtle design differences in how type identification, Key Expressions, and schema mapping are handled across the two stacks.
I’d love to hear your thoughts on this possibility:
Does the HIROZ team see potential or interest in standardizing / aligning on Protobuf wire-format conventions across HIROZ-native Rust and ROS 2 C++?
If you have a chance to take a quick glance at protoros2, we’d greatly appreciate any feedback or feasibility analysis on what it would take to bridge the two ecosystems cleanly.
Supported
Very soon
:* vs hiroz_msgs::proto::*, while protoros2 currently uses a mirrored .msg.pb convention with ROS 2 TypeAdapter bindings. There are likely subtle design differences in how type identification, Key Expressions, and schema mapping are handled across the two stacks.