Kommunikationsarchitektur der DLR Hand II

Die DLR Hand II bietet eine hervorragende Plattform für die Entwicklung zukünftiger Greifstrategien. Um die Komplexität von Hardware, Sensoren und Anwendungen zu bewältigen, muss eine geeignete Hard- und Softwarestruktur bereitgestellt werden.

Die Informationsverarbeitungsarchitektur des Handsystems besteht aus Hardware, Software und Kommunikationsstrukturen. Die Hand verwendet ein serielles Kommunikationssystem, so dass sie in jedes Robotersystem integriert werden kann, insbesondere in verschiedene Generationen des DLR-Leichtbauroboters mit einer angepassten Werkzeugaufnahme. Das Ergebnis ist ein System, das sowohl kompakt als auch einfach zu bedienen ist.

Das Kommunikationssystem der DLR Hand II wurde so modular wie möglich aufgebaut, um einen einfachen Zugriff auf die Messdaten, eine einfache Wartung und einen schnellen Austausch oder eine Erweiterung von Teilen des Systems zu ermöglichen, um es an neue Bedürfnisse bei Experimenten und Anwendungen anzupassen. In diesem Zusammenhang wurde die Datenverarbeitung in mehrere Abstraktionsebenen aufgeteilt.

In der untersten Hardware-Ebene werden die Daten in analoger, zeitkontinuierlicher Hardware gesammelt und aufbereitet. Die Kommunikationsprotokollebene steht für die Steuerung des Datenerfassungsprozesses und die logische Übertragung der digitalisierten Sensorwerte an höhere Ebenen. Auf den Ebenen drei und höher schließlich werden Softwareimplementierungen von Algorithmen angewandt, um Messungen zu verarbeiten und Steuersignale auf mehreren Komplexitätsebenen zu erzeugen.

Hardware Ebenen

Diese unterste Ebene der Datenverarbeitung besteht aus analoger zeitkontinuierlicher oder quasi zeitkontinuierlicher Hardware. Wir verwenden handelsübliche Hardwarekomponenten außerhalb der DLR Hand II zur Steuerung der Hand. In Übereinstimmung mit den Überlegungen zum modularen Design kann die Kapazität des externen Prozessors ohne kostspieliges Redesign angepasst werden. Die Daten in der DLR Hand II werden von den Sensoren gesammelt und für die weitere Verarbeitung aufbereitet. Der Verkabelungsaufwand in und zur Hand musste gering gehalten werden, um die Hand flexibel an verschiedenen Robotersystemen einsetzen zu können. Daher werden die Sensordaten in der DLR Hand II von einem Netzwerk von FPGAs gesammelt und seriell an einen übergeordneten digitalen Signalverarbeitungscontroller gesendet. Der serielle Datentransport wird durch ein auf der Kommunikationsprotokollebene implementiertes Protokoll geregelt. Die Verwendung von FPGAs ermöglicht eine flexible Struktur von Datensammlern. Jede neue Datenquelle kann leicht in das System integriert werden. Die Daten werden der Datenverarbeitungsebene und höheren Ebenen auf den Kontrollrechnern über eine doppelt portierte Speicherkarte zur Verfügung gestellt, die den gegenseitigen Zugriff auf Daten aus dem FPGA-Netzwerk sowie von externer Prozessorhardware ermöglicht.

Hardware für Datenerfassung und Signalaufbereitung

Um eine sensible Interaktion mit der Umgebung zu ermöglichen, wurde die DLR Hand II mit verschiedenen Sensoren zur Messung von Position, Geschwindigkeit, Gelenkdrehmoment und Temperatur ausgestattet. Der Aufwand für die Erfassung und Aufbereitung eines bestimmten Sensorsignals richtet sich nach der beabsichtigten Verwendung dieser Daten. Die physikalischen Daten des Sensors, z.B. der Spannungsausgang eines Potentiometers, werden der Sensorsignalvorverarbeitung zugeführt. Diese befindet sich direkt neben dem Sensor selbst und besteht aus einem Impedanzwandler und einem Instrumentenverstärker mit einem Butterworth-Tiefpassfilter dritter Ordnung. An diese Schaltung schließt sich ein 12-Bit-A/D-Wandler an, der so nah wie möglich an den Schaltungen zur Sensorsignalaufbereitung in jedem Fingerglied angeordnet ist, um den Verkabelungsaufwand und die Rauschinduktion gering zu halten. Die Wandler werden asynchron mehr als zehnmal schneller abgetastet als die eigentliche Taktrate des Steuersystems, wodurch ein quasi kontinuierlicher Datenstrom gewährleistet wird und Raum für weitere Erweiterungen bleibt. Die Daten werden über eine serielle Kommunikationsverbindung an einen in einem FPGA implementierten Fingerdatensammler gesendet. Jeder Finger-Datensammler leitet seine Daten seriell an den Hand-Datensammler weiter, der alle gesammelten Daten an die Dual-Ported-RAM-Karte weiterleitet. Der Einfachheit halber verwenden alle Sensoren unabhängig von ihrem tatsächlichen Auflösungsbedarf die gleichen 12-Bit-A/D-Wandler. Daher ist jedes bewegliche Glied des Fingers mit einem 8-Kanal 12-Bit A/D-Wandler ausgestattet. Auf der nicht beweglichen Basisplatine jedes Fingers befinden sich zwei dieser A/D-Wandler. Insgesamt ergibt dies fünf Wandler pro Finger, die 40 Kanäle bereitstellen. Derzeit werden 25 Kanäle verwendet, so dass 15 Kanäle für weitere Anwendungen wie zusätzliche taktile Sensoren zur Verfügung stehen.

Verteilung von Befehlssignalen

Die Steuerwerte für die Motoren, die von der Steuerungssoftware kommen, werden auf dem umgekehrten Weg der Sensorsignalerfassung verteilt. Um die Leistungselektronik von den signalverarbeitenden Geräten zu trennen, wird eine zusätzliche galvanische Entkopplung zwischen dem Finger Controller und der Leistungselektronik eingeführt.

Controller Hardware

Um leicht skalierbar zu sein und einen einfachen Zugriff sowohl auf den Code als auch auf die Daten des Controllers zu gewährleisten, wurde die gesamte Datenverarbeitung der höheren Ebene auf zwei industriellen PowerPC VME-Bus-Karten implementiert. Für die Kommunikation mit externen Computern und Datenquellen sind beide Boards mit einem LAN-Anschluss und einer seriellen Schnittstelle ausgestattet. Auf beiden VME-Karten läuft das Echtzeitbetriebssystem VxWorks.

EEPROM für Kalibrierungsdaten

Die Kalibrierungsparameter für Sensoren variieren sowohl zwischen den einzelnen Sensoren als auch zwischen den Fingern. Um die Modularität und Austauschbarkeit der Hardware zu erhalten, werden diese Parameter in den einzelnen Fingern gespeichert. Daher ist jeder Finger mit einem EEPROM ausgestattet, in dem die Parameter für den entsprechenden Finger gespeichert sind. Beim Einschalten des Systems werden die Parameter gelesen.

Kommunikationsprotokoll Ebene

Um Daten zu sammeln und zu übertragen, wurde ein hierarchisches serielles Kommunikationssystem in der Handfläche und den Fingern der DLR Hand II implementiert. Es ist in FPGAs gemäß dem IEEE 1355 Standard implementiert, der eine schlanke Protokollschicht spezifiziert, Kollisionen verhindert und verschiedene physikalische Übertragungsmedien unterstützt. Die Zeichenverbindungen des Netzwerks werden mit Daten- und Strobe-Leitungen in beide Richtungen realisiert, so dass sich vier Leitungen ergeben. Ein Heartbeat-Ereignis aktiviert den Datensammler, um die Daten des gemeinsamen Speichers von einem Paket zu übernehmen und an den Host zu senden. Ein spezielles Zeichen mit hoher Priorität wird verwendet, um das Heartbeat-Ereignis an alle Datensammler zu übertragen, um das System in Echtzeit zu synchronisieren. Ein Host-Interface-Controller mit einer Dual-Ported-Memory-Schnittstelle zur Host-CPU verarbeitet die eingehenden Pakete mit den Sensorwerten, bereitet die ausgehenden Pakete mit den Aktuatorwerten vor, um sie an die Datensammler zu senden, und erzeugt das Heartbeat-Ereignis zur Synchronisierung des Systems. In DLR Hand II ermöglicht eine physikalische Datenrate von 10 Mbits einen vollen Zyklus, in dem Sensordaten abgetastet und Aktuatorwerte jede Millisekunde berechnet und eingestellt werden.

Architektur der Steuerungssoftware

Die mehrstufige, modulare Struktur des gesamten Handsystems wird auch in der Softwarearchitektur der Hand eingeführt. Die Datenverarbeitung in der Software wird in vier weiteren logischen Ebenen realisiert. Die Ebenen steigen von der niedrigsten Kommunikationsprotokollebene an. Die folgende Datenverarbeitungsebene führt alle Berechnungen durch, die für die Umwandlung digitalisierter Sensorwerte in anwendbare Messungen in SI-Einheiten erforderlich sind. Es folgt die untere Controller-Ebene, die grundlegende Steuerungs-, Systemüberwachungs- und Sicherheitsaufgaben im Zusammenhang mit einzelnen Fingern, Gelenken und Sensoren durchführt. Die vierte Softwareebene, die Höhere Controller-Ebene, implementiert koordinierte Steuerungen für alle Finger und führt grundlegende Operationen aus, die von externen Befehlsgeneratoren der höchsten Externen Befehlsebene verwendet werden können.

Datenverarbeitungsebene

Auf dieser Ebene wartet für jeden Finger eine unabhängig geplante Aufgabe auf neu eingetroffene Sensordaten, die durch einen Interrupt signalisiert werden. In den meisten Fällen müssen die Daten verarbeitet werden, damit sie von anderen Aufgaben interpretiert werden können. Die meisten Signale können mit einer linearen Messfunktion umgewandelt werden. Einige Signale können jedoch besser durch Polynome höherer Ordnung oder spezielle Berechnungen angepasst werden.

Untere Controller-Ebene

In dieser Ebene wartet die Controller-Schleife auf einen Heartbeat-Interrupt und verarbeitet Messungen aller Finger, um sich mit der Hardware-Uhr zu synchronisieren. In einem zweiten Schritt werden Gelenk- oder kartesische Befehle von der höheren Controller-Ebene empfangen. Neben diesen Befehlswerten werden auch Steuerwerte empfangen, die die Auswahl und Parametrisierung von Controllern und den Ein-Aus-Status von Motoren usw. bestimmen. Nacheinander wird ein Schritt in der gewünschten Art von Controller ausgeführt. Zu den implementierten Controller-Typen gehören die Impedanzsteuerung der Gelenkebene mit Reibungs- und Schwerkraftkompensation, die Null-Drehmoment-Steuerung und zwei verschiedene Implementierungen der kartesischen Steuerung. Schließlich werden umfangreiche Sicherheitsprüfungen durchgeführt, einschließlich Gelenk- und Temperaturgrenzen, Gültigkeit der Sensorsignale und Integrität des Kommunikationssystems. Daraus resultierende Fehler werden mit geringerer Priorität in einer zusätzlichen Aufgabe gemeldet, um ein korrektes Zeitverhalten auch in fehlerhaften Fällen zu gewährleisten. Im Falle eines schwerwiegenden Systemfehlers ist ein Post-Mortem-Dump der Sensorwerte und Befehle möglich, um Fehler zu rekonstruieren und zu beseitigen.

Obere Controller-Ebene

Auf dieser Ebene werden grundlegende Fähigkeiten wie koordinierte Steuerungen und Datenverarbeitung auf höherer Ebene bereitgestellt, die zur Ausführung komplexer Aufgaben erforderlich sind. Diese grundlegenden Fähigkeiten umfassen zum Beispiel die Erkennung von Berührungen, die Schätzung der Geschwindigkeit eines gegriffenen Objekts oder eine Schnittstelle zu einem Datenhandschuh. Im Gegensatz zur unteren Controller-Ebene ist es hier dringend notwendig, in einem fließenden Übergang von einer Steuerungsart zur anderen wechseln zu können, ohne eine Steuerungsart vorher beenden zu müssen. Aus diesem Grund werden Operationen und Controller, die in dieser Ebene erzeugt werden, von einem speziell entwickelten Scheduler gesteuert, der für jede Operation einen Zustandsautomaten steuert, der in diesem Kontext als Anwendung bezeichnet wird. Auf dieser Ebene müssen kontextabhängige Sicherheitsüberprüfungen durchgeführt werden.

Anwendungsplaner

Wir unterscheiden zwei Arten von Anwendungen: befehlende Anwendungen und unterstützende Anwendungen. Die erste Art umfasst z.B. Controller mit geschlossenem Regelkreis und verschiedene Arten von Referenzpositionsgeneratoren, z.B. Data Glove Interfaces. Es kann jeweils nur eine aktive befehlende Anwendung geben. Die zweite Art umfasst alle Anwendungen, die Daten für eine befehlende Anwendung bereitstellen und verarbeiten. Es können mehrere unterstützende Anwendungen gleichzeitig aktiv sein.

Programmablauf der höheren Controller-Ebene

Der Zeitplanungsmechanismus ist in den Programmablauf der fünften Ebene integriert. Die Kontrolltask wartet auf Messungen von der unteren Controller-Ebene und synchronisiert sich dadurch indirekt mit der Hardware-Uhr. Nacheinander prüft sie, ob Befehle aus externen Quellen vorliegen, plant die Anwendungen neu und führt sie aus und sendet die daraus resultierenden Befehle. Die Schnittstellen zu externen Befehlsgebern sind als separate RPC- oder serielle Schnittstellentreiber konstruiert, die über eine unterstützende Anwendung mit der Steuerungsaufgabe kommunizieren.

Externe Befehlsebene

Das entwickelte modulare Ebenenkonzept wurde vor allem für die Durchführung verschiedener Aufgaben auf einer hohen Abstraktionsebene konzipiert. Die Realisierung dieser Aufgaben kann auf jeder Computerplattform erfolgen. Die Externe Kommandoebene ist über eine RPC-Verbindung mit Schnittstellen zu den unteren Ebenen ausgestattet. Ein grafisches, aufgabenorientiertes Programmiersystem wurde mit DLR Hand II verbunden, ebenso wie mehrere Kontroll- und Überwachungsmenüs, um den Zustand des Systems auszuwerten. Unter Verwendung dieser grundlegenden Schnittstellen wurden viele Anwendungen entwickelt.

Downloads