ROS, kurz für Robot Operating System, ist eine freie Open-Source-Sammlung von Softwarebibliotheken und Werkzeugen für die Entwicklung von Robotersoftware. Trotz des Namens ist es kein Betriebssystem wie Windows oder Linux. ROS läuft auf einem solchen, meist auf Ubuntu Linux, und gibt den vielen Programmen in einem Roboter eine gemeinsame Grundlage, um Daten auszutauschen, Treiber gemeinsam zu nutzen und auf der Arbeit der anderen aufzubauen.

Der Name sorgt für viel Verwirrung, deshalb lohnt es sich, genau abzugrenzen, was ROS abdeckt. Alles innerhalb eines Roboters organisiert es sehr gut: Laserscanner, Räder, Karte, Planer. Zum Gebäude, in dem der Roboter arbeitet, hat es dagegen deutlich weniger zu sagen, also zu Türen, Aufzügen, Sensoren und den Menschen, die erfahren müssen, wenn etwas schiefgeht. Wo das eine endet und das andere beginnt, ist eine ganz praktische Frage für alle, die Roboter außerhalb des Labors einsetzen.

Kurz erklärt

  • ROS ist Middleware: ein Nachrichtensystem, ein Satz von Konventionen und eine große Bibliothek wiederverwendbarer Pakete, die auf einem normalen Betriebssystem laufen.
  • Im Roboter veröffentlichen kleine Programme, sogenannte Nodes, Daten in benannten Datenströmen, den Topics, und abonnieren sie. So können ein Lidar-Treiber und ein Navigationsplaner von verschiedenen Leuten stammen und trotzdem zusammenarbeiten.
  • ROS 2 ist die aktuelle Generation. Der Support für ROS 1 ist im Mai 2025 ausgelaufen (End of Life), deshalb starten neue Projekte mit einem ROS-2-Release mit Langzeitsupport.
  • ROS koordiniert die Komponenten eines Roboters. Um diesen Roboter mit den Türen, Sensoren und Alarmen eines Standorts zu verbinden, braucht es eine eigene Ebene darüber.

Was ist ein Robot Operating System?

Ein Roboter ist ein Sammelsurium aus Hardware verschiedener Hersteller: ein Laserscanner vom einen Zulieferer, Motortreiber vom nächsten, dazu Kameras, Stoßsensoren und eine Platine für das Batteriemanagement. Jedes Teil bringt seine eigene Schnittstelle mit. Vor ROS schrieb jedes Labor und jedes Unternehmen eigenen Verbindungscode, damit diese Teile miteinander reden, und kaum etwas davon ließ sich beim nächsten Roboter wiederverwenden.

Ein Robot Operating System löst das, indem es sich als Schicht zwischen die Hardwaretreiber und das Verhalten des Roboters schiebt. Es gibt Programmen einen einheitlichen Weg, einander Daten zu schicken, sodass der Code, der den Laser ausliest, nicht wissen muss, wer seine Daten verwendet. Es legt Standardformate für häufige Daten fest, etwa für einen Laserscan, ein Kamerabild oder einen Geschwindigkeitsbefehl. Und es bringt Werkzeuge mit, um Daten aufzuzeichnen, sichtbar zu machen, was der Roboter wahrnimmt, und ihn zu simulieren, bevor er auf echter Hardware läuft.

Die Bezeichnung „Betriebssystem“ ist eine Metapher. So wie Anwendungen dank des Betriebssystems nicht wissen müssen, welche Festplatte oder Netzwerkkarte im Computer steckt, muss Robotersoftware dank ROS nicht wissen, welche Scannermarke verbaut ist, solange ein Treiber die Standardnachricht veröffentlicht.

ROS entstand 2007, mit ersten Arbeiten in Stanford und der Weiterentwicklung beim Robotikunternehmen Willow Garage. Heute betreuen es Open Robotics und die Open Source Robotics Foundation, und eine große Gemeinschaft aus Unternehmen und Hochschulen steuert Pakete bei. Zu den bekanntesten Paketen gehören Nav2, der Navigationsstack für mobile Roboter, und MoveIt, das Bewegungen für Roboterarme plant.

Wie funktioniert ein Robot Operating System?

Am einfachsten versteht man es, wenn man einen Roboter bei der Arbeit begleitet. Nehmen wir einen Lieferroboter, der Material durch einen Krankenhausflur bringt.

  1. Ein Treiber-Node liest den Laserscanner aus und veröffentlicht jeden Scan auf einem Topic namens /scan, je nach Sensor etwa zehn- bis vierzigmal pro Sekunde.
  2. Ein Lokalisierungs-Node abonniert /scan und die Radodometrie, gleicht beides mit einer gespeicherten Karte ab und veröffentlicht, wo sich der Roboter seiner Einschätzung nach befindet.
  3. Der Navigationsstack nimmt ein Ziel entgegen, etwa „fahre zu Station 3“, plant einen Weg um die Hindernisse im aktuellen Scan und veröffentlicht Geschwindigkeitsbefehle auf einem Topic namens /cmd_vel.
  4. Ein Motorsteuerungs-Node abonniert /cmd_vel und setzt diese Befehle in Radgeschwindigkeiten um.

Keiner dieser Nodes ruft einen anderen direkt auf. Sie einigen sich nur auf Topic-Namen und Nachrichtentypen. Deshalb können Sie den Laserscanner gegen ein anderes Modell tauschen, indem Sie einen einzigen Treiber-Node ersetzen.

Topics eignen sich für kontinuierliche Datenströme. Für andere Aufgaben hat ROS zwei weitere Muster. Ein Service ist eine kurze Anfrage mit Antwort, etwa „aktuelle Karte speichern“. Eine Action ist ein länger laufendes Ziel mit Fortschrittsmeldungen und der Möglichkeit zum Abbruch; so wird „fahre zu Station 3“ üblicherweise gesendet. Parameter konfigurieren Nodes, und Launch-Dateien starten mit einem einzigen Befehl eine ganze Gruppe von Nodes.

Ein weiteres Element leistet im Hintergrund viel Arbeit: tf2, die Transformationsbibliothek. Jeder Sensor ist irgendwo am Roboter montiert, und jede Karte hat ihren eigenen Ursprung. tf2 verfolgt, wie all diese Koordinatensysteme über die Zeit zueinander stehen. Sieht die Kamera ein Hindernis 1,2 Meter voraus und 30 Zentimeter links, kann der Planer daraus eine Position auf der Karte machen, ohne dass jeder Node seine eigene Geometrie rechnen muss.

Um diesen Kern herum liegen die Werkzeuge, mit denen man täglich arbeitet: RViz, um Sensordaten und Pläne des Roboters in 3D zu sehen, rosbag, um Topics aufzuzeichnen und wieder abzuspielen, und der Simulator Gazebo, um einen Roboter in einer virtuellen Welt zu testen.

In ROS 2 läuft die Nachrichtenschicht auf DDS (Data Distribution Service), einem industriellen Publish-Subscribe-Standard. Nodes finden sich im Netzwerk gegenseitig, ohne den zentralen Master-Prozess, den ROS 1 brauchte, und jedes Topic kann eigene Quality-of-Service-Einstellungen haben, zum Beispiel, ob verlorene Nachrichten erneut gesendet werden sollen.

ROS 1 vs. ROS 2: Welches Robot Operating System wählen?

Die meisten Teams, die heute starten, wissen schon, dass sie ROS verwenden werden. Offen ist noch die Wahl von Generation und Release und die Frage, ob einige Teile des Roboters mit etwas anderem laufen sollen.

ROS 1 ROS 2
Status Letztes Release Noetic, End of Life im Mai 2025 Aktiv weiterentwickelt, jedes Jahr im Mai ein neues Release
Nachrichtenübertragung Eigenes Protokoll mit zentralem Master DDS, kein Single Point of Failure
Langzeitsupport Künftig keiner LTS-Releases mit fünf Jahren Support, z. B. Jazzy Jalisco bis 2029
Sicherheit Keine integrierte Transportsicherheit SROS2 ergänzt Verschlüsselung und Zugriffskontrolle
Geeignet für Wartung bestehender Roboter Neue Projekte und Produkte

In der Praxis entscheiden einige Fragen über die Wahl:

  • Treiber. Liefert der Hersteller Ihres Sensors oder Roboterarms einen ROS-2-Treiber? Ein fehlender Treiber kann mehr Zeit kosten als alles andere zusammen.
  • Release-Rhythmus. Jedes Jahr im Mai erscheint ein neues ROS-2-Release. Releases aus geraden Jahren erhalten fünf Jahre Support, die dazwischen etwa anderthalb Jahre. Produkte legen sich deshalb meist auf ein LTS-Release fest und planen den Umstieg auf das nächste.
  • Kleine Hardware. micro-ROS bringt ROS-2-Konzepte auf Mikrocontroller, sodass eine Sensorplatine direkt an den Topics des Roboters teilnehmen kann.
  • Industrieroboter. Viele Industrieroboterarme werden über die Steuerung und Sprache des Herstellers programmiert. ROS läuft dann oft neben dieser Steuerung, statt sie zu ersetzen, ein Weg, an dem das ROS-Industrial-Konsortium seit Jahren arbeitet.

Planen Sie auch das Netzwerk früh ein. DDS erkennt Nodes automatisch. Auf dem Testaufbau ist das bequem, in einem gemeinsam genutzten Firmennetz mit vielen Robotern erzeugt es viel Datenverkehr. Teams trennen Roboter deshalb meist über DDS-Domain-IDs, beschränken die Erkennung auf bekannte Hosts und aktivieren SROS2, bevor ein Roboter das Labor verlässt.

Manche Unternehmen bauen auf ROS 2 auf und setzen eigene Stacks darüber, etwa NVIDIAs Isaac-ROS-Pakete für GPU-beschleunigte Wahrnehmung. Andere behalten einen proprietären Software-Stack und stellen nach außen nur eine Schnittstelle bereit. Beide Wege sind verbreitet, und der zweite wird wichtig, sobald der Roboter mit allem anderen an einem Standort zusammenarbeiten muss.

Wie verbindet man ROS mit IoT-Geräten?

ROS wurde für das Innere eines Roboters gebaut oder für eine Flotte in einem gemeinsamen Netzwerk. Ein Gebäude oder Werk hat aber eine zweite Gruppe von Geräten, die der Roboter nicht wahrnehmen kann: einen Türkontakt am anderen Ende des Lagers, einen Lecksensor in einem Technikraum, den Zustand einer Brandschutztür, einen Luftqualitätswert auf einer Station. Diese Geräte sprechen meist LoRaWAN, MQTT, Modbus oder BACnet, keine ROS-Topics.

Es gibt bewährte Brücken. rosbridge stellt ROS-Topics als JSON über WebSockets bereit, Community-Pakete leiten ausgewählte Topics an MQTT-Broker weiter und von dort zurück, und Open-RMF, das Open Robotics Middleware Framework, koordiniert mehrere Roboterflotten mit gemeinsam genutzter Infrastruktur wie Türen und Aufzügen. Damit ist der Transport gelöst. Zu entscheiden, welches Sensorereignis welchen Roboter wohin schicken soll, und diese Logik zu testen, bevor sie an einem echten Standort läuft, ist eine eigene Aufgabe.

Es lohnt sich, früh festzulegen, was diese Grenze überschreitet. Rohdaten-Topics wie Laserscans und Kamerabilder kommen für Standortsysteme viel zu häufig und sind viel zu detailliert. Der Rest des Standorts braucht eine kleine, stabile Menge an Fakten und Anfragen: die Position des Roboters auf dem Standortplan, seinen Akkustand, den aktuellen Missionsstatus und eine Handvoll Aufgaben, die er annimmt, etwa einen benannten Ort anfahren, andocken oder pausieren. Bleibt diese Schnittstelle klein, kann das Roboterteam innerhalb von ROS alles ändern, ohne dass die Standortlogik bricht.

Diese Entscheidungsebene setzt ein Betriebssystem für Physical AI auf ROS auf, und genau als diese Ebene entwickeln wir Kilo. Stellt die Integration des Roboters einige Befehle über MQTT bereit, zum Beispiel „Wegpunkt anfahren“ oder „zur Dockingstation zurückkehren“, können Sie diese in Kilo speichern und eine Regel einen davon senden lassen, sobald ein Sensor an anderer Stelle des Standorts ein Ereignis meldet. ROS übernimmt dabei weiterhin die Navigation an Bord. Jeder so gesendete Befehl erscheint in seinem Verlauf als Ausstehend, Zugestellt, Bestätigt, Soft-Warnung oder Fehlgeschlagen.

Weil diese Befehle eine echte Maschine bewegen, proben Sie die Regel zuerst: Gehen Sie sie im Debugger von Kilo Schritt für Schritt durch und simulieren Sie die Antwort des Roboters. So sehen Sie, wie jeder Pfad abläuft, bevor irgendetwas in Betrieb geht.

Häufige Fragen zum Robot Operating System

Ist ROS kostenlos?

Ja. ROS ist Open Source unter freizügigen Lizenzen, die eine kommerzielle Nutzung ohne Lizenzgebühren erlauben. Kosten entstehen weiterhin für Entwicklungszeit, Hardware und gegebenenfalls einen kommerziellen Supportvertrag, den ein Unternehmen bei einer der Firmen abschließt, die ROS-Beratung anbieten.

Welche Programmiersprache verwendet ROS?

Die beiden offiziellen Client-Bibliotheken sind C++ (rclcpp) und Python (rclpy), und in einem Roboter kommen oft beide zum Einsatz. Für Rust, Java und andere Sprachen gibt es Community-Bibliotheken. Nachrichtentypen werden in einfachen Schnittstellendateien definiert, aus denen für jede Sprache Code generiert wird.

Läuft ROS unter Windows?

ROS 2 führt Windows neben Ubuntu Linux unter seinen unterstützten Plattformen, und jedes Release legt seine genauen Plattformstufen in einem Dokument namens REP 2000 fest. Die meisten Tutorials, Treiber und Roboter im produktiven Einsatz nutzen aber weiterhin Ubuntu, deshalb bleibt Linux der einfachere Weg.

Ist ROS 2 echtzeitfähig?

Nicht von sich aus. ROS 2 wurde so entworfen, dass es sich in Echtzeitsystemen einsetzen lässt. Dafür braucht es aber auch einen Echtzeit-Kernel wie Linux mit dem PREEMPT_RT-Patch, eine sorgfältige Konfiguration von Speicher und Threads sowie Hardware, die ihr Timing einhält. Das Framework ros2_control ist der übliche Weg, um schnelle Regelkreise für Arme und Räder in ROS 2 zu betreiben.

Mit einem ROS-2-Roboter, den Sie bereits betreiben, können Sie die Standortseite im Kleinen ausprobieren. Veröffentlichen Sie über eine der Community-Brücken drei seiner Topics nach MQTT, etwa Akkustand, Missionsstatus und Position, registrieren Sie den Roboter als ein Gerät in Kilo und stellen Sie die drei Werte in einem Dashboard dar. Fügen Sie dann eine Regel hinzu, die Sie alarmiert, wenn der Akku unter 20 % fällt, während noch eine Mission läuft. Das sind ein Gerät und eine Regel, bequem im Rahmen des kostenlosen Tarifs, und am Roboter ändert sich außer der Brücke nichts.