Einführung in das Robot Operating System

Inhaltsverzeichnis

Die Entwicklungsarbeiten an dem heute als Robot Operating System (ROS) bekannten Software-Framework begannen im Jahr 2007 unter dem Namen "switchyard" am Stanford Artificial Intelligence Laboratory. Seit 2008 wurde ROS hauptsächlich durch das von Scott Hassan privat finanzierte US-amerikanische Unternehmen beziehungsweise Robotikforschungsinstitut Willow Garage in Kooperation mit verschiedenen Partnern vorangetrieben. Anfang 2014 wurde Willow Garage geschlossen und die Verantwortung für die Pflege und Weiterentwicklung von ROS an die neu gegründete Open Source Robotics Foundation übertragen.

Die aktuelle ROS-Version trägt den Codenamen "Kinetic Kame" und wurde am 23. Mai 2016 veröffentlicht. Die Vorgänger waren nach chronologisch absteigender Reihenfolge sortiert: Jade Turtle, Indigo Igloo, Hydro Medusa, Groovy Galapagos, Fuerte Turtle, Electric Emys, Diamondback, C Turtle, Box Turtle, ROS 1.0.

Design-Philosophie

Dem Design von ROS liegen fünf Gedanken zugrunde, die in ihrer Summe die ROS-Philosophie ergeben:

• Peer-to-Peer
• werkzeugbasiert
• mehrsprachig
• schlank
• Open Source

Peer-To-Peer: ROS wurde für den Einsatz in komplexen Servicerobotern entwickelt. Diese verfügen über mehrere im Roboter befindliche Computer, die via Ethernet miteinander verbunden sind. Zusätzlich übertragen sie Daten über WLAN an leistungsstarke Rechner außerhalb des Roboters, um dort rechenintensive Aufgaben wie Spracherkennung oder Bildverarbeitung durchzuführen.

Bei Verwendung eines Software-Frameworks mit einem zentralen, außerhalb des Roboters befindlichen Hauptrechner müssten alle Daten über die WLAN-Datenverbindung fließen. Da die meisten Nachrichtennetze ohnehin in sich geschlossen sind und sich entweder innerhalb oder außerhalb des Roboters befinden, erfolgt auf diese Weise ein unnötig großer Datenaustausch über die langsamste Verbindung, was die Leistungsfähigkeit des Systems beeinträchtigt. Bei einer Peer-to-Peer-Architektur unter Verwendung von Eingangs- beziehungsweise Ausgangsdatenpuffern lassen sich die Engpässe vermeiden. Dazu ist lediglich ein Auskunftsmechanismus nötig, der den Prozessen das Auffinden ihrer Kommunikationspartner zur Laufzeit ermöglicht.

Werkzeugbasiert: Um eine geringe Komplexität und gleichzeitig eine hohe Stabilität von ROS zu erreichen, ist das ROS im Mikrokerneldesign umgesetzt. Eine Vielzahl von Werkzeugen ist für die Ausführung der zahlreichen ROS-Komponenten verantwortlich. Nachfolgend ist eine unvollständige Auswahl der Aufgaben aufgelistet, die die Werkzeuge durchführen:

• einfache Navigation zu den Paketen (roscd)
• Darstellung der Peer-to-Peer-Topologie (rqt_graph)
• Anzeige der übertragenen Daten (rostopic)
• Starten von Prozessen (rosrun, roslaunch)

Eine Übersicht über die gebräuchlichsten Werkzeuge ist im ROS Cheat Sheet zu finden.

Mehrsprachig: ROS verfügt über Anbindungen für die Programmiersprachen C++, Python und Lisp in Form sogenannter ROS Client Libraries. Des Weiteren existieren unter anderem Module für Java, Haskell und Lua. Auf der ROS-Seite befindet sich eine vollständige Liste aller Client-Bibliotheken.

Schlank: Viele der für zahlreiche Roboter entwickelten Algorithmen ließen sich theoretisch ebenso gut außerhalb der konkreten Projekte einsetzen. Die Wiederverwendbarkeit ist jedoch typischerweise dadurch eingeschränkt, dass die meisten Methoden dermaßen mit den anderen hardwarenahen Modulen des Roboters verzahnt sind, dass eine Extraktion der Programmlogik unmöglich ist. ROS umgeht das Problem, indem die Entwicklung von Algorithmen unabhängig von der konkreten Hardware in Bibliotheken erfolgt.

Entwickler implementieren die vollständigen Algorithmen in Bibliotheken, sodass lediglich eine kleine ausführbare Datei notwendig ist, welche die Funktionen der Bibliothek für ROS zur Verfügung stellt. Ein weiterer Vorteil unabhängiger Bibliotheken ist die einfache Testbarkeit über die definierte Schnittstelle.

Open Source: ROS steht unter der BSD-Lizenz und kann daher sowohl für kommerzielle als auch für nichtkommerzielle Projekte ohne Einschränkungen zum Einsatz kommen. Die einzelnen Module tauschen die Daten über Interprozesskommunikation aus. Entwickler müssen somit nicht mehrere Module zu einer einzigen ausführbaren Datei kompilieren. Dadurch können Anwender Module mit unterschiedlichen, beliebigen Lizenzen von GPL über BSD bis hin zu proprietären Lizenzen in einer Applikation einsetzen. Die Beschränkung des Anwendungsgebiets einer proprietären Lizenz auf das jeweilige Modul verhindert eine etwaige Lizenzverschmutzung.