Software- und Regelungsarchitektur
Die Roboterentwicklungsumgebung ArmarX zielt darauf ab, eine Infrastruktur für die Entwicklung eines benutzerdefinierten Roboter-Frameworks bereitzustellen, das die Realisierung von verteilten Roboter-Softwarekomponenten ermöglicht. Zu diesem Zweck ist ArmarX in drei Schichten organisiert: die Middleware-Schicht, die Kernfunktionen wie Kommunikationsmethoden und Bereitstellungskonzepte bereitstellt, die Roboter-Framework-Schicht, die aus standardisierten, konfigurierbaren Komponenten besteht, und die Anwendungsschicht, in der Roboterprogramme implementiert werden. Diese Schichtenarchitektur erleichtert die Entwicklung von Roboter-Softwarearchitekturen durch den Einsatz von Standardschnittstellen und einsatzbereiten Komponenten, die entsprechend den Fähigkeiten und Anwendungen des Roboters angepasst, erweitert und/oder parametrisiert werden können. Zur Unterstützung des Entwicklungsprozesses stellt ArmarX eine Reihe von Tools zur Verfügung, wie z.B. Plug-in-basierte grafische Benutzeroberflächen, einen Statechart Editor und Tools für die Online-Inspektion und Zustandsoffenlegung.
Software- und Reglungsarchitektur des humanoiden Roboters ARMAR-6
Um die Hochleistungsaktoren des ARMAR-6 angemessen steuern zu können, wurde am H2T ein roboterunabhängiges, echtzeitfähiges Steuerungskonzept ArmarXRT entwickelt. Die entwickelten Konzepte ermöglichen die Kombination und Umschaltung zwischen verschiedenen Steuerungsansätzen mit unterschiedlichen Zykluszeiten und Echtzeitanforderungen bei voller Kompatibilität mit unserem bestehenden Roboterframework ArmarX. Der Roboter wird dzu in eine Reihe von virtuellen Steuerungs- und Sensorgeräten abstrahiert. Diese Steuergeräte stellen Aktoren oder das Power-Management-System dar, empfangen Sollwerte von übergeordneten Komponenten, wandeln sie in das hardware-spezifische Format um und senden sie an die reale Hardware. Sensorgeräte empfangen reale Daten (z. B. Motor-Ticks) oder virtuelle Daten (z. B. Steuerfrequenz) und stellen diese übergeordneten Komponenten zur Verfügung. Um flexible und wiederverwendbare Kontrollmechanismen zu entwickeln, bietet das Framework eine zweistufige Hierarchie für Controller:
- Hardwarespezifische Joint-Controller berücksichtigen Low-Level-Steuerungsaufgaben wie das Kodieren von Gelenkwinkeln in Encoder-Ticks oder das Berechnen des Motorstroms basierend auf einer Drehmomentvorgabe.
- Hardwareunabhängige Multi-Joint-Controller wie Trajektorieausführung über mehrere Gelenke oder kartesische Geschwindigkeitsregelung.
Mit diesen Mechanismen sind wir in der Lage, die gleichen Softwareschnittstellen am realen Roboter und in der Simulation anzubieten, was eine schnellere Entwicklung ermöglicht, da Multi-Joint-Controller in der Simulation und am realen Roboter laufen.
Das Kontrollrahmenwerk ist unterteilt in einen echtzeitfähigen Teil und einen Nicht-Echtzeitteil. Der Nicht-Echtzeit-Teil stellt Kommunikationsschnittstellen zu externen Softwaremodulen bereit und bietet die Möglichkeit, bestehende Komponenten zu nutzen, einschließlich der Plattformsteuerung, der Bewegungsplanung, der Speicherarchitektur und der Visualisierung des internen Zustands. Darüber hinaus werden alle Verwaltungsfunktionen wie die Erstellung von Controllern verwaltet. Der echtzeitfähige Kontroll-Thread übernimmt die Buskommunikation, die Ausführung der Steuerung sowie die blockierungsfreie Anbindung an übergeordnete Komponenten über die TCP- oder UDP-basierten Kommunikationsprotokolle mit ArmarX/Ice.
Software- und Reglungsarchitektur des humanoiden Roboters ARMAR-III
Die Software- und Regelungsarchitektur des humanoiden Roboters ARMAR-III besteht aus drei Schichten (siehe Abbildung). Auf der niedrigsten Ebene befinden sich die DSP für die sensormotorische Regelung bestehend aus kaskadierten Geschwindigkeits- und Positionsreglern. Des Weiteren stehen auf der gleichen Ebene diverse Hardwarekomponenten wie z.B. Mikrophone, Lautsprecher und Kameras zur Verfügung. Alle Komponenten sind entweder direkt oder via CAN-Bus verbunden mit PCs in der mittleren Ebene der Architektur. Die Software in der mittleren Ebene ist mit Hilfe von Modular Controller Architecture (MCA2 
) integriert. Die PCs in der mittleren Ebene werden für die Berechnung der Vorwärtskinematik als auch der inversen Kinematik genutzt sowie für die Steuerung der holomischen Plattform und der Sprachverarbeitung.
Die ersten beiden Ebenen der Architektur können als stabil angesehen werden, da die implementierten Module nicht mehr starken Änderungen unterliegen. Die Programmierung des Roboters wird auf der obersten Ebene durchgeführt. Hierbei wird auf die unteren Ebenen mittels einer standardisierten Schnittstelle zugegriffen. Programme für den Roboter auf dieser Ebene werden hauptsächlich in C++ geschrieben.
Für die effektive und effiziente Programmierung des Roboters sind zwei Abstraktionsebenen definiert: Taks und Skills. Skills sind hierbei atomare Fähigkeiten des Roboter z.B. Navigation der Plattform, visuelle suche von Objekten etc. Tasks hingegen werden aus mehreren Skills zusammengesetzt, um komplexere Operationen auszuführen z.B. Apfelsaft aus dem Kühlschrank dem Benutzer bringen.