Configuration Complexity

← Back to overview

The pain

Getting DDS to work well in ROS 2 routinely means becoming a part-time DDS network engineer (21 reports): hundreds of XML knobs, per-vendor dialects (Fast DDS profiles vs Cyclone XML vs Connext QoS), kernel tuning (rmem_max, ipfrag_*), and hidden prerequisites that are nearly impossible to find. The shipped defaults are not the robotics-/WiFi-appropriate ones, so “good enough” takes days of trial and error.

  • Localhost-only mode silently requires multicast enabled on the loopback interface (ip link set lo multicast on) — undocumented in practice.
  • Selecting the right network interface, or making a Discovery Server introspectable, needs expert XML.
  • A binary install can even go looking for a paid vendor by default.

Most recent example

ROS Discourse — “I’m done manually tuning DDS parameters!” (2026-04-30). A long, well-received thread: hundreds of knobs, days of trial-and-error, and still suboptimal results — a representative statement of the configuration-complexity tax.

Reference list (most recent)

Date Source Problem
2026-04-30 ROS Discourse “Done tuning DDS”: hundreds of knobs, days lost
2025-12-09 ROS Discourse OSRF “Consolidated User Insights” on DDS pain
2025-08-15 ros2#1716 Jazzy on Windows searches for paid RTI Connext
2025-04-04 rmw_cyclonedds#537 failed to create domain, error Error
2025-04-02 cyclonedds#2201 Network-interface selection requires config spelunking

How ZeroDDS solves it

Robotics-appropriate defaults out of the box, and environment variables instead of XML dialects.

  • ros_defaults() works out of the box. A single RuntimeConfig::ros_defaults() sets the representation offers (XCDR1 + XCDR2) and the 16 MiB reassembly cap ROS actually needs — rmw_zerodds interops with a real ROS 2 talker 20/20 with no XML and no environment tuning.
  • Configuration is environment variables, not an XML dialect. Discovery (ZERODDS_PEERS, ZERODDS_NO_MULTICAST), interface pinning (ZERODDS_INTERFACE), sample caps (ZERODDS_MAX_SAMPLE_BYTES), peer limits (ZERODDS_MAX_PEER_PARTICIPANTS) — flat, documented knobs, not nested profile XML you debug with a parser.
  • Interface selection is one variable. The “network-interface selection” pain (cyclonedds#2201) is ZERODDS_INTERFACE=<ip>, applied uniformly across UDP/TCP/SHM/UDS.
  • No hidden loopback prerequisite. Unicast localhost discovery does not depend on multicast being enabled on lo.
  • No paid-vendor fallback. The whole stack is open source (Apache-2.0 / MIT); there is no proprietary tier a default install can drift toward.

Why it no longer has to be a pain

The configuration tax comes from defaults tuned for data-center DDS, exposed through per-vendor XML. ZeroDDS ships defaults tuned for the robotics/WiFi case and exposes the few knobs you actually need as flat environment variables — so the median project needs zero configuration, and the rest needs a handful of documented variables, not a weekend with a vendor’s XML schema.

Reproduce it yourself

# Out-of-the-box ROS interop with no XML / no env tuning:
crates/ros2-rmw/interop/run_interop.sh   # uses ros_defaults()

→ Back to overview · Next: Scaling

Konfigurations-Komplexität

← Zurück zur Übersicht

Der Schmerz

DDS in ROS 2 gut zum Laufen zu bringen heißt routinemäßig, ein Teilzeit-DDS-Netzwerk-Ingenieur zu werden (21 Reports): hunderte XML-Knöpfe, Per-Vendor-Dialekte (Fast-DDS-Profile vs Cyclone-XML vs Connext-QoS), Kernel-Tuning (rmem_max, ipfrag_*) und versteckte Voraussetzungen, die nahezu unmöglich zu finden sind. Die ausgelieferten Defaults sind nicht die robotik-/WiFi-passenden, sodass „gut genug” Tage von Trial-and-Error kostet.

  • Localhost-Only-Modus erfordert still, dass Multicast auf dem Loopback-Interface aktiviert ist (ip link set lo multicast on) — in der Praxis undokumentiert.
  • Das richtige Netzwerk-Interface zu wählen oder einen Discovery-Server introspizierbar zu machen, braucht Experten-XML.
  • Ein Binary-Install kann sogar per Default nach einem bezahlten Vendor suchen.

Jüngstes Beispiel

ROS Discourse — „I’m done manually tuning DDS parameters!” (2026-04-30). Ein langer, gut aufgenommener Thread: hunderte Knöpfe, Tage von Trial-and-Error und immer noch suboptimale Ergebnisse — eine repräsentative Aussage über die Konfigurations-Komplexitäts-Steuer.

Referenzliste (jüngste zuerst)

Datum Quelle Problem
2026-04-30 ROS Discourse „Done tuning DDS”: hunderte Knöpfe, Tage verloren
2025-12-09 ROS Discourse OSRF „Consolidated User Insights” zum DDS-Schmerz
2025-08-15 ros2#1716 Jazzy auf Windows sucht nach bezahltem RTI Connext
2025-04-04 rmw_cyclonedds#537 failed to create domain, error Error
2025-04-02 cyclonedds#2201 Netzwerk-Interface-Auswahl erfordert Config-Spelunking

Wie ZeroDDS es löst

Robotik-passende Defaults out of the box, und Umgebungsvariablen statt XML-Dialekte.

  • ros_defaults() funktioniert out of the box. Ein einziges RuntimeConfig::ros_defaults() setzt die Representation-Offers (XCDR1 + XCDR2) und den 16-MiB-Reassembly-Cap, die ROS tatsächlich braucht — rmw_zerodds interopt mit einem echten ROS-2-Talker 20/20 ohne XML und ohne Umgebungs-Tuning.
  • Konfiguration ist Umgebungsvariablen, kein XML-Dialekt. Discovery (ZERODDS_PEERS, ZERODDS_NO_MULTICAST), Interface-Pinning (ZERODDS_INTERFACE), Sample-Caps (ZERODDS_MAX_SAMPLE_BYTES), Peer-Limits (ZERODDS_MAX_PEER_PARTICIPANTS) — flache, dokumentierte Knöpfe, kein verschachteltes Profile-XML, das du mit einem Parser debuggst.
  • Interface-Auswahl ist eine Variable. Der „Netzwerk-Interface-Auswahl”-Schmerz (cyclonedds#2201) ist ZERODDS_INTERFACE=<ip>, uniform über UDP/TCP/SHM/UDS angewandt.
  • Keine versteckte Loopback-Voraussetzung. Unicast-Localhost-Discovery hängt nicht davon ab, dass Multicast auf lo aktiviert ist.
  • Kein Paid-Vendor-Fallback. Der ganze Stack ist Open Source (Apache-2.0 / MIT); es gibt keinen proprietären Tier, zu dem ein Default-Install driften könnte.

Warum es kein Schmerz mehr sein muss

Die Konfigurations-Steuer kommt von Defaults, die für Data-Center-DDS getunt sind, exponiert über Per-Vendor-XML. ZeroDDS liefert Defaults, die für den Robotik-/WiFi-Fall getunt sind, und exponiert die wenigen Knöpfe, die du wirklich brauchst, als flache Umgebungsvariablen — sodass das mediane Projekt null Konfiguration braucht, und der Rest eine Handvoll dokumentierter Variablen, kein Wochenende mit dem XML-Schema eines Vendors.

Selbst reproduzieren

# Out-of-the-box-ROS-Interop ohne XML / ohne Env-Tuning:
crates/ros2-rmw/interop/run_interop.sh   # nutzt ros_defaults()

→ Zurück zur Übersicht · Weiter: Scaling