Migration / Alternative Middleware

← Back to overview

The pain

The clearest signal that DDS pain is real: in 2023 the ROS project officially adopted an alternative middleware (Zenoh, rmw_zenoh) because DDS, as the sole middleware, did not work out of the box for a large part of the community (7 reports, plus this is the conclusion the rest of the corpus points to).

  • The official Alternative Middleware Report cites network-wide crashes from DDS multicast packet storms, DDS not working out of the box on managed networks, and the need for expert, application-specific DDS configuration.
  • Zenoh was selected as the most-recommended alternative.

Most recent / flagship example

ROS 2 Alternative middleware report (2023-09-27, OSRF). The canonical statement of why DDS alone was deemed insufficient, and the decision to add a non-DDS middleware.

Reference list

Date Source Point
2023-09-27 ROS 2 Alternative middleware report Official: DDS insufficient alone → adopt Zenoh
2023-10-30 Eclipse newsroom Zenoh selected as alternate ROS 2 middleware
2024-06-12 ZettaScale news Zenoh experimental support lands in ROS 2
2024-07-03 arXiv 2407.03091 Middleware comparison for multi-robot mesh networks
2025-01-03 ROS Discourse rmw_zenoh binaries shipped for Rolling/Jazzy/Humble

The ZeroDDS position

You don’t have to leave DDS to escape DDS pain.

Zenoh fixes the ergonomics (router-/broker-style discovery, works on WiFi and in the cloud) by leaving the RTPS wire — which means a Zenoh fleet no longer speaks native DDS, and bridging back to existing DDS systems is a separate component. For the large installed base of DDS robots, sensors, and tooling, that is a real cost.

ZeroDDS takes the other path: fix the reasons people left DDS, while staying on the RTPS wire.

  • Discovery ergonomics like Zenoh, without leaving RTPS. Multicast-free unicast peers (no broadcast storms, works on WiFi/Docker/cloud) — but the wire is still native RTPS 2.5, so ZeroDDS nodes interoperate directly with the existing Fast DDS / Cyclone / OpenDDS / Connext fleet (verified 20/20 with real rmw_cyclonedds).
  • The structural fixes, not a workaround. Loud QoS failures, no silent large-data cap, variable-size zero-copy SHM, robotics-appropriate defaults, full DDS-Security — the specific clusters this trail documents.
  • Standard-preserving. A complete, audited OMG DDS spec stack means existing DDS tooling, type systems and security models keep working; there is no new protocol to bridge.
  • Memory-safe, MCU-to-server. Pure Rust, forbid(unsafe_code) safe core, no_std + alloc for embedded — a property neither the incumbent C++ stacks nor a separate-protocol middleware offers.

Why this is the better migration

The choice the community was forced into was “keep DDS and keep the pain” or “adopt Zenoh and lose native DDS interop.” ZeroDDS is the third option: keep the DDS standard and the wire interop, and lose the pain — so a team can drop in rmw_zerodds on one robot, interoperate with the rest of its DDS fleet unchanged, and validate the improvement incrementally.

Validate it yourself

This whole trail is a set of falsifiable, reproducible claims. Start anywhere:

crates/ros2-rmw/interop/run_interop.sh                 # live ROS 2 interop
crates/ros2-rmw/interop/run_multicast_free_xvendor.sh  # cross-vendor, no multicast
crates/ros2-rmw/interop/run_largedata.sh               # large data, byte-perfect

→ Back to overview

Migration / Alternative Middleware

← Zurück zur Übersicht

Der Schmerz

Das klarste Signal, dass DDS-Schmerz real ist: 2023 adoptierte das ROS-Projekt offiziell eine alternative Middleware (Zenoh, rmw_zenoh), weil DDS als alleinige Middleware für einen großen Teil der Community nicht out of the box funktionierte (7 Reports, plus dies ist die Schlussfolgerung, auf die der Rest des Korpus zeigt).

  • Der offizielle Alternative-Middleware-Report nennt netzweite Crashes durch DDS-Multicast-Packet-Storms, DDS, das auf verwalteten Netzen nicht out of the box funktioniert, und die Notwendigkeit von Experten-, anwendungsspezifischer DDS-Konfiguration.
  • Zenoh wurde als die meistempfohlene Alternative ausgewählt.

Jüngstes / Flaggschiff-Beispiel

ROS 2 Alternative middleware report (2023-09-27, OSRF). Die kanonische Aussage, warum DDS allein als unzureichend erachtet wurde, und die Entscheidung, eine Nicht-DDS-Middleware hinzuzufügen.

Referenzliste

Datum Quelle Punkt
2023-09-27 ROS 2 Alternative middleware report Offiziell: DDS allein unzureichend → Zenoh adoptieren
2023-10-30 Eclipse newsroom Zenoh als alternative ROS-2-Middleware ausgewählt
2024-06-12 ZettaScale news Zenoh-Experimental-Support landet in ROS 2
2024-07-03 arXiv 2407.03091 Middleware-Vergleich für Multi-Roboter-Mesh-Netze
2025-01-03 ROS Discourse rmw_zenoh-Binaries für Rolling/Jazzy/Humble ausgeliefert

Die ZeroDDS-Position

Du musst DDS nicht verlassen, um dem DDS-Schmerz zu entkommen.

Zenoh fixt die Ergonomie (Router-/Broker-Style-Discovery, funktioniert auf WiFi und in der Cloud), indem es den RTPS-Draht verlässt — was bedeutet, dass eine Zenoh-Flotte kein natives DDS mehr spricht und das Bridging zurück zu bestehenden DDS-Systemen eine separate Komponente ist. Für die große installierte Basis an DDS-Robotern, -Sensoren und -Tooling ist das eine echte Kostenstelle.

ZeroDDS geht den anderen Weg: behebt die Gründe, aus denen Leute DDS verließen, und bleibt dabei auf dem RTPS-Draht.

  • Discovery-Ergonomie wie Zenoh, ohne RTPS zu verlassen. Multicast-freie Unicast-Peers (keine Broadcast-Storms, funktioniert auf WiFi/Docker/Cloud) — aber der Draht ist weiterhin natives RTPS 2.5, sodass ZeroDDS-Nodes direkt mit der bestehenden Fast-DDS- / Cyclone- / OpenDDS- / Connext-Flotte interoperieren (verifiziert 20/20 mit echtem rmw_cyclonedds).
  • Die strukturellen Fixes, kein Workaround. Laute QoS-Fehler, kein stiller Large-Data-Cap, variabel-große Zero-Copy-SHM, robotik-passende Defaults, volle DDS-Security — die spezifischen Cluster, die dieser Trail dokumentiert.
  • Standard-erhaltend. Ein vollständiger, auditierter OMG-DDS-Spec-Stack bedeutet, dass bestehendes DDS-Tooling, Type-Systeme und Security-Modelle weiterarbeiten; es gibt kein neues Protokoll zu bridgen.
  • Memory-safe, MCU-bis-Server. Pure-Rust, forbid(unsafe_code)-sicherer-Kern, no_std + alloc für Embedded — eine Eigenschaft, die weder die etablierten C++-Stacks noch eine Separate-Protokoll-Middleware bietet.

Warum das die bessere Migration ist

Die Wahl, in die die Community gedrängt wurde, war „DDS behalten und den Schmerz behalten” oder „Zenoh adoptieren und native DDS-Interop verlieren”. ZeroDDS ist die dritte Option: den DDS-Standard und die Wire-Interop behalten und den Schmerz verlieren — sodass ein Team rmw_zerodds auf einem Roboter drop-in einsetzen, mit dem Rest seiner DDS-Flotte unverändert interoperieren und die Verbesserung inkrementell validieren kann.

Selbst validieren

Dieser ganze Trail ist ein Satz falsifizierbarer, reproduzierbarer Aussagen. Starte irgendwo:

crates/ros2-rmw/interop/run_interop.sh                 # live ROS-2-Interop
crates/ros2-rmw/interop/run_multicast_free_xvendor.sh  # cross-vendor, kein Multicast
crates/ros2-rmw/interop/run_largedata.sh               # Large-Data, byte-genau

→ Zurück zur Übersicht