Motion control

Aus toolbox_interaktion
Version vom 30. November 2014, 11:31 Uhr von Bruenig (Diskussion | Beiträge)

(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche

Beim Projekt MotionControl wurde in einer Projektarbeit eine kontaktlose Steuerung eines Roboterarmes mit Hilfe eines Bildsensors ermöglicht. Konkret sollen dreidimensionale Gelenk-Koordinaten mit Hilfe eines Bildsensors ausgewertet und bestimmte Bewegungen von einem Roboterarm imitiert werden. Die aufgenommenen Daten werden über das OSC Kommunikationsprotokoll an eine zentrale Software gesendet. Diese kann auch von anderen Quellen Daten empfangen (z.B. PC Simulation). Die empfangenen Daten werden dann in der API (Programmierschnittstelle) weiterverarbeitet und zur Steuerung eines Roboterarms vorbereitet. Die Motoransteuerung selbst erfolgt dann über den Roboterarm.


Projektarbeit
Titel motioncontrol.png
Betreuung Professor Heinz Brünig
Umsetzung Myron Griebel
Patrick Reul
Simon Zisler
Zeitraum WS 13/14



Zielbestimmung

Musskriterien

  • Das System soll Personen erkennen, die sich beim eingeschalteten Zustand im Tracking-Bereich befinden
  • Die Daten sollen automatisch an die Verarbeitungseinheit gesendet werden
  • Fehler müssen behandelt und dem Nutzer signalisiert werden
  • Der Roboterarm soll die Arm Bewegungen in Echtzeit imitieren
  • Es werden Verriegelungsoptionen eingebaut, die das Zerstören der Hardware verhindern sollen
  • Das System soll nach kurzer Einweisung bedien bar sein

Wunschkriterien

  • Daten können nicht nur vom Bildsensor sondern auch über andere Quellen an den Roboterarm gesendet werden.
  • Systemtest: Versuch das System auf einem raspberry PI laufen zu lassen. Wenn dies aus Rechenleistungsgründen nicht möglich ist, wird versucht einen Teil der Software darauf laufen zu lassen.

Abgrenzungskriterien

  • Die verarbeiteten Daten aus der Berechnungs-API sind auf den AREXX Roboterarm RA1 PRO optimiert
  • Das Aufnehmen der Daten wird auf den ASUS Xtion PRO Sensor optimiert
  • Das System wird für optimale Bildaufnahme Bedingungen entwickelt (keine Gegenstände im Weg, ruhiger Hintergrund)
  • Bei Austauschen einzelner Komponenten entsteht möglicherweise Umarbeitungsaufwand
  • Das System ist auf die Erkennung von nur einer Person ausgelegt
  • Es ist keine Teaching-Funktion vorgesehen

Projekteinsatz

Anwendungsbereich

Einzelpersonen können mit diesem System einen Roboterarm mit Hilfe des eigenen Armes (fern-) steuern. Es soll ein Produkt für spätere Tätigkeiten geschaffen werden, der das hantieren mit Gefahrenstoffen oder Schwerlasten ungefährlicher bzw. leichter machen soll.

Zielgruppe

Für die allgemeine Benutzung müssen keine Vorkenntnisse vorhanden sein. Das System soll für jedermann schon nach kurzer Einführungszeit verwendbar sein. Erst im Umgang mit Gefahrenstoffen bzw. Schwerlasten sind Fachkenntnisse der jeweiligen Anwenderfirmen erforderlich. Für die Weiterentwicklung müssen die deutschsprachigen Dokumentationen verstanden werden können.

Betriebsinformation

Im Wesentlichen gibt es hier kaum Einschränkungen. Bei Feststellung von Mängeln an der Hardware soll der Betrieb unverzüglich eingestellt werden. Die mechanische Belastung des Roboterarms muss vom Anwender berücksichtigt werden. Das System arbeitet nach dem Starten weitestgehend autonom.

Übersicht Datenfluss

Datenfluss.png

Software

Die Software ist in C / C++geschrieben. Dabei werden die Möglichkeiten der Abkapselung verwendet. Das Entwicklungssystem ist Linux. Dabei gibt es eine Software Aufteilung in drei Bereiche:

  1. Daten Aufnahme
    • Verbindung zum Sensor und Aufnahme der Bilder über openNI
    • Skeleton-Tracking über Middleware NiTE2
  2. Daten Verarbeitung
    • Eigene C / C++ Programme zur Verarbeitung
  3. Daten Verwendung
    • Eigene C / C++ Programme zum Senden und Empfangen der Daten auf dem Mikrocontroller
  4. Plattform
    • Linux
  5. Tools
    • openNI SDK
    • NiTE2 Middleware
    • Doxygen
    • LATEX
    • make

Die einzelnen Softwareprogramme werden auf dem jeweiligen System von einem Hauptprogramm aufgerufen. Der nötige Datenverkehr wird ebenfalls von dem Hauptprogramm gesteuert.


OSC Protokoll

Für die Kommunikation wird das OSC-Protokoll verwendet. Dadurch ist es möglich, Gelenk-Koordinaten über das Netzwerk an den Raspberry PI zu senden. Dadurch entsteht die Möglichkeit den Roboterarm fern zu steuern. In Projekt MotionControl wir OSC-Pack verwendet und die folgende Datenformate zur Berechnung geschickt:

Int Double Double Double Double Double Double
Gelenk Nummer X1-Koordinate Y1-Koordinate Z1-Koordinate X2-Koordinate Y2-Koordinate Z2-Koordinate

Die Daten werden vom raspberry PI empfangen und anschließend von der calculate.cpp in Bewegungsbefehle umgerechnet.


Hardware

Verwendete Hardware:

  • AREXX Robotarm mit Atmega64 Mikroprozessor
  • ASUS Xtion PRO Sensor
  • raspberry PI (Linux und LAN-fähig)
  • Rechner (Windows und LAN-fähig)

Aufbau und Stromversorgung

Aufbau.png

Power Box

Die meiste Elektronik steckt in der Power Box. Sie beinhaltet den raspberry PI und das Power Supply. Zudem befinden sich auf der Front mehrere Leds, die den Zustand des Systems repräsentieren, da kein Monitor verwendet werden muss.

Powerbox.png

Power (LEDs Hardware mäßig verschaltet)
Gelbe LED: Power/Strom ist vorhanden
Grüne LED: Power/Strom ist zugeschaltet -> Lastspannung liegt an
Power Line 1/2 (LEDs Hardware mäßig verschaltet)
Powerline 1: erster Laststromkreis vorhanden
L1 enabled: erster Laststromkreis zugeschaltet
L1 disabled: erster Laststromkreis nicht zugeschaltet
Powerline 2: zweiter Laststromkreis vorhanden
L2 enabled: zweiter Laststromkreis zugeschaltet
L2 disabled: zweiter Laststromkreis nicht zugeschaltet
raspberry (LEDs über raspberry gesteuert)
OK: Raspberry funktionsbereit
Error: Fehler auf Raspberry
RX: zeigt an das Daten über OSC empfangen werden
TX: zeigt an das Daten an den Roboterarm gesendet werden


Im Fehlerfall:

  • Power Line 1 leuchtet und weder L1 enabled noch L1 disabled leuchtet -> Sicherung geschmolzen
  • Power Line 2 leuchtet und weder L2 enabled noch L2 disabled leuchtet -> Sicherung geschmolzen
  • Raspberry Error -> Roboterarm nicht über USB angeschlossen -> Kabel anschließen

Power Supply

Ursprünglich sind vom Arm-Hersteller für Benutzung des Armes lediglich 2A vorgesehen gewesen. Doch war dieser Strom viel zu niedrig, da nicht alles Servos gleichzeitig benutzt werden konnten. Noch viel schwer wiegender war jedoch die Tatsache, dass der Strom nicht ausgereicht hat, das der Arm in selbst Haltung verharren konnte (z.B. bei ausgetrecktem Arm). Deswegen wurde kurzer Hand ein eigenes Stromversorgungsnetz geplant. Damit ist es möglich, das der Arm jetzt bis zu 10A Zu Verfügung hat. Um dem ganzen eine ordentliche Verpackung zu geben, haben wir eine Power Supply Box hergestellt. Damit es bei Fehlsteuerungen nicht zur selbst Zerstörung des Armes kommt, wurde ein Schlüssel zu Trennung der Lastspannung angebracht. Bei Betätigung werden Lastspannung von den Servos genommen, der Raspberry PI behält seinen Strom und ist somit weiterhin ansprechbar. Da die Servos unterschiedliche Versorgungsspannungen benötigen (verschiedene Baugrößen), wurden zwei Laststromkreise eingeführt. Diese besitzen jeweils eine eigene Feinsicherung. Diese beinhaltet neben den drei normalen Steckernetzteilen auch das Netzteil für den Raspberry, den Raspberry PI selbst und auf der Vorderseite sind mehrere Leds als Überprüfung und Kontrollmöglichkeit vorhanden.

Powersupply.png

Benutzung

Um das System zu nutzen:

  1. Strom einschalten
  2. Warten bis grüne LED (raspberry OK) leuchtet
  3. Tracking starten (Empfohlen wird die Grundstellung des Armes anzunehmen)
  4. Power einschalten -> Servos unter Strom
  5. Arm bewegen

VIDEO Vorführung

Daten Aufnahme

Die Bilddaten werden mit Hilfe eines ASUS Xtion PRO Bildsensors erfasst. Die logische Verbindung zum Sensor wird über die Entwicklungsumgebung openNI geschaffen. Die einzelnen Koordinaten der Gelenke können über Middleware NiTE2 zur Weiterverarbeitung analysiert werden. Die Koordinaten werden über OSC-Protokoll zur Weiterverarbeitung gesendet.

Aufnahme.png

Sensor

Der Sensor Xtion Pro Live der Firma Prime Sense/ASUS (Hier Link zum Sensor) ist genau für diesen Einsatzzweck entwickelt worden: Zur Aufnahme von Körperdaten in 3D. Dazu beinhaltet er eine RGB Kamera, einen Infrarot Emitter und Empfänger und zwei Mikrophone: Damit ist er im Stande Objekte dreidimensional auszuwerten.

Technische Daten

RGB Kamera Auflösung: SXGA (1280*1024)
Tiefenkamera Auflösung: VGA (640x480) : 30 fps
QVGA (320x240): 60 fps
Entfernung vom Sensor: 0,8 bis 3,5 Meter
Blickfeld: 58° Horizontal
45° Vertikal
Betriebssysteme: Windows 32/64 Bit
Linux 32/64 Bit
Android


OpenNI

Diese Software dient als Schnittstelle zur Hardware. Mit ihrer Hilfe lassen sich im Fehlerfall die Fehlerdaten und im Normalfall die Daten auslesen. Dazu stellt die Software Streams zur Verfügung, in denen die Daten weitergegeben werden. Man unterscheidet vier Tiefen der Daten:

openNI::OpenNI: Dient als Einstiegspunkt für alle Zugriffe auf die Hardware. Leitet Streams weiter und liest Informationen aus der Hardware wie Fehler aus.

openNI::Device: Speichert Informationen und Streams für einen einzelnen Sensor und stellt diese bereit

openNI::Stream: Bietet Zugriff auf einen bestimmten Stream von einem bestimmten Sensor

openNI::FrameRef: Beinhaltet ein einzelnes Standbild aus diesem Stream, womit sich dann die Koordinaten der Gelenke berechnen lassen


NiTE2

NiTE kann zwei verschiedene Arten von Tracking ausführen: Hand- oder Bodytracking.

In unserem Fall wird das Bodytracking genutzt. Dazu wird der OpenNI Stream an NiTE weiter gegeben. Dieses liest dann die Koordinaten der einzelnen Gelenke. In diesem Fall werden folgende Koordinaten genutzt:

  • Rechte Schulter
  • Linke Schulter
  • Rechter Ellenbogen
  • Linker Ellenbogen
  • Rechtes Handgelenk
  • Linkes Handgelenk

Gelenke.png

Die Koordinaten werden der Reihe nach aus einem einzelnen Standbild ausgelesen und zwischengespeichert.

Capture (eigenes Programm)

In unserem persönlichen Teil werden die Schnittstellen zu OpenNI und NiTE initialisiert und der Sensor gestartet. Auf der Konsole werden dann die Anweisungen zum Tracken ausgegeben. Auch wird der aktuelle Status angezeigt:

  • New User
  • Calibrating ( Dazu mit zur Seite ausgestreckten Armen ruhig stehen bleiben)
  • Tracking
  • Out of Scene
  • Lost

Bei der Weitergabe der Streams von OpenNI zu NiTE wird jeweils ein Standbild übertragen und die von NiTE berechneten Koordinaten paarweise( wie zur Winkelberechnung benötigt) per OSC versendet. Des weiteren wird nach jedem Durchlauf geprüft, ob der Sensor einen Fehler sendet und dann dementsprechend reagiert.

Daten Verarbeitung

Um dem Arrexx Roboterarm kontrollieren zu können, sind Bewegungsbefehl notwendig. Nachdem die Daten auf dem Raspberry PI empfangen wurden, werden Sie an die Berechnungsfunktion übergeben. Hierbei bestand das Hauptproblem darin, das für jedes Gelenk drei Koordinaten zur Verfügung stehen. Der Roboterarm benötigt aber für die Bewegungen keine Koordinaten. Es wird eine Servo-Nummer (1 Greifen, 2 Hand drehen, 3 Hand kippen, 4 Ellenbogen, 5 Schulter kippen, 6 Schulter drehen) und eine Zielposition die über eine entsprechende Spannung mittels Pulsweitenmodulation realisiert wird. Will man zum Beispiel die Hand öffnen wird folgender Bewegungsbefehl benötigt:

Bewege( 2 2 500 )
Servo Nummer Geschwindigkeit Zielposition
  • Servo Nummer z.B. 2 zuständig zum Kippen der Hand
  • Servogeschwindigkeit von 1 schnell bis 10 langsam
  • Zielposition Position im Raum

raspberry PI

Der raspberry PI ist in diesem Projekt die zentrale Einheit. Er ist dafür zuständig, die Daten über OSC zu empfangen, zu verarbeiten und anschließend an den Roboterarm zu senden. Da das Projekt keine Ausgabeeinheiten hat (Monitor) starten alle relevanten Programm auf dem Raspberry beim Starten von alleine. Über die LEDS auf der Vorderseite des Power Supply kann der Benutzer Informationen über den Zustand der Mini-PCs erfahren.

Es wurde die aktuelle Version von Raspbian mit dem dort enthaltenen vanilla Kernel verwendet. Das rootfs und der Kernel ist bereits für die Hardware des Raspberry Pi angepasst. Neben Ethernet und USB werden auch die GPIOs für die LEDs benötigt. Diese können direkt über die Shell parametriert und angesprochen werden. Beim Hochfahren wird ein, von uns erzeugtes, init.d Skript gestartet. Dieses konfiguriert als erstes die GPIOs, danach die virtuelle serielle Schnittstelle (/dev/ttyUSB0). Letzteres ist für die Kommunikation mit dem externen MAX232 Chip nötig. Es werden die gleichen Einstellungen gesetzt, die der Hersteller bei seinen Bootloader verwendet.

Am System wurde nur ein init Skript in /etc/init.d angelegt und für den Runnlevel 5 verlinkt. Die gesamte User Software und die Skripte für die Parameter befindet sich im Home-Verzeichnis. Alle Logs werden in /tmp angelegt um ein ungewolltes vollschreiben der SD-Karte zu vermeiden.


Ablauf.png

Im Init Schritt wird die grüne LED "raspberry OK" eingeschaltet.

ATMEGA64

Die Servos werden über die PWM Ausgänge eines AtMega64 Mikrocontroller gesteuert. Für die Firmware auf dem Controller wurde die Hersteller Bibliothek und ein von uns entwickeltes Protokoll verwendet. Ein Einsatz eines RTOS war nicht notwendig. Es reichte eine kooperatives Task Queue mit Verwendung von Interrupts aus.

Das verwendete Protokoll ist wie folgt aufgebaut:

  • Das erste Byte eines Befehls muss dem ASCII Zeichen $ entsprechenden
  • Der Befehl wurde vollständig Übertragen, wenn das letzte Zeichen dem ASCII Zeichen ! Entspricht
  • Die Länge eines Befehls beträgt 8 Byte
  • Bei Parameter mit mehr als einem Byte wird zuerst das höherwertige übertragen. (Big Endian)
  • Es werden keine negativen Werte übertragen. Mittels Offset (= minimal Position) werden nur positive Werte übertragen, was das 8,32,64 Bit Problem vereinfacht.
gesendeter Befehl: $sppvrr!
  • s = Servonummer
  • pp = Position
  • v = speed (0..10)
  • rr = reserviert

Das Protokoll kann in der include/share/defines.h komplett verändert werden. Ein Update der Firmware und der Software am Raspberry ist dann nötig.

Daten Verwendung

Der Mikrocontroller empfängt die Daten aus der Hardware-API und bewegt die entsprechenden Servos auf die berechneten Positionen. Die Stellung der Servos wird über Pulsweitenmodulation kontrolliert und gibt keine Rückmeldung auf die tatsächliche Position zurück. Damit die Verbindung frei zum Empfangen neuer Daten ist, wird auf das Rückmelden von Empfangsbestätigungen verzichtet.

Verarbeitung.png


Zusammenfassung

Mit der Projektarbeit wird die Grundlage zur Kommunikation einer Datenquelle bis hin zu Steuerung eines Roboterarms geschaffen. Bestand der Projektarbeit:

  • Auslesen verschiedener Arm Koordinaten eines Bildsensors mit Hilfe eines Software Developer Kits (openNI + NiTE2 Middleware für Skeleton-Tracking)
  • Versenden der Daten über OSC-Schnittstelle
  • Empfangen von X Y Z - Koordinaten per OSC und weiterleiten an die Berechnungs-API
  • Beispielhafte Umrechnung der Koordinaten in Winkel
  • Verschicken der Daten an den μ-Controller mittels eigenem Protokoll
  • Verarbeiten der Daten im μ-Controller und Ansteuerung der Servos
  • Klärung ob andere Roboterarme in Frage kommen
  • Aufbau des AREXX Roboterarm inkl. Hardware Modifikationen (Netzteile, diverse Widerstände)
  • Software/Apis für o.g. Funktionen installieren und bereitstellen
  • Systemtest: Versuch einer Implementierung der Software auf einem raspberry PI


Dokumentation mit Doxygen und Code

Um für die Zukunft Modifikationen und Erweiterungen zu erleichtern, sind alle Software- Komponenten so modular wie möglich gehalten. Zudem werden für alle APIs Dokumentationen/Beschreibungen erstellt (Doxygen).

Code Init Datei

Code MotionControl Code

Doku Software Manual