Einen neuen Middleware-Ansatz für autonome Systeme verfolgt die ROS2-Plattform (Robot Operating System 2). Ein Überblick über Architektur, Funktionen und Vorteile.
30. Juli 2020
© iStock.com/tickcharoen04
Beim autonomen Fahren stellt die zunehmende Komplexität der Systeme eine große Herausforderung für die Softwareentwicklung dar. So muss die Zuverlässigkeit des autonomen Systems während des gesamten Lebenszyklus der Software gewährleistet sein – angefangen vom Entwurf für ein neues Produkt bis hin zum letzten Update. Dabei liegen aus Sicht der Forschung in der Middleware [1] die größten Herausforderungen. Dies sind unter anderem die Fähigkeit der Laufzeitanpassung an die Anwendungen, die Kommunikation zwischen heterogenen Systemen in verschiedenen Ebenen der Middleware [1] und die Gewährleistung der Laufzeitsicherheit unter Ausfallbedingungen.
ROS2 ist der Nachfolger von ROS1, einem Open-Source-Software-Framework, das sich in den letzten Jahren zu einem der beliebtesten Prototyping-Plattformen für die Entwicklung von Robotern entwickelt hat. Das ursprüngliche Designziel von ROS1 war es, eine Entwicklungsplattform für den Roboter PR2 (Personal Robotics 2) für die Forschung an der Stanford University bereitzustellen [2]. Aufgrund der kontinuierlichen Weiterentwicklung der Plattform durch eine weltweite Community erweiterte ROS1 seinen Einsatzbereich auf viele verschiedene Felder, wie Industrieroboter, selbstfahrende Autos und Luftfahrzeuge. Die Einschränkungen der Architektur, zum Beispiel Single Point of Failure und Leistungsengpässe wie fehlende Echtzeitfähigkeit, verhindern jedoch, dass ROS1 in dynamischen autonomen Systemen eingesetzt werden kann.
Im Einzelnen halten folgende Einschränkungen ROS1 in Grenzen [2, 3]:
Obwohl viele Entwicklerinnen und Entwickler sowie Forschungseinrichtungen versucht haben, die oben genannten Probleme in den Griff zu bekommen, war es schwierig, die Gesamtleistung zu verbessern. Dies motivierte die Entwicklung von ROS2, einem kompletten Refactoring von ROS1, das das erfolgreiche Konzept in eine modernere und verbesserte Architektur überführt [4].
Im Vergleich zu ROS1 beseitigt ROS2 die beschriebenen Einschränkungen, das heißt mangelnde Echtzeitfähigkeit, fehlende Unterstützung für Multi-Roboter-Systeme sowie mehrere Plattformen. Darüber hinaus verfolgt ROS2 weitere Designziele [2]:
ROS2 setzt auf den Erfahrungen in der Entwicklung von ROS1 auf und bietet eine umfangreiche Bibliothek an Funktionen an, um beliebte Anwendungen wie die Navigation von Robotern zu unterstützen. So können sich Entwicklerinnen und Entwickler mehr auf anwendungsspezifische Aufgaben konzentrieren und Funktionen der ROS1-Bibliotheken zur Beschleunigung der Softwareentwicklung nutzen.
Die Architektur von ROS2 besteht aus mehreren Schichten (siehe Abbildung). Die Hauptunterschiede zu ROS sind folgende:
© Y. Maruyama, S. Kato, and T. Azumi
Ein Überblick über die ROS1/ROS2-Architektur [5].
Für die Kommunikation zwischen den Knoten nutzt ROS2 DDS, einen industriellen Kommunikationsstandard der OMG (Object Management Group), der den Transport der Daten nach dem Publish-Subscribe-Prinzip umsetzt. Der Vorteil der Verwendung von DDS besteht darin, dass es konkrete Spezifikationen für Dritte gibt, die mit unterschiedlichem Grad an Interoperabilität überprüft, auditiert und implementiert werden können [6]. Die QoS (Quality-of-Service) von DDS bietet flexible Parametereinstellungen zur Steuerung der Zuverlässigkeit der Kommunikation. Darüber hinaus kann ROS2 mit verschiedenen DDS-Anbietern wie FastRTPS, RTI-Connext oder OpenSplice zusammenarbeiten. Die Portabilität zwischen den DDS-Anbietern bietet den Benutzern Alternativen zur Auswahl der spezifizierten Anforderungen sowie bei Änderungen bei den DDS-Anbietern.
Das Kommunikationsmodell von ROS1 besteht hauptsächlich aus Kommunikationsmechanismen wie Topics und
Services. Das Kommunikationsmodell von ROS2 ist dagegen etwas komplexer,
da hier DDS-Kommunikationsmechanismen hinzugefügt wurden. Das
DDS-basierte Kommunikationsmodell von ROS2 enthält die folgenden
Schlüsselkonzepte [5]:
Teilnehmer (Participant): In DDS wird jeder Publisher oder Subscriber als Teilnehmer bezeichnet. Jeder Teilnehmer, der DDS verwendet, kann lesend und schreibend auf den Global Data Space zugreifen.
Publisher: Der Publisher ist für die Veröffentlichung mehrerer Datentypen im globalen Data Space zuständig und ist dazu mit einem oder mehreren Data Writern verbunden, die jeweils Nachrichten zu einem Topic veröffentlichen.
Subscriber: Der Subscriber ist mit einem oder mehreren Data Readern verbunden, wobei jeder Data Reader Nachrichten eines Topics abonniert. Abonnieren bedeutet, dass der Subscriber automatisch mit Hilfe der Data Reader neue Nachrichten zu den abonnierten Topics erhält, sobald diese vom Publisher versendet werden.
Data Writer: Der Data Writer aktualisiert das Datenobjekt für den Publisher. Jeder Data Writer ist einem bestimmten Topic zugeordnet, ähnlich wie ein Message Publisher in ROS.
Data Reader: Der Data Reader liest Daten von Subscribern. Jeder Data Reader ist einem bestimmten Topic zugeordnet, ähnlich wie ein Message Subscriber in ROS.
Topic: Topics sind Datentypen, die im Global Data Space liegen und auf die von allen Teilnehmern (Publisher/Subscriber) der ROS2-Anwendung zugegriffen wird. Ähnlich wie in ROS1 bestehen Topics in ROS2 aus einem Namen und einer Datenstruktur, zusätzlich sind hier nicht nur die aktuellen sondern auch historische Nachrichtendaten gespeichert.
Quality of Service Policy: Abgekürzt als QoS Policy ist dies ein neues und sehr wichtiges Konzept, das in ROS2 hinzugefügt wurde. Es enthält Kommunikationsmechanismen wie Zeitlimit, Zuverlässigkeit, Kontinuität und Historie, um die Anforderungen den zuverlässigen Transport der Benutzerdaten für verschiedene Szenarien zu erfüllen.
Dieser Text ist in einer englischen Version im Rahmen des European Training Network for Safer Autonomous Systems (ETN SAS) entstanden.
Obwohl sich ROS2 noch in der frühen Phase der Entwicklung befindet,
stellt es einen vielversprechenden Ansatz für den Einsatz in autonomen
Systemen dar. Weitere von der Industrie gestellte Anforderungen wie
Sicherheitsmechanismen, die Performance des Echtzeit-Scheduling oder die
Interoperabilität mit ROS1 werden derzeit umgesetzt.
Es wird Tausende von Entwicklern und Forschern aus Industrie und Wissenschaft motivieren, die Entwicklung von ROS2 für den autonomen Bereich zu verbessern. In naher Zukunft werden weitere ROS2-basierende Software-Produkte für den Bereich der autonomen Systeme veröffentlicht werden.
This project has received funding from the European Union's EU Framework Programme for Research and Innovation Horizon 2020 under Grant Agreement No # 812788
[1] A. Pretschner, M. Broy, I.H. Krüger, und T. Stauner, "Software Engineering für Automobilsysteme": Eine Roadmap", Proc. Konf. Zukunft der Softwaretechnik, S. 55-71, 2007
[2] https://design.ros2.org/articles/why_ros2.html
[3] http://design.ros2.org/articles/changes.html
[4] D. Casini, T. Blaß, I. Lütkebohle, und B. Brandenburg, "Responsetime analysis of ROS 2 processing chains under reservation-based scheduling", in Proceedings 31th Euromicro Conference on Real-Time Systems (ECRTS 2019), 2019
[5] Y. Maruyama, S. Kato und T. Azumi. Untersuchung der Leistungsfähigkeit von ROS2. In Proc. von ACM EMSOFT, Seiten 5:1-5:10, 2016
