Why ZeroDDS for ROS 2
RC7 preparation: this page retains historical investigations and measurements, not approval of the current candidate. Runtime file contracts were checked against current source; historical interoperability, performance and platform claims were not remeasured by that review.
A Rust DDS project with native RTPS interoperability and source-bound evidence for the contracts actually tested.
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 historical field scan of 349 reports (GitHub issues, ROS Discourse, Stack Exchange, vendor blogs). The consolidated research is internal, not published RC7 evidence.
- 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
The source tree prepares 1.0.0-rc.7. Implemented APIs and successful individual measurements do not establish blanket conformance of the entire DDS specification family. Each component has its own bounded source and test contract.
Java does not yet provide automatic remote TypeObject assignability. Native Python registration explicitly refuses unsupported inverse key contexts. Package publication and final candidate approval are separate steps.
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
(
discovery.peers,discovery.no_multicast,transport.user_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 — recorded in an internal historical investigation. That report is not a publicly available RC7 reproduction record.
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 consolidated historical research is internal. The individual public tickets cited on the topic pages can be inspected directly; that does not publish or validate the internal research as RC7 evidence.
Honest status
The current source is RC7 preparation, not a published or approved RC7. Historical measurements above retain their original scope. Current package, transport and documentation checks must converge on one candidate before release.
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
RC7-Vorbereitung: Diese Seite enthält historische Untersuchungen und Messwerte, keine Freigabe des aktuellen Kandidaten. Die Runtime-Dateiverträge wurden mit dem aktuellen Quellstand abgeglichen; historische Interop-, Performance- und Plattformbehauptungen dadurch nicht erneut vermessen.
Ein Rust-DDS-Projekt mit nativer RTPS-Interop und quellgebundenen Nachweisen für die jeweils getesteten Verträge.
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 historischen Field-Scan von 349 Reports (GitHub-Issues, ROS Discourse, Stack Exchange, Vendor-Blogs). Die zusammengeführte Untersuchung ist intern, kein veröffentlichter RC7-Nachweis.
- 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
Der Quellstand bereitet 1.0.0-rc.7 vor. Implementierte APIs und erfolgreiche Einzelmessungen ergeben keine pauschale Konformitätsfreigabe der gesamten DDS-Familie. Maßgeblich sind die begrenzten Quell- und Testverträge der jeweiligen Komponente.
Java bietet noch keine automatische Remote-TypeObject-Assignability. Die native Python-Registrierung verweigert nicht unterstützte inverse Key-Kontexte ausdrücklich. Paketveröffentlichung und endgültige Candidate-Freigabe sind separate Schritte.
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
(
discovery.peers,discovery.no_multicast,transport.user_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 — in einer internen historischen Untersuchung festgehalten. Dieser Bericht ist kein öffentlich zugänglicher RC7-Reproduktionsnachweis.
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. Die zusammengeführte historische Untersuchung ist intern. Die auf den Themenseiten einzeln verlinkten öffentlichen Tickets lassen sich direkt prüfen; das veröffentlicht oder validiert die interne Untersuchung nicht als RC7-Nachweis.
Ehrlicher Status
Der aktuelle Quellstand ist RC7-Vorbereitung, nicht ein veröffentlichtes oder freigegebenes RC7. Die historischen Messungen oben behalten ihren ursprünglichen Umfang. Aktuelle Paket-, Transport- und Dokumentationsprüfungen müssen an einem gemeinsamen Kandidaten abgeschlossen werden.
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