Why ZeroDDS for ROS 2
A pure-Rust, fully spec-compliant DDS that fixes the reasons people leave DDS — without leaving RTPS interop behind.
The short version
ROS 2 runs on DDS. DDS is a good standard with a hard reality: the default configuration floods networks, breaks on WiFi, fails silently on QoS mismatches, drops large messages, and needs expert XML tuning before it works. Those are not rare edge cases — they are the most-reported, most-recent problems in the ROS community, and they are the reason the project adopted an alternate middleware (Zenoh) in 2023.
ZeroDDS is a from-scratch, pure-Rust DDS implementation that stays on the
wire (native RTPS 2.5, interoperable with Fast DDS / Cyclone DDS / OpenDDS /
Connext) but removes the structural causes of those failures. It speaks the
ROS 2 middleware ABI (rmw_zerodds), so it is a drop-in RMW_IMPLEMENTATION,
not a fork of ROS.
This trail does three things, per pain cluster:
- Describes the pain — grounded in a fresh field scan of 349 real reports (GitHub issues, ROS Discourse, Stack Exchange, vendor blogs; ).
- Cites the most recent ticket as a concrete, checkable example.
- Explains how ZeroDDS removes it — and how you can reproduce the fix yourself from the open harnesses.
For open-source validators: every performance and interop claim below ships with the command that produced it. We want you to run them, break them, and file what you find. This page is a set of falsifiable claims, not a brochure.
Why this matters more than it looks
ROS 2 is the de-facto standard for modern robotics R&D and a growing share of production robotics. The pain is not theoretical — it is a daily tax measured in lost lab afternoons, crashed demos, and “why don’t my nodes talk” threads. A scan of the field (2016–2026, newest dominating) breaks down like this:
| Pain cluster | Reports | Most-recent example |
|---|---|---|
| Discovery — multicast SDP, discovery storms, nodes not found | 62 | Fast-DDS#6401 (2026-05-18) |
Shared memory — Iceoryx/SHM segfaults, /dev/shm, same-host fails |
52 | rmw_cyclonedds#585 (2026-06-02) |
| QoS silent no-match — incompatible QoS → no data, no error | 36 | ros2#1562 (2024-05-10) |
| Multicast / WiFi — blocked, floods, dropouts | 34 | turtlebot4#673 (2026-02-04) |
| Cross-vendor / inter-distro interop | 32 | rmw_cyclonedds#577 (2026-04-02) |
| Large data / fragmentation — images, point clouds, 262 kB ceiling | 29 | Fast-DDS#5686 (2025-03-05) |
| DDS-Security / SROS2 | 22 | Fast-DDS#5753 (2025-04-08) |
| Configuration complexity — XML tuning, hidden prerequisites | 21 | Discourse “I’m done tuning DDS” (2026-04-30) |
| Docker / Kubernetes / cloud | 19 | IsaacSim#407 (2026-01-09) |
| Performance / latency / CPU | 19 | rmw_cyclonedds#559 (2026-03-03) |
| Scaling / fleets / many nodes | 16 | autoware#6759 (2026-01-24) |
| Migration to alternative middleware | 7 | Alternative Middleware Report (2023-09-27) |
Each row links to a page that follows the same shape: the pain → the most recent ticket → how ZeroDDS solves it → reproduce it yourself.
The standard: what ZeroDDS implements
ZeroDDS is not a DDS-flavoured transport. It is a complete, audited implementation of the OMG DDS specification family — the same stack RTI, eProsima, ZettaScale and OpenDDS implement, written in safe Rust.
| Specification | Scope | Status |
|---|---|---|
| DDSI-RTPS 2.5 | Wire protocol (SPDP/SEDP, reliable, fragmentation, HB/ACKNACK) | Full — native interop with Fast DDS / Cyclone / OpenDDS / Connext |
| DDS-DCPS 1.4 | Pub/Sub API, QoS, instances, listeners | Full |
| DDS-XTypes 1.3 | TypeObject/TypeLookup, assignability, XCDR1 + XCDR2 | Full |
| DDS-Security 1.2 | Authentication, access control, crypto, logging, tagging | Full — cross-vendor security matrix |
| DDS-XML, DDS-XRCE, DDS-RPC | XML profiles, Micro-DDS agent/client, services | Full |
| Language PSMs | C / C++ (PSM-Cxx) / Java / C# / Python / TypeScript | Full, codegen-driven |
| ROS 2 RMW | rmw_zerodds (REP-2003/2004/2005/2007/2008/2009) |
Drop-in RMW_IMPLEMENTATION, live cross-RMW interop with rmw_cyclonedds |
RC1 is published: 97 crates on crates.io + docs.rs, 100 % documented. It is all open source.
What we can do
- Native RTPS 2.5 interop — talks to Fast DDS, Cyclone DDS, OpenDDS and
Connext on the wire. A ZeroDDS node and a
rmw_cycloneddsnode match and exchange data bidirectionally (verified 20/20 onrt/chatter). - Discovery without multicast — unicast initial-peers (
ZERODDS_PEERS,ZERODDS_NO_MULTICAST) give you working discovery on WiFi, in Docker, across subnets, with no discovery server to deploy and babysit. - Loud failures instead of silent ones — an incompatible QoS match emits a
qos.incompatibleevent with the exact offending policy, and a staticqos_checkCLI validates compatibility before you launch. - Large data that actually arrives — application-level fragmentation with selective NACK_FRAG retransmit and a 16 MiB default reassembly cap (no silent drop at 1 MiB / 262 kB).
- Variable-size zero-copy shared memory — a length-prefixed SHM ring, not a fixed-size Iceoryx pool you have to dimension by hand.
- Runs from MCU to server — pure Rust
no_std + alloc; the core builds forthumbv7em-none-eabihf(Cortex-M4F) at a ~1.6 MB footprint, and scales up to multi-robot fleets. - Memory-safe by construction — safe Rust,
forbid(unsafe_code)across the safe core; whole classes of the SHM segfaults and buffer races reported against C++ stacks are not expressible.
How fast we are
All numbers are reproducible from the open examples and harnesses. Hardware and method are stated so you can compare on your own boxes.
| Metric | Number | How to reproduce |
|---|---|---|
| Round-trip latency, loopback, 256 B | p50 = 40 µs / p99 = 83 µs (200 samples, 0 lost) | latency_ping / latency_pong |
| Round-trip latency, cross-machine over WiFi, 256 B | p50 ≈ 4.3 ms (full discovery, 0 lost) † | latency_ping / latency_pong across two hosts |
| Large-data throughput over WiFi (fragmented) | 10.8 MiB/s (~86 Mbit/s) | run_wifi_largedata.sh |
| Large samples intact (2 / 4 / 8 MB) | byte-perfect, multicast-free | run_largedata.sh |
| All-to-all discovery, multicast-free | 50 participants in ~2.9 s, 100 in ~19.9 s | ZERODDS_SCALE_N scaling harness |
| Embedded footprint | ~1.6 MB, thumbv7em-none-eabihf |
cargo build --target thumbv7em-none-eabihf --no-default-features |
† The cross-machine WiFi number required keeping the WiFi NIC awake; idle 802.11 power-save on the client otherwise drops the latency-sensitive unicast discovery frames. This is an OS/AP power-management artifact (vendor-agnostic, reproducible A/B with a packet capture), not a ZeroDDS limitation.
Validate it yourself
This is the part that matters for an open-source audience. We do not ask you to trust a benchmark slide — we ship the harnesses:
- Cross-vendor, multicast-free discovery vs Cyclone DDS:
crates/ros2-rmw/interop/run_multicast_free_xvendor.sh— a ZeroDDS subscriber and a Cyclone talker discover each other with multicast fully disabled, and exchange 20/20 samples. - Live ROS 2 interop:
crates/ros2-rmw/interop/run_interop.sh—rmw_zeroddsagainst a realrmw_cycloneddstalker/listener onrt/chatter. - Latency / throughput / large data: the
latency_*,largedata_*examples undercrates/dcps/examples/.
If a claim on these pages does not reproduce on your hardware, that is a bug report we want. The pain corpus is also open — pick any ticket, reproduce it on your current RMW, then try it on ZeroDDS.
Honest status
ZeroDDS is at 1.0.0-rc.3. The spec stack is complete and audited; the cross-vendor interop, multicast-free discovery, large-data and QoS-loudness claims are e2e-verified. Areas still being hardened and measured: head-to-head latency/throughput comparison tables against each vendor, and broader real-fleet scaling numbers. Where a claim is verified we say so; where it is aspirational we mark it. The per-cluster pages are explicit about which is which.
Pages in this trail: Discovery · Multicast / WiFi · QoS silent no-match · Large data · Cross-vendor interop · Shared memory · Configuration complexity · Scaling · Docker / cloud · Security · Performance · Migration
Warum ZeroDDS für ROS 2
Ein Pure-Rust-DDS mit voller Spec-Konformität, das die Gründe behebt, aus denen Leute DDS verlassen — ohne die RTPS-Interop aufzugeben.
Die Kurzfassung
ROS 2 läuft auf DDS. DDS ist ein guter Standard mit harter Realität: die Default-Konfiguration flutet Netze, bricht auf WiFi, scheitert still bei QoS-Mismatches, droppt große Nachrichten und braucht Experten-XML-Tuning, bevor es funktioniert. Das sind keine seltenen Edge-Cases — es sind die meistgemeldeten, jüngsten Probleme der ROS-Community, und der Grund, warum das Projekt 2023 eine alternative Middleware (Zenoh) adoptierte.
ZeroDDS ist ein from-scratch Pure-Rust-DDS, das auf dem Draht bleibt (natives RTPS 2.5, interoperabel mit Fast DDS / Cyclone DDS / OpenDDS / Connext), aber die strukturellen Ursachen dieser Fehler beseitigt. Es spricht die ROS-2-Middleware-ABI (rmw_zerodds) und ist damit eine drop-in RMW_IMPLEMENTATION, kein Fork von ROS.
Dieser Trail leistet drei Dinge, je Schmerz-Cluster:
- Beschreibt den Schmerz — fundiert auf einem frischen Field-Scan von 349 echten Reports (GitHub-Issues, ROS Discourse, Stack Exchange, Vendor-Blogs).
- Zitiert das jüngste Ticket als konkretes, prüfbares Beispiel.
- Erklärt, wie ZeroDDS ihn beseitigt — und wie du den Fix selbst reproduzieren kannst, aus den offenen Harnessen.
Für Open-Source-Validatoren: jede Performance- und Interop-Aussage unten kommt mit dem Befehl, der sie erzeugt hat. Wir wollen, dass du sie fährst, brichst und meldest, was du findest. Diese Seite ist ein Satz falsifizierbarer Aussagen, keine Broschüre.
Warum das mehr zählt, als es aussieht
ROS 2 ist der De-facto-Standard für moderne Robotik-F&E und ein wachsender Anteil der Produktions-Robotik. Der Schmerz ist nicht theoretisch — er ist eine tägliche Steuer, gemessen in verlorenen Labor-Nachmittagen, abgestürzten Demos und „warum reden meine Nodes nicht”-Threads. Ein Scan des Feldes (2016–2026, neueste dominierend) gliedert sich so:
| Schmerz-Cluster | Reports | Jüngstes Beispiel |
|---|---|---|
| Discovery — Multicast-SDP, Discovery-Stürme, Nodes nicht gefunden | 62 | Fast-DDS#6401 (2026-05-18) |
Shared Memory — Iceoryx/SHM-Segfaults, /dev/shm, Same-Host scheitert |
52 | rmw_cyclonedds#585 (2026-06-02) |
| QoS stilles No-Match — inkompatible QoS → keine Daten, kein Fehler | 36 | ros2#1562 (2024-05-10) |
| Multicast / WiFi — blockiert, flutet, Aussetzer | 34 | turtlebot4#673 (2026-02-04) |
| Cross-Vendor- / Inter-Distro-Interop | 32 | rmw_cyclonedds#577 (2026-04-02) |
| Large-Data / Fragmentierung — Bilder, Punktwolken, 262-kB-Decke | 29 | Fast-DDS#5686 (2025-03-05) |
| DDS-Security / SROS2 | 22 | Fast-DDS#5753 (2025-04-08) |
| Konfigurations-Komplexität — XML-Tuning, versteckte Voraussetzungen | 21 | Discourse „I’m done tuning DDS” (2026-04-30) |
| Docker / Kubernetes / Cloud | 19 | IsaacSim#407 (2026-01-09) |
| Performance / Latenz / CPU | 19 | rmw_cyclonedds#559 (2026-03-03) |
| Scaling / Flotten / viele Nodes | 16 | autoware#6759 (2026-01-24) |
| Migration zu alternativer Middleware | 7 | Alternative Middleware Report (2023-09-27) |
Jede Zeile verlinkt auf eine Seite mit derselben Form: der Schmerz → das jüngste Ticket → wie ZeroDDS ihn löst → selbst reproduzieren.
Der Standard: was ZeroDDS implementiert
ZeroDDS ist kein DDS-angehauchter Transport. Es ist eine vollständige, auditierte Implementierung der OMG-DDS-Spec-Familie — derselbe Stack, den RTI, eProsima, ZettaScale und OpenDDS implementieren, in sicherem Rust geschrieben.
| Spezifikation | Umfang | Status |
|---|---|---|
| DDSI-RTPS 2.5 | Wire-Protokoll (SPDP/SEDP, reliable, Fragmentierung, HB/ACKNACK) | Voll — native Interop mit Fast DDS / Cyclone / OpenDDS / Connext |
| DDS-DCPS 1.4 | Pub/Sub-API, QoS, Instances, Listener | Voll |
| DDS-XTypes 1.3 | TypeObject/TypeLookup, Assignability, XCDR1 + XCDR2 | Voll |
| DDS-Security 1.2 | Authentication, Access-Control, Crypto, Logging, Tagging | Voll — Cross-Vendor-Security-Matrix |
| DDS-XML, DDS-XRCE, DDS-RPC | XML-Profile, Micro-DDS-Agent/Client, Services | Voll |
| Sprach-PSMs | C / C++ (PSM-Cxx) / Java / C# / Python / TypeScript | Voll, codegen-getrieben |
| ROS 2 RMW | rmw_zerodds (REP-2003/2004/2005/2007/2008/2009) |
Drop-in RMW_IMPLEMENTATION, live Cross-RMW-Interop mit rmw_cyclonedds |
RC1 ist publiziert: 97 Crates auf crates.io + docs.rs, 100 % dokumentiert. Alles Open Source.
Was wir können
- Native RTPS-2.5-Interop — spricht mit Fast DDS, Cyclone DDS, OpenDDS und Connext auf dem Draht. Ein ZeroDDS-Node und ein
rmw_cyclonedds-Node finden sich und tauschen Daten bidirektional aus (verifiziert 20/20 aufrt/chatter). - Discovery ohne Multicast — Unicast-Initial-Peers (
ZERODDS_PEERS,ZERODDS_NO_MULTICAST) geben funktionierende Discovery auf WiFi, in Docker, über Subnetze, mit keinem Discovery-Server zum Deployen und Babysitten. - Laute statt stille Fehler — ein inkompatibler QoS-Match löst ein
qos.incompatible-Event mit der genauen verletzenden Policy aus, und ein statischesqos_check-CLI prüft Kompatibilität vor dem Launch. - Large-Data, die ankommt — Application-Level-Fragmentierung mit selektivem NACK_FRAG-Retransmit und 16-MiB-Default-Reassembly-Cap (kein stiller Drop bei 1 MiB / 262 kB).
- Variabel-große Zero-Copy-Shared-Memory — ein längen-präfixierter SHM-Ring, kein fix-dimensionierter Iceoryx-Pool, den du von Hand auslegen musst.
- Läuft vom MCU bis zum Server — Pure-Rust
no_std + alloc; der Kern baut fürthumbv7em-none-eabihf(Cortex-M4F) mit ~1,6 MB Footprint und skaliert hoch bis zu Multi-Roboter-Flotten. - Memory-safe by construction — sicheres Rust,
forbid(unsafe_code)über den sicheren Kern; ganze Klassen der SHM-Segfaults und Buffer-Races, die gegen C++-Stacks gemeldet werden, sind nicht ausdrückbar.
Wie schnell wir sind
Alle Zahlen sind aus den offenen Examples und Harnessen reproduzierbar. Hardware und Methode sind angegeben, damit du auf deinen eigenen Maschinen vergleichen kannst.
| Metrik | Zahl | Wie reproduzieren |
|---|---|---|
| Roundtrip-Latenz, Loopback, 256 B | p50 = 40 µs / p99 = 83 µs (200 Samples, 0 verloren) | latency_ping / latency_pong |
| Roundtrip-Latenz, Cross-Machine über WiFi, 256 B | p50 ≈ 4,3 ms (volle Discovery, 0 verloren) † | latency_ping / latency_pong über zwei Hosts |
| Large-Data-Durchsatz über WiFi (fragmentiert) | 10,8 MiB/s (~86 Mbit/s) | run_wifi_largedata.sh |
| Große Samples intakt (2 / 4 / 8 MB) | byte-genau, multicast-frei | run_largedata.sh |
| All-to-all-Discovery, multicast-frei | 50 Participants in ~2,9 s, 100 in ~19,9 s | ZERODDS_SCALE_N-Scaling-Harness |
| Embedded-Footprint | ~1,6 MB, thumbv7em-none-eabihf |
cargo build --target thumbv7em-none-eabihf --no-default-features |
† Die Cross-Machine-WiFi-Zahl erforderte, die WiFi-NIC wach zu halten; idle 802.11-Power-Save auf dem Client droppt sonst die latenz-sensitiven Unicast-Discovery-Frames. Das ist ein OS/AP-Power-Management-Artefakt (vendor-agnostisch, reproduzierbar A/B mit einem Packet-Capture), keine ZeroDDS-Limitation.
Selbst validieren
Das ist der Teil, der für ein Open-Source-Publikum zählt. Wir bitten dich nicht, einem Benchmark-Slide zu trauen — wir liefern die Harnesse:
- Cross-Vendor, multicast-freie Discovery vs Cyclone DDS:
crates/ros2-rmw/interop/run_multicast_free_xvendor.sh— ein ZeroDDS-Subscriber und ein Cyclone-Talker finden sich bei voll deaktiviertem Multicast und tauschen 20/20 Samples aus. - Live-ROS-2-Interop:
crates/ros2-rmw/interop/run_interop.sh—rmw_zeroddsgegen einen echtenrmw_cyclonedds-Talker/Listener aufrt/chatter. - Latenz / Durchsatz / Large-Data: die
latency_*-,largedata_*-Examples untercrates/dcps/examples/.
Wenn eine Aussage auf diesen Seiten auf deiner Hardware nicht reproduziert, ist das ein Bug-Report, den wir wollen. Der Schmerz-Korpus ist ebenfalls offen — nimm irgendein Ticket, reproduziere es auf deiner aktuellen RMW, dann probiere es auf ZeroDDS.
Ehrlicher Status
ZeroDDS ist bei 1.0.0-rc.3. Der Spec-Stack ist vollständig und auditiert; die Cross-Vendor-Interop-, multicast-freie-Discovery-, Large-Data- und QoS-Lautheit-Aussagen sind e2e-verifiziert. Bereiche, die noch gehärtet und vermessen werden: Head-to-head-Latenz-/Durchsatz-Vergleichstabellen gegen jeden Vendor, und breitere Real-Flotten-Scaling-Zahlen. Wo eine Aussage verifiziert ist, sagen wir es; wo sie aspirational ist, markieren wir sie. Die Pro-Cluster-Seiten sind explizit, was was ist.
Seiten in diesem Trail: Discovery · Multicast / WiFi · QoS stilles No-Match · Large-Data · Cross-Vendor-Interop · Shared Memory · Konfigurations-Komplexität · Scaling · Docker / Cloud · Security · Performance · Migration