Autonome Systeme
Roboter-Betriebssysteme: ROS2 bügelt Schwächen aus

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

mask ROS2

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.

Warum ROS2?

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]:

  • Keine Eignung für Multi-Roboter-Systeme
    Multi-Roboter-Systeme sind ein zentrales Thema im Bereich der Robotik. Sie können die Probleme der unzureichenden Leistung und der Nichtverfügbarkeit eines einzelnen Roboters lösen. Eine Standardmethode für den Aufbau eines Multi-Roboter-Systems gibt es in ROS1 jedoch nicht.
  • Mangelnde Unterstützung verschiedener Betriebssysteme
    ROS1 setzt auf Linux auf und kann unter Windows, MacOS, RTOS und anderen Systemen nicht oder nur mit eingeschränkten Funktionen eingesetzt werden. Dies stellt höhere Anforderungen an die Roboter-Entwicklung und Entwicklungswerkzeuge und hat auch große Einschränkungen.
  • Fehlendes Echtzeitverhalten
    Roboter haben in vielen Anwendungsszenarien hohe Anforderungen an das Echtzeitverhalten, insbesondere im industriellen Bereich. Hier muss ein System harte Echtzeit-Kriterien erfüllen. ROS1 besitzt jedoch kein auf Echtzeit ausgelegtes Design, so dass die Middleware in komplexen Anwendungen überfordert ist.
  • Störanfälligkeit gegenüber schwankenden Netzwerkverbindungen
    Die verteilte Architektur von ROS1 erfordert eine stabile Netzwerkumgebung, um die Datenintegrität zu gewährleisten. Darüber hinaus verfügt die Kommunikationsschnittstelle über keine Datenverschlüsselung. Somit kann jeder Host im Netzwerk die von einem Knoten ausgegebenen oder empfangenen Nachrichtendaten abhören.
  • Fehlende Zuverlässigkeit für den industriellen Einsatz
    Die ROS1-Middleware ist sehr unzuverlässig. Wichtige Kommunikationsverbindungen wie z.B. zwischen dem sog. ROS1-Master und den einzelnen Knoten sind instabil, was den zuverlässigen Einsatz von auf ROS1 basierenden Robotern in der Industrie nahezu unmöglich macht.

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]:

  • Vom Prototyp zum Produkt
    ROS2 zielt nicht nur auf den Bereich der wissenschaftlichen Forschung ab, sondern auch auf den professionellen Einsatz. Daher ist zu erwarten, dass mehr Roboter mit ROS2 auf dem Markt erscheinen.
  • Unterstützung von Mikrocontrollern
    ROS2 kann nicht nur auf bestehenden X86- und ARM-Systemen laufen, sondern unterstützt auch eingebettete Mikrocontroller wie MCUs (ARM-M4, M7-Cores).

Die ROS/ROS2-Architektur

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:

  • Wie bereits dargelegt, unterstützt ROS hauptsächlich Linux-basierte Betriebssysteme. ROS2 bietet mehr Portabilität bei der Nutzung in Verbindung mit Betriebssystemen wie Linux, Windows, MacOS und RTOS.
  • ROS verwendet das proprietäre Datentransportprotokoll TCPROS/UDPROS und die Kommunikation hängt vom Master-Knotens ab. Die Kommunikation in ROS2 basiert auf dem DDS-Standard (Data Distribution Service) [7], wodurch die Fehlertoleranz verbessert wird.
  • Der Intra-Prozess in ROS2 bietet einen optimierten Übertragungsmechanismus.
ROS2-Architektur

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 ROS2

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.

English version

Was kommt ...

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.


Europa

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

[6] https://design.ros2.org/articles/ros_on_dds.html

[7] https://www.omg.org/spec/DDS/About-DDS/

Nächster Artikel

Safer Autonomous Systems
Safety by Design – Entwicklung sicherheitsbewusster autonomer Systeme

Dominika Giselbrecht / Fraunhofer IKS
Dominika Giselbrecht
Fraunhofer blog icon mono koginitve systeme
Kognitive Systeme