In der Robotik wächst mit der Zahl der Fähigkeiten und der Funktionen, die ein Ro-boter haben soll, die Komplexität der Software, die diese Funktionalitäten bereitstellt.
Damit die Wartung und Überarbeitung sowie die Integration neuer Funktionen in bestehende Software auch mit wachsender Komplexität einfach bleibt, wird das Ziel verfolgt, die Software möglichst in einzelne, kleine und überschaubare Module auf-zuteilen. Dabei übernimmt jedes Modul jeweils eine konkrete Aufgabe. Beispielsweise kann ein Modul die Algorithmen zur Pfadplanung enthalten, während ein anderes Mo-dul die Personenerkennung übernimmt. Diese MoMo-dularität ermöglicht den einfachen Austausch von Modulen in bestehenden Anwendungen und erhöht die Wiederverwert-barkeit erstellter Algorithmen. Dadurch lassen sich die Funktionalitäten komplexer Robotikapplikationen durch Zusammenführung verschiedener bestehender Module er-zeugen. Dabei sorgt ein Framework dafür, dass die notwendigen Module in einen Ge-samtablauf integriert werden und über verschiedene Mechanismen miteinander kom-munizieren können. Für diesen Zweck wurde von der TU Ilmenau in Zusammenarbeit mit der MetraLabs GmbH die Middleware for Robotic Applications1 (MIRA) entwi-ckelt. Die einzelnen Module lassen sich nach Komplexität und Aufgabe in verschiedene hierarchisch geordnete Schichten (Layer) unterteilen. Abbildung 3.1 zeigt diese hierar-chische Struktur.
1http://www.mira-project.org/MIRA-doc/
Abbildung 3.1: Module können nach Art und Verwendung in die einzelnen Schichten (Layer) der Applikationsarchitektur geordnet werden. Module des Skill Layers stel-len einzelne Funktionalitäten dar, während in den Behaviors diese Funktionalitäten zu komplexeren Anwendungen zusammen geführt werden [Müller, 2016, 67].
Die oberste Schicht enthält die Services (Service Layer), die aus einer oder mehreren Konfigurationsdateien (Frames) bestehen. In den Frames wird die Reihenfolge festge-legt, in der die Behaviors abgearbeitet werden. Dies erfolgt in Abhängigkeit von Events.
Dazu zählen Sensorinformationen aus der Umwelt genauso wie die Änderungen interner Zustände. Die Events gelangen über sogenannte Slots zu den entsprechenden Frames des Services. In den Frames wird definiert, welche Aktionen ausgeführt werden, wenn neue Events in den Slots zur Verfügung stehen. Beispielsweise können Events der Slots Bedingungen sein, um Module zu starten oder Bildschirm- bzw. Sprachausgaben zu erzeugen. Auch Timeouts können genutzt werden, um Aktionen auszulösen.
ren die Services nicht direkt miteinander, können aber auf andere Services verweisen, die daraufhin vom ServiceManager gestartet werden. Die einzelnen Funktionen eines Services werden durch die Behaviors bestimmt. Ein Behavior ist eine konkrete Aufga-be, die ein Roboter ausführen soll. Eine solche Aufgabe kann das Suchen eines Nutzers (Drive to), das Folgen eines Nutzers (Follow User) oder das Warten auf ein Event (Idle) sein. Aus diesen Behaviors lassen sich Services wie z.B. das Versteckspiel in Abbildung 3.1 erzeugen. So wie der Ablauf der Services über den ServiceManager ge-steuert wird, werden die Behaviors vom BehaviorManager kontrolliert. Dabei meldet der aktivierte Service, welches Behavior vom BehaviorManager gestartet werden soll.
Dieser beendet daraufhin laufende Behaviors und verhindert somit, dass verschiedene Behaviors gleichzeitig den Roboter bewegen wollen und damit Konflikte in der Na-vigation auslösen. Da der BehaviorManager die Behaviors exklusiv aktiviert und nur das aktive Behavior auf die Navigation zugreifen darf, können Konflikte ausgeschlos-sen werden. Es ist deshalb sinnvoll, jedes Modul, welches die Navigation des Roboters nutzt, als Behavior zu implementieren.
Neben den Behaviors gibt es die Schicht der Skills. Hierbei handelt es sich um Ba-sisfunktionalitäten des Roboters. Sie können genutzt werden, um in Kombination mit anderen Skills neue Behaviors zu erzeugen. Skills können entweder indirekt über die Behaviors gesteuert werden oder sie laufen parallel im Hintergrund. So kann ein Skill im Hintergrund aktiv sein und aus Sensorinformationen der Umwelt Events generieren, die den Ablauf eines Services beeinflussen oder den Behaviors zur Verfügung stehen.
Beispielsweise ist ein Modul zur Erzeugung und Aktualisierung von Umgebungskarten ebenso ein Skill, wie ein Modul zur Personendetektion.
In MIRA werden Skills als Units oder MicroUnits realisiert. Die Entscheidung, ob ein Modul als Unit oder MicroUnit implementiert wird, hängt davon ab, ob das Modul
reaktiv angelegt werden soll (MicroUnit), d.h. ob es gestartet werden soll, sobald ein neues Event vorliegt oder ob es sich periodisch selbst starten soll (Unit). Eine Unit kann regelmäßig eigene Berechnungen durchführen, um damit neue Events zu erzeugen.
Die Kommunikation zwischen verschiedenen Units bzw. MicroUnits kann in MIRA auf zwei Wegen erfolgen: Entweder über Channels oder über Remote Procedure Calls (RPC). Channels sind Strukturen, auf die Daten geschrieben und von denen Daten gelesen werden können. Damit ein Modul Daten von einem Channel lesen kann, muss es dafür auf dem Channel zum Lesen registriert werden (Subscribe auf einen Chan-nel). Soll ein Modul Daten auf einen Channel schreiben, so muss dies ebenfalls dem Channel mitgeteilt werden (Publish auf einen Channel). Auf dem Channel liegen die mit einem Zeitstempel versehenen Daten vor. Dadurch können sie zugeordnet werden, auch wenn sie erst zu einem späteren Zeitpunkt abgerufen werden. Durch das Konzept der Channels können Daten unterschiedlichen Modulen zur gleichen Zeit bereitgestellt werden.
Während beim Konzept der Channels viele Module von einem Channel lesen oder auf diesen schreiben, erfolgt eine direkte Kommunikation zwischen zwei Modulen via RPC.
Dabei wird die Methode eines Moduls durch ein anderes Modul nach dem request-reply-Prinzip aufgerufen. Ein Zugriff erfolgt über die callService()-Methode aus dem aufrufenden Modul. Zusätzlich können auf diesem Weg auch Parameter in die aufge-rufene Methode übergeben werden. In Abbildung 3.2 sind die beiden Wege der Kom-munikation zwischen Units bzw. MicroUnits dargestellt.
Abbildung 3.2: Die Kommunikation zwischen zwei Units kann über Channels oder Remote Procedure Calls (RPC) erfolgen. Dabei können die Units auch zu unter-schiedlichen Prozessen gehören [Einhorn und Langner, 2012, 2593].