ROS 2 in der Produktion: Was sich beim Übergang vom Forschungslabor zur Roboterflotte ändert

Was ändert sich bei ROS 2, wenn aus einem Prototyp eine Flotte wird?

Im Forschungslabor ist ROS 2 ein Werkzeugkasten: ein einzelner Roboter, ein Entwickler-Laptop, eine Handvoll Nodes, die über die Datenverteilungsschicht DDS (Data Distribution Service) miteinander sprechen. Sobald derselbe Stack zehn, hundert oder tausend Einheiten im Feld steuern soll, verschiebt sich der Schwerpunkt komplett: Aus „Funktioniert die Demo?“ wird „Läuft die Flotte auch nach dem dreißigsten Over-the-Air-Update noch zuverlässig, in einem Netzwerk mit Dutzenden gleichzeitig sendenden Robotern, und lässt sich der Fehlerfall in Minuten statt Tagen eingrenzen?“ Die drei zentralen Verschiebungen sind: Middleware-Verhalten unter Last (DDS-Discovery, Multicast, Netzwerksegmentierung), Versionsdisziplin über einen mehrjährigen Support-Zeitraum hinweg, und operative Beobachtbarkeit der gesamten Flotte statt eines einzelnen Prozesses. Die folgenden Abschnitte beleuchten diese drei Verschiebungen im Detail – inklusive der Frage, welche ROS-2-Distribution für einen Produktivstart 2026 tatsächlich sinnvoll ist.

Warum wird DDS im Labor kaum bemerkt, in der Flotte aber zum Dauerthema?

DDS ist die Standard-Middleware, auf der ROS 2 seine Kommunikation zwischen Nodes aufbaut – Publish/Subscribe-Nachrichten, Services, Discovery von Teilnehmern. Auf einem einzelnen Entwicklungsrechner mit wenigen Nodes läuft DDS praktisch unsichtbar im Hintergrund: Discovery per Multicast findet alle Teilnehmer sofort, Quality-of-Service-Einstellungen (QoS) sind selten ein Thema, weil kein Konkurrenzverkehr existiert.

In einer Flotte ändert sich das fundamental. Mehrere Roboter im selben WLAN-Segment erzeugen Discovery-Traffic, der bei Standardkonfiguration quadratisch mit der Teilnehmerzahl wächst. Multicast wird in vielen Unternehmensnetzwerken restriktiv gefiltert oder von Industrie-WLAN-Access-Points gar nicht sauber weitergeleitet. QoS-Profile (Reliability, Durability, History-Tiefe), die im Labor nie konfiguriert wurden, entscheiden in der Produktion darüber, ob ein Not-Halt-Signal garantiert ankommt oder bei Netzwerklast verloren geht. Domain-IDs müssen bewusst vergeben werden, damit sich benachbarte Roboter nicht gegenseitig „sehen“ und Bandbreite verschwenden. Kurz gesagt: DDS-Tuning ist in der Produktion keine Randoptimierung, sondern eine der ersten Aufgaben, die ein Team beim Übergang vom Einzelroboter zur Flotte lösen muss.

Reicht DDS noch, oder braucht es eine Alternative?

DDS bleibt die Standard-Middleware in ROS 2 – auch mit Blick auf die kommenden Releases wird sich daran nichts ändern. Parallel dazu wurde mit rmw_zenoh ab der Distribution Jazzy Jalisco eine offiziell unterstützte Alternative eingeführt, die mit Kilted Kaiju im Mai 2025 erstmals vollständig ausgeliefert wurde. Zenoh verspricht insbesondere in Szenarien mit schlechter Netzwerkanbindung, großer Teilnehmerzahl oder Edge-zu-Cloud-Kommunikation ein schlankeres Discovery-Verhalten als klassische DDS-Implementierungen. Für Teams, die heute eine Flotte aufbauen, bedeutet das: DDS ist die sichere Standardwahl, aber die Middleware-Entscheidung ist inzwischen kein Naturgesetz mehr, sondern eine bewusste Architekturentscheidung, die man bei der Auslegung des Netzwerks mitdenken sollte – gerade wenn Roboter über mobile Netzwerke oder instabile WLAN-Zellen kommunizieren müssen.

Welche ROS-2-Version eignet sich für einen Produktivstart?

Die Wahl der Distribution ist beim Übergang ins Feld keine Nebensache, weil ein Fleet-Rollout selten in wenigen Wochen abgeschlossen ist – Support-Fenster von Jahren sind hier die relevante Größe.

Distribution	Veröffentlicht	Support-Typ	Support-Ende	Tier-1-Betriebssysteme
Jazzy Jalisco	23. Mai 2024	LTS	Ende Mai 2029	Ubuntu 24.04 Noble Numbat (arm64/amd64), Windows 10
Kilted Kaiju (11. Distribution)	23. Mai 2025	Standard	November 2026	–
Lyrical Luth (12. Distribution)	Mai 2026	LTS	Mai 2031	–

Für eine Flotte, die über mehrere Jahre im Feld laufen soll, ist die Logik unmittelbar ersichtlich: Eine LTS-Distribution wie Jazzy Jalisco oder die neuere Lyrical Luth bietet einen Support-Horizont von mehreren Jahren, während eine Standard-Distribution wie Kilted Kaiju bewusst kurzlebiger ausgelegt ist und eher zu Teams passt, die neue Funktionen früh evaluieren wollen, ohne sich langfristig zu binden. Wer heute, Mitte 2026, eine Flottenmigration plant, steht praktisch vor der Wahl zwischen der etablierten Jazzy-Basis mit Support bis 2029 und der frisch veröffentlichten Lyrical-Luth-LTS mit Support bis 2031 – beides tragfähige Optionen, während Kilted Kaiju für einen mehrjährigen Flottenbetrieb wegen des kürzeren Support-Fensters (Ende 2026) eher ungeeignet ist.

Was heißt „von null auf Flotte“ konkret in der Praxis?

Ein oft zitiertes Beispiel für den Übergang vom Forschungsprototyp zur produktiven Flotte ist Dexory, ein Anbieter autonomer Roboter zur Lagerbestandserfassung. Das Unternehmen hat seine Flotte auf ROS 2 und dem Navigationsstack Nav2 aufgebaut; die Verantwortung für die Skalierung der Autonomie-Software liegt bei Dr. Marcus Schuenemann in seiner Rolle als Head of Autonomy. Interessant ist, dass verfügbare Quellen zur genauen Zahl der im Feld eingesetzten Einheiten uneinheitlich sind – eine Quelle spricht von über 200 produktiven Einheiten weltweit, während eine andere, aus einer früheren Finanzierungsrunde stammende Aussage von einer Skalierung „von null auf 90 Roboter“ berichtet. Da sich beide Angaben nicht auf denselben Zeitpunkt beziehen und keine zweite unabhängige Quelle die aktuelle Zahl bestätigt, lässt sich hier ehrlicherweise nur sagen: Die Flotte ist über mehrere Finanzierungsrunden hinweg spürbar gewachsen, eine exakte aktuelle Größe ist öffentlich nicht sauber belegt.

Was sich dagegen klar belegen lässt, ist die Kapitalseite des Wachstums: Im Oktober 2025 sicherte sich Dexory eine Series-C-Finanzierung von insgesamt 165 Millionen US-Dollar, bestehend aus 100 Millionen US-Dollar Eigenkapital unter Führung des Growth-Teams von Eurazeo (mit Beteiligung von LTS Growth, Endeavor Catalyst sowie den Bestandsinvestoren Atomico, Lakestar, Elaia und Latitude Ventures) plus 65 Millionen US-Dollar Fremdkapital von Bootstrap Europe. CEO Andrei Danescu steht dem Unternehmen vor. Eine Finanzierung dieser Größenordnung, die ausdrücklich mit „starker Kundennachfrage“ begründet wird, ist ein plausibler Indikator dafür, dass der Übergang von der Lagerhalle als Testumgebung zum mehrstandortigen Flottenbetrieb technisch und geschäftlich funktioniert – auch wenn die exakte Stückzahl der Roboter offenbleibt.

Welche technischen Bausteine kommen beim Flottenbetrieb neu hinzu?

Neben der Middleware-Abstimmung verändern sich beim Übergang typischerweise vier weitere Bausteine, die im Labor keine oder nur untergeordnete Rolle spielen.

Versionsdisziplin über die Flotte hinweg. Im Labor läuft ein Roboter mit dem Stand, den der Entwickler gerade gebaut hat. In der Flotte muss jede Einheit nachvollziehbar denselben (oder einen kontrolliert gestaffelten) ROS-2-Stand fahren, weil unterschiedliche Patch-Level bei DDS-QoS-Profilen zu subtilen Inkompatibilitäten zwischen Robotern führen können. Ein definierter Update-Rhythmus, orientiert an den offiziellen Distributions- und Support-Fenstern, wird zur Pflicht.

Netzwerksegmentierung statt flachem Netzwerk. Domain-IDs, Namespaces und teils separate Subnetze verhindern, dass Discovery-Traffic einer Halle die Bandbreite einer anderen belastet – ein Thema, das im Ein-Roboter-Setup schlicht nicht existiert.

Beobachtbarkeit auf Flottenebene. Logging und Diagnose, die im Labor über die Konsole eines einzelnen Rechners liefen, müssen in der Produktion zentral aggregiert werden, damit ein Vorfall auf Roboter 47 nicht bedeutet, dass jemand physisch vor Ort das Log ausliest. Genau an dieser Stelle überschneidet sich die ROS-2-Ebene mit dem, was in der Fachwelt zunehmend als eigenständige Disziplin für den Flottenbetrieb beschrieben wird – inklusive Rollback-Strategien, Flotten-Dashboards und Incident-Response-Prozessen, die über einzelne ROS-Nodes hinausgehen.

Sicherheitsabgrenzung. DDS-Discovery per Multicast ist im geschlossenen Labornetz unkritisch, in einem Werksnetzwerk mit weiteren Systemen jedoch ein Angriffsvektor, der durch Zugriffskontrollen auf Domain-Ebene und Netzwerksegmentierung eingegrenzt werden muss.

Wie lässt sich der Übergang vom Labor zur Flotte praktisch vorbereiten?

Bevor ein Team den ersten Rollout über mehrere Standorte plant, lohnt sich eine nüchterne Bestandsaufnahme entlang dreier Fragen: Erstens, auf welcher Distribution soll die Flotte über die geplante Nutzungsdauer laufen, und deckt deren Support-Fenster diesen Zeitraum tatsächlich ab? Zweitens, ist die Netzwerkarchitektur (Domain-IDs, QoS-Profile, gegebenenfalls eine Zenoh-basierte Alternative zu DDS) explizit für Mehrroboter-Betrieb ausgelegt, oder wurde sie ungeprüft aus dem Einzelroboter-Setup übernommen? Drittens, existiert eine zentrale Beobachtungs- und Update-Infrastruktur, die eine Flotte als Ganzes behandelt, statt jede Einheit einzeln zu betreuen? Wer diese drei Fragen vor dem Rollout beantwortet hat, vermeidet den häufigsten Fehler beim Übergang: die stillschweigende Annahme, dass sich Laborverhalten linear auf hundert Roboter skalieren lässt.

Diese Fragen sind kein isoliertes ROS-2-Thema, sondern Teil des größeren Software- und Hardware-Stacks physischer KI, in dem Middleware, Simulation und Datenerfassung ineinandergreifen. Wer vor dem Feldeinsatz zunächst in Simulation und digitalen Zwillingen testet und Trainingsdaten über Teleoperation erfasst, reduziert das Risiko, DDS-Probleme erst live im Kundenbetrieb zu entdecken. Ein Blick ins Glossar hilft, Begriffe wie QoS, Domain-ID oder Middleware im Team einheitlich zu verwenden, bevor Rollout-Dokumentation und Runbooks entstehen. Wie genau diese Middleware-Schicht die Rolle eines sicherheitskritischen Harnesses übernimmt, wenn man den Roboter als Agenten betrachtet, beschreibt der Beitrag Agentic Engineering für physische KI.