Abschlussbericht - Universität Oldenburg

Projektgruppe 2012/13 

Roboarm 

Abschlussbericht 

Erstgutachter 

Claas Diederichs 

Zweitgutachter 

Tobias Tiemerding 

Oldenburg den, 10. Oktober 2013

Inhaltsverzeichnis 

Präambel 2 

Inhaltsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

Abbildungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . 16 

Tabellenverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 

Quellcodeverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 

1 Lastenheft 20 

1.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 

1.1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 20 

1.1.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . 23 

1.1.2.1 Szenarien . . . . . . . . . . . . . . . . . . . . . 24 

1.1.3 Vorstellung der Gruppe . . . . . . . . . . . . . . . . . . 25 

1.1.4 Darstellung aktueller Technologien . . . . . . . . . . . 25 

1.1.5 Abgrenzung des Systems . . . . . . . . . . . . . . . . . 27 

1.1.6 Beschreibung der Ausgangslage . . . . . . . . . . . . . 28 

1.2 Anforderungsdefinition . . . . . . . . . . . . . . . . . . . . . . 29 

1.2.1 Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . 29 

1.2.2 Gobaler Anwendungsfall . . . . . . . . . . . . . . . . . 30 

1.2.3 Primäre Anwendungsfälle . . . . . . . . . . . . . . . . . 31 

1.2.3.1 Armhaltung nachahmen . . . . . . . . . . . . 31 

1.2.3.2 Objekt bewegen . . . . . . . . . . . . . . . . . 33 

1.2.3.3 Roboter steuern durch alternative Gesten . . 36 

1.2.3.4 Skizze zeichnen . . . . . . . . . . . . . . . . . 40 

1.2.4 Enthaltene Anwendungsfälle . . . . . . . . . . . . . . . 42 

1.2.4.1 Kalibrierung für Gestenerkennung . . . . . . 42 

1.2.4.2 Initialisierung für Roboterarmsteuerung . . . 45 

1.2.4.3 Roboterarm bewegen . . . . . . . . . . . . . . 47 

1.2.4.4 Greifer ansteuern . . . . . . . . . . . . . . . . 49 

1.2.4.5 Kalibrierung für alternative Gestenerkennung 50 

1.2.4.6 Kalibrierung für Portraitaufnahme . . . . . . 53 

1.2.4.7 Portrait aufnehmen . . . . . . . . . . . . . . . 54 

1.2.5 Funktionale Anforderungen . . . . . . . . . . . . . . . 55 

2

Inhaltsverzeichnis 10. Oktober 2013 

1.2.6 Nicht funktionale Anforderungen . . . . . . . . . . . . 57 

1.3 Risikoanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 

1.4 Entwicklungszyklus . . . . . . . . . . . . . . . . . . . . . . . . 63 

1.5 Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . 63 

1.6 Lieferumfang . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 

2 Implementation 65 

2.1 Sprintplanung Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . 66 

2.1.1 Machbarkeitsstudie Eye-Tracking . . . . . . . . . . . . 66 

2.1.2 Anbindung des Kameramoduls . . . . . . . . . . . . . 68 

2.1.3 Roboter-Arm . . . . . . . . . . . . . . . . . . . . . . . . 70 

2.1.4 Objektverfolgung . . . . . . . . . . . . . . . . . . . . . . 72 

2.2 Sprint 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 

2.2.1 Machbarkeitsstudie Eye-Tracking . . . . . . . . . . . . 74 

2.2.1.1 Einleitung . . . . . . . . . . . . . . . . . . . . . 75 

2.2.1.2 Systemdefinition . . . . . . . . . . . . . . . . . 78 

2.2.1.3 Systemparameter . . . . . . . . . . . . . . . . 79 

2.2.1.4 Ansätze . . . . . . . . . . . . . . . . . . . . . . 81 

2.2.1.5 Messungen . . . . . . . . . . . . . . . . . . . . 92 

2.2.1.6 Probleme . . . . . . . . . . . . . . . . . . . . . 97 

2.2.1.7 Evaluation . . . . . . . . . . . . . . . . . . . . 99 

2.2.1.8 Fazit . . . . . . . . . . . . . . . . . . . . . . . . 101 

2.2.1.9 Datenstruktur . . . . . . . . . . . . . . . . . . 102 

2.2.2 Anbindung des Kameramoduls . . . . . . . . . . . . . 103 

2.2.2.1 Toolbox Plugin . . . . . . . . . . . . . . . . . . 109 

2.2.2.2 Aufgetretene Probleme . . . . . . . . . . . . . 109 

2.2.2.3 Ausblick . . . . . . . . . . . . . . . . . . . . . 110 

2.2.3 Roboter-Arm . . . . . . . . . . . . . . . . . . . . . . . . 112 

2.2.3.1 Ziel . . . . . . . . . . . . . . . . . . . . . . . . 112 

2.2.3.2 Vorwärtskinematik . . . . . . . . . . . . . . . 117 

2.2.3.3 Rückwärtskinematik . . . . . . . . . . . . . . 124 

2.2.4 Objektverfolgung . . . . . . . . . . . . . . . . . . . . . . 140 

2.2.4.1 Bewegungsrichtungserkennung der Hand . . 140 

2.2.4.2 Arm mit Winkeln . . . . . . . . . . . . . . . . 144 

2.2.5 Zusammenführung von Objektverfolgung und Roboterarmsteuerung 

. . . . . . . . . . . . . . . . . . . . . . . . 153 

2.2.5.1 Integration von Objektverfolgung und Roboterarmsteuerung 

. . . . . . . . . . . . . . . . . . 153 

2.2.5.2 Erstellung eines stabilen Demonstators . . . . 153 

2.2.5.3 Ausblick . . . . . . . . . . . . . . . . . . . . . 154 

3


2.2.6 Fazit und Ausblick . . . . . . . . . . . . . . . . . . . . . 155 


2.3.1 Image Bus Switch . . . . . . . . . . . . . . . . . . . . . . 157 

2.3.2 Filter Cores . . . . . . . . . . . . . . . . . . . . . . . . . 158 

2.3.3 HDMI Analyse . . . . . . . . . . . . . . . . . . . . . . . 159 

2.3.4 Histogramm . . . . . . . . . . . . . . . . . . . . . . . . . 160 

2.3.5 Notwendigkeit eines Histogramms . . . . . . . . . . . 161 

2.4 Sprint 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 

2.4.1 Image Bus Switch . . . . . . . . . . . . . . . . . . . . . . 162 

2.4.1.1 image_bus_switch 1.00.a . . . . . . . . . . . . 163 

2.4.1.2 xps_timer 1.02.a . . . . . . . . . . . . . . . . . 164 

2.4.1.3 simple_i2c 2.00.a . . . . . . . . . . . . . . . . . 165 

2.4.1.4 Toolbox Plugin . . . . . . . . . . . . . . . . . . 168 

2.4.1.5 Dateistruktur . . . . . . . . . . . . . . . . . . . 169 

2.4.1.6 Aufgetretene Probleme . . . . . . . . . . . . . 169 

2.4.1.7 Ergebnis . . . . . . . . . . . . . . . . . . . . . . 170 

2.4.2 Filter Cores . . . . . . . . . . . . . . . . . . . . . . . . . 171 

2.4.2.1 schwellwertfilter_v1_00_a . . . . . . . . . . . 171 

2.4.2.2 rgb2grey_v1_00_a . . . . . . . . . . . . . . . . 172 

2.4.2.3 morphology_v1_00_a . . . . . . . . . . . . . . 175 

2.4.3 HDMI Analyse . . . . . . . . . . . . . . . . . . . . . . . 177 

2.4.3.1 hdmi_out . . . . . . . . . . . . . . . . . . . . . 177 

2.4.3.2 VFBC . . . . . . . . . . . . . . . . . . . . . . . 178 

2.4.3.3 Ergebnis HDMI . . . . . . . . . . . . . . . . . 180 

2.4.3.4 Ergebnis ImageCache . . . . . . . . . . . . . . 181 

2.4.4 Histogramm . . . . . . . . . . . . . . . . . . . . . . . . . 182 

2.4.4.1 Umsetzung . . . . . . . . . . . . . . . . . . . . 182 

2.4.5 Notwendigkeit eines Histogramms . . . . . . . . . . . 184 

2.4.5.1 Evaluation . . . . . . . . . . . . . . . . . . . . 184 

2.4.5.2 Beschreibung Der Arbeitsumgebung . . . . . 184 

2.4.5.3 Aufnahmen und Ergebnisanalyse . . . . . . . 185 



2.5.1 Softwareprototyp Kopfsteuerung . . . . . . . . . . . . 189 

2.5.2 Tiefenerkennung . . . . . . . . . . . . . . . . . . . . . . 192 

2.5.3 Echtzeitbildausgabe auf HDMI . . . . . . . . . . . . . . 194 

2.5.4 Hardware Umsetzung der Bewegungserkennung . . . 196 

2.6 Sprint 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 

2.6.1 Softwareprototyp Kopfsteuerung . . . . . . . . . . . . 198 

2.6.1.1 1. Ansatz: Kopfsteuerung ohne Markierungen198 

4


2.6.1.2 2. Ansatz: Kopfsteuerung mit Markierungen 198 

2.6.1.3 Servo IP-Core . . . . . . . . . . . . . . . . . . 203 

2.6.1.4 USB Driver IP-Core . . . . . . . . . . . . . . . 207 

2.6.1.5 Cam-USB IP-Core . . . . . . . . . . . . . . . . 209 

2.6.1.6 VmodCam . . . . . . . . . . . . . . . . . . . . 210 

2.6.1.7 Kinematik . . . . . . . . . . . . . . . . . . . . . 210 

2.6.1.8 Anbindung an die Rückwärtskinematik . . . 213 

2.6.2 Tiefenerkennung . . . . . . . . . . . . . . . . . . . . . . 214 

2.6.2.1 Vorgehen . . . . . . . . . . . . . . . . . . . . . 214 

2.6.2.2 Planungsphase: identifizierte Aufgaben . . . 215 

2.6.2.3 Tiefenberechnung . . . . . . . . . . . . . . . . 216 

2.6.2.4 Tests . . . . . . . . . . . . . . . . . . . . . . . . 218 

2.6.2.5 Probleme in der Testphase . . . . . . . . . . . 231 

2.6.2.6 Vergleich mit OpenCV . . . . . . . . . . . . . 232 

2.6.2.7 Problemlösungen . . . . . . . . . . . . . . . . 234 

2.6.2.8 Implementierung . . . . . . . . . . . . . . . . 235 

2.6.3 Echtzeitbildausgabe auf HDMI . . . . . . . . . . . . . . 239 

2.6.4 Hardware Umsetzung der Bewegungserkennung . . . 248 

2.6.4.1 Umsetzung der Bildverarbeitungskette auf 

dem FPGA . . . . . . . . . . . . . . . . . . . . 248 

2.6.4.2 Anpassung des Schwellwertfilter IP-Core . . 250 

2.6.4.3 IP-Core ImageBusConverter . . . . . . . . . . 251 

2.6.4.4 IP-Core Erkennung von Regionen in Bildern 253 

2.6.4.5 Armerkennung und Verfolgungstreiber . . . 254 

2.6.4.6 Übertragung und Darstellung der Armposition 

mit der OFFIS-Automation-Toolbox . . . 257 

2.6.4.7 Schwierigkeiten . . . . . . . . . . . . . . . . . 258 

2.6.4.8 Fazit . . . . . . . . . . . . . . . . . . . . . . . . 258 



2.7.1 Softwareprototyp Handsteuerung . . . . . . . . . . . . 260 

2.7.2 Überarbeitung der Dokumentation . . . . . . . . . . . 262 

2.8 Sprint 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 

2.8.1 Softwareprototyp Handsteuerung . . . . . . . . . . . . 264 

2.8.1.1 State-of-the-Art . . . . . . . . . . . . . . . . . 264 

2.8.1.2 Ansatz zur Handsteuerung . . . . . . . . . . 266 



2.9.1 ImageBus Overlay . . . . . . . . . . . . . . . . . . . . . 272 

2.9.2 3D Armerkennung - Portierung auf den Microblaze . 274 

5


2.9.3 Aufbau der dreidimensionalen Bildverarbeitungskette 275 

2.9.4 Spezifikation eines neuen Roboterarms . . . . . . . . . 276 

2.9.5 Erweiterung des Servo-IP-Cores . . . . . . . . . . . . . 278 

2.9.6 Entwicklung einer Trajektorienführung . . . . . . . . . 279 

2.9.7 Erweitern des Zeichenbereiches und Untersuchung 

des Zig-Zag Verhaltens . . . . . . . . . . . . . . . . . . 281 

2.9.8 Drehgelenk . . . . . . . . . . . . . . . . . . . . . . . . . 283 

2.9.9 Referenztakt für den cam_bootloader . . . . . . . . . . 284 

2.10 Sprint6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285 

2.10.1 ImageBus Overlay . . . . . . . . . . . . . . . . . . . . . 285 

2.10.1.1 FIFO-VHDL-Modul . . . . . . . . . . . . . . . 285 

2.10.1.2 image_bus_overlay_1_00_a . . . . . . . . . . . 286 

2.10.1.3 Overlay Microblaze Code . . . . . . . . . . . . 290 

2.10.2 3D Armerkennung - Portierung auf den Microblaze . 297 

2.10.2.1 Datenstrukturen der Armerkennung . . . . . 297 

2.10.2.2 Klassen der Armerkennung . . . . . . . . . . 298 


2.10.3 Aufbau der dreidimensionalen Bildverarbeitungskette 302 

2.10.3.1 Bildgrößen Anpassung . . . . . . . . . . . . . 302 

2.10.3.2 Dreidimensionale Hardware Bildverarbeitungskette 

. . . . . . . . . . . . . . . . . . . . . . . . 303 


2.10.4 Spezifikation eines neuen Roboterarms . . . . . . . . . 305 

2.10.4.1 Schwachstellen der aktuellen Konfiguration . 305 

2.10.4.2 State of the Art . . . . . . . . . . . . . . . . . . 306 

2.10.4.3 Anforderungen . . . . . . . . . . . . . . . . . 309 

2.10.4.4 Erarbeitung der Grundlagen . . . . . . . . . . 311 

2.10.4.5 Ansätze neuer Roboterkonfigurationen . . . . 322 

2.10.5 Erweiterung des Servo-IP-Cores . . . . . . . . . . . . . 333 

2.10.5.1 VHDL-Code . . . . . . . . . . . . . . . . . . . 334 

2.10.5.2 Treiber . . . . . . . . . . . . . . . . . . . . . . . 335 

2.10.6 Entwicklung einer Trajektorienführung . . . . . . . . . 337 

2.10.6.1 Algorithmus . . . . . . . . . . . . . . . . . . . 338 

2.10.6.2 Ermittlung der theoretischen Schrittweite . . 340 

2.10.6.3 Anpassung der Kinematik auf 2D Ebene . . . 341 


2.10.6.5 Aufbau . . . . . . . . . . . . . . . . . . . . . . 345 


des Zig-Zag Verhaltens . . . . . . . . . . . . . . . . . . 349 

2.10.7.1 Strategiewechsel . . . . . . . . . . . . . . . . . 349 

6


2.10.7.2 Tests und Erkenntnisse/Bericht . . . . . . . . 351 

2.10.7.3 Ermittelter Arbeitsbereich für Skizze Zeichnen352 

2.10.8 Drehgelenk . . . . . . . . . . . . . . . . . . . . . . . . . 354 

2.10.8.1 Algorithmus . . . . . . . . . . . . . . . . . . . 354 


2.10.8.3 Testfälle . . . . . . . . . . . . . . . . . . . . . . 359 

2.10.8.4 Probleme . . . . . . . . . . . . . . . . . . . . . 362 


2.10.9 Referenztakt für den cam_bootloader . . . . . . . . . . 364 

2.10.9.1 Modifizierter cam_bootloader . . . . . . . . . 364 



2.11.1 Portierung der Kinematik . . . . . . . . . . . . . . . . . 367 

2.11.2 Portierung der alternativen Gestensteuerung . . . . . . 369 

2.11.3 Integration der Komponenten zum Demonstrator Armhaltung 

nachahmen . . . . . . . . . . . . . . . . . . . . . . 370 

2.11.4 Kinematik für neuen Roboterarm . . . . . . . . . . . . 371 

2.11.5 Anbindung des Grauwertfilters an den PLB . . . . . . 372 

2.11.6 Vektorisieren eines Portraits . . . . . . . . . . . . . . . . 373 

2.12 Sprint 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374 

2.12.1 Portierung der Kinematik . . . . . . . . . . . . . . . . . 374 

2.12.1.1 Durchgeführte Änderungen . . . . . . . . . . 374 


2.12.2 Portierung der alternativen Gestensteuerung . . . . . . 376 

2.12.2.1 Umstellung des Graustufenfilters auf mehrere 

Farben . . . . . . . . . . . . . . . . . . . . . . . 376 

2.12.2.2 Probleme . . . . . . . . . . . . . . . . . . . . . 376 


2.12.3 Kinematik für neuen Roboterarm . . . . . . . . . . . . 378 

2.12.3.1 Umstellung der Entwicklungsstrategie . . . . 379 

2.12.3.2 Vorwärtskinematik . . . . . . . . . . . . . . . 379 

2.12.3.3 Rückwärtskinematik . . . . . . . . . . . . . . 380 

2.12.3.4 OFFIS-Automation-Toolboxplugin für neue 

Kinematik . . . . . . . . . . . . . . . . . . . . . 381 

2.12.3.5 Generierung des Quelltextes der Kinematik . 383 

2.12.3.6 Probleme . . . . . . . . . . . . . . . . . . . . . 385 


2.12.3.8 Ausblick . . . . . . . . . . . . . . . . . . . . . 387 

7


2.12.4 Integration der Komponenten zum Demonstrator Armhaltung 

nachahmen . . . . . . . . . . . . . . . . . . . . . . 389 

2.12.4.1 Integration der Hardware Komponenten . . . 389 

2.12.4.2 Integration der Software . . . . . . . . . . . . 391 

2.12.4.3 Probleme . . . . . . . . . . . . . . . . . . . . . 391 

2.12.4.4 Testfälle . . . . . . . . . . . . . . . . . . . . . . 393 

2.12.4.5 Geschwindigkeitsanalyse . . . . . . . . . . . . 398 

2.12.4.6 Optimierung . . . . . . . . . . . . . . . . . . . 407 


2.12.5 Anbindung des Grauwertfilters an den PLB . . . . . . 410 

2.12.5.1 Herangehensweise . . . . . . . . . . . . . . . . 410 


2.12.6 Vektorisierung von Portraitaufnahme . . . . . . . . . . 412 

2.12.6.1 Bildvorverarbeitung . . . . . . . . . . . . . . . 412 

2.12.6.2 Vektorisierung . . . . . . . . . . . . . . . . . . 415 

2.12.6.3 Ausblick auf anstehende Aufgaben . . . . . . 416 


2.12.7 Design und Bau des Roboterarms . . . . . . . . . . . . 418 

2.12.7.1 Designentscheidungen . . . . . . . . . . . . . 418 

2.12.7.2 CAD-Zeichnungen . . . . . . . . . . . . . . . 418 

2.12.7.3 Zusammenbau . . . . . . . . . . . . . . . . . . 427 

2.12.7.4 Ausblick . . . . . . . . . . . . . . . . . . . . . 427 




2.13.1 Fertigstellung und Optimierung des Demonstrators 

„Armhaltung nachahmen“ . . . . . . . . . . . . . . . . 430 

2.13.2 Semi-Demonstrator „Gestensteuerung“ . . . . . . . . . 432 

2.14 Sprint 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433 

2.14.1 Fertigstellung und Optimierung des Demonstrators 

„Armhaltung nachahmen“ . . . . . . . . . . . . . . . . 433 

2.14.1.1 Verbesserung der Performanz . . . . . . . . . 433 

2.14.1.2 Gesamtzeit . . . . . . . . . . . . . . . . . . . . 438 

2.14.1.3 Stabilisierung . . . . . . . . . . . . . . . . . . . 439 

2.14.1.4 Ausblick . . . . . . . . . . . . . . . . . . . . . 439 


2.14.1.6 Finale Methoden . . . . . . . . . . . . . . . . . 440 

2.14.2 Semi-Demonstrator „Gestensteuerung“ . . . . . . . . . 443 

2.14.2.1 Greiferansteuerung . . . . . . . . . . . . . . . 443 

2.14.2.2 Tool-Center-Point-Ansteuerung . . . . . . . . 444 

8


2.14.2.3 Hardware der Bildverarbeitungskette . . . . . 445 

2.14.2.4 Ausblick . . . . . . . . . . . . . . . . . . . . . 446 


2.14.3 Fertigstellung und Optimierung „Skizze Zeichen “ . . 448 

2.14.3.1 Umsetzung der Anforderungen . . . . . . . . 448 

2.14.3.2 Optimierungen für die Anforderungen . . . . 448 

2.14.3.3 Optimierungen der Bildaufnahme . . . . . . 450 

2.14.3.4 Verwendete Komponenten . . . . . . . . . . . 451 

2.14.3.5 Prozess Steuerung . . . . . . . . . . . . . . . . 452 

2.14.3.6 Ergebnis und Ausblick . . . . . . . . . . . . . 454 


3 Fazit 457 

4 Ausblick 461 

Literaturverzeichnis 464 

Glossar 465 

9

Abbildungsverzeichnis 

1.1 Roboter spielt Jenga, TU Braunschweig . . . . . . . . . . . . . 21 

1.2 Industrieroboter zeichnet eine Skizze . . . . . . . . . . . . . . 22 

1.3 Kinect der Firma Microsoft . . . . . . . . . . . . . . . . . . . . 26 

1.4 LeapMotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 

1.5 Hardwarebestandteile . . . . . . . . . . . . . . . . . . . . . . . 28 

1.6 Globaler Anwendungsfall . . . . . . . . . . . . . . . . . . . . . 30 

1.7 Skizze einer Aufnahme . . . . . . . . . . . . . . . . . . . . . . . 40 

1.8 Kalibrierung für Gestenerkennung . . . . . . . . . . . . . . . . 42 

1.9 Beispiel einer Kalibrierung . . . . . . . . . . . . . . . . . . . . . 43 

1.10 Initialisierung für Roboterarmsteuerung . . . . . . . . . . . . . 45 

1.11 Roboterarm bewegen . . . . . . . . . . . . . . . . . . . . . . . . 47 

1.12 Greifer ansteuern . . . . . . . . . . . . . . . . . . . . . . . . . . 49 

1.13 Kalibrierung für alternative Gestenerkennung . . . . . . . . . 50 

1.14 Beispiel einer Kalibrierung für alternative Gestenerkennung . 51 

1.15 Kalibrierung für Portraitaufnahme . . . . . . . . . . . . . . . . 53 

1.16 Portrait aufnehmen . . . . . . . . . . . . . . . . . . . . . . . . . 54 

1.17 Greifen eines Objekts, Anwendungsfall 1.2.3.2 . . . . . . . . . 59 

1.18 Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . 64 

2.1 Struktur eines Sprints . . . . . . . . . . . . . . . . . . . . . . . 65 

2.2 Steuerungsschichten . . . . . . . . . . . . . . . . . . . . . . . . 70 

2.3 Bewegungsrichtungen des Auges . . . . . . . . . . . . . . . . . 75 

2.4 TrackEye Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . 76 

2.5 Kamera DMK21F04 . . . . . . . . . . . . . . . . . . . . . . . . . 78 

2.6 Aufbauten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 

2.7 Raumbeleuchtung . . . . . . . . . . . . . . . . . . . . . . . . . . 80 

2.8 Kameraposition . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 

2.9 Infrarot-Scheinwerfer . . . . . . . . . . . . . . . . . . . . . . . . 81 

2.10 Reihenfolge und Prioritäten der Prozessoren . . . . . . . . . . 82 

2.11 Input Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 

2.12 Eye-Tracking Processor . . . . . . . . . . . . . . . . . . . . . . . 84 

2.13 Formen unterschiedlicher Augentemplates . . . . . . . . . . . 85 

2.14 Probleme beim Template Matching . . . . . . . . . . . . . . . . 85 

10

Abbildungsverzeichnis 10. Oktober 2013 

2.15 Reference Processor . . . . . . . . . . . . . . . . . . . . . . . . . 87 

2.16 Referenzpunktes . . . . . . . . . . . . . . . . . . . . . . . . . . 88 

2.17 Blob Tracking Processor . . . . . . . . . . . . . . . . . . . . . . 89 

2.18 Kalibrierungsbild um die Ecken des Anzeigefläche zu erkennen 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 

2.19 Bewegung der CoGs zwischen zwei Kalibrierungspunkten . . 92 

2.20 Quadrantenaufteilung zur Visualisierung . . . . . . . . . . . . 93 

2.21 Aufnahme des Eingangsbildes der ersten Messung . . . . . . 93 

2.22 Festgelegter Blickweg der ersten Messung . . . . . . . . . . . 94 

2.23 Aufnahme des Eingangsbildes der zweiten Messung . . . . . 96 

2.24 Probleme die durch das Tragen einer Brille entstehen . . . . . 98 

2.25 weitere mögliche Einteilungen zur Quadrantenbestimmung . 100 

2.26 Kamerabild vom GazeTracker . . . . . . . . . . . . . . . . . . . 100 

2.27 Aufbau der Kameraansteuerung . . . . . . . . . . . . . . . . . 103 

2.28 Signal Sequenz zur initialen Ansteuerung der Kamera . . . . 104 

2.29 Blockschaltbild des cam_data IP-Core . . . . . . . . . . . . . . 106 

2.30 Konfigurationmenü des cam_deserializer IP-Cores . . . . . . 107 

2.31 Blockschaltbild des cam_deserializer IP-Cores . . . . . . . . . 108 

2.32 Blockschaltbild des RGB565 zu RGB888 IP-Cores . . . . . . . 108 

2.33 Blockschaltbild des Cam-USB IP-Cores . . . . . . . . . . . . . 109 

2.34 Steuerungsschichten des Roboterarms (rot markiert = In diesem 

Sprint entwickelt) . . . . . . . . . . . . . . . . . . . . . . . . . . 113 

2.35 Kinematisches Modell des Roboarms . . . . . . . . . . . . . . 118 

2.36 Kalibrierung der Drehwinkel der Gelenke mit den Tasten auf 

dem FPGA-Board. . . . . . . . . . . . . . . . . . . . . . . . . . . 124 

2.37 Der TCP befindet sich im 3D-Raum. Der Winkel α wird geometrisch 

bestimmt. . . . . . . . . . . . . . . . . . . . . . . . . 126 

2.38 Winkeläquivalenz für die virtuelle Drehung. . . . . . . . . . . 126 

2.39 Nach der Drehung um die z-Achse befindet sich der TCP 

genau über der x-Achse. Der TCP ist im 2D-Raum . . . . . . . 127 

2.40 Fall 1: Kreis um TCP (grün) und Basis (schwarz) überlappen 

sich nicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 

2.41 Fall2: Kreis um TCP (grün) und Basis (schwarz) überlappen 

sich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 

2.42 Winkelberechnung aus den Ergebnispunkten . . . . . . . . . . 132 

2.43 Problem der Auswahl der korrekten Winkels . . . . . . . . . . 138 

2.44 Lösung der Auswahl der korrekten Winkels mittels Hilfswinkel 

(real r/virtuell v) . . . . . . . . . . . . . . . . . . . . . . . . . . 138 

2.45 Beispielbild: Probleme durch Extraktion des Hintergrundes . 141 

11


2.46 Beispielbild: Verfolgung der Hand mit Hilfe von Schwerpunkten 

innerhalb einer Kontur. . . . . . . . . . . . . . . . . . 142 

2.47 Bildverarbeitungskette: Verfolgung der Hand mit Hilfe von 

Schwerpunkten innerhalb einer Kontur . . . . . . . . . . . . . 143 

2.48 Aufbau des resultierenden Ergebnisses . . . . . . . . . . . . . 144 

2.49 Beispielbild: Kalibrierung des Systems auf die Gelenke des 

Akteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 

2.50 Beispielbild: Trennung der Kontur durch Reflekton des Lichtes 

am Klebeband . . . . . . . . . . . . . . . . . . . . . . . . . . 146 

2.51 Beispielbild: Zusammenfließen der Konturen durch Berührung147 

2.52 Bildverarbeitungskette: Verfolgung des Arms mit Hilfe von 

Posen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 

2.53 Beispielbild: Springen der Posen . . . . . . . . . . . . . . . . . 149 

2.54 Beispielbild: Berechnung der Winkel mit Hilfe des Schnittpunktes 

der Orthogonalen zu Phi . . . . . . . . . . . . . . . . . . . . 150 

2.55 Beispielbild: Verfolgung des Arms mit Hilfe von Posen . . . . 151 

2.56 Grafische Oberfläche für die Interaktion mit dem Skript . . . 154 

2.57 Verwischungseffekt bei schnellen Bewegungen durch die geringe 

Geschwindigkeit der WebCam . . . . . . . . . . . . . . . . . . 155 

2.58 Aufbau mit ImageBus Schalter IP-Core . . . . . . . . . . . . . 162 

2.59 Blockschaltbild des ImageBusSwitch IP-Cores . . . . . . . . . 163 

2.60 Blockschaltbild des xps_timer IP-Cores . . . . . . . . . . . . . 164 

2.61 Bilder von linker und rechter Kamera . . . . . . . . . . . . . . 170 

2.62 Blockschaltbild des Schwellwertfilters . . . . . . . . . . . . . . 172 

2.63 Blockschaltbild des RGB888 zu Graustufenwandler . . . . . . 173 

2.64 Testbilder rgb2grey_v1_00_a in AMiR Automation Toolbox, 

Quellbild (link oben), Ergebnis Toolbox (rechts oben), Ergebnis 

Hardware (links unten), Ergebnis modifizierter Toolbox 

Filter (rechts unten) . . . . . . . . . . . . . . . . . . . . . . . . . 174 

2.65 Blockschaltbild des Morphologiefilter . . . . . . . . . . . . . . 175 

2.66 Konfigurationsoberfläche des Morphologiefilter . . . . . . . . 176 

2.67 Blockdiagramm vom IP-Core hdmi_out . . . . . . . . . . . . . 177 

2.68 Blockdiagramm vom Video Frame Buffer Controller (VFBC) . 179 

2.69 VFBC: VGA Fenster in 1080p Frame . . . . . . . . . . . . . . . 180 

2.70 Aufname mit Autokorrekturfunktionen bei dunklen Lichtverhältnissen 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 

2.71 Aufname ohne Autokorrekturfunktionen bei dunklen Lichtverhältnissen 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 

2.72 Aufname ohne Autokorrekturfunktionen bei durchschnittlichen 

Lichtverhältnissen . . . . . . . . . . . . . . . . . . . . . . . . . . 186 

12


2.73 Aufname ohne Autokorrekturfunktionen bei durchschnittlichen 

Lichtverhältnissen . . . . . . . . . . . . . . . . . . . . . . . . . . 187 

2.74 OLVIS-Bildverarbeitungskette zum Ansatz 1 . . . . . . . . . . 199 

2.75 Ergebnis der OLVIS-Bildverarbeitungskette zum Ansatz 1 . . 200 

2.76 OLVIS-Bildverarbeitungskette zum Ansatz 2 . . . . . . . . . . 201 

2.77 Ausgaben der OLVIS-Bildverarbeitungskette zum Ansatz 2 . 202 

2.78 Blockschaltbild des Servo IP-Core . . . . . . . . . . . . . . . . 203 

2.79 Servo Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 

2.80 Zustandsautomat im Servo IP-Core . . . . . . . . . . . . . . . 204 

2.81 Blockschaltbild des USB Driver IP-Core . . . . . . . . . . . . . 207 

2.82 Blockschaltbild des Cam USB IP-Core . . . . . . . . . . . . . . 209 

2.83 Testumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 

2.84 Skizze zur Tiefenberechnung . . . . . . . . . . . . . . . . . . . 217 



2.87 Bildverarbeitungskette mit Binary Large Object-Erkennung 

(ohne Morphologiefilter) . . . . . . . . . . . . . . . . . . . . . . 219 

2.88 Bildverarbeitungskette mit Morphologiefilter . . . . . . . . . . 220 

2.89 Bildverarbeitungskette mit mehreren Morphologiefiltern . . . 221 

2.90 Stereobildpaar der Armbinde (Bild manueller Drehung beider 

Bilder) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 

2.91 Zwei rote Armbinden mit unterschiedlicher Tiefe . . . . . . . 223 

2.92 Stereobilder mit blauer und roter Armbinde ohne automatische 

Helligkeitsanpassung . . . . . . . . . . . . . . . . . . . . 223 

2.93 Stereobilder mit blauer und roter Armbinde mit automatische 

Helligkeitsanpassung . . . . . . . . . . . . . . . . . . . . . 224 

2.94 Bildverarbeitungskette mit heller grüner Armbinde in Form 

eines angemalten Papiers . . . . . . . . . . . . . . . . . . . . . 225 

2.95 Bildverarbeitungskette mit grüner Armbinde und mehreren 

Morphologiefiltern . . . . . . . . . . . . . . . . . . . . . . . . . 226 

2.96 Testbilder mit rückwärtiger Beleuchtung und BLOB-Erkennung229 

2.97 Fehlerbild mit voller Kameraauflösung . . . . . . . . . . . . . 230 

2.98 Abstandsmessung bei zwei Armbinden . . . . . . . . . . . . . 231 

2.99 Beispielstereobild. . . . . . . . . . . . . . . . . . . . . . . . . . . 233 

2.100Beispieltiefenbild zu Abbildung 2.99. . . . . . . . . . . . . . . 233 

2.101Tiefenbild zu Abbildung 2.90 . . . . . . . . . . . . . . . . . . . 234 

2.102Aufnahme eines Bildes durch eine der beiden Kameras. Verhältnis 

von Breite auf dem Sensor zur Brennweite verhält 

sich wie das Verhältnis der realen Breite zur realen Tiefe im 

Raum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 

13


2.103Blockschaltbild des imagebus_to_memory IP-Core . . . . . . 239 

2.104VFBC Write Timing . . . . . . . . . . . . . . . . . . . . . . . . . 240 

2.105Zustandsautomat des image_bus_switch IP-Cores . . . . . . . 242 

2.106Blockschaltbild des memory_to_usb IP-Core . . . . . . . . . . 243 

2.107VFBC Read Timing . . . . . . . . . . . . . . . . . . . . . . . . . 244 

2.108Timing der Lese-/Schreiboperationen . . . . . . . . . . . . . . 245 

2.109Zustandsautomat zum ersten Ansatz des IPCores . . . . . . . 246 

2.110Auf dem FPGA realisierte Bildverarbeitungskette mit IP-Cores248 

2.111Schematische Darstellung des aufgezeichneten Arms und der 

berechneten Winkel . . . . . . . . . . . . . . . . . . . . . . . . . 249 

2.112Ergebnisaufnahme mit der VmodCamBlob Erweiterung für 

die OFFIS-Automation-Toolbox . . . . . . . . . . . . . . . . . . 250 

2.113Schwellwertfilter mit Anbindung an den Microblaze . . . . . 250 

2.114IP-Core ImageBusConverter mit 24 Bit RGB Ausgangssignal . 252 

2.115IP-Core ImageBusConverter Signalkonvertierung . . . . . . . 252 

2.116Erkannte Regionen in einem Bild mit ihren eingezeichneten 

Schwerpunkten . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 

2.117Vereinfachter Ablauf der Unterbrechungsroutine . . . . . . . . 254 

2.118Mögliche Lage von drei Punkten zueinander . . . . . . . . . . 256 

2.119Visualisierung der Gelenkpositionen durch die VmodCam- 

Blob Erweiterung . . . . . . . . . . . . . . . . . . . . . . . . . . 257 

2.120Hand in farbigem Handschuh. . . . . . . . . . . . . . . . . . . 264 

2.121Hand-Erkennung . . . . . . . . . . . . . . . . . . . . . . . . . . 265 

2.122OLVIS Bildverarbeitungskette . . . . . . . . . . . . . . . . . . . 268 

2.123Erkennung des Schließzustandes der Hand mittels Markierungen 

an den Fingerkuppen von Zeigefinger und Daumen . . . 270 

2.124Blockschaltbild des First in First out (FIFO)-Very High Speed 

Integrated Hardware Description Language (VHDL)-Modul . 286 

2.125Blockschaltbild des ImageBus-Overlay-IP-Core . . . . . . . . . 287 

2.126Schematischer Aufbau des ImageBus-Overlay-IP-Core . . . . 287 

2.127Funktionsweise des pixelSkipping IP-Cores . . . . . . . . . . . 302 

2.128Blockschaltbild des pixelSkipping IP-Cores . . . . . . . . . . . 303 

2.129Bildverarbeitungskette für zwei Kamerabildströme . . . . . . 304 

2.130Modell des Industrieroboterarms KUKA KR5 . . . . . . . . . 307 

2.131Modell des Industrieroboterarms Puma . . . . . . . . . . . . . 307 

2.132Pick & Place Roboter der Fa. SCARA . . . . . . . . . . . . . . 308 

2.133Modell des Hobby Roboterarms Oomlout Thingiverse . . . . 309 

2.134Schachbrett der Standard-Größe innerhalb des Arbeitsbereiches 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 

2.135Arbeitsbereich des Roboterarms . . . . . . . . . . . . . . . . . 312 

14


2.136Arbeitsbereich des Roboterarms . . . . . . . . . . . . . . . . . 313 

2.137Drehmoment (M) . . . . . . . . . . . . . . . . . . . . . . . . . . 315 

2.138Berechnung des Drehmomentes für den Servomotor G 2 . . . 316 

2.139Servo-Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 

2.140Greifervarianten . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 

2.141Kinematische Konfiguration des neuen Roboarms . . . . . . . 323 

2.142Ausrichtung der Arbeitsbereiche der Servos . . . . . . . . . . 324 

2.143Längen des Greifers und des Base . . . . . . . . . . . . . . . . 324 

2.144Minimal benötigte Länge des Teilarmes. Sicht von oben . . . 325 

2.145Längen der restlichen Verbindungsstücke . . . . . . . . . . . . 326 

2.146Berechnung der Drehmomente . . . . . . . . . . . . . . . . . . 328 

2.147Modell der Gelenkgenkonfiguration mit Längen und Gewichten 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329 

2.148Konfiguration des alten Roboterarms . . . . . . . . . . . . . . 330 

2.149Servovarianten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 

2.150Kinematische Konfiguration Scara . . . . . . . . . . . . . . . . 333 

2.151Funktion der Rampen im Servo-IP-Core . . . . . . . . . . . . . 334 

2.152Blockschaltbild Servo-IP-Core . . . . . . . . . . . . . . . . . . . 335 

2.153Lineare Interpolation eines Vektors . . . . . . . . . . . . . . . . 338 

2.154Berechnung der minimalen Schrittweite . . . . . . . . . . . . . 340 

2.155Aufbau des vorläufigen Demonstrators . . . . . . . . . . . . . 345 

2.156erste Zeichnungen . . . . . . . . . . . . . . . . . . . . . . . . . 346 

2.157Arbeitsbereich nach neuen Strategiewechsel . . . . . . . . . . 350 

2.158Quadrat ohne Strategiewechsel . . . . . . . . . . . . . . . . . . 350 

2.159Quadrat über Eckpunkte ohne Interpolation der Trajektorie . 351 

2.160Koordinaten des Arbeitsbereichs . . . . . . . . . . . . . . . . . 353 

2.161Virtuelle Punkte am Benutzer . . . . . . . . . . . . . . . . . . . 355 

2.162Ebene und Winkel . . . . . . . . . . . . . . . . . . . . . . . . . 355 

2.163Angewinkelter Arm . . . . . . . . . . . . . . . . . . . . . . . . 357 

2.164Gestreckter Arm . . . . . . . . . . . . . . . . . . . . . . . . . . . 357 

2.165Blockschaltbild des geänderten cam_bootloader . . . . . . . . 364 

2.166Kinematische Konfiguration des neuen Roboarms . . . . . . . 380 

2.167Modell des neuen Roboarm in Open Robotics Automation 

Virtual Environment (OpenRAVE) . . . . . . . . . . . . . . . . 381 

2.168Arbeitsfluss für IKfast-Generierung . . . . . . . . . . . . . . . 384 

2.169Aufbau der Verwendeten Hardwarekomponenten . . . . . . . 390 

2.170Falsche Berechnung des Ellenbogenwinkels . . . . . . . . . . . 397 

2.171Korrekte Berechnung des Ellenbogenwinkels . . . . . . . . . . 398 

2.172Profiling im Board Support Package Settings aktivieren . . . . 400 

2.173Compileroption für Profiling setzen . . . . . . . . . . . . . . . 400 

15


2.174Konfiguration des Profilings . . . . . . . . . . . . . . . . . . . . 401 

2.175Farbbild und resultierende schematische Darstellung, als Anforderung 

an die Vektorisierung . . . . . . . . . . . . . . . . . 412 

2.176Zwischenergebnis der Bildverarbeitungskette . . . . . . . . . . 413 

2.177die gesammte Bildverarbeitungskette . . . . . . . . . . . . . . 414 

2.178Farbbild und resultierende schematische Darstellung von einer 

Testperson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415 

2.179Farbbild und resultierende schematische Darstellung von einer 

weiteren Testperson . . . . . . . . . . . . . . . . . . . . . . . 415 

2.180Farbbild, Zwischenschritt und resultierende schematische vektorisierte 

Darstellung . . . . . . . . . . . . . . . . . . . . . . . . 416 

2.181Darstellung des generierten Gcodes . . . . . . . . . . . . . . . 416 

2.182Bildausschnitt und die Komplexität der Pfade aus der generierten 

Vektorgrafik . . . . . . . . . . . . . . . . . . . . . . . . . 417 

2.183Base Seiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419 

2.184Base Axialverbindung zum zweiten Link . . . . . . . . . . . . 420 

2.185Zweiter Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421 

2.186Dritter Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422 

2.187Vierter Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423 

2.188Axialverbindung . . . . . . . . . . . . . . . . . . . . . . . . . . 424 

2.189Fünfter Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425 

2.190Differential . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425 

2.191Kugellager-Halterung . . . . . . . . . . . . . . . . . . . . . . . 426 

2.192Gripper for Micro Robot Arm . . . . . . . . . . . . . . . . . . . 426 

2.193Gesamter Arm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427 

2.194einzelne Abschnitte des Roboterarms . . . . . . . . . . . . . . 427 

2.195Optimierungsdiagramm . . . . . . . . . . . . . . . . . . . . . . 434 

2.196Handgesten zur Ansteuerung des Greifers . . . . . . . . . . . 443 

2.197Steuerung der Tool-Center-Point-Position . . . . . . . . . . . . 444 

2.198Bildverarbeitungskette für die Gestensteuerung . . . . . . . . 446 

2.199Bildverarbeitungsketten die verwendet wurden . . . . . . . . 449 

2.200Links vor und rechts nach der Optimierung der Bildverarbeitungskette 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 450 

2.201Aufbau der Benutzeroberläche für den Benutzer . . . . . . . . 451 

2.202Aufbau des Demonstrator Skizze zeichnen . . . . . . . . . . . . 452 

2.203Programmablauf der Hauptfuntion . . . . . . . . . . . . . . . 453 

2.204Links ist das Ausgangsbild gezeigt, und in der Mitte und 

Rechts die Roboterumsetzung mit verschiedenen Stiften . . . 455 

16

Tabellenverzeichnis 

1.1 Teambetreuer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

1.2 Teammitglieder . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 

1.3 Anwendungsfallschablone - Armbewegung nachahmen . . . 33 

1.4 Anwendungsfallschablone - Objekt bewegen . . . . . . . . . . 36 

1.5 Anwendungsfallschablone - Steuerung durch alternative Gesten 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 

1.6 Anwendungsfallschablone - Skizze zeichnen . . . . . . . . . . 42 

1.7 Anwendungsfallschablone - Kalibrierung für Gestenerkennung 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 

1.8 Anwendungsfallschablone - Initialisierung für Roboterarmsteuern 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 

1.9 Anwendungsfallschablone - Roboterarm bewegen . . . . . . . 48 

1.10 Anwendungsfallschablone - Greifer ansteuern . . . . . . . . . 50 

1.11 Anwendungsfallschablone - Kalibrierung für alternative Gestensteuerung 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 

1.12 Anwendungsfallschablone - Kalibrierung für Portraitaufnahme 54 

1.13 Anwendungsfallschablone - Portrait aufnehmen . . . . . . . . 55 

1.14 Risikoanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 

1.15 Eintrittswahrscheinlichkeit . . . . . . . . . . . . . . . . . . . . . 62 

1.16 Wirkung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 

1.17 Risiko . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 

2.1 Messwerte der Erkennungsrate des ersten Ansatzes . . . . . . 95 

2.2 Messwerte der Erkennungsrate des zweiten Ansatzes . . . . . 95 

2.3 Messwerte der Quadrantenbestimmung des ersten Ansatzes . 96 

2.4 Messwerte der Quadrantenstabilität von Ansatz 2 . . . . . . . 97 

2.5 VFBC Steuerpaket . . . . . . . . . . . . . . . . . . . . . . . . . . 180 

2.6 Parameter für eine Auflösung von 1280x720 im Speicherbereich 

0x00000000. . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 

2.7 Image Bus Overlay PLB Register . . . . . . . . . . . . . . . . . 288 

2.8 Servospezifikationen der Fa. Dago Metall . . . . . . . . . . . . 317 

2.9 Servospezifikationen der Fa. Hitec . . . . . . . . . . . . . . . . 319 

2.10 Servospezifikationen der Fa. Hitec . . . . . . . . . . . . . . . . 319 

17

Tabellenverzeichnis 10. Oktober 2013 

2.11 Konnektor zwischen FPGA-Board und Servoplatine . . . . . . 347 

2.12 Laufzeitmessung Übersicht . . . . . . . . . . . . . . . . . . . . 404 

2.13 Laufzeitmessung Sortieren . . . . . . . . . . . . . . . . . . . . . 405 

2.14 Laufzeitmessung Tracking ohne Armbewegung . . . . . . . . 405 

2.15 Laufzeitmessung Tracking mit Armbewegung . . . . . . . . . 405 

2.16 BLOB-Treiber . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406 

2.17 Laufzeit des Image-Overlays . . . . . . . . . . . . . . . . . . . 406 

2.18 Laufzeit der Winkelberechnung . . . . . . . . . . . . . . . . . . 406 

2.19 Laufzeitmessung nach Treiberoptimierung . . . . . . . . . . . 434 

2.20 Laufzeitmessung nach erster Overlayoptimierung . . . . . . . 435 

2.21 Laufzeitmessung nach zweiter Overlayoptimierung . . . . . . 435 

2.22 Laufzeitmessung Tracking ohne Armbewegungg . . . . . . . 436 

2.23 Laufzeitmessung nach Trackingoptimierung . . . . . . . . . . 436 

2.24 Laufzeitmessung nach Array und Vektor Optimierung . . . . 437 

2.25 Laufzeitmessung nach inline-Optimierung . . . . . . . . . . . 437 

2.26 Laufzeitmessung im Releasemodus . . . . . . . . . . . . . . . 438 

2.27 Beobachtete Reaktionszeit . . . . . . . . . . . . . . . . . . . . . 438 

18

Quellcodeverzeichnis 

2.1 Formel zur Bestimmung von M & N für WolframAlpha . . . 166 

19

1 Lastenheft 

Dieses Kapitel beschreibt die Gesamtheit der Forderungen des Auftraggebers 

an die Lieferungen und Leistungen des Auftragnehmers. Es enthält 

die Motivation mit daraus folgender Zielsetzung, Anforderungserhebung, 

Risikoanalyse und den angestrebten Entwicklungszyklus. Weiter wird die 

Systemarchitektur beschrieben und der Umfang der Lieferung definiert. 

1.1 Einleitung 

Heutige automatisierte Anlagen werden zunehmend durch Kamerasysteme 

gesteuert oder mit deren Hilfe überwacht. Seien es Sicherheitssysteme, 

Industrieanlagen, Verkehrsüberwachung oder die Konsumerelektronik, 

in allen diesen Bereichen sind Kameralösungen gegenwärtig nicht 

mehr weg zu denken. 

Die Verwendung von auf Kameras basierenden Lösungen erleichtert die 

Bedienung von Robotersystemen in vielen Aspekten. Ein Roboterarm könnte 

anstelle eines menschlichen Arms in gefährlichen Umgebungen, z.B. 

bei der Entschärfung von Sprengstoffen eingesetzt werden. Darüber hinaus 

kann ein Roboterarm als Alltagshilfe für Menschen dienen, welche nur 

über einen oder keinen Arm verfügen. 

Zwar kann hier auch ein durch mechanische oder elektronische Kontrolle 

gesteuertes System gewählt werden, jedoch ist die Nachahmung eines Roboters 

der vom Benutzer ausgeführten Bewegungen einfacher und intuitiver. 

Die Intuitivität ist dadurch gegeben, dass das System genau die Bewegungen 

des Benutzers ausführt. Im Rahmen der Projektgruppe RoboArm 

der Universität Oldenburg wird ein System aus kamerabasierter Raumwahrnehmung, 

eingebetteter Steuerung sowie einem Roboterarm zur Nachahmung 

von menschlichen Bewegungen entwickelt. 

1.1.1 Motivation 

Die Möglichkeiten eines Systems aus Roboterarm, 3D-Kamera und eingebetteter 

Bildverarbeitung sind vielfältig. Eine direkte Steuerung des Ro- 

20

Kapitel 1. Lastenheft 10. Oktober 2013 

boterarmes kann zum Beispiel durch die Nachahmung des menschlichen 

Armes erzielt werden. Es kann außerdem eine Hilfestellung für körperlich 

beeinträchtigte Personen sein. Für solche Menschen wäre eine Anwendung 

möglich, um einen Telefonhörer aufzunehmen. Eine weitere Möglichkeit 

wäre der Einsatz des Roboterarmes als Hilfe beim Anziehen. Natürlich 

sind auch weitere Szenarien im täglichen Leben denkbar, in denen ein 

teleoperierter Roboterarm eine Hilfe sein könnte. 

Diese Szenarien erfordern jedoch, dass der Roboter auch durch andere 

Gesten als denen des menschlichen Armes gesteuert werden kann, da es 

auch Menschen gibt, die keinen Arm zur Steuerung zur Verfügung haben. 

Eine solche Steuerung muss keine direkte Nachahmung sein, sondern eine 

Interpretation. Denkbar wären hier Bewegungen des Kopfes oder der Augen 

zu verfolgen. 

Abbildung 1.1: Roboter spielt Jenga, TU Braunschweig 1 

Eine weitere Anwendung eines solchen Systems könnte z.B. spielerischer 

Natur sein, wie in der Abb. 1.1 dargestellt ist. Dabei wird der Roboter 

verwendet, um in Spielen wie Jenga oder Mikado gezielt die Spielsteine zu 

greifen und abzusetzen. 

Bei den bisher genannten Szenarien ist die exakte Position der Armgelenke 

nicht immer relevant. Dies ändert sich jedoch, sobald Armbewegun- 

1 Informationsdienst Wissenschaft, Die TU Braunschweig auf der Hannover Messe, 

http://www.idw-online.de/pages/de/newsimage?id=16541&size=screen, letzter Zugriff 

30.11.2012 

21


gen nachgeahmt werden sollen. Beispielsweise bei der Führung des Armes 

zwischen verschiedenen Hindernissen hindurch ist dies von Bedeutung. 

Eine weitere Möglichkeit wäre ein Szenario, in dem der Roboterarm für 

die Zeichnung einer Skizze, wie in Abb. 1.2, verwendet wird. Eine solche 

Skizze kann auch automatisch gezeichnet werden, indem das Kamerasystem 

ein Bild, der vor der Kamera stehenden Person, aufnimmt und dieses 

zu einer Skizze umrechnet. Die Skizze wird dann vom Roboterarm auf eine 

Oberfläche übertragen. 

In der Industrie könnte dieses System verwendet werden, um die Position 

und Ausrichtung eines zu verarbeitenden Werkstücks gegebenenfalls zu 

korrigieren. Hierbei wird dieses durch das 3D-Kamerasystem wahrgenommen 

und mit einem Soll-Muster verglichen. Sollten die Position und Ausrichtung 

des Werkstücks vom Sollwert abweichen, wird es durch den Roboter 

in die richtige Stellung versetzt. 

Abbildung 1.2: Industrieroboter zeichnet eine Skizze 2 

Damit die aufgeführten Anwendungen schneller und kostengünstiger realisiert 

werden können als bisherige Produkte, bietet sich ein eingebettetes 

System an. Das heißt, dass die Bildverarbeitung und die Robotersteuerung 

in Hardware umgesetzt werden. Durch den Einsatz von Hardware 

ist eine Bildverarbeitung gegenüber einer Softwarelösung in der Regel 

um ein Vielfaches schneller. Dies liegt darin begründet, dass es der Hardware 

möglich ist Berechnungen ohne Speicherzugriff nacheinander und 

/ oder parallel zueinander durchzuführen. Auch kann bei einer modularen 

Lösung schnell Hardware ausgetauscht werden, um verschiedenen 

2 Materialsgate, Robotik Artikel, http://www.materialsgate.de/de/mnews/9053/Robotik, 

letzter Zugriff 30.11.2012 

22


Anwendungsgebieten gerecht zu werden. Es können, je nach Szenario, unterschiedliche 

Module in Form von Filtern benutzt werden. 

Im Vergleich zu industriellen Robotersystemen wird das im Rahmen der 

Projektgruppe entwickelte System sehr kostengünstig und einfach gehalten 

sein. Dies ist dadurch begründet, dass Komponenten verwendet werden, 

welche einem breitem Publikum zur Verfügung stehen und von jeder 

Privatperson im Handel erworben werden können. Bei dem Roboterarm 

handelt es sich um einen Arexx der nur einen Bruchteil eines Industrieroboters 

kostet. Jedoch müssen dabei die Grenzen solcher Komponenten in 

Betracht gezogen werden, sodass z.B. das Gewicht der zu handhabenden 

Objekte den geringen Maximalwert nicht überschreitet. 

Im Folgenden werden die Ziele der Projektgruppe ausführlicher dargestellt. 

Im Abschnitt 1.2 werden diese durch die entsprechenden Anwendungsfälle 

präzisiert. 

1.1.2 Zielsetzung 

Die im Abschnitt 1.1.1 aufgeführten Szenarien stellen die Vorteile und 

Möglichkeiten der Anwendung einer hardware- und kamerabasierten Robotersteuerung 

dar. Das bedeutet, dass die Informationen über die Umwelt 

über ein Kamerasystem aufgenommen werden. Diese Daten werden dann, 

je nach Szenario, mit Hilfe von Software oder Hardware verarbeitet. Außerdem 

wurde die Möglichkeit der Realisierung durch günstige Komponenten 

dargestellt. 

Das Ziel der Projektgruppe RoboArm ist es, ein kamerabasiertes Echtzeitsystem 

zur Erfassung menschlicher Gesten und Merkmale zu realisieren. 

Ein solches System wird, anhand des zur Verfügung gestellten Roboterarms, 

demonstrativ vorgestellt werden. 

Der Schwerpunkt liegt dabei auf der Umsetzung des Echtzeitsystems. Dieses 

liefert Ansteuerungssignale, sodass sich der Roboterarm entsprechend des 

aktuellen Szenarios, bewegt. Bei bestimmten Szenarien darf ein nicht echtzeitfähiges 

System hinzugenommen werden. 

Das Echtzeitsystem muss auf den vorgegebenen Hardwarekomponenten 

aufbauen, siehe Unterabschnitt 1.1.6. Aus diesem Grund werden aus den 

im Unterabschnitt 1.1.1 vorgestellten Szenarien einige ausgewählt, die sich 

mit der gegebenen Technik realisieren lassen. Somit können Einsätze demonstriert 

werden, die auch auf weitere Szenarien übertragbar sind. 

23


1.1.2.1 Szenarien 

Das erste zu realisierende Szenario ist die Nachahmung der Haltung und Bewegung 

des menschlichen Arms. Dies spiegelt die Führung des Roboterarmes 

durch die Hindernisse und das Greifen des Objektes aus der gewünschten 

Richtung wieder. 

Das zweite Szenario geht aus dem Fall des Aufnehmens und Bereitstellens 

eines Telefonhörers hervor. Das Gewicht eines Telefonhörers überschreitet 

die maximal tragbare Last des Roboterarms. Der zur Verfügung gestellte 

Greifer ist zudem kleiner als ein Telefonhörer. Das Szenario wird daher auf 

das Aufheben, Bewegen und Ablegen eines für den Roboterarm greif- und 

tragbaren Objekts reduziert. Das Szenario Objekt bewegen spiegelt den Fall 

des Jenga oder Mikado spielens wieder. Hier ist das präzise Greifen eines 

Objektes von Bedeutung. 

Das dritte Szenario realisiert das Zeichnen der Skizze vom Gesicht einer 

Person. Der Fall Skizze zeichnen spiegelt sich hier wieder. Dieses wird nicht 

in Echtzeit erfolgen, wobei hier jedoch am stärksten auf die Ansteuerung 

des Roboterarms gesetzt wird. Das Zeichnen der Skizze durch die Führung 

des Roboterarms wird daher durch komplizierte Steuerungsalgorithmen 

realisiert. 

Das vierte Szenario spiegelt die Hilfestellung für körperlich beeinträchtigte 

Personen wider. Wegen der Größe und den Freiheitsgraden, über welche 

der Roboterarm verfügt, ist es nicht möglich eine Hilfestellung beim Anziehen 

zu realisieren. Dieses Szenario wird daher auf die Steuerung durch 

alternative Gesten reduziert. 

Im Folgenden werden die Gruppenmitglieder vorgestellt, die die beschriebenen 

Ziele realisieren werden. Auch werden die Betreuer der Projektgruppe 

vorgestellt. 

24


1.1.3 Vorstellung der Gruppe 

Im Rahmen der Projektgruppenarbeit an der Universität Oldenburg in der 

Abteilung Mikrorobotik und Regelungstechnik (AMiR) hat sich im Wintersemester 

2012/13 die Gruppe RoboArm zusammengeschlossen. Das Projekt 

wird betreut durch folgende Personen. 

Name 

Claas Diederichs 

Tobias Tiemerding 

E-Mail-Adresse 

claas.diederichs@uni-oldenburg.de 

tobias.tiemerding@uni-oldenburg.de 

Tabelle 1.1: Teambetreuer 

Die Gruppe RoboArm besteht aus den folgenden studentischen Mitgliedern. 

Name 

Vitaliy Beguchiy 

Fabian Diefenbach 

Patrick Elfert 

Peter Gewald 

Markus Müller 

Sebastian Reichel 

Tobias Schüürhuis 

Matthias Stasch 

E-Mail-Adresse 

vitaliy.beguchiy@uni-oldenburg.de 

fabian.diefenbach@uni-oldenburg.de 

patrick.elfert@uni-oldenburg.de 

peter.gewald@uni-oldenburg.de 

markus.mueller@uni-oldenburg.de 

sebastian.reichel@uni-oldenburg.de 

tobias.schueuerhuis@uni-oldenburg.de 

matthias.stasch@uni-oldenburg.de 

Tabelle 1.2: Teammitglieder 

1.1.4 Darstellung aktueller Technologien 

Es gibt heute bereits einige Produkte, welche kamerabasiert eine Umgebung 

dreidimensional untersuchen sowie gegebenenfalls zeitliche Änderungen 

wahrnehmen und verarbeiten. Ein paar derartige 3D-Kamerasysteme 

sind z.B. die Kinect 3 für die XBox 360, das Asus Xtion 4 und die LeapMotion 

5 als eine Erweiterung für den Personal Computer (PC). 

Die Kinect, dargestellt in Abb. 1.3, ist ein zusätzliches Eingabegerät für 

die Spielekonsole XBox 360 der Firma Microsoft und dient primär der 

Unterhaltung. Sie besteht aus zwei Kameras und einer Infrarotlichtquelle. 

Diese strahlt ein Raster aus, das von den Kameras aufgezeichnet wird. Die 

Spielekonsole setzt die Aufzeichnungen in Bewegungsinformationen um. 

3 Produktseite der Kinect für die XBox 360 - http://www.xbox.com/de-DE/Kinect letzter 

Zugriff 28.11.2012 

4 Asus Xtion Produktseite - http://goo.gl/wKUzG letzter Zugriff 28.11.2012 

5 Leap Motion Artikel - https://leapmotion.com letzter Zugriff 28.11.2012 

25


Abbildung 1.3: Kinect der Firma Microsoft 6 

Ein ähnliches Produkt ist die LeapMotion, welche als Eingabegerät für 

herkömmliche PCs dient und auf dem Schreibtisch positioniert wird, wie 

in Abb. 1.4. Der Fokus der zwei Kameras ist dabei auf die Hände gerichtet. 

Die Kameras nehmen das Infrarotlicht der Emitter auf, wobei die LeapMotion 

drei Emitter einsetzt, um die Genauigkeit der Messung zu verbessern. 

Bisher existiert die LeapMotion nur als Prototyp, soll jedoch ab 2013 erhältlich 

sein. 

Abbildung 1.4: LeapMotion 7 

6 Produktseite der Kinect für die XBox 360 - http://www.xbox.com/de-DE/Kinect letzter 

Zugriff 28.11.2012 

7 Leap Motion Artikel - https://leapmotion.com letzter Zugriff 28.11.2012 

26


Das Asus Xtion ist technisch vergleichbar mit der Microsoft Kinect, jedoch 

ausschließlich an PCs nutzbar und nicht für den Konsumermarkt vorgesehen. 

1.1.5 Abgrenzung des Systems 

Das von der Projektgruppe zu entwickelnde System wird ein Field Programmable 

Gate Array (FPGA) einsetzen, um die Informations- und Bildverarbeitung 

zu realisieren und somit die Algorithmen in Hardware umzusetzen. 

Dies ermöglicht eine schnellere Verarbeitung von Daten gegenüber 

einer auf Software basierenden Realisierung. Begründet ist dies durch die 

Eigenschaften einer Realisierung in Hardware. Hardware bietet den Vorteil, 

dass verschiedene Prozesse parallel zueinander ausgeführt werden können, 

wie im Unterabschnitt 1.1.1 angeführt wurde. Somit können zum 

Beispiel mehrere Bildverarbeitungsalgorithmen zur gleichen Zeit arbeiten. 

Dies ist zum Beispiel bei der Stereoskopie erforderlich. Hier wird jeweils 

eine Bildverarbeitungskette pro Kamera benötigt. Durch die Hardware ist 

es möglich, dass diese parallel zueinander laufen können. Die Stereoskopie 

wird benötigt, um die Tiefeninformationen zu erhalten, welche z.B. für die 

Verfolgung des Arms in der dritten Ebene von Bedeutung ist. 

Ein weiterer Vorteil, den Hardware bietet, ist die Geschwindigkeit der 

Berechnung, da spezialisierte Schaltungen verwendet werden. Ebenfalls ist 

es möglich einen Zuwachs an Performanz zu erhalten, indem man den 

Datenstrom ohne Zwischenspeicherung der Daten an den nächsten IP-Core 

gibt. 

Ebenfalls ist es mit der Lösung der Projektgruppe möglich Hardwaremodule, 

wie zum Beispiel einen Roboterarm, direkt anzusteuern ohne dafür 

einen PC oder ähnliches einzusetzen. Weiterhin ist hervorzuheben, dass, 

bei Bedarf, die Kamera oder auch der Roboterarm gegen andere Module 

ausgetauscht werden können, um gegebenenfalls das System zu optimieren. 

Alle in Unterabschnitt 1.1.4 genannten Lösungen bieten ihre Informationen 

nur über eine Universal Serial Bus (USB) Schnittstelle an. Das 

von der Projektgruppe eingesetzte Kameramodul besitzt eine Very-High- 

Density Cable Interconnect (VHDCI) Schnittstelle und wird über das I 2 C- 

Protokoll angesprochen. Das System ist zwar stationär, jedoch durch die 

Größe seiner Komponenten dennoch portabel. 

Das resultierende Produkt stellt einen Prototypen da, welcher einige Möglichkeiten 

aufzeigt, die aus der Verbindung eines Roboterarms und hardwarebasierender 

Bildverarbeitung von dreidimensionalen Bildinformationen hervorgehen. 

27


1.1.6 Beschreibung der Ausgangslage 

Für den Aufbau wird die Entwicklungsplatine ATLYS der Firma Digilent 

eingesetzt. Dieses Entwicklungsboard besitzt einen FPGA der Firma Xilinx 

aus der Baureihe Spartan-6, welcher die Signale des Kameramoduls 

empfängt und verarbeitet. Die Verarbeitung erfolgt durch IP-Cores, in denen 

die Algortihmen in Hardware implementiert sind. Bei der Entwicklung 

der Algorithmen wird die OFFIS-Automation-Toolbox für den Softwareprototypenentwurf 

eingesetzt. Um die Algorithmen in Hardware zu implementieren 

und zu Testen wird neben dem ATLYS, die Nexus 2 Entwicklungsplatine 

eingesetzt. Da dieses Board nicht über eine VHDCI-Schnittstelle 

verfügt, wird eine virtuelle Kamera eingesetzt. Diese ermöglicht es über die 

OFFIS-Automation-Toolbox Bilder an das Nexus 2 zu übertragen. Bei dem 

Kameramodul handelt es sich ebenfalls um ein Produkt der Firma Digilent 

mit zwei unabhängigen 2 Megapixel Bildsensoren. Die Bilder werden 

mittels des FPGA in Bewegungen auf eine Roboterarm umgesetzt, welcher 

einen eingeschränkten drei dimensionalen Raum mit seinem Endeffektor 

erreichen kann. Der Roboterarm ist von der Firma AREXX und besitzt 

die Produktbezeichnung Robot ARM Pro (RA1-Pro). Um Bewegungen 

umzusetzen steuert der FPGA sechs Servos über Pulspositionsmodulation 

an. Eine schematische Darstellung der einzelnen Hardwarekomponenten 

findet sich im Abb. 1.5. 

Abbildung 1.5: Hardwarebestandteile 

28


1.2 Anforderungsdenition 

Die Anforderungsdefinition präzisiert die in der Zielsetzung festgelegten 

Szenarien. Aus diesen Szenarien ergeben sich durch Verallgemeinerung die 

im Folgenden behandelten Anwendungsfälle. Diese werden jeweils durch 

ein Anwendungsfalldiagramm, eine textuelle Beschreibung und eine Anwendungsfallschablone 

beschrieben. Aus den verschiedenen Darstellungen 

der unterschiedlichen Anwendungsfälle werden die funktionalen und 

nichtfunktionalen Anforderungen erhoben. 

Funktionale Anforderungen beschreiben dabei das, was das System leisten 

soll. Die nichtfunktionalen Anforderungen hingegen geben die qualitativen 

Eigenschaften des Systems an. Diese werden in den Unterabschnitten für 

die funktionalen Anforderungen 1.2.5 und nicht funktionalen Anforderungen 

1.2.6 aufgeführt. 

1.2.1 Anwendungsfälle 

In diesem Unterabschnitt werden die ausgewählten Anwendungsfälle beschrieben. 

Hierzu wird zunächst eine grafische Darstellung des jeweiligen 

Anwendungsfalles gezeigt und durch eine textuelle Beschreibung erläutert. 

Für die verschiedenen Möglichkeiten innerhalb eines Anwendungsfalles 

ist zusätzlich noch eine Anwendungsfallschablone mit den beteiligten Akteuren, 

dem Standardablauf, dem alternativen Ablauf, der Reaktion des 

Systems, den Vorbedingungen, den Nachbedingungen, den Qualitätsanforderungen 

und den enthaltenden Anwendungsfällen beigefügt. 

Akteure sind alle Beteiligten des entsprechenden Anwendungsfalls. Diese 

können Teile des Systems oder Personen sein, welche das System verwenden. 

Der Standardablauf beschreibt den störungsfreien Ablauf des Anwendungsfalles. 

Der Alternative hingegen beschreibt den Verlauf des Anwendungsfalls 

bei einer Störung oder einem vom Standard abweichendem 

Ablauf. Die Reaktion des Systems beschreibt die Aktionen des Systems im 

Falle des alternativen Ablaufs. Die Vorbedingung gibt den Zustand der 

Umgebung vor dem Start des Anwendungsfalles an und die Nachbedingung 

den Zustand der Umgebung nachdem der Anwendungsfall ausgeführt 

wurde. Die Qualität macht Angaben darüber, welche qualitativen 

Eigenschaften der Anwendungsfall einhalten muss. Unter die enthaltenen 

Anwendungsfälle fallen alle im jeweiligen Anwendungsfall Aufgeführten. 

Im nächsten Unterabschnitt wird zunächst eine globale Übersicht über 

sämtliche Anwendungsfälle gegeben. 

29


1.2.2 Gobaler Anwendungsfall 

In diesem Unterabschnitt wird zunächst der globale Anwendungsfall 1.6 

dargestellt, um eine Übersicht über das zu implementierende System zu 

erhalten. Dieses beinhaltet sämtliche Anwendungsfälle, welche aus den 

Szenarien ermittelt wurden. 

Abbildung 1.6: Globaler Anwendungsfall 

30


1.2.3 Primäre Anwendungsfälle 

Im Folgenden werden die primären Anwendungsfälle Armhaltung nachahmen, 

Objekt bewegen, Roboter steuern durch alternative Gesten und Skizze zeichnen 

im Detail beschrieben. Anschließend werden die jeweils enthaltenen 

Anwendungsfälle betrachtet und ebenfalls im Detail beschrieben. Diese 

werden jedoch jeweils nur einmal ausgeführt, auch wenn sie zu mehreren 

primären Anwendungsfällen gehören. 

1.2.3.1 Armhaltung nachahmen 

Im Anwendungsfall Armhaltung nachahmen kann der Benutzer den Roboter 

über Bewegungen seines Arms steuern. Dabei muss sich der Roboterarm, 

im Rahmen seiner Einschränkungen, äquivalent zu den Bewegungen 

des menschlichen Arms verhalten und sie somit nachahmen. Vorher 

wird jedoch das System initialisiert und kalibriert, damit dieses die Gesten 

des Benutzers korrekt erkennen kann und sich der Roboterarm an einer 

definierten Startposition befindet. 

Sollte während Nachahmung der Armposition durch das System ein Fehler 

festgestellt werden, so begibt sich das System in einen Fehlerzustand. Um 

diesen Fehlerzustand zu verlassen, ist es notwendig das System, bzw. einen 

Teil des Systems neu zu starten. 

Name 

Akteure 

Standardablauf 

Armbewegung nachahmen 

Benutzer 

1. Das System wird initialisiert. 

2. Das System wird für die Erkennung 

der Gesten kalibriert. 

3. Benutzer startet Eingabe durch eine 

initiale Geste. 

4. Benutzer bewegt seinen Arm im 

Sichtbereich der Kamera. 

31


Alternativer Ablauf 

1. Tracking geht verloren. Dies kann 

z.B. geschehen, wenn sich die Bewegungen 

außerhalb des Sichtbereiches 

der Kamera befinden. 

2. System reagiert auf keine Eingabe. 

3. System läuft im Fehlerzustand. 

4. Das System gibt eine Warnmeldung 

aus und stoppt an seiner aktuellen 

Position. 

Reaktion des Systems 

1. Roboter ahmt Bewegungen nach, 

die durch den Benutzer vor dem 

Kamerasystem durchgeführt werden. 

Die nachzuahmenden Bewegungen 

sind jedoch auf die des 

Arms beschränkt. 

2. Benutzer beendet Eingabe durch 

eine entsprechende Geste oder 

durch das Verlassen des Sichtbereiches 

der Kameras. 

Vorbedingung 

1. Das System ist aktiviert. 

2. Das System ist nicht im Fehlerzustand. 

3. Benutzer befindet sich im 

Wahrnehmungsbereich des Systems. 

Nachbedingung 1. Bewegungen des Benutzers 

wurden durch den Roboterarm 

nachgeahmt. 

32


Qualität 

1. Das System reagiert mit einer maximalen 

Latenz von 500 ms auf die 

Bewegung des Benutzers. 

2. Das System ahmt die Bewegung 

des Benutzer, mit einer maximalen 

Winkelabweichung von 10 Grad, 

nach. 

Enthaltene Anwendungsfälle 

1. Kalibrierung für Gestenerkennung, 

siehe Unterabschnitt 1.2.4.1. 

2. Initialisierung für Roboterarmsteuerung, 


3. Roboterarm bewegen, siehe Unterabschnitt 

1.2.3.2. 

Tabelle 1.3: Anwendungsfallschablone - Armbewegung nachahmen 

1.2.3.2 Objekt bewegen 

Im Anwendungsfall Objekt bewegen kann der Benutzer den Roboter über 

Bewegungen seines Arms steuern. Dabei muss der Roboterarm ausschließlich 

die Zielposition der Hand des Benutzers nachahmen. Die Gelenkstellungen 

bzw. die Haltung ist dabei dem System überlassen. Zusätzlich muss es 

dem Benutzer möglich sein, durch eine entsprechende Geste, den Greifer 

des Roboterarms zu öffnen oder zu schließen, damit dieser ein Objekt aufnehmen 

und wieder ablegen kann. 

33


Name 

Akteure 


Objekt bewegen 

Benutzer 

1. Benutzer startet Eingabe durch initiale 

Geste. 

2. Benutzer bewegt Arm. 

3. Benutzer führt Geste fürs Schließen 

des Greifers aus. 

4. Benutzer bewegt Arm. 

5. Benutzer führt Geste fürs Öffnen 

des Greifers aus. 

6. Benutzer beendet Eingabe durch 

Geste oder durch das Verlassen des 

Sichtbereiches des Kamerasystems. 

Alternativer Ablauf 1. Roboter verliert Tracking. Dies 

kann durch das Verlassen des 

Sichtbereiches des Kamerasystems 

geschehen oder durch zu schneller 

Bewegungen des Benutzers. 



aus und stoppt an aktueller Position. 

4. System kann nun erneut gestartet 

werden. 

34



1. Roboterarm fährt Zielposition zum 

Aufnehmen eines Objektes an. 

2. Roboterarm schließt Greifer, um ein 

Objekt zu greifen. 

3. Roboterarm fährt Zielposition für 

das Ablegen eines Objektes an. 

4. Roboterarm öffnet Greifer, um ein 

Objekt abzulegen. 

Vorbedingung 



3. Benutzer befindet sich im 


4. Das zu greifende Objekt befindet 

sich im Arbeitsbereich des Roboters. 

5. Das zu greifende Objekt darf ein 

Gewicht von 20 g nicht überschreiten. 

Nachbedingung 1. Objekt wurde gegriffen, bewegt 

und abgelegt. Dabei wurden jeweils 

die Positionen durch den Roboterarm 

abgedeckt, welche vom Benutzer 

über die Steuerung des 

Greifers mit Hilfe seines Arms 

angefahren werden. 

35


Qualität 







nach. 

3. Das System behält das gegriffene 

Objekt fest, bis es abgelegt wird. 


1. Kalibrierung für Gestenerkennung, 




3. Greifer ansteuern, siehe Unterabschnitt 

1.2.4.4. 


1.2.4.3. 

Tabelle 1.4: Anwendungsfallschablone - Objekt bewegen 

1.2.3.3 Roboter steuern durch alternative Gesten 

Im Anwendungsfall Roboter steuern durch alternative Gesten kann der Benutzer 

den Roboterarm durch definierte alternative Gesten steuern. Diese 

müssen es ihm ermöglichen den Roboterarm ohne die Verwendung seines 

eigenen Arms zu steuern. 

Hierzu wird eine Machbarkeitsstudie für die Wahl der Art der alternativen 

Gestensteuerung erstellt. Untersucht wird die Möglichkeit der Implementierung 

eines Eye-Tracking Verfahrens. Dabei steuert der Benutzer 

den Roboterarm durch die Bewegung seiner Augen. Sollte diese Machbarkeitsstudie 

ergeben, dass dies nicht mit der zur Verfügung stehenden Zeit 

bzw. Hardware zu realisieren ist, so wird eine andere alternative Gestensteuerung 

gewählt. Diese beinhaltet die Steuerung des Roboterarms durch 

verschiedene Bewegungen, welche der Benutzer mit Hilfe seines Kopfes 

durchführt. 

36


Name 

Akteure 


Steuerung durch alternative Gesten 

Benutzer 

1. Benutzer startet Eingabe durch initiale 

Geste. 

2. Benutzer führt alternative Gesten 

für Armbewegung aus. 

3. Benutzer führt Geste aus, um die 

zu bewegende Achse auszuwählen. 

Dabei wird pro Ausführung der 

entsprechenden Geste eine Achse 

weitergeschaltet. 

4. Benutzer führt alternative Geste 

fürs Schließen des Greifers aus. 

5. Benutzer führt alternative Geste 

fürs Öffnen des Greifers aus. 

Alternativer Ablauf 1. Roboter verliert Tracking. Dies 

kann durch das Verlassen des 

Sichtbereiches des Kamerasystems 

geschehen oder durch zu schneller 

Bewegungen des Benutzers. 


3. System reagiert auf keine Eingabe. 


aus und stoppt an seiner aktuellen 

Position. 

37


Reaktion des Systems 1. Roboterarm übertragt die alternative 

Geste des Benutzers auf 

eine Bewegung der entsprechenden 

Achse. 

2. Roboterarm fährt Zielposition an. 

3. Roboterarm schließt Greifer. 

4. Roboterarm öffnet Greifer. 

Vorbedingung 



3. Der Benutzer ist im 


4. System wird initialisiert für 

Roboterarmsteuerung. 

5. System wird kalibriert für alternative 

Gestenerkennung. 

Nachbedingung 1. Objekt wurde gegriffen, bewegt 

und abgelegt. 

38


Qualität 







nach. 

3. Das System behält das gegriffene 

Objekt fest, bis es abgelegt wird. 

4. Das System erkennt in der Regel 

(über 80gehören, welche für 

die Alternative Gestensteuerung 

vorgesehen sind. Hinzu kommt 

noch, dass die Lichtverhältnisse 

den Anforderungen des Systems 

entsprechen müssen. Dabei ist die 

Art des Lichtes (sehr helles Tageslicht) 

und der Einfallwinkel des 

Lichtes auf die Kameras wichtig. 


1. Kalibrierung für alternative Gestenerkennung, 

siehe Unterabschnitt 

1.2.4.1. 




1.2.4.3. 

4. Greifer ansteuern, siehe Unterabschnitt 

1.2.4.4. 

Tabelle 1.5: Anwendungsfallschablone - Steuerung durch alternative Gesten 

39


1.2.3.4 Skizze zeichnen 

Im Anwendungsfall Skizze zeichnen muss das System eine Skizze vom Gesicht 

des Benutzers erstellen. Dabei muss sich der Benutzer im Sichtbereich 

der Kamera befinden, sodass ein Bild von ihm aufgenommen werden kann. 

Dieses Bild muss vom System verarbeitet werden und daraufhin entsprechende 

Steuersignale an den Roboterarm senden, sodass dieser eine Skizze 

zeichnen kann. Diese wird dabei vom Roboterarm auf einer planaren Oberfläche 

angefertigt. 

Dabei soll die vom System verarbeitete und durch den Roboterarm gezeichnete 

Skizze mindestens der Qualität der im Folgenden gezeigten Abbildung 

1.7 von Bild und Skizze entsprechen. 

Abbildung 1.7: Skizze einer Aufnahme 

Name 

Akteure 

Skizze zeichnen 

Benutzer 

40


Standardablauf 1. Initialisierung für Skizzenzeichnung. 

2. Kalibrierung für Portraitaufnahme. 

3. Portrait aufnehmen. 

4. Portrait verarbeiten. 



1. Es gibt keinen alternativen Ablauf, 

da das System über keine Sensorik 

verfügt. Sollte jedoch während des 

Zeichnens ein Fehler auftreten, so 

kann der Prozess vom Benutzer 

abgebrochen werden. 

1. Roboter zeichnet Skizze. 

2. Roboterarm fährt Ausgangsstellung 

an. 

Vorbedingung 



3. Der zu skizzierende Benutzer ist im 

Sichtbereich des Systems. 

4. Die Umgebungseigenschaften 

liegen innerhalb der gültigen 

Konfiguration. 

Nachbedingung 

1. Das System begibt sich in einen 

Standby-Zustand. 

2. Das System fährt den Roboterarm 

zurück in seine Ausgangslage. 

Qualität 1. Die Skizze ähnelt dem Vorbild, 

siehe Abb. 1.7. 

41



1. Portrait aufnehmen, siehe Unterabschnitt 

1.2.3.4. 

2. Kalibrierung für Portraitaufnahme, 


Tabelle 1.6: Anwendungsfallschablone - Skizze zeichnen 

1.2.4 Enthaltene Anwendungsfälle 

Im Folgenden werden die enthaltenen Anwendungsfälle Kalibrierung für 

Gestenerkennung, Initialisierung für Roboterarmsteuerung, Roboterarm bewegen, 

Greifer ansteuern, Kalibrierung für alternative Gestenerkennung, Kalibrierung für 

Portraitaufnahme und Portrait aufnehmen im Detail beschrieben. 

1.2.4.1 Kalibrierung für Gestenerkennung 

Abbildung 1.8: Kalibrierung für Gestenerkennung 

Es muss eine Kalibrierung durchgeführt werden, um das System auf den 

Benutzer anzupassen. Dazu gehört die definierte Bewegung des Armes des 

Benutzers in verschiedene Positionen, siehe Abb. 1.9, damit das System 

42


diese erfassen kann. Ob die Kalibrierung erfolgreich ist, soll dem Benutzer 

über einen externen Bildschirm mitgeteilt werden, sodass dieser darauf 

entsprechend reagieren kann. Möchte der Benutzer ein Objekt greifen, so 

muss dieser die definierte Greifbewegung ebenfalls durchführen, sodass 

diese vom System erkannt werden kann. Ob die Kalibrierung erfolgreich 

ist, wird dem Benutzer durch das System mitgeteilt. Ebenfalls wird 

in diesem Anwendungsfall die Kalibrierung der Kamera durchgeführt, um 

z.B. einen Weißabgleich durchzuführen. 

Abbildung 1.9: Beispiel einer Kalibrierung 

Der Roboterarm kann um 90 Grad gedreht werden, damit dieser die selbe 

Stellung bzw. Ausrichtung hat wie der menschliche Arm. Dies soll eine 

bessere und intuitive Bedienung ermöglichen. 

Name 

Kalibrierung für Gestenerkennung 

43


Akteure 


Benutzer 

1. Benutzer startet Kalibrierung für Gestenerkennung. 

2. Kalibrierung der Kamera. Hier wird zum 

Beispiel der Weißabgleich der Kamera 

durchgeführt. 

3. Benutzer bewegt seinen Arm nacheinander 

an unterschiedliche Positionen. Diese 

müssen vom System erkannt und bestätigt 

werden. 

4. Benutzer führt Greifbewegungen durch, 

welche ebenfalls durch das System erkannt 

und bestätigt werden müssen. 

5. System teilt dem Benutzer die erfolgreiche 

Kalibrierung mit. 

6. Benutzer beendet Kalibrierung. 


1. Benutzer startet Kalibrierung. 

2. Kalibrierung schlägt fehl, dies kann z.B. 

durch zu schlechte Lichtverhältnisse oder 

durch zu schnelle Bewegungen des Benutzer 

geschehen. 

3. System teilt dem Benutzer die fehlgeschlagene 


4. Möchte der Benutzer den Vorgang wiederholen, 

so kann es dies dem System mitteilen 

und von vorne beginnen. 

44



Vorbedingung 

1. Das System ist auf den Benutzer kalibriert 

und der Benutzer kann das System verwenden. 

1. System muss eingeschaltet werden. 

2. Lichtverhältnisse müssen sich im Bereich 

der für die Kamera gültigen Werte befinden. 

3. Der Arm des Benutzers muss entsprechend 

markiert sein. Hierzu werden rote Armbinden 

verwendet. 

Nachbedingung 

Qualität 


und erkennt die definierten Gesten. 

1. Die Erfolgsrate bei der Kalibrierung des 

Systems muss bei mindestens 75 % liegen. 

Tabelle 1.7: Anwendungsfallschablone - Kalibrierung für Gestenerkennung 

1.2.4.2 Initialisierung für Roboterarmsteuerung 

System 

Initialisierung 

für Roboterarmsteuerung 

 

Roboterarm 

fährt in Startposition 

Benutzer 

Abbildung 1.10: Initialisierung für Roboterarmsteuerung 

Nach dem Start erfolgt im ersten Schritt die Initialisierung des Systems. 

Dazu gehört die Bewegung des Roboterarms in die Ausgangsstellung. Diese 

Ausgangsstellung ist wichtig, damit das System eine definierte Position 

hat. 

Name 

Initialisierung für Roboterarmsteuern 

45


Akteure 



Benutzer 

1. Benutzer startet System. 

1. System kann nicht initialisiert werden. 

2. System gibt eine Fehlermeldung aus. 

3. System gibt dem Benutzer die Möglichkeit 

für einen Neustart. 


1. System begibt sich in Ausgangslage. 

2. System wartet auf entsprechende Kalibrierung. 

Vorbedingung 

Nachbedingung 

1. System ist deaktiviert. 

1. System ist initialisiert und kann nun kalibriert 

werden. 

Qualität 1. Das System beendet die Initialisierung 

nach maximal 5 Sekunden. 

Tabelle 1.8: Anwendungsfallschablone - Initialisierung für Roboterarmsteuern 

46


1.2.4.3 Roboterarm bewegen 

System 

Roboterarm 

bewegen 

 

Ansteuerung 

der Servos 

Benutzer 

Abbildung 1.11: Roboterarm bewegen 

Damit der Roboterarm bewegt werden kann, müssen die aufgenommenen 

und erkannten Gesten in Signale für die Servos des Roboterarms umgesetzt 

werden. 

47


Name 

Akteure 



Roboterarm bewegen 

Benutzer 

1. Benutzer führt eine Geste aus 

1. Ansteuerung der Servos schlägt fehl. 

2. System gibt eine Fehlermeldung aus. 




1. System erkennt die Geste. 

2. System berechnet die auszuführende Aktion 

des Roboterarms. 

3. System berechnet die Signale für die Servos. 

4. System steuert Servomotoren an. 

5. Servomotoren bewegen den Roboterarm. 

Vorbedingung 

Nachbedingung 

Qualität 

1. Das System ist initialisiert und kalibriert. 

1. Der Roboterarm hat die gewünschte Position 

angefahren. 


Latenz von 500 ms auf die Bewegung des 

Benutzers. 

2. Das System ahmt die Bewegung des Benutzers, 

mit einer maximalen Winkelabweichung 

von 10 Grad, nach. 

Tabelle 1.9: Anwendungsfallschablone - Roboterarm bewegen 

48


1.2.4.4 Greifer ansteuern 

Abbildung 1.12: Greifer ansteuern 

Befindet sich der Benutzer im primären Anwendungsfall Objekt bewegen 

1.2.3.2, ist es diesem möglich mit einer entsprechenden Geste den Greifer 

des Roboterarms zu öffnen und zu schließen, um damit ein Objekt zu 

greifen und dieses an anderer Stelle wieder ablegen zu können. 

Name 

Akteure 


Greifer ansteuern 

Benutzer 

1. Benutzer führt mit der Hand eine Geste 

zum Öffnen des Greifers aus. 

2. Roboterarm öffnet den Greifer. 

3. Benutzer führt mit der Hand eine Geste 

zum Schließen des Greifers aus. 

4. Roboterarm schließt den Greifer. 


1. Benutzer führt eine Geste zum Öffnen oder 

Schließen des Greifers aus. 

2. System reagiert nicht auf die Eingabe. 

3. Benutzer startet System neu. 


1. System startet neu. 

49


Vorbedingung 

Nachbedingung 

Qualität 

1. System muss kalibriert und initialisiert 

worden sein. 

1. Greifer wurde geöffnet und danach wieder 

geschlossen und hat das entsprechend zu 

greifende Objekt gegriffen. 

1. Die Objekte, die vom Greifer gegriffen werden 

sollen, müssen die entsprechenden 

Spezifikationen einhalten. Diese Spezifikationen 

sind in den nicht funktionalen Anforderungen 

1.2.6 im Abschnitt Effizienz 

beschrieben. 

Tabelle 1.10: Anwendungsfallschablone - Greifer ansteuern 

1.2.4.5 Kalibrierung für alternative Gestenerkennung 

System 

 

Kalibrierung 

der Kamera 

Benutzer 

Kalibrierung 

für alternative 

Gestenerkennung 

 

Erkennung 

der die alternative 

Geste ausführenden 

Körperteile 

Abbildung 1.13: Kalibrierung für alternative Gestenerkennung 

Bei der Kalibrierung für alternative Gesten wird der Benutzer und dessen 

alternative Gesten, siehe Abb. 1.14, zur Steuerung des Roboters auf das 

System angepasst. Ebenfalls wird an dieser Stelle die Kamera des Systems 

kalibriert. 

50


Abbildung 1.14: Beispiel einer Kalibrierung für alternative Gestenerkennung 

Name 

Akteure 


Kalibrierung für alternative Gestensteuerung 

Benutzer 

1. Benutzer startet durch eine Geste die Kalibrierung 

für alternative Gestenerkennung. 

2. Kalibrierung der Kamera. 

3. Benutzer führt nacheinander drei unterschiedliche 

alternative Gesten aus. Diese 

müssen vom System erkannt und bestätigt 

werden. 

51


4. Benutzer führt alternative Geste für 

Greiferansteuerung aus, welche ebenfalls 

durch das System erkannt und bestätigt 

werden muss. 

5. Benutzer beendet Kalibrierung. 



2. Kalibrierung schlägt fehl. 




1. Das System Kalibriert sich auf die Gesten 

des Nutzers. 

2. Das System teilt dem Benutzer mit, ob 

die Kalibrierung erfolgreich durchgeführt 

wurde. 

Vorbedingung 




3. Der für die Ausführung der alternativen 

Geste verwendete Körperteil muss 

sich im Wahrnehmungsbereich der Kamera 

befinden. 

Nachbedingung 

Qualität 


und erkennt die definierten Gesten. 



52


Tabelle 1.11: Anwendungsfallschablone - Kalibrierung für alternative 

Gestensteuerung 

1.2.4.6 Kalibrierung für Portraitaufnahme 

System 

 

Kalibrierung 

von Schreibgerät 

und Oberfläche 

Kalibrierung 

für Portraitaufnahme 

 

Benutzer 

Kalibrierung 

der Kamera 

Abbildung 1.15: Kalibrierung für Portraitaufnahme 

Die Kalibrierung für die Portraitaufnahme beinhaltet die Kalibrierung der 

Kamera sowie die Kalibrierung des verwendeten Schreibgerätes mit der 

entsprechenden Oberfläche. 

Name 

Akteure 



Kalibrierung für Portraitaufnahme 

Benutzer 



2. Kalibrierung schlägt fehl. 



4. System bietet dem Benutzer die 

Möglichkeit die Kalibrierung neu zu 

starten. 

53



1. Das System führt eine Kalibrierung der 

Kamera durch. 

2. Das System führt eine Kalibrierung des 

Roboterarm zur Position vom Schreibgerät 

und Oberfläche durch. 

Vorbedingung 




3. Der Roboterarm muss mit einem 

Schreibgerät ausgestattet sein. 

4. Es muss eine Oberfläche für die Ausführung 

der Skizze vor dem Roboterarm 

aufgestellt sein. 

Nachbedingung 

Qualität 

1. Das System ist für die Portraitaufnahme 

kalibriert. 



Tabelle 1.12: Anwendungsfallschablone - Kalibrierung für Portraitaufnahme 

1.2.4.7 Portrait aufnehmen 

System 

Portrait aufnehmen 

 

Kamera auslösen 

Benutzer 

Abbildung 1.16: Portrait aufnehmen 

54


Damit der Benutzer ein Portrait von sich aufnehmen lassen kann, muss 

er dies durch eine definierte Aktion dem System mitteilen. Dieses Portrait 

wird dann weiter durch das System verarbeitet. 

Name 

Akteure 



Portrait aufnehmen 

Benutzer 

1. Benutzer führt Aktion zum Auslösen der 

Kamera aus. 

1. Benutzer führt Aktion zum Auslösen der 

Kamera aus. 

2. System reagiert nicht auf die Eingabe. 




1. System nimmt ein Bild mit der Kamera auf. 

2. System erzeugt ein Portrait auf Basis des 

Bildes. 

Vorbedingung 1. Benutzer sitzt in Position um Portrait 

aufzunehmen. 

Nachbedingung 

1. Portrait wurde aufgenommen. 

Qualität 1. Das Portrait muss von seiner Auflösung, 

Kontrast und Helligkeit ausreichend 

sein, damit das System daraus eine 

entsprechende Skizze erstellen kann. 

Tabelle 1.13: Anwendungsfallschablone - Portrait aufnehmen 

1.2.5 Funktionale Anforderungen 

Im Folgenden sind die Eigenschaften aufgelistet, welche das System besitzen 

soll bzw. muss: 

55


F 1 Das System muss sich vor dem Einsatz kalibrieren lassen. 

F 2 Das System muss sich innerhalb der Freiheitsgrade des Roboterarms 

bewegen lassen. 

F 3 Der Roboterarm muss durch die Steuerung des Benutzers in der Lage 

sein ein Objekt innerhalb des Bewegungsradius zu greifen und abzulegen, 

siehe Abb. 1.17). 

F 4 Das System muss einem Benutzer die Bewegung des Roboterarms 

ermöglichen. 

F 5 Das System muss das Öffnen der menschlichen Hand erkennen können, 

um bei geöffneter Hand den Greifer zu öffnen und bei geschlossener 

Hand den Greifer zu schließen. 

F 6 Das System muss Personen innerhalb des Sichtbereichs der Kamera 

erkennen. 

F 7 Der Roboterarm soll eine Skizze, siehe Abb. 1.7) einer Person auf 

einer dafür vorgesehenen Oberfläche malen können. 

F 8 Das System muss eine alternative Gestensteuerung des Roboterarms 

anhand von Kopf- oder Augenbewegung zulassen. 

F 9 Das System muss Informations-, Warn- und Fehlermeldungen ausgeben 

können. 

F 10 Das System muss durch den Benutzer neu gestartet werden können. 

Alternative Steuerung durch Kopfbewegungen 

F 1 Die Kopfbewegungen müssen erkannt und nachverfolgt werden, um 

anhand derer die Bewegungsrichtung in der x-Achse und y-Achse 

des Roboterarms zu steuern. 

F 2 Durch eine Geste, die vom System erkannt wird, muss in den z- 

Modus gewechselt werden können. Nun kann durch die Kopfbewegung 

die z-Position angepasst und der Greifer gesteuert werden. 

56


Alternative Steuerung durch Eye-Tracking 

F 1 Die Augenbewegungen müssen nachverfolgt werden, um anhand derer 

die Bewegungsrichtung in der x-Achse und y-Achse des Roboterarms 

zu steuern. 

F 2 Durch ein Geste, die vom System erkannt wird, muss in den z-Modus 

gewechselt werden. Nun kann durch die Augenbewegung die z-Position 

angepasst und der Greifer gesteuert werden. 

F 3 Die Umsetzbarkeit einer alternativen Steuerung durch Eye-Tracking 

wird in einer Machbarkeitsstudie untersucht. Abhängig von dem Ergebnis 

der Machbarkeitsstudie, wird bei einem posetiven Ergenis ein 

Eye-Tracking Verfahren umgesetzt. Sollte die Machbarkeitsstudie ergeben, 

dass ein Eye-Tracking nicht umgesetzt werden kann, wird eine alternative 

Steuerung durch Kopfbewegungen 1.2.5 umgesetzt. 

1.2.6 Nicht funktionale Anforderungen 

Folgender Abschnitt definiert die Rahmenbedingungen der oben erwähnten 

Eigenschaften. 

• Benutzbarkeit 

NF 1.1 Die Plattform des Roboterarms muss an einer senkrechten 

stationäre Befestigung fixiert werden. Durch diese Befestigung 

ist der Roboterarm um 90 Grad, in die Waagerechte, gedreht. 

NF 1.2 Das System muss vor dem Einsatz für den jeweiligen Benutzer 

kalibriert werden. 

NF 1.3 Das System darf sich von einem zweiten Benutzerarm nicht 

in seiner Funktionalität beeinflussen lassen. 

NF 1.4 An den Gelenken des Benutzers müssen Punkte befestigt werden, 

damit dieser durch das System erkannt wird. 

NF 1.5 Zum Zeichnen der Skizze muss ein Schreibinstrument im Tool- 

Center-Point befestigt werden. 

NF 1.6 Das System muss eine zu skizzierende Person aufnehmen 

können, sofern sich diese nicht bewegt. 

NF 1.7 Um eine Skizze erstellen zu können muss der Roboterarm 

den Kontakt von Schreibinstrument und Oberfläche aufrecht 

erhalten. 

57


NF 1.8 Der Greifer des Roboterarms muss ein gegriffenes Objekt solange 

festhalten, bis der Benutzer das System auffordert das 

Objekt explizit abzulegen. 

• Zuverlässigkeit 

NF 2.1 Zwecks der Vermeidung von Selbstbeschädigung des Roboterarms, 

muss die Bewegungsfreiheit des Roboterarms auf einen 

Arbeitsbereich eingeschränkt werden. 

NF 2.2 Das System muss den Benutzer ab einer ausreichenden Beleuchtung 

erkennen. 

NF 2.3 Das System muss nach einem Absturz durch einen Neustart 

des Systems wieder in einen einsatzbereiten Zustand überführt 

werden können. 

NF 2.4 Das System muss auf eindeutige, d.h. in ihrer Form und Bewegung 

unterschiedliche, Gesten reagieren. 

NF 2.5 Das System muss weitere Arme oder Personen von dem Steuerarm 

bzw. der Steuerperson differenzieren können. 

NF 2.6 Das System muss die Bewegung des Benutzers mit einer maximalen 

Winkelabweichung von 10 Grad imitieren. 

• Effizienz 

NF 3.1 Das System muss Objekte mit einem Gewicht von maximal 

20 g, welche eine Mindestgröße von 5 mm × 5 mm × 5 mm und 

eine Maximalgröße von 40 mm × 40 mm × 40 mm haben, greifen 

können. 

NF 3.2 Die Latenz des Systems muss unterhalb von 500 ms liegen. 

NF 3.3 Die Bildverarbeitung und -vorverarbeitung muss, für die Anwendungsfälle 

1.2.3.2, 1.2.3.3 und 1.2.3.1, ausschließlich durch 

eine Implementierung in Hardware realisiert werden. 

NF 3.4 Die Berechnung der Bilder für die Skizze werden extern durch 

einen PC durchgeführt. 

NF 3.5 Die Erfolgsrate bei der Kalibrierung des Systems muss bei 

mindestens 75% liegen. 

NF 3.6 Das System muss den Roboterarm innerhalb von maximal 

fünf Sekunden initialisiert haben. 

• Änderbarkeit 

58


Abbildung 1.17: Greifen eines Objekts, Anwendungsfall 1.2.3.2 

NF 4.1 Das System muss Systemupdates in Form von Änderungen 

der Bildverarbeitungskette zulassen. Somit ist es möglich das 

System, im Rahmen seiner technischen Möglichkeiten, auf 

ähnliche Anwendungsfälle anzupassen. 

NF 4.2 Durch die Verwendung von Schnittstellen muss es möglich 

sein die verschiedenen Hardwarekomponenten des Systems 

auszutauschen. Diese Schnittstellen müssen zwischen dem 

Roboterarm, der 3D-Kamera sowie der Steuerungslogik implementiert 

werden. 

NF 4.3 Der Greifer des Roboterarms muss ebenfalls austauschbar sein. 

Hierbei darf jedoch ein entsprechendes Gewicht von 100 g 

nicht überschritten werden. Soll dieser vom Roboterarm aktuiert 

werden, so muss dieser entsprechend mit dem Servo 

des Roboterarms verbunden werden. 

NF 4.4 Das System muss erlauben die Servos, durch alternative Motoren 

mit den selben Abmessungen, zu ersetzen. Hierzu muss 

jedoch auch die Regelungselektronik entsprechend angepasst 

werden. 

NF 4.5 Das System muss einen Austausch der Komponenten der Bildverarbeitungskette, 

welche für die Erkennung der Gesten verantwortlich 

sind, zulassen. 

• Übertragbarkeit 

NF 5.1 Durch Anpassungen der Algorithmen, zur Erkennung der 

59


Gesten, lässt sich das System auf andere alternative Eingabeweisen 

übertragen, beispielsweise zur Erkennung von Schachfiguren 

statt eines Arms. 

NF 5.2 Der Roboterarm, die Steuerungselektronik und die 3D-Kamera 

sind durch einfache Kabelverbindungen miteinander verbunden, 

sodass diese leicht ausgetauscht werden können. Hierbei 

muss aber darauf geachtet werden, dass dieser mindestens 

die selben Anforderungen wie der im Original verwendete 

einhält. 

• Wartbarkeit 

NF 6.1 Struktur und Funktionalität des Quellcodes werden durch 

entsprechende Kommentare erläutert, sodass die Einarbeitung 

Dritter möglich ist. 

NF 6.2 Zur Wartbarkeit der Bildverarbeitungsketten werden für die 

Schritte der Bildverarbeitung und Vorverarbeitung einzelne 

Softwarebausteine geschrieben. Diese können dann einzeln 

verändert oder ausgetauscht werden. 

60


1.3 Risikoanalyse 

Da das Projekt in einem begrenzten Zeitraum realisiert werden muss, wird 

während der Planungsphase eine Risikoanalyse duchgeführt. In dieser Risikoanalyse 

werden bei der Projektdurchführung zu erwartende Probleme 

analysiert. Dabei werden speziell Probleme erfasst, welche zu einem Scheitern 

des Projekts führen können. Die ermittelten Probleme werden mit einer 

Wahrscheinlichkeit, einer Auswirkung und einer Risikobewertung versehen. 

Die Wahrscheinlichkeit bewertet, wie wahrscheinlich es ist, dass ein 

Problem auftritt. Die Auswirkung ist eine Skala, welche bewertet wie groß 

die Auswirkungen auf das gesamte Projekt sind. Das Risikobewertung erfolgt 

über die Risikoampel. Diese gibt ein Maß an, wie hoch das Risiko 

eingeschätz wird. Das Risiko wird dabei in Abhängigkeit von der Wahrscheinlichkeit 

und der Auswirkung abgeschätzt. Die Legende erläutert wie 

die Punkte im einzelnen notiert werden. 

Neben der Risikobewertung wird zusätzlich eine Gegenmaßnahme aufgeführt. 

Diese Gegenmaßnahme definiert, falls das entsprechende Problem 

aufgetreten ist, wie auf das Problem reagiert und welche Maßnahmen ergriffen 

werden müssen, um die Folgen zu minimieren. Als letztes wird das 

Restrisiko angegeben. Dieses definiert, wie hoch das Risiko eines Fehlschlagens 

der Gegenmaßnahme ist. 

1 Anzahl der für die Bildverarbeitungsketten 

verwendeten 

IP-Cores überschreitet das 

Maximum der auf dem FPGA 

vorhandenen Logikgatter. 

2 Disparitätskarte der 3D- 

Kamera ist nicht fein genug 

aufgelöst um Bewegungen des 

Benutzer korrekt zu erkennen. 

3 Die Genauigkeit des Roboterarms 

am Tool-Center-Point reicht 

nicht für eine qualitative 

Übertragung des digital 

vorverarbeiteten Bildes, in 

Form einer Skizze, auf eine 

Oberfläche. 

4 Das Verfahren für die alternative 

Gestensteuerung 

lässt sich aufgrund von 

nicht evaluierten vorhandenen 

Technologien, nicht 

realisieren. 

Nr. Risikobeschreibung Wahrsch. Auswirkung 

Risiko- 

Ampel 

Maßname 

3 3 6 Verwendung eines größeren 

FPGAs oder eines zweiten FP- 

GAs. 

2 4 6 Stärkere Bewegungen des Benutzers, 

Interpolation von Bewegungsabläufen. 

3 4 7 Zusätzliche Regelung und / 

oder mechanische Änderungen 

am Roboter. Präzisere Servomotoren 

kaufen. Roboterarm 

kürzen. 

2 4 6 Auswahl einer anderen Form 

der alternativen Gestensteuerung. 

Anbringung einer 

fixen Kamera am Benutzer. 

Restrisiko 

2 

4 

3 

4 

61


5 Kalibrierung des entsprechenden 

Anwendungsfalles 

schlägt zur mehr als 25 % 

fehl. Dies beinhaltet die Kalibrierung 

der Kamera und der 

entsprechenden Gesten des 

Anwendungsfalles. 

6 Gemessene Latenz liegt über 

500 Millisekunden. Diese 

beziehen sich auf die Zeit 

zwischen der initialen Bewegen 

des Benutzers und der 

Reaktion des Roboters. 

7 Die Initialisierung des Systems 

benötigt mehr als die 

in den nichtfunktionalen 

Anforderungen festgelegten 

5 Sekunden. 

8 Die gemessene Winkelabweichung 

zwischen dem 

Arm des Benutzers und des 

Roboterarms ist größer als 

die in den nichtfunktionalen 

Anforderungen festgelegten 

10 Grad. 

9 Qualität der Skizze des Portraits 

entspricht nicht den 

Mindestanforderungen. Diese 

können einer Beispielgrafik 

entnommen werden, siehe 

Abb. 1.7. 

10 Greifer kann spezifizierte Objekte, 

siehe Abschnitt 1.2.6, 

nicht greifen. 

3 4 7 Stabilisierung der Lichtverhältnisse, 

Änderung der 

Kalibrierungsgrundlage. 

3 3 6 Überarbeitung entsprechender 

Algorithmen, Anpassung 

der Regelung. 

2 4 6 Verwendung stärkerer Servomotoren 

oder Änderung des 

Initialisierungsvorgangs 

2 4 6 Verwendung genauerer Servomotoren, 

Verbesserung der 

Regelung und Anpassung der 

Algorithmen. Änderung des 

Verhältnissen zwischen Hintergrund 

und Extremitäten 

zur Besseren Extraktion von 

Vorder- und Hintergrund. 

3 4 7 Siehe Maßnahme Nr. 8. 3 

3 3 6 Änderung des Greifers, Änderung 

der Greiftechnik, zum 

Beispiel Formschluss 8 . 

3 

3 

2 

3 

3 

Tabelle 1.14: Risikoanalyse 

Skalierung Eintrittswahrscheinlichkeit 

1 extrem unwahrscheinlich ˆ= < 15% 

2 sehr unwahrscheinlich ˆ= < 30% 

3 unwahrscheinlich ˆ= < 45% 

4 wahrscheinlich ˆ= < 60% 

5 sehr wahrscheinlich ˆ= < 75% 

6 extrem wahrscheinlich ˆ= < 100% 

Skalierung Schadenswirkung Skalierung Risiko 

1 unbedeutend 

4 vernachlässigbar 

2 gering 

6 gering 

3 erheblich 

7 mittel 

4 katastrophal 

>8 hoch 

Tabelle 1.16: WirkungTabelle 1.17: Risiko 

Tabelle 1.15: Eintrittswahrscheinlichkeit 

8 Ein Objekt wird durch umschließendes Greifen mit verhältnismäßig wenig Kraft gefasst 

62


1.4 Entwicklungszyklus 

Die Entwicklung des Systems wird mittels Konzepten aus der Agilen Softwareentwicklung 

durchgeführt. Dies bedeutet insbesondere, dass das System 

in kleinere Komponenten geteilt wird, welche in ca. 2 Wochen langen 

Zeiträumen, so genannten Sprints, bearbeitet werden. 

Abgesehen von dem Sprint Konzept werden die folgenden Konzepte aus 

der Agilen Softwareentwicklung von uns als Entwicklungsbasis verwendet: 

• Funktionierende Software ist wichtiger als ausführliche Dokumentation. 

• Das Eingehen auf Änderungen ist wichtiger als das Verfolgen eines 

Plans. 

• Programmierung erfolgt durch jeweils zwei Programmierer an einem 

PC. 

• Vorhandene Ressourcen werden möglichst mehrfach verwendet. 

• Jede Programmiergruppe kann am gesamten Code arbeiten. 

• Die Entwicklung erfolgt Kundennah. 

• Der Quellcode wird möglichst kurz und einfach gehalten (KISS Prinzip). 

• Es erfolgt ausschließlich zweckmäßige Entwicklung. 

1.5 Systemarchitektur 

Das Hardwaresystem wird aus 3 interagierenden Komponenten bestehen, 

siehe Abb. 1.18. Zunächst werden alle Eingaben des Benutzers von der 

Kamera aufgezeichnet. Diese gibt die Informationen als Datenstrom an 

ein geschlossenes System weiter, welches die Daten verarbeitet und einen 

Roboterarm ansteuert. Dieser interagiert dann gegebenenfalls mit Objekten. 

Die nachfolgende Grafik veranschaulicht den Ablauf. 

63


Kamera 

geschlossenes System 

Arm 

Bildstream 

weiterreichen 

XILINX 

FPGA 

steuern 

interagieren 

bewegen 

Benutzer 

Objekt 

Abbildung 1.18: Systemarchitektur 

1.6 Lieferumfang 

Der Kunde erhält ein abgeschlossenes System, welches er über Mensch- 

Maschine Interaktionen steuern kann. Das System besteht aus einem Roboterarm, 

zwei digitalen Kameras und einer Schaltung, welche die Logik 

für die Bildverarbeitung und die Roboteransteuerung enthält. Die Logik 

wird in Form von Quelltext ausgeliefert. 

64

2 Implementation 

Dieses Kapitel beschreibt die Entwicklungs- und Implementierungsphase 

sowie die Machbarkeitsstudien einiger Ansätze für die im vorherigen Kapitel 

definierten Anwendungsfälle. Die Entwicklung erfolgt in Sprints 1 . 

Das Kapitel besteht aus den Sprintdokumentationen, die wie folgt aufgebaut 

sind: 

Beschreibung der 

Ziele sowie Teilziele 

des Sprints 

Sprintplanung mit 

Teilaufgaben, 

Zuständigkeiten und 

Fristen 

Dokumentation 

der Ergebnisse 

Fazit 

und 

Ausblick 

Abbildung 2.1: Struktur eines Sprints 

Am Anfang jedes Sprints folgt eine Einleitung, welche die zu erreichenden 

Zeile sowie Teilziele des Sprints vorstellt. Danach wird in jedem Sprint eine 

Planung der Tätigkeiten und Entwicklungsschritte sowie die Personenzuteilung 

mit den festgelegten Fristen als Deadlines ausführlich beschrieben. 

Die genaue Festlegung der Deadlines wird jedoch erst ab Sprint 3 (2.4) 

vorgenommen, da im Sprint 2 (2.2) mehrere zeitlich unvorhersehbare Tätigkeiten 

durchgeführt werden müssen. Diese werden im folgenden Abschnitt 

beschrieben. Nach der festgelegten Sprintplanung werden die Ergebnisse 

der Tätigkeiten dokumentiert und Evaluiert. Am Ende jedes Sprints folgt 

ein zusammenfassendes Fazit, das den Erfolg der gesetzten Ziele evaluiert 

und einen Ausblick der nachfolgenden Ziele eröffnet. In Abbildung 2.1 ist 

die Struktur eines Sprints veranschaulicht. 

Das vorherige Kapitel ist im Sinn dieser Struktur als der erste Sprint anzusehen. 

Dieses Kapitel fängt daher mit dem Sprint 2 an. 

1 http://www.viskonz.de/AgileSoftwareEntwicklung.pdf 

65

Kapitel 2. Implementation 10. Oktober 2013 

2.1 Sprintplanung Sprint 2 

Der Sprint 2 setzt den Schwerpunkt auf das Schaffen der grundlegenden 

Steuerungseinheiten für die gegebene Systemarchitektur (siehe 1.18). Hier 

wird eine Steuerung des Kameramoduls entwickelt und an den FPGA 

angebunden. Die Steuerung des Roboterarms wird entwickelt sowie die 

Schnittstellen für die Ansteuerung der einzelnen Servos und der Kinematik 

zur Verfügung gestellt. Außerdem wird ein Bildverarbeitungsmodul 

für die Objektverfolgung entwickelt und anschließend mit der fertigen 

Robotersteuerung zusammengeführt. Zusätzlich wird für den Anwendungsfall 

alternative Gestensteuerung die Machbarkeitsstudie für das Eye- 

Tracking durchgeführt. Dies geschieht, um über die Machbarkeit des Eye- 

Tracking mit den vorhandenen Mitteln eine Aussagen treffen zu können. 

Das Ergebnis dieser Studie muss der Entscheidung beitragen, ob die alternative 

Gestensteuerung mit Hilfe der Augenverfolgung oder mit der 

Erkennung von Kopfbewegungen realisiert wird. 

Alle genannten Aufgaben werden als Ergebnis Schnittstellen für die OFFIS- 

Automation-Toolbox zur Verfügung stellen. In diesem Sprint werden keine 

festen Deadlines gesetzt, sondern Zeiteinschätzungen für die jeweiligen Arbeitspakete 

vorgenommen. Zum Überblick des Arbeitsstandes wird vom 

Projektmanager ein Ganttdiagramm geführt, das am Ende des Sprints zu 

finden ist. Dieses wird der Gruppe helfen den Fortschritt jedes Arbeitspakets 

im Auge zu halten sowie bei den eventuell entstehenden kritischen Pfaden 

rechtzeitig zu reagieren. 

2.1.1 Machbarkeitsstudie Eye-Tracking 

Durch Einsatz eines PCs mit installierter OFFIS IDE sowie einer Webcam(2D) 

und einer Infrarotlichtquelle soll die Umsetzung einer automatisierten 

Augenverfolgung in Software implementiert werden. Das Arbeitspaket 

beinhaltet die Schritte der Erkennung, Verfolgung sowie Erfassung der 

Blickrichtung. Als Ergebnis des Sprints soll ein Bericht mit Evaluation und 

Fazit über die Machbarbeit des Eye-Trackings im Rahmen der PG RoboArm 

für die alternative Gestensteuerung vorliegen. Ausserdem existiert eine 

Software Implementierung des Verfahrens in der OFFIS IDE. 

Im ersten Schritt dieses Arbeitspakets soll die Erkennung der benötigten 

Augen- und Gesichtsmerkmale anhand eines von der Webcam aufgenommenen 

Bildes umgesetzt werden. Zu diesem Zweck muss eine Bildverarbeitungskette 

unter Verwendung der OFFIS IDE erstellt werden. Hierfür sind drei 

Wochen Zeit eingeplant. 

66


Im nächsten Schritt des Arbeitspakets wird die in 2.1.1 erstellte Verarbeitungskette 

für die Verwendung mit einem Videostream erweitert. Außerdem 

wird die Bewegungsverfolgung der erkannten Augen implementiert. 

Für diesen Schritt stehen zwei Wochen Zeit zur Verfügung. 

Im letzten Schritt soll anhand der gewonnenen Daten die Blickrichtung 

einer Testperson automatisiert berechnet und visualisiert werden. Hierfür 

stehen zwei Wochen zur Verfügung. 

Personen 

• Tobias Schüürhuis 

• Matthias Stasch 

67


2.1.2 Anbindung des Kameramoduls 

Das von Digilent stammende Kameramodul VmodCAM, welches von der 

Projektgruppe verwendet wird, benötigt eine spezielle Startsequenz für 

beide Kameras, welche von uns mit einem IP-Core implementiert wird. 

Sind die beiden Kameras initialisiert, müssen die Mikrocontroller noch 

zusätzlich über das I2C Protokoll aktiviert und konfiguriert werden. Diese 

Kommunikation wird von uns mittels eines I2C-Cores, welcher Teil der Xilinx 

Suite ist durchgeführt. Zur Vermittlung zwischen den beiden IP-Cores 

und zur Steuerung wird von uns ein Hardware Abstraction Layer (HAL) 

in C++ entwickelt, welcher auf dem MicroBlaze Core läuft. Diese Arbeiten 

sollen in den ersten 2 Wochen abgeschlossen sein. 

Zur weiteren Analyse am PC wird der bereitgestellte USB IP-Core und 

dessen HAL so angepasst, dass dieser Bildinformationen von dem Kamera 

Modul an den PC vermitteln kann. Für diese Aufgabe sind weitere 2,5 

Wochen vorgesehen. 

Auf dem PC wird, falls nötig, das Plugin der Offis Automation Toolbox 

angepasst, damit dieses die Bilder anzeigen kann. Um die gesamte Integration 

aller von uns bearbeiteten Komponenten zu gewährleisten sind weitere 

2,5 Wochen Arbeitszeit eingeplant. 

Ein Informationsfluss ist in folgender Grafik dargestellt, wobei die gelb 

markierten Elemente von uns erstellt oder bearbeitet werden müssen. 

Personen 

• Sebastian Reichel 

• Markus Müller 

68


VmodCam 

Boot-Core 

I²C-Core 

Data-Core 

HAL (in C++) 

FPGA 

USB Handler 

USBCam-Core 

USB 

Treiber 

PC 

HAL 

Offis Toolbox 

69


2.1.3 Roboter-Arm 

In der Automationsumgebung muss für jedes Gelenk des Roboters ein 

Winkel angegeben werden. Dabei wird von einem PC mit dem FPGA über 

einen Hardwareabstractionlayer (HAL) via USB kommuniziert. Die Demonstration 

der Roboteransteuerung erfolgt im Offis-Automationstool, indem 

für die Skriptsprache Python eine C++ Schnittstelle (HAL) zur Ansteuerung 

des Roboterarms bereitgestellt wird. Die Roboteransteuerung wird durch 

die Umsetzung von Vor- und Rückwärtskinematik realisiert. 

In einem ersten Arbeitsschritt soll die 

Basis geschaffen werden, um eine Kinematik 

welche den Roboterarm steuert auf 

dem PC in Python verwenden zu können. 

Dazu muss ein auf USB aufbauendes 

Protokoll entwickelt werden, welches 

das Kommunikationsformat zwischen 

PPM-IP-Core (FPGA) und PC definiert. Zu 

diesem Zweck soll ein bereits existenter 

USB IP-Core sowie ein HAL auf dem FP- 

GA eingesetzt werden. Der HAL muss eine 

Kalibrierung des Roboterarms erlauben. 

Es muss ein zweiter HAL geschrieben 

werden, der es ermöglicht die unten 

beschriebenen Kinematiken in Python zu 

programmieren und aus dieser Umgebung 

C++ Funktionen aufzurufen. Die zu erstelleneden 

Module sind in der nebenstehenden 

Abbildung 2.34 rot makiert, wobei 

die Kinematik Aufgabe nachfolgender Arbeitspakete 

ist. Es sind zwei Wochen hierzu 

geplant. 

Roboterarm 

IP − Core(PPM) 

HAL(C + +) 

USB − Handler(C + +) 

IP − Core(USB) 

Hardware 

Treiber 

HAL(C + +) 

Kinematik(Python) 

Abbildung 2.2: Steuerungsschichten 

FPGA 

PC 

Ziel des nächsten Arbeitsschrittes ist eine Realisierung der Vorwärtskinematik 

in Python. Die Koordinaten eines Endeffektors müssen abhängig von 

den Winkeln der Gelenke berechnet werden. Dabei werden die Winkel auf 

die Koordinaten abgebildet. Die Vorwärtskinematik muss anhand von selbst 

definierten Testfällen getestet werden. Auch hier werden zwei Wochen 

veranschlagt. 

70


Im Weiteren muss eine Rückwärtskinematik in Python umgesetzt werden. 

Die Koordinaten der Gelenke des Roboterarms müssen dabei in Winkel 

umgerechnet werden. Die von der Kinematik berechneten Werte müssen 

bei dem Roboterarm von dem PC (via USB) über den FPGA ankommen. 

Hierzu sind vier Wochen eingeplant. 

Personen 

• Peter Gewald 

• Vitaliy Beguchiy 

71


2.1.4 Objektverfolgung 

Das Ziel des Arbeitspaketes Objekt Tracking ist es einen Arm zu erkennen. 

Dabei sollen am Arm die Winkel der einzelnen Gelenke berechnet 

werden. Der zu erkennende Arm befindet sich dabei vor einem einfachen 

Hintergrund, um einen guten Kontrast zwischen Vorder- und Hintergrund 

zu erreichen. Zur Unterscheidung der einzelnen Gelenke des Arms dürfen 

Markierungen verwendet werden. Die Erkennung des Arms soll am Computer 

mit Hilfe der AMiR Toolbox durchgeführt werden. Zur Aufnahme 

der Szenerie wird eine Webcam verwendet. Die Erkennung der Winkel des 

Arms erfolgt dabei zweidimensional (Breite und Höhe). Ein erstes Teilziel 

ist es, eine Hand zu erkennen und eine entsprechende Bewegung dieser 

nachzuvollziehen. Hierbei wird eine Trajektorie der Hand erschaffen. Diese 

kann für eine Erkennung von Gesten verwendet werden. Die Winkel des 

Arms werden bestimmt, um diese später an den Roboterarm zu senden. 

Zunächst wird die Webcam mit der AMiR Toolbox verbunden. Danach 

wird das erhaltene Bild mit Hilfe entsprechender Filter derart bearbeitet, 

dass die Positionen der Hand innerhalb mehrerer Bilder erkannt werden. 

Aus den Unterschieden dieser verschiedenen Positionen wird dann der 

Bewegungsvektor der Hand berechnet. Hierfür stehen zwei Wochen zur 

Verfügung. 

Die entwickelten Algorithmen zur Erkennung der Hand werden derart verfeinert, 

dass ein Arm erkannt wird. Die Gelenkpositionen des erkannten 

Arms sollen dann in entsprechende Winkel umgerechnet werden. Es sind 

drei Wochen dazu eingeplant. 

Personen 

• Patrick Elfert 

• Fabian Diefenbach 

72


73


2.2 Sprint 2 

Im Folgenden werden die Ergebnisse der Planung sowie die Dokumentation 

der Umsetzung der einzelnen Arbeitspakete ausführlich beschrieben. 

2.2.1 Machbarkeitsstudie Eye-Tracking 

In den globalen Anwendungsfällen in Abschnitt 1.2.3 des Lastenhefts, wird 

in Abschnitt 1.2.3.3 der Anwendungsfall Roboter steuern durch alternative 

Gesten beschrieben. Dieser Anwendungsfall beschreibt eine alternative 

Eingabemethode um z. B. behinderten Menschen die Verwendung des 

Roboterarms zu ermöglichen. Es wurden zwei mögliche alternative Eingabemethoden 

vorgeschlagen. Zum einen die Steuerung des Roboters durch Bewegungen 

des Kopfes und zum anderen die Steuerung durch Bewegungen 

der Augen. Dieses Arbeitspaket beschäftigt sich mit der letzteren Methode 

der alternativen Eingaben, im Folgenden als Eye-Tracking bezeichnet. Bevor 

eine alternative Eingabe auf dem FPGA implementiert wird, soll zunächst 

eine Machbarkeitsstudie über die Umsetzbarkeit des Eye-Tracking mit den 

uns zur Verfügung stehenden Mitteln durchgeführt werden. 

Nach einer Einleitung in die Thematik des Eye-Tracking werden in Abschnitt 

2.2.1.1 einige aktuell existierende Ansätze vorgestellt. Dabei wird 

auch auf FPGA-basierte Ansätze eingegangen, gefolgt von einer konkreten 

Vorstellung der Aufgabenstellung. 

Weiter erfolgt in Abschnitt 2.2.1.2 die Beschreibung der zur Studiendurchführung 

verwendeten Hard- und Softwarekomponenten. Anschließend werden 

in Abschnitt 2.2.1.3 die ermittelten Systemparameter aufgeführt. 

Darauf aufbauend werden im Abschnitt 2.2.1.4 die von uns verfolgten Ansätze 

und deren Implementierungen erläutert. Abschnitt 2.2.1.5 enthält die 

Daten der Messungen, um eine Vergleichbarkeit der Ansätze zu gewährleisten. 

Daraufhin wird in 2.2.1.6 auf die Probleme beim Entwurf sowie auf 

Schwachstellen der Ansätze, welche sich im Laufe der Studie herausgestellt 

haben, eingegangen. Abschließend wird in Abschnitt 2.2.1.7 eine Evaluation 

anhand der Ergebnisse der implementierten Ansätze durchgeführt 

und in Abschnitt 2.2.1.8 ein abschließendes Fazit gegeben. Dabei wird 

auch die Umsetzbarkeit der Ansätze auf einem FPGA betrachtetet und eine 

definitive Aussage über die Machbarkeit des Eye-Tracking im Rahmen der 

Projektgruppe getroffen. 

74


2.2.1.1 Einleitung 

In der Einleitung erfolgt eine kurze Einführung in die Grundlagen des Eye- 

Tracking. Daraufhin werden im Unterabschnitt State of the Art einige Systeme 

vorgestellt, welche das Prinzip des Eye-Tracking in unterschiedlicher 

Form anwenden. Da die Umsetzung des Systems dieser Projektgruppe 

auf Basis eines FPGAs erfolgt, muss auch auf die spezifische Realisierung 

geachtet werden. Anschließend wird die Aufgabenstellung vorgestellt. 

Grundlagen Eye-Tracking 

Das Thema Eye-Tracking behandelt im Wesentlichen 

die Registrierung einer Blickbewegung bzw. eines Blickverlaufs einer Person 

während der Betrachtung eines Objekts. (z. B. ein Bild) 

Abbildung 2.3 zeigt die möglichen Bewegungsrichtungen des Auges 2 . Das 

Auge selbst ist in der Lage Horizontal- und Vertikalbewegungen durchzuführen 

und verfügt weiterhin über eine Drehachse. 

Abbildung 2.3: Bewegungsrichtungen des Auges 

Dabei kann zwischen zwei Arten von Blickbewegungen unterschieden werden, 

der Fixation und der Sakkade. 

Bei der Fixation wird ein bestimmter Punkt im Raum mit den Augen 

fokussiert. Dieser Vorgang enthält nie eine absolute Ruheposition sondern 

wird immer durch leichte Zitterbewegungen begleitet. Eine Sakkade beschreibt 

den Sprung von einer Fixation zur nächsten. Sakkaden können dabei nicht 

bewusst kontrolliert werden. Im Durchschnitt führt das menschliche Auge 

2-3 Sakkaden pro Sekunde durch [1]. Ein Blickverlauf setzt sich somit 

aus einer zeitlich aneinandergereihten Folge von Fixationen und Sakkaden 

zusammen. Diese Blickverläufe werden beim Eye-Tracking mit unterschiedlichen 

technischen Hilfsmitteln aufgezeichnet. 

2 http://de.wikipedia.org/wiki/Augenbewegung, letzter Zugriff: 22.02.2013 

75


Dabei kann zwischen zwei Hauptmethoden von Eye-Tracking-Systemen 

unterschieden werden. Zum einen den sogenannten Überkopfsystemen (head 

mounted), welche am Kopf einer Person befestigt werden und zum Anderen 

den ferngesteuerten Systemen (remote), bei welchen eine Person nicht direkt 

mit der Kamera eines Eye-Tracking-Systems verbunden ist. 

Oft werden in Zusammenarbeit mit Eye-Tracking-Systemen Infrarotlicht- 

Quellen in Verbindung mit entsprechenden Kameras genutzt, um ein zur 

Weiterverarbeitung taugliches Bild zu erhalten. 

Anwendung findet das Eye-Tracking in unterschiedlichsten Gebieten wie 

der Marktforschung, der Psychologie oder auch der Medizin 3 . 

State of the Art 

In diesem Unterabschnitt erfolgt eine kurze Beschreibung 

einiger Eye-Tracking Umsetzungen. Dabei werden jedoch nur Systeme 

mit Hardware- und Softwarevoraussetzungen vorgestellt, die mit den 

in dieser Machbarkeitstudie verwendeten Komponenten weitestgehend übereinstimmen. 

Damit werden z. B. alle Überkopfsysteme ausgeschlossen und 

die Betrachtung auf ferngesteuerte Systeme beschränkt. 

Zur Bildverarbeitung nutzen viele Softwarebasierte Ansätze die Bibliothek 

OpenCV 4 . Einige Beispiele für Webcam basierte Low-Cost Eye-Tracking 

Lösungen werden im Folgenden aufgeführt. 

Ein erstes Beispiel ist das in Abbildung 2.4 dargestellte TrackEye 5 Projekt, 

welches auf die OpenCV Bibliothek zurückgreift und die Kopf- und Augenerkennung 

mit Hilfe eines CAMSHIFT Algorithmus [10] sowie Template 

Matching umsetzt. 

Abbildung 2.4: TrackEye Projekt 

3 http://blickinteraktion.pgraesser.de/, letzter Zugriff: 22.02.2013 

4 http://opencv.willowgarage.com/wiki/, letzter Zugriff: 22.02.2013 

5 http://www.oocities.org/zafersavas/, letzter Zugriff: 22.02.2013 

76


Weitere Projekte sind die Software opengazer 6 oder auch der von der ITU 7 

vorgestellte GazeTracker 8 . 

In den meisten Fällen sind Eye-Tracking Projekte ohne die Verwendung 

zusätzlicher Hardware jedoch als verwaiste Projekte aufzufinden und kaum 

Gegenstand aktueller Studien. 

FPGA spezische Realisierung 

Da das endgültige System der Projektgruppe 

auf Basis eines FPGAs arbeiten soll, müssen einige Eigenschaften 

von FPGAs in Betracht gezogen werden. Für Informationen zur FPGA eigenen 

Architektur wird an dieser Stelle auf [15] verwiesen. 

Dies bedeutet in erster Linie, die Umsetzbarkeit von einem in Software 

verwendeten Algorithmus auf einen in Hardware lauffähigen Algorithmus 

in die Studie mit einzubeziehen. Daher können bereits einige Algorithmen 

der OpenCV Bibliothek ausgeschlossen werden, da diese nur mit hohem 

Aufwand bzw. in begrenztem Maße in Hardware umgesetzt werden können. 

Algorithmen mit einem hohen Bedarf an Speicherplatz sowie auch Algorithmen 

mit der Anwendung von Random Access zugriffen sollten daher 

gemieden werden, da die Verarbeitung auf einem FPGA möglichst streambasiert 

ablaufen soll. Rechenaufwendig sind daher auch alle Algorithmen, 

die ein gesamtes bzw. einen großen Teil eines Bildes für bestimmte Operationen 

benötigen. Operationen wie das Template Matching sind daher 

FPGA technisch durchaus umsetzbar, jedoch stark abhängig von der 

Größe eines Templates und der zur Verfügung stehenden Rechenleistung 

des FPGAs. Am vorteilhaftesten für die Umsetzung mittels FPGAs sind die 

Gruppe der Punktoperationen, da hier direkt auf einem Stream gearbeitet 

werden kann. Dies gilt auch für Nachbarschaftsoperationen, wobei hier auf 

die Größe der Nachbarschaft geachtet werden muss. Weitere Operationen 

wie der Median Filter, der Threshold oder morphologische Operationen 

sind weitestgehend problemlos in Hardware implementierbar. 

Die Probleme der Verwendung von Bildverarbeitungsalgorithmen auf einem 

PC wie eventuellen Timing Einschränkungen oder auch einer begrenzten 

Bandbreite durch unterschiedliche Schnittstellen fallen bei Nutzung eines 

FPGAs deutlich weniger ins Gewicht. 

In [14] wird eine FPGA basierte Umsetzung des Template Matching auf 

Basis von Distanztransformationen 9 vorgestellt. 

6 http://www.inference.phy.cam.ac.uk/opengazer/, letzter Zugriff: 22.02.2013 

7 IT University of Copenhagen, Denmark 

8 http://www.gazegroup.org/downloads/23-gazetracker, letzter Zugriff: 22.02.2013 

9 Jedem Pixel eines Segments wird sein kleinster Abstand zum Segmentrand zugewiesen 

77


An dieser Stelle soll zur genaueren Definition der Gruppe von FPGA umsetzbaren 

Bildverarbeitungsalgorithmen auf [3] sowie die erarbeiteten Reviewpaper 

[9] und [16] verwiesen werden. 

Aufgabenstellung 

Das Arbeitspaket wird in drei Teilziele aufgeteilt. Erstes 

Teilziel ist die Erkennung der Augen auf einem mit Hilfe der Webcam 

aufgenommenen Bild. Im zweiten Schritt soll die Verfolgung der Augen 

auf einem Videostream realisiert werden, um daraufhin im letzten Teilziel 

eine Blickrichtung bestimmen und visualisieren zu können. 

2.2.1.2 Systemdenition 

In diesem Abschnitt erfolgt die Beschreibung der verwendeten Hardware 

sowie der eingesetzten Software Tools. 

Hardware 

Zu Anfang der Studie wurde bereits festgestellt, dass eine Infrarotlicht-Quelle 

zur besseren Erkennung der Augen eingesetzt werden 

sollte. Da die zur Verfügung gestellte Webcam Logitech C270 jedoch mit 

einen Infrarot-Sperrfilter ausgestattet ist, wurde stattdessen das in Abbildung 

2.5 gezeigte Kameramodell DMK21F04 der Fa. The Imaging Source 

verwendet. Die Bildaufnahme erfolgt dabei Monochrom mit einer Auflösung 

von 640x480 Pixeln bei einer maximalen Bildwiederholrate von 30fps. 

Abbildung 2.5: Kamera DMK21F04 

Des Weiteren wurden zwei Infrarot-Scheinwerfer der Fa. Kemo Electronic 

sowie ein PC eingesetzt. 

Software 

Zur Entwicklung der Bildverarbeitungskette so wie einer zugehörigen 

Automatisierung wurde die OFFIS Automation Toolbox Software 

eingesetzt, die eine komfortables Testen und Entwickeln von Filterketten 

78


erlaubt. Die Erstellung einer Automatisierung wird unterstützt, indem durch 

die Skriptsprache Python auf Filterparameter zugegriffen und diese separat 

verarbeitet oder auch gesetzt werden können. 

Zur Konfiguration der Kamera wurde die mitgelieferte Software IC Capture 

2.2 10 genutzt. 

Aufbau 

Im Laufe der Studie wurden zwei Aufbauten zur Bildaquise genutzt. 

(a) mit einem Infrarot- 

Scheinwerfer 

(b) mit zwei Infrarot- 

Scheinwerfern 

Abbildung 2.6: Aufbauten 

Der erste Aufbau gestaltet sich wie in Abbildung 2.70(a) und basiert auf 

einem Infrarot-Scheinwerfer. Dabei wurde die Kamera an einem, vom Monitor 

unabhängigen, beweglichen Standfuß befestigt. Der Infrarot-Scheinwerfer 

wurde über die Kamera und in Richtung der Blickachse dieser montiert. 

Der zweite Aufbau gestaltet sich wie in Abbildung 2.70(b) und nutzt zwei 

Infrarot-Scheinwerfer. Dabei wurden die Kamera, sowie beide Infrarot- 

Quellen direkt am Monitor befestigt. Die Scheinwerfer befinden sich hier 

links und rechts neben der Kamera, liegen ebenfalls auf der gleichen 

Blickachse. 

2.2.1.3 Systemparameter 

Da ein kamerabasiertes System von einer Vielzahl an Umgebungsvariablen 

abhängig ist, werden in diesem Abschnitt die wichtigsten Systemparameter 

aufgeführt und die jeweiligen Einflüsse beschrieben. 

10 http://www.theimagingsource.com/de_DE/products/software/enduser/ 

iccapturetis/ 

79


(a) mit eingeschalteter Raumbeleuchtung 

(b) ohne eingeschaltete Raumbeleuchtung 

Lichtquellen: 

Abbildung 2.7: Raumbeleuchtung 

Einen starken Einfluss auf das resultierende Bild haben sämtliche 

Lichtquellen in der Umgebung. Wie in Abbildungen 2.7(a) und 2.7(b) zu 

erkennen, konnte tagsüber ein erheblicher Unterschied bei der Bildaquise 

festgestellt werden, der mit Ein- und Ausschalten der Raumbeleuchtung 

einher ging. 

(a) Kameraposition: frontal 

(b) Kameraposition: von unten 

Abbildung 2.8: Kameraposition 

80


Kameraposition: 

Der Winkel sowie der Abstand der Kamera zum Benutzer 

stellen einen weiteren wichtigen Faktor da. Je nach Kameraposition 

sind in Abbildungen unter 2.8 starke Unterschiede im Schattenwurf um 

die Augen erkennbar. 

(a) Mit Beleuchtung durch einen IR- (b) Mit Beleuchtung durch zwei IR- 

Scheinwerfer 

Scheinwerfer 

Abbildung 2.9: Infrarot-Scheinwerfer 

Infrarotscheinwerfer Position: 

Die Position der Infrarot-Lichtquellen sollte 

möglichst auf einer Achse mit der Blickrichtung der Kamera liegen, um 

eine maximale Ausleuchtung der Gewünschten Bereiche zu erlangen. Die 

Unterschiede sind deutliche in Abbildungen 2.9(a) und 2.9(b) zu erkennen. 

Kameraeinstellungen: 

In Bezug auf die Kameraeinstellung hat sich der 

automatische Weißabgleich 11 als sehr störend erwiesen, da dieser die Einstellungen 

der Kamera dynamisch ändert und damit das Erstellen einer 

stabilen Filterkette erschwert. Der Automatismus sollte daher ausgeschaltet 

werden. 

2.2.1.4 Ansätze 

Im Laufe der Machbarkeitsstudie wurden zwei Ansätze verfolgt, die im 

Folgenden schrittweise vorgestellt werden. Die Implementierung erfolgt 

über die Filter- sowie Automationsfunktion der OFFIS Toolbox und die 

Skriptsprache Python. 

11 gleicht das Gesamtbild auf die hellste erkannte Stelle an 

81


Erster Ansatz: Template Matching und Blob Tracking 

Im ersten Ansatz 

wird das Template Matching Verfahren in Kombination mit einem Blob 

Tracking eingesetzt. Den Ablauf regeln dabei drei, in Abbildung 2.10 dargestellte, 

Prozessoren. 

Abbildung 2.10: Reihenfolge und Prioritäten der Prozessoren 

82


Der Input Prozessor in Abbildung 2.11 dient lediglich zum einbinden der 

Kamera sowie zum Setzen einer ersten region of interest (ROI), welche das 

Bild auf den Bereich der Augen und des Referenzpunktes einschränkt, in 

dem sich ein Benutzer im weiteren Verlauf aufhalten muss. 

Abbildung 2.11: Input Processor 

Abbildung 2.12 zeigt den Eye-Tracking Prozessor. 

Das Template Matching wird für die Detektion der Augen verwendet. Dazu 

wird zu Beginn jedes Skript-Durchlaufs ein Template des rechten Auges 

erzeugt. Die Templateeigenschaften sollten dabei weitestgehend mit Abbildung 

2.13(a) übereinstimmen. 

83


Abbildung 2.12: Eye-Tracking Processor 

Die Abbildungen 2.13(b) und 2.13(c) zeigen andere Templates, welche aufgrund 

übermäßiger oder unzureichender Erkennungsmerkmale zu Problemen 

beim Template Matching führen. Das Template in Abbildung 2.13(b) 

zeigt ein sehr sauberes Template der Iris mit der Pupille. Dieses Template 

führt beim Template Matching zu Fehlern bei der Detektion, da z. B. dunkle 

Augenbrauen oder Augenringe als Augen erkannt werden, wie in Abbildung 

2.14(a) zu sehen ist. In Abbildung 2.13(c) wurde als Template zusätzlich 

eine größere Umgebung um die Iris mit aufgenommen. 

84


(a) Kompromisslösung 

mehrerer Augentemplates 

(b) Spezifische 

Lösung 

mit wenig 

Information 

(c) Spezifische 

Lösung mit 

viel Information 

Abbildung 2.13: Formen unterschiedlicher Augentemplates 

Diese führt zu einer besseren Erkennungsrate des Auges, von dem das 

Template erzeugt wurde. Es führt aber ebenfalls dazu, dass die Erkennungsrate 

des zweiten Auges sinkt. Weiterhin wird das Auge mit dem 

Template nicht gefunden, wenn die Iris zu weit von der zentralen Position 

abweicht, da das aktuelle Bild in dieser Situation wiederum stark vom 

aufgenommenen Template abweicht. 

(a) Mittelpunkte aller erkannten 

Regionen, inklusive der Augenbrauen 

(b) Ergebniskarte eines schlechten 

Templates (Hell bedeutet eine 

hohe Übereinstimmung) 

Abbildung 2.14: Probleme beim Template Matching 

Auf der vorgestellten Filterkette in Abbildung 2.12 arbeitet nun eine in 

Python geschriebene Automatisierung. Diese initialisiert zu Anfang alle 

wichtigen Filter mit manuell bestimmten default Werten. Daraufhin werden 

die zwei ROI’s für den Augenbereich sowie das rechte Auge gesetzt. 

Ein Benutzer wird nun aufgefordert, sein rechtes Auge in der angezeigten 

ROI zu positionieren und mit einem Klick auf Take Template zu bestätigen. 

Ist das aufgenommene Template ausreichend, so kann die Selection OK? 

Frage mit yes beantwortet werden. Dieser Vorgang sollte so oft wiederholt 

werden, bis ein brauchbares Template aufgenommen wurde. 

Sobald das Template erzeugt wurde darf die kleinere ROI wieder mit der 

85


Iris verlassen werden. Das Resultat des Template Matching stellt sich wie 

in Abbildung 2.14(b) dar. Aus dieser Ausgabe werden mit einem Threshold 

Objekte mit zu geringer Übereinstimmung entfernt und anschließend 

eine morphologische Operation (Dilatation) genutzt um zusammenhängende 

Flächen zu erzeugen. Auf das erhaltene Bild wird nun ein Blob Detection 

Filter gelegt, der einen Datensatz liefert, welcher mögliche Kandidaten 

für Augen enthält. Dieser Datensatz wird im Anschluss gefiltert, um das 

gewünschte Augenpaar zu extrahieren. 

Um nun die Positionen der Augen zu verfolgen wird mit dem Moments 

Filter das Center of Gravity (CoG) der Blobs berechnet. 

Filtern des Augenpaares 

Interessant ist die Filterung des Blob Datensatzes 

auf ein Augenpaar. Die Filterung arbeitet direkt auf den erhaltenen 

CoG’s des Eye-Tracking Blob Datensatzes. Im ersten Filterschritt wird überprüft, 

ob mindestens zwei Objekte gefunden wurden. Daraufhin werden 

Augenpaare behalten, die bis auf ein festgelegtes y-Offset auf einer Linie 

liegen. Die nun gefilterten, möglichen Augenpaare werden im folgenden 

Schritt auf eine minimale Distanz zwischen den ermittelten Augen in x- 

Richtung überprüft. Die übrig gebliebenen Objekte werden als Augenpaar 

übergeben. 

Der Referenz Prozessor ist in 2.15 abgebildet und arbeitet auf der gleichen 

ROI wie der Eye-Tracking Prozessor. Die Verarbeitungskette beschränkt 

sich jedoch auf ein Thresholding, gefolgt von einer morphologischen Operation 

(Opening) und einer Blob Detektion. Wiederum wird das CoG der 

erkannten Blobs berechnet und ein Datensatz möglicher gefundener Referenzpunkte 

erstellt. 

Im nächsten Schritt muss ein Koordinatensystem erstellt werden, um die 

Blickrichtung zu erhalten. Hierzu wird eine Kalibrierung durchgeführt. Da 

in den Anforderungen festgelegt wurde, das kein Überkopfsystem eingesetzt 

wird, muss ein zusätzlicher Referenzpunkt eingeführt werden. Dieser 

ist notwendig, da zu erwarten ist, dass der Benutzer seinen Kopf während 

der Arbeit mit dem System nicht immer Still in derselben Position hält. 

Diese Bewegungen des Kopfes führen zu einer ständigen Bewegung der 

Augen, welche die Bestimmung der Blickrichtung der Augen ohne einen 

Referenzpunkt mit unseren Mitteln nicht möglich macht. Dieser Referenzpunkt 

muss sich dabei gleich zu den Kopfbewegungen verhalten, dabei 

aber in einer fixen Position zu den Augen befinden. Für die Machbarkeitsstudie 

wird eine schwarze Markierung auf der Stirn angebracht, siehe 2.16(a). 

Der Referenzpunkt wird mit einer eigenen Filterkette identifiziert, welche 

parallel zur ersten Filterkette läuft, die zur Abwicklung der Augenerken- 

86


Abbildung 2.15: Reference Processor 

nung genutzt wird. Es werden hierbei ein Threshold und eine morphologische 

Operation (Opening) auf dem Bild angewendet. 

87


Diese vorverarbeiteten Daten werden anschließend invertiert und durch 

eine Blob Detektion geführt, sodass ein Datensatz möglicher Referenzpunkte 

bestimmt werden kann. Um nun den exakten Referenzpunkt aus dem 

vorliegenden Datensatz zu gewinnen wird ein Pythonskript eingesetzt. 

Dabei werden die zur Verfügung stehenden Informationen über den Bereich 

in dem sich der Referenzpunkt befinden muss genutzt. 

(a) Anbringung des Referenzpunktes 

(b) Identifizierung des 

Referenzpunktes 

Abbildung 2.16: Referenzpunktes 

In Abbildung 2.16(a) ist der am Benutzer angebrachte Referenzpunkt zu sehen 

und in Abbildung 2.16(b) der eingeschränkte Suchbereich, in welchem 

der Referenzpunkt gesucht wird. 

Filtern des Referenzpunktes 

Interessant ist die Filterung des Blob Datensatzes 

auf den Referenzpunkt. Diese Filterung arbeitet ebenfalls direkt auf 

den erhaltenen CoG’s des Referenz Blob Datensatzes und erfolgt im gleichen 

Schritt wie die Ermittlung eines Augenpaares, da der Referenzpunkt 

zu jedem Zeitpunkt fest an der Stirn des Benutzers angebracht wurde. 

Der Blob Datensatz wird daher zuerst auf die Region zwischen und über 

dem ermittelten Augenpaar eingeschränkt. Aufgrund von Problemen durch 

z. B. erkannte dunkle Augenbrauen wird nun der höchste gefundene Referenzpunkt 

ausgewählt und übergeben. Ab diesem Punkt wird im Ansatz 

davon ausgegangen, dass stabil beide Augen und der Referenzpunkt gefunden 

werden. 

Zweiter Ansatz: Blob Tracking 

Im zweiten Ansatz wird die Erkennung 

der Augen sowie des Referenzpunktes über ein gemeinsames Blob Tracking 

realisiert. Abbildung 2.17 zeigt die zugehörige Filterkette, welche wesentlich 

kürzer ist als die des ersten Ansatzes und daher in einem Prozessor untergebracht 

ist. 

88


Abbildung 2.17: Blob Tracking Processor 

Im ersten Schritt wird eine ROI auf das Bild gelegt, in der sich im folgenden 

Verlauf der Kopf des Benutzers befinden muss. Nach einer Bildvorver- 

89


arbeitung durch einen Threshold sowie morphologischer Operationen (Dilatation 

und Opening) kann ebenfalls auf dem ermittelten Blob Datensatz 

gearbeitet werden. Hier kommt, wie auch im ersten Ansatz, die Automatisierung 

zum Einsatz. Zur Ermittlung der Augen und des Referenzpunktes 

wird in diesem Fall auf Rechtecken sowie auch CoG’s gearbeitet. 

Aufgrund der Position die durch die ROI gefordert wird, kann davon ausgegangen 

werden, dass sich das Augenpaar nicht im obersten oder unterstem 

Viertel der ROI befindet. Daher werden diese Bereiche bei der 

Suche nach den Augen ausgeschlossen. Die ROI ermöglicht außerdem Einschränkungen 

in Bezug auf die minimale und maximale Distanz der Augen 

festzulegen. Zu diesem Zeitpunkt liegt nur eine eingeschränkte Menge an 

Blobs vor, die potentiell Augen sein können. 

Filtern des Augenpaares 

Die Filterung der Augen sowie des Referenzpunktes 

erfolgt in diesem Fall auf dem gleichen Blob Datensatz. Dieser 

wird im ersten Schritt auf ein mögliches Augenpaar durchsucht. Nach einer 

manuellen Einschränkung des y-Suchraums wird jedes überbleibende, 

mögliche Auge mit jedem anderen verglichen. Dabei werden nur Objekte 

in der Liste behalten, die einen Partner mit einem Offset auf der Y-Ebene 

um max. 5% besitzen. Paare, die einen, durch Tests ermittelten, zu großen 

oder zu kleinen Abstand in der X-Ebene besitzen werden ebenfalls gefiltert. 

Bleiben im Anschluss an diese Filteroperationen noch genug Daten erhalten, 

werden diese sortiert und als valides Augenpaar übergeben. 

Um ein Augenpaar zu identifizieren werden alle Blobs, welche die bisherige 

Filterung bestanden haben, ausgewertet. Aufbauend auf einem validen 

Augenpaar wird, wie schon im Template Matching Ansatz, der Refenzpunkt 

gesucht. 

Filtern des Referenzpunktes 

Wurde ein Augenpaar identifiziert, wird 

im nächsten Schritt der Blob Datensatz auf einen validen Referenzpunkt 

durchsucht. Dazu werden, wie auch im ersten Ansatz nur Objekte betrachtet, 

welche in der Region über und zwischen dem zuvor identifizierten 

Augenpaar liegen. Dies ist durch den Anbringungspunkt des Referenzpunktes 

mittig zwischen den Augen möglich, siehe Abbildung 2.16(a). Aufgrund 

der bekannten Maße des Referenzobjekts werden im Folgeschritt nur die 

Objekte behalten, deren Höhe größer als die Breite ist. Sobald ein Referenzpunkt 

identifiziert wurde, wird die Suche unterbrochen und der gefundene 

Referenzpunkt übergeben. Nachdem nun valide Augenpaare und der 

Referenzpunkt erfasst werden können, erfolgt eine Kalibrierung. 

90


Diese erfolgt analog zum ersten Ansatz, über drei Punkte auf der Arbeitsfläche. 

Der weitere Ablauf erfolgt ebenfalls wie im Template Matching 

Ansatz. Die drei Datensätze der Kalibrierung werden auf ein gemeinsames 

Koordinatensystem umgerechnet, welches sich am Referenzpunkt 

des ersten Kalibrierungspunktes orientiert. Somit kann ab diesem Punkt 

die Blickrichtung, wie bereits beim Template Matching Ansatz, auf der Arbeitsfläche 

verfolgt werden. 

Kalibrierung 

Als nächster Schritt folgt eine Kalibrierung. Dabei muss der 

Benutzer nacheinander drei Punkte auf dem Bildschirm fokussieren. Hierzu 

müssen nacheinander die Mitte, die obere Rechte sowie die untere 

Linke Ecke der Arbeitsfläche mit beiden Augen fixiert und mit einem Klick 

auf den entsprechenden Button bestätigt werden. An allen drei Punkten 

wird jeweils die Position beider Augen und des Referenzpunktes aufgenommen. 

Aufbauend auf diesen drei Positionen wird ein Koordinatensystem 

aufgebaut. An dieser Stelle ist zu erwähnen, dass das Ziel nicht die Umsetzung 

mit Hilfe von Tiefeninformationen beinhaltet. Es wird der Blickpunkt 

auf der Arbeitsfläche bestimmt, heißt eine reine Position in der X- 

/Y-Ebene. Als Arbeitsfläche wird hier der Bildschirm verwendet. Dieser 

wird in Quadranten unterteilt in denen sich der Blickpunkt des Benutzers 

befindet. Die Quadrantenunterteilung erfolgt in einem 3x3 Raster, zu sehen 

in Abbildung 2.20. Um den Blickpunkt zu bestimmen muss zunächst 

eine Kalibrierung durchgeführt werden. Dabei muss der Blickpunkt auf die 

äußeren Ränder des Arbeitsbereichs gemappt werden. Da in der Studie der 

Bildschirm der Arbeitsbereich ist wird ein Kalibrierungsbild 2.18 verwendet. 

Abbildung 2.18: Kalibrierungsbild um die Ecken des Anzeigefläche zu 

erkennen 

91


Kalibrieren des Augenpaares auf den Referenzpunkt 

Um dem System 

eine gewisse Stabilität gegenüber Kopfbewegungen zu verschaffen, wird 

in jedem Durchlauf das ermittelte Augenpaar auf den ermittelten Referenzpunkt 

kalibriert. Eine Darstellung dieses Vorgangs erfolgt in Abbildung 

2.19. Dabei wird die Position des Referenzpunktes bei der Aufnahme des 

Blickpunkts im Mittelpunkt der Arbeitsfläche als Basis verwendet, dargestellt 

in Abbbildung 2.19. Anschließend wird die Abweichung der Position des 

Referenzpunktes der beiden anderen Kalibrierungspunkte zum Referenzpunkt 

der Basis berechnet. Diese Abweichung wird auf die beiden anderen 

Referenzpunkte und die Blickpunkte angerechnet. Nach diesem Schritt 

sind die Kalibrierungspunkte 

1. 

alle auf einen Refenzpunkt geeicht. Weiterhin 

ist die Blickrichtung der Augen in Referenz zum Referenzpunkt auf 

die Arbeitsfläche gemappt. Nachdem die Kalibrierung auf einen Referenzpunkt 

erfolgt ist, kann der aktuelle Blickpunkt 2. der Augen auf der Arbeitsfläche 

bestimmt werden. Der Schritt der Kalibrierung der Position der 

Augen und 

1. 

des Referenzpunktes auf die Position des Referenzpunktes der 

Kalibrierung muss bei jeder Aquise der Positionen erfolgen. 

1. 

2. 3. 

2. 

Abbildung 2.19: Bewegung der CoGs zwischen zwei Kalibrierungspunkten 

Ist die Kalibrierung erfolgt, kann der eigentliche Ablauf beginnen. In jedem 

Durchlauf werden nun die Augen sowie 

3. 

der Referenzpunkt ermittelt, um 

die aktuelle Augenposition zu bestimmen. Diese wird auf einem in neun 

Quadranten eingeteilten Bild auf dem Monitor dargestellt. 

Abbildung 2.20 zeigt die genutzte neun Quadranten Einteilung. 

2.2.1.5 Messungen 

Um die Ergebnisse beider Ansätze zu analysieren sowie Vergleiche ziehen 

zu können, wurden zwei unterschiedliche Messungen durch zwei Testpersonen 

vorgenommen. Zur Aufnahme der Messdaten wurden die Python 

Skripte jeweils um ein Statistik-Panel erweitert. 

Erkennungsrate 

3. 

Die erste Messung dient zur Einstufung der Erkennungsraten 

beider Ansätze. Eine erfolgreiche Erkennung beinhaltet dabei die Fil- 

92


Abbildung 2.20: Quadrantenaufteilung zur Visualisierung 

terung eines validen Augenpaares sowie eines validen Referenzpunktes. 

Die Daten basieren dabei auf Messungen zweier Testpersonen. In den folgenden 

Tabellen 2.1 und 2.2 sind die Ergebnisse aufgeführt. Wichtig ist der 

Vergleich zwischen der Anzahl aller Filteraufrufe und der Anzahl aller erfolgreichen 

Filteraufrufe, in welchen Augenpaar und Referenzpunkt erkannt 

wurden. 

Abbildung 2.21 zeigt die zur Messung gehörende Aufnahme der Testpersonen 

in der bereits eingeschränkten ROI. 

(a) Testperson 1 (b) Testperson 2 

Abbildung 2.21: Aufnahme des Eingangsbildes der ersten Messung 

93


Die Messungen erfolgen dabei mit optimalen Filtereinstellungen für die 

jeweilige Testperson, welche nach der Kalibrierungsphase den in Abbildung 

2.22 dargestellten Weg mit den Augen verfolgt. 

Abbildung 2.22: Festgelegter Blickweg der ersten Messung 

94



Tabelle 2.1 enthält 

die Werte der Messungen für den ersten Ansatz. 

Messung 

Filteraufrufe 

Augenpaare 

Erkannte 

Augenpaare 

Filteraufrufe 

Referenzpunkt 

Erkannte 

Referenzpunkte 

1 450 404 404 404 

2 450 350 350 350 

3 480 330 330 330 

1 419 252 252 252 

2 501 327 327 326 

3 431 283 283 283 

Tabelle 2.1: Messwerte der Erkennungsrate des ersten Ansatzes 

Aus den gewonnenen Messwerten errechnet sich eine mittlere Erkennungsrate 

der Augenpaare von 71, 2%. Nach einem erkannten Augenpaar wird in 

diesem Ansatz die Suche nach einem Referenzpunkt gestartet. Die mittlere 

Erkennungsrate des Referenzpunktes nach bereits erkanntem Augenpaar 

liegt bei 99, 9%. 

Das endgültige Ergebnis ist daher hauptsächlich von der Erkennung der 

Augen abhängig und es ergibt sich eine mittlere gesamte Erkennungsrate 

von 71, 19% für den ersten Ansatz. 


Tabelle 2.2 enthält die Werte der Messungen 

für den zweiten Ansatz. 

Messung Filteraufrufe 

gesamt 

Erkannte 

Augenpaare 

Erkannte 

Referenzpunkte 

1 1223 1215 1215 

2 1250 1203 1203 

3 1265 1239 1239 

1 1223 1134 1134 

2 1255 874 874 

3 1210 1057 1057 

Tabelle 2.2: Messwerte der Erkennungsrate des zweiten Ansatzes 

In diesem Ansatz werden Augenpaar und Referenzpunkt aus dem gleichen 

Blob Datensatz gewonnen. Aus den aufgenommenen Messwerten ergibt 

95


sich eine mittlere gesamte Erkennungsrate der Augenpaare und Referenzpunkte 

von 90, 5%. 

Quadrantenstabilität 

Die zweite Messung dient zur Einstufung der stabilen 

Erkennung eines in Abbildung 2.20 dargestellten Quadranten. Dabei 

fixiert eine Testperson direkt nach der Kalibrierung einen vorher definierten 

Quadranten. Während der Messung wird nun geprüft, wie oft der ermittelte 

Blickpunkt im richtigen, heißt von der Testperson fest fixierten, Quadranten 

liegt. In den folgenden Tabellen 2.3 und 2.4 sind die Ergebnisse 

aufgeführt. Wichtig ist der Vergleich zwischen der Anzahl aller während 

der Messung erfassten Quadranten und der Anzahl aller stabilen Quadranten. 

Abbildung 2.23 zeigt die zur Messung gehörende Aufnahme der Testpersonen 

in der bereits eingeschränkten ROI. 

(a) Testperson 1 (b) Testperson 2 

Abbildung 2.23: Aufnahme des Eingangsbildes der zweiten Messung 


Tabelle 2.3 enthält 

die Werte der Messungen für den ersten Ansatz. 

Messung Quadrantenaufrufe 

gesamt 

stabile 

Quadrantenaufrufe 

1 428 156 

2 425 217 

3 386 124 

1 432 103 

2 440 126 

3 412 133 

Tabelle 2.3: Messwerte der Quadrantenbestimmung des ersten Ansatzes 

96


Es errechnet sich eine gemittelte stabile Quadrantenstabilität von 34, 1% für 

den ersten Ansatz. 

Zweiter Ansatz 

Tabelle 2.4 enthält die Werte der Messungen für den ersten 

Ansatz. 

Messung Quadrantenaufrufe 

gesamt 

stabile 

Quadrantenaufrufe 

1 996 846 

2 1008 741 

3 920 741 

1 935 619 

2 620 515 

3 1077 570 

Tabelle 2.4: Messwerte der Quadrantenstabilität von Ansatz 2 

Es errechnet sich eine gemittelte stabile Quadrantenbestimmungsrate von 

73, 5% für den zweiten Ansatz. 

2.2.1.6 Probleme 

Dieser Abschnitt beschäftigt sich mit den bei der Implementierung aufgetretenen 

Probleme und Hindernisse. Es wird dabei sowohl auf allgemeine 

Probleme des Eye-Trackings als auch auf spezielle Probleme beider Ansätze 

eingegangen. 

Allgemein 

Hier werden die Probleme beschrieben, welche allgemein für 

beide aufgeführten Ansätze gelten. 

Diese allgemeinen Probleme beziehen sich auf die in Abschnitt 2.70(a) 

beschriebenen Aufbauten. Eine Problemgruppe, welche aus unterschiedlicher 

Kamera- bzw. Infrarot-Scheinwerfer-Position entsteht, ist die der Reflektion. 

Daraus resultiert, dass bei Benutzung des Systems eine definiert 

eingeschränkte Umgebung vorausgesetzt werden muss. Ein weiteres Problem 

ist der Schattenwurf aufgrund von unterschiedlichen Lichtverhältnissen. 

Dieser konnte im zweiten Ansatz durch Einsatz des zusätzlichen Infrarot- 

Scheinwerfers jedoch weitestgehend aufgehoben werden. Weiterhin sichern 

die durch den Referenzpunkt kompensierten Kopfbewegungen das System 

nicht gegen die in Abschnitt 2.2.1.1 beschriebenen Sakkaden ab, welche daher 

zu einer instabilen Zuordnung der Blickrichtung und daraus folgender, 

schwankender Präzision führen. 

97


(a) keine Spiegelung 

(b) starke Spiegelung 

Abbildung 2.24: Probleme die durch das Tragen einer Brille entstehen 

Auch hat sich das Tragen einer Brille als negativ bei der Erkennung herausgestellt, 

zu sehen in Abbildungen 2.24. Spiegelungen der Gläser sowie ein 

dunkles Brillengestell führten zu Problemen bei der Erkennung. 


traten weiterhin die folgenden Probleme auf: 

Im ersten Ansatz 

Durch das Template Matching können zwar gute Ergebnisse bei der Augenerkennung 

erreicht werden, jedoch ist die Aufnahme eines brauchbaren 

Templates für ein benutzbares System schwer umsetzbar, was in einer starken 

Templatebhängigkeit resultiert. Dies begründet sich darin, dass das Template 

aufgenommen wird während der Benutzer frontal in die Kamera schaut. 

Dadurch kann es in Folge dazu kommen, dass das Template nicht ausreicht, 

um die Augen bei der Kalibrierung korrekt zu erkennen. Zusätzlichen 

Einfluss nehmen die Lichtverhältnisse zum Aufnahmezeitpunkt des Templates. 

Mit dem gewählten Aufbau als ferngesteuertes System und dem 

somit festgelegten Aufenthaltsbereich des Benutzers geht ebenfalls eine 

maximale Auflösung der erhaltenen Bilder einher. Dies führt zu einer mangelhaften 

Qualität des Templates, welche auch die Qualität der Erkennung 

durch das Template Matching negativ beeinflusst. Es führt z. B. zu einer 

fehlerhaften Erkennung bei dunklen Augenbrauen, Wimpern oder auch 

am Haaransatz und ist daher stark von persönlichen Merkmalen eines 

Benutzers abhängig. Die Arbeit mit einem Referenzpunkt hat zur Folge, 

dass in diesem Ansatz eine zusätzliche Verarbeitungskette zur Erkennung 

aufgebaut werden musste. 

Auf einem FPGA wäre der im ersten Ansatz vorgestellte Algorithmus zwar 

umsetzbar, siehe 2.2.1.1, da jedoch mit einer Vielzahl von Filtern gearbeitet 

wird sehr aufwendig zu implementieren. 

98



Nachdem festgestellt wurde, dass der 

erste Ansatz keine ausreichende Stabilität gewährleistet und sich weiter 

nicht für ein Mehrbenutzersystem eignet, wurde mit der Ausarbeitung 

des zweiten Ansatzes begonnen. Dieser Ansatz bringt auf den ersten Blick 

weniger spezielle Probleme mit sich, die im ersten Teil dieses Abschnitts erläuterten, 

allgemeinen Probleme bleiben jedoch weiterhin bestehen. Dazu 

zählen die Probleme der Reflektion ebenso wie die Probleme von Spiegelung 

und Schattenwurf. Da bis zum Ende der Studie keine speziellen Probleme 

auf den Ansatz zurückzuführen zu sind, entfällt eine Aufzählung. 

Verbesserungsvorschläge 

Aufgrund der begrenzten Zeit der Studie konnten 

nicht sämtliche Ideen und Ansätze vollständig umgesetzt werden. Daher 

werden im Folgenden einige dieser Ideen aufgelistet. 

• Testen weiterer Aufbauten, Infrarot-Scheinwerfer, z. B. seitlich vom 

Benutzer 

• Verwendung einer Kamera mit höherer Auflösung. (Wurde in der 

Studie nicht durchgeführt, da bereits von der laut Sprintbeschreibung 

zu verwendenden Kamera abgewichen wurde) 

• Erweiterung der Blob Filterketten 

– Verbesserte Einordnung in Quadranten durch Mittelwertbildung 

– Verbesserte Einordnung in Quadranten durch Einführung von 

virtuellen Abständen zwischen einzelnen Quadranten, siehe Abbildungen 

2.25(a) und 2.25(b) 

• weitere Ausführung des zweiten Ansatzes 

2.2.1.7 Evaluation 

Basierend auf den Ergebnissen der Messungen in Abschnitt 2.2.1.5 wird 

nun die Leistungsfähigkeit beider Ansätze evaluiert. Dabei kann nur begrenzt 

ein Vergleich zu bestehenden Ansätzen gezogen werden, da diese 

Projekte meist nur Ansätze, nicht gepflegt oder nicht mehr verfügbar sind. 

Das Projekt mit dem besten Bezug zum Inhalt dieser Studie ist das Projekt 

GazeTracker 12 , welches sowohl mit Überkopf-, als auch mit ferngesteuerten 

Kameras arbeitet. Bei der Nutzung als ferngesteuertes System 

12 http://www.gazegroup.org/downloads/23-gazetracker, letzter Zugriff: 22.02.2013 

99


Q1 Q2 Q3 

Q1 Q2 Q3 

The application is intended to run on a Microsoft platform. The main 

Q4 Q5 Q6 

Q4 

Q6 

Q5 

initial release was Windows XP SP3 using the latest Microsoft .Net 3 

downloaded at http://www.microsoft.com/NET/. 

Q7 Q8 Q9 

Make sure that you have installed the drivers for your camera and tu 

(a) Quadratisch 

(b) Parabol 

(nightmode). In some cameras this can be achieved through software se 

Abbildung 2.25: the weitere light mögliche sensor, possibly Einteilungen with nonopaque zur Quadrantenbestimmung 

into a folder of your choice and double click the GazeTracker.ex 

plastic tape. After downlo 

archive 

From here on the ITU Gaze Tracker v1.0 will be referred to as the GT. 

wird empfohlen mit einer HD-Kamera und eventuell einem zusätzlichem 

Zoom-Objektiv zu Configuration 

arbeiten. Dies führt dazu, dass die Kamera eine ähnliche 

Ausgabe wie eine Überkopf-Kamera erzeugt, siehe Abbildung 2.26. Ähnlich 

unserem zweiten Ansatz werden beim Projekt GazeTracker ebefalls 

zwei Infrarotlicht-Quellen eingesetzt. 

Main application screen 

Q7 

Q8 

Q9 

When launching the GT the o 

Setup button. This is where yo 

calibration options and proc 

mouse etc. 

The Calibrate button starts th 

values specific during the Setup 

After accepting a calibration th 

Abbildung 2.26: Kamerabild vom GazeTracker 

Activating the Setup button w 

access to all configurable param 

Erster Ansatz: Template Matching und Blob Tracking Der there erstewill Ansatz be saved every t 

ist technisch umsetzbar. Die Implementierung erfordert dabei minimized. allerdings, 

wie bereits in Abschnitt 2.2.1.4 erläutert, einen hohen Aufwand. Dieser 

hohe Aufwand und die Fig Notwendigkeit, 1. The ITU GazeTracker größere Bildausschnitte für das 

Template Matching zwischenspeichern zu müssen, machen den Ansatz in 

der FPGA-Umsetzung unattraktiv. Die Leistung des Ansatzes, welche in 

Abschnitt 2.2.1.5Setup analysiert Pupil wurde, Tracking ist nur mangelhaft. Die Zuverlässigkeit 

Click the Setup button. The first step is to adjust the Pupil Detector slider 

switches mode into a processed view helpful for adjusting the tracker set 

slider until the color 100of 

the pupil is green. Try to find a position where 

parts of the eye. You may click the icon just underneath the image to de 

window. This will display the video in its native resolution, making it ea 

settings. If no video is displayed click the Options tab and follow ins 

selecting camera. Notice that the infrared light sources must be turne


der Erkennung von Augen und Referenzpunkt mit 71, 19% unter optimalen 

Bedingungen wird als ausreichend angesehen. Die Qualität der stabilen 

Quadrantenerkennung unter optimalen Bedingungen ist jedoch mit einer 

mittleren Erkennungsrate von 34, 1% nur mangelhaft. Neben den Ergebnissen 

muss der Aufwand in Betracht gezogen werden, welcher notwendig ist, 

um die Messungen zu erzeugen. Um verwertbare Ergebnisse zu erhalten ist 

eine aufwendige Kalibrierung notwendig. Dazu mussten die Parameter des 

Threshold Filters sowie der morphologischen Operationen sehr speziell auf 

die jeweilige Testperson angepasst werden. Auf Basis der Messungen und 

der Auswertung des Aufwands wird der Ansatz somit als nicht praktikabel 

angesehen. Eine Implementierung wird mit entsprechend hohen Aufwand 

als theoretisch umsetzbar eingeschätzt. 


Der zweite Ansatz verwendet eine vollständig 

FPGA-Implementierbare Filterkette, welche nur wenige Filter verwendet. 

Wie die Messungen in Abschnitt 2.2.1.5 ergeben haben, ist die mittlere 

Erkennungsrate und somit die Qualität der Erkennung von Augen 

und Referenzpunkt mit 90, 5% deutlich besser als im ersten Ansatz. Die 

stabile Erkennung von Quadranten ist 73, 5% Prozent ebenfalls deutlich 

besser als im ersten Ansatz. Eine Umsetzung ist damit in erster Linie theoretisch 

und praktisch machbar. Ob eine praktische Umsetzung sinnvoll 

ist, muss mit Ausblick auf die notwendigen Anforderungen an das System 

getroffen werden. Hierbei ist die Qualität der in der Studie verwendeten 

Kamera mit in Betracht zu ziehen. Sollte die Kamera, welche vom Zielsystem 

verwendet wird, bessere Spezifikation in Hinsicht auf Auflösung und 

Bildwiederholrate besitzen, kann sich die Leistung des Systems verbessern. 

2.2.1.8 Fazit 

In der Studie wurden in Abschnitt 2.2.1.4 zwei unterschiedliche Ansätze 

ausgearbeitet und implementiert. Diese Ansätze implementieren die Erkennung 

und Verfolgung der Augen. Dabei erfolgt eine Abbildung der Blickrichtung 

der Augen auf eine in Quadranten eingeteilte Arbeitsfläche. Diese 

Quadranten stellen eine Abstraktion der Bewegungsmöglichkeiten des Roboters 

auf 9 Basisrichtungen dar. Beide Ansätze wurde auf die mittleren Erkennungsraten 

der Augen und die mittlere Stabilität der Zuordnung zu den 9 

Quadranten analysiert. Die Ergebnisse wurden in Abschnitt 2.2.1.5 aufgeführt 

und daraufhin in in Evaluation bewertet, siehe 2.2.1.7. Das Ziel dieser 

Studie ist es, eine Aussage über die Machbarkeit eines Eye-Tracking-Verfahrens 

im Rahmen der Projektgruppe, zu machen. Daher muss zwischen theoretis- 

101


cher und praktischer Machbarkeit unterschieden werden. Die theoretische 

Machbarkeit beider Ansätze wurde in der Evaluation für beide Ansätze 

festgestellt. Diese ist jedoch nicht hinreichend um eine Empfehlung für die 

Umsetzung zu geben. Die praktische Machbarkeit wurde für den zweiten 

Ansatz festgestellt. Die kurze Filterkette, welche nur aus wenigen Basisoperationen, 

einem Threshold und morphologischen Operationen besteht, 

macht eine FPGA-Implementierung umsetzbar. Zudem steht eine Implementierung 

des benötigten Blob-Tracking Filters bereits zur Verfügung. 

In Kombination mit den Ergebnissen der Messungen zur Stabilität und 

Qualität des Ansatzes wird festgestellt, dass der Ansatz, mit wenigen Erweiterungen 

und Optimierungen in der Analyselogik, machbar ist. Dennoch 

wird der Ansatz nicht umgesetzt, da das Erkennen der Blickrichtung 

zu ungenau ist für unsere Fälle. 

2.2.1.9 Datenstruktur 

Die Datenstruktur ergibt sich wie folgt: 

sprint2/eye_tracking/eyeV1/eye.oap : OFFIS Automation Framework Projektdatei 

sprint2/eye_tracking/eyeV1/eye_v1.ogr : Bildverarbeitungskette für die 

Erkennung der Augen und der Darstellung der ermittelten Position 

/ Trajektorie. 

sprint2/eye_tracking/eyeV1/eye_v1.py : Automation zum Erhalt und Verarbeitung 

der Augenposition. 

sprint2/eye_tracking/eyeV2/eye_v2.oap : OFFIS Automation Framework 

Projektdatei 

sprint2/eye_tracking/eyeV2/eye_v2.ogr : Bildverarbeitungskette für die 

Erkennung der Augen und der Darstellung der ermittelten Position 

/ Trajektorie. 

sprint2/eye_tracking/eyeV2/eye_v2.py : Automation zum Erhalt und Verarbeitung 

der Augenposition 

102


2.2.2 Anbindung des Kameramoduls 

Das Ziel dieses Arbeitspaketes ist die Ansteuerung des Kameramoduls 

VmodCam von Digilent. Am Ende des Paketes soll die OFFIS-Automation- 

Toolbox die Daten von einer der beiden Kameras über USB von dem FPGA 

empfangen und anschließend anzeigen können. 

Eine Visualisierung des implementierten Aufbaus ist in Abbildung 2.27 

dargestellt. Dieser realisiert den Hardwareteil der Kameraanbindung. Zusätzlich 

wurde noch ein Treiber für den simple_i2c IP-Core auf dem Microblaze 

implementiert, welcher Methoden zur Konfiguration der Kamera bereitstellt. 

Als Teil des Arbeitspaketes wurde zudem ein Interrupthandler für 

den Microblaze implementiert, welcher USB Messages behandelt. Außerdem 

wurde auch ein Plugin für die OFFIS-Automation-Toolbox erstellt, 

welches Daten vom FPGA entgegennimmt und in der OFFIS-Automation- 

Toolbox anzeigt. 

Im folgenden werden die involvierten IP-Core, der Treiber zur Kamera 

Konfiguration und das Plugin für die OFFIS-Automation-Toolbox näher 

beschrieben. 

simple_i2c 

cam_bootloader 

cam_rgb565_to_rgb888 

VmodCam 

cam_usb 

cam_data 

usb_driver 

cam_deserialzer 

PC 

Abbildung 2.27: Aufbau der Kameraansteuerung 

103


VDD-EN 

t 1 t 2 t 3 

MCLK 

SDA 

Power-Up Sequence 

MCLK 

t 4 

t 5 

t 4 t 6 

RST 

SDA 

Reset Sequence 

Abbildung 2.28: Signal Sequenz zur initialen Ansteuerung der Kamera 

cam_bootloader 1.00.a 

Die VmodCam verlangt eine bestimmte Signalabfolge 

bevor sie Befehle über das I 2 C Protokoll verarbeitet und auf diese 

reagiert. Die Signalsequenz ist in Abbildung 2.28 dargestellt. Die Sequenz 

ist in zwei Teile unterteilt, eine Power-Up- und eine Resetsequenz die hintereinander 

ausgeführt werden. Die einzelnen Teilabschnitte (t 1 bis t 6 ) wurden 

von uns mit Hilfe eines endlichen Automaten umgesetzt. 

Dieser IP-Core reicht die Signalabfolge an beide Kameras der VmodCam 

weiter, so das diese vom IP-Core initialisiert werden. Der Core meldet über 

ein Register dem Microblaze das die Sequenz abgeschlossen ist und die 

Kameras für das Protokoll ansprechbar sind. Weiterhin stellt dieser Core 

den Referenztakt für die Kameras dauerhaft bereit. 

104


simple_i2c 2.00.a 

Der von den Projektbetreuern bereitgestellte IP-Core 

zur Übertragung von I 2 C Kommandos wurde von uns unverändert in das 

Projekt aufgenommen. Jedoch wurde ein Treiber geschrieben, der den bereitgestellten 

nutzt und für unsere speziellen Aufgaben erweitert. So wurden 

von uns die Werte der genutzten Register- und Variablenadressen im 

Treiber hinterlegt. Auch wurden Funktionen dem Treiber hinzugefügt, die 

16 Bit Werte versenden und lesen. 

Der Treiber bietet die folgenden Methoden zur Konfiguration der Kamera 

an: 

void reset ( u8 N , u8 M); 

Die Methode muss vor Benutzung der Kamera aufgerufen werden. Die 

Parameter N und M dienen dabei zur Beschreibung des Takts mit dem 

Pixel auf den Datenbus gelegt werden. Die Berechnung erfolgt wie folgt: 

PCLK = 

MCLK∗M 

N+1 

8 

Dabei steht PCLK für Pixel Clock, also dem Takt mit dem Pixeldaten aus 

der Kamera geschoben werden. MCLK ist der Referenztakt, den der Kamerachip 

bekommt. cam_bootloader gibt als MCLK ein viertel der Bus Taktung 

an die Kamera. 

Bei der Wahl von N und M müssen desweiteren die folgenden Beschränkungen 

beachtet werden: 

• 0 < M < 256 

• 0 < N < 64 

• 6 Mhz


Zusätzlich zu den Registern gibt es auch Variablen. Diese können mit den 

oben genannten Methoden ausgelesen und beschrieben werden. 

Für alle Register und Variablen, die in der Digilent Dokumentation enthalten 

sind, existieren zudem Definitionen in dem Treiber. So kann z.B. die 

Auflösung mittels des folgenden Codes eingestellt werden: 

camA . variable_write ( CAM_B_OUTPUT_WIDTH , SIZE_X ); 

camA . variable_write ( CAM_B_OUTPUT_HEIGHT , SIZE_Y ); 

Für das korrekte Setup der Kamera ist zusätzlich zu dem Treiber detailliertes 

Wissen über den verwendeten Kamera-Chip nötig. Eine weitere Vereinfachung 

des Treibers durch hinzufügen von Methoden die bestimmte 

Optionen setzten wird für den nächsten Sprint vorgeschlagen. 

cam_data 1.00.a 

Der IP-Core Cam Data wurde ebenfalls von den Projekbetreuern 

bereitgestellt, jedoch von uns modifiziert, da er wesentlich 

mehr Funktionalität bereitstellte als von uns benötigt. Im wesentlichen 

nimmt dieser IP-Core den Datenstrom einer Kamera entgegen und stellt 

diese weiteren IP-Cores bereit. Dabei nimmt der Core die Daten mit der 

Kamerataktung, das entsprechende Signal heißt cam_clk, entgegen und 

gibt diese mit dem FPGA Takt weiter. Das Taktsignal des FPGA heißt pixel_clk. 

Die weiteren Datensignale sind in der Abbildung 2.29 dargestellt. 

pixel_clk 

cam_clk 

frame_valid 

line_valid 

data_valid 

data_in [7:0] 

cam_data 

frame_valid_out 

line_valid_out 

data_valid_out 

data_out [7:0] 

Abbildung 2.29: Blockschaltbild des cam_data IP-Core 

cam_deserializer 1.00.a 

Die Kamera überträgt pro Pixel zweimal 8 Bit 

Daten, die zusammengehören. Diese Daten werden in diesem IP-Core zu 

jeweils einmal 16 Bit zusammengesetzt, sodass in unserem Fall ein vollständiges 

RGB565 Signal ausgegeben wird. Dabei lässt sich dieser Core 

flexibel konfigurieren, wie in der Abbildung 2.30 dargestellt. 

Es gibt die Möglichkeit die Eingangsdatenbreite einzustellen, wobei die 

Ausgangsdatenbreite immer das Doppelte der Eingangsdatenbreite ist. Außerdem 

gibt es die Option die Byte- Reihenfolge umzustellen, bei Bedarf auf 

106


Abbildung 2.30: Konfigurationmenü des cam_deserializer IP-Cores 

107


Little-Endian oder Big-Endian. Die Ein- und Ausgangssignale welche dieser 

Core erfordert sind in Abbildung 2.31 dargestellt. 

pixel_clk 

frame_valid_in 

line_valid_in 

data_valid_in 

data_in [7:0] 

cam_deserializer 





Abbildung 2.31: Blockschaltbild des cam_deserializer IP-Cores 

cam_RGB565_to_RGB888 1.00.a 

Von diesem IP-Core wird ein 16 Bit 

breites Signal entgegen genommen welches aus 5 Bit Rot, 6 Bit Grün und 

5 Bit Blau besteht. Die Farbanteile werden in jeweils gleichbreite 8 Bit Anteile 

umgerechnet und als 24 Bit Datenstrom ausgegeben. So kommt es zustande, 

das der in Abbildung 2.32 dargestellte IP-Core aus den 16 Bit Eingangssignal 

ein 24 Bit breites Ausgangssignal erstellt. Die restlichen Eingangssignale 

werden lediglich unverändert an den Ausgang weiter gegeben. 


line_valid_in 

data_valid_in 

data_in [15:0] 






Abbildung 2.32: Blockschaltbild des RGB565 zu RGB888 IP-Cores 

cam_usb 2.00.a 

Dieser IP-Core dient dazu die Daten vom ImageBus 

in den Cache des USB IP-Core zu laden. Der IP-Core wurde uns ebenfalls 

von den Projektbetreuern bereitgestellt, musste von uns jedoch so erweitert 

werden, dass das DataValid Signal ausgewertet wird. 

usb_driver 2.00.a 

Dieser IP-Core stellt eine USB Verbindung zum PC 

her. Der IP-Core wurde unverändert von den Projektbetreuern übernommen. 

Der Teil zum Empfang von Bulkdaten enthaltende Teil des IP-Core 

wird von dem Projekt jedoch nicht benutzt. Zusammen mit dem IP-Core 

108


PLB 

pixel_clk 

frame_valid 

line_valid 

data_valid 


cam_usb 

direct_wrClk 

direct_wrReq 

direct_wrData [31:0] 

Abbildung 2.33: Blockschaltbild des Cam-USB IP-Cores 

kommt ein Treiber für den Microblaze, welcher ebenfalls unverändert übernommen 

wurde. 

image_bus 1.00.a 

Auch dieser IP-Core kommt unverändert von den 

Projektbetreuern. Der Core beschreibt einen Bus, auf dem die Bilddaten 

zusammen mit Steuerinformationen zwischen den Cores weitergereicht 

werden können. Zusätzlich zu den normalen Steuerdaten berechnet er die 

Position des gerade weitergereichten Pixels und reicht diese Information 

weiter. Die zu verarbeitende Datenbreite ist frei konfigurierbar. 

2.2.2.1 Toolbox Plugin 

Damit die OFFIS-Automation-Toolbox Daten von dem FPGA empfangen 

kann, wird ein neues Plugin benötigt. Das Plugin schickt dem FPGA über 

USB zunächst ein Steuersignal, dass es bereit ist ein Bild zu empfangen. 

Danach wird zunächst auf ein Steuersignal vom FPGA gewartet, welches 

dem Plugin die Auflösung von dem nächsten Bild mitteilt. Dann wird das 

Bild über die USB Bulkdaten Schnittstelle entgegengenommen. Die empfangenen 

Daten werden dann in ein OpenCV RGB-Bild umgewandelt. 

2.2.2.2 Aufgetretene Probleme 

Während des Sprints sind unter anderem die folgenden Probleme aufgetreten: 

• Die Kommunikation mit der Kamera erwies sich als schwieriger als 

erwartet. Für die Beschreibung der Pinbelegung zwischen Kamera 

und FPGA wurde das Demo Projekt von Digilent als Beispiel genommen, 

bei welchem jedoch keine Pull-up Widerstands benutzt wurden. 

Bei dem von uns genutzten IP-Core sind jedoch Pull-up Widerstands 

nötig um eine Kommunikation zu ermöglichen. 

109


• Die von uns eingesetzte FPGA Platine (Atlys) hat nicht ausreichend 

Ein-/Ausgabe Pins, um ein Debugging der Kamera Daten zu ermöglichen. 

Um dieses Problem zu umgehen wurde von uns ein neues 

Projekt für die Genesys Platine von Digilent angelegt und der Code 

so angepasst, dass er auf dieser lauffähig ist. 

• Bei der Entwicklung des cam_deserialzer IP-Cores wurde für das 

DataValid Signal kein Grundzustand gesetzt. Dies führte zu 200 MByte/s 

Datenmüll die an den USB-Core weitergereicht wurden. 

• Die VmodCam Dokumentation von Digilent [8], ist sehr spärlich. 

Während des Sprints wurden noch zwei verschiedene Datenblätter 

von Micron [11] und Aptina [2] gefunden, welche beide den, von der 

VmodCam benutzten, Chip produzieren. Außerdem wurde von uns 

der Quellcode des Treibers im Linux-Kernel [7] zu Hilfe genommen. 

• Die, in der Dokumentation von Digilent beschriebene, Resetsequenz 

des Microcontrollers auf Kamera lässt sich nur einmalig ausführen. 

Abhilfe verschaffte hier der Quellcode des Linux Kernels, welcher 

eine korrekte Resetsequenz enthält. 

2.2.2.3 Ausblick 

Während des Arbeitspaketes sind mehrere mögliche neue Aufgaben gefunden 

worden: 

• Der Treiber, der zur Kamera-Konfiguration dient soll noch verbessert 

werden. Zur Zeit sind viele Funktionen der Kamera nur durch Auslesen 

und Beschreiben der Kameraregister verfügbar. Stattdessen sollten 

Methoden angeboten werden. 

• Der Treiber zur Kamera Konfiguration benötigt ein sleep(). Hierfür 

sollte ein Timer IP-Core zum Projekt hinzugefügt und ein passender 

Treiber geschrieben werden. 

• Zur Berechnung der Tiefenkarte werden Bilder von beiden Kameras 

benötigt. Um zu ermöglichen, dass Bilder von beiden Kameras an den 

PC gelangen können soll ein Processor Local Bus (PLB) gesteuerter 

Muxer geschrieben werden. Dieser soll 2 ImageBus Eingänge und 

einen ImageBus Ausgang haben. 

110


• Das Übertragen von Bilddaten über die USB Schnittstelle konnte in 

diesem Sprint nur durch wählen einer sehr geringen Taktung der 

Kamera erreicht werden. Um die Übertragung über USB bei hoher 

Kamerataktrate zu gewährleisten soll ein ImageCache IP-Core angelegt 

werden. 

• Um späteres Debugging zu erleichtern soll eventuell ein HDMI IP- 

Core angelegt werden, so dass die Kamerabilder bei maximaler Bildwiederholungsrate 

und voller Auflösung ausgegeben werden können. 

Hierzu sollte zunächst das Testprojekt der VmodCam betrachtet 

werden, um den Arbeitsumfang einschätzen zu können. 

111


2.2.3 Roboter-Arm 

In der Automationsumgebung muss für jedes Gelenk des Roboters ein 

Winkel angegeben werden. Dabei wird von einem PC mit dem FPGA über 

einen Hardwareabstractionlayer (HAL) via USB kommuniziert. Die Demonstration 

der Roboteransteuerung erfolgt im Offis-Automationstool, indem 

für die Skriptsprache Python eine C++ Schnittstelle (HAL) zur Ansteuerung 

des Roboterarms bereitgestellt wird. Die Roboteransteuerung wird durch 

die Umsetzung von Vor- und Rückwärtskinematik realisiert. 

2.2.3.1 Ziel 

Ziel dieses Sprints ist eine Ansteuerung des Roboterarms in Form von einfacher 

Funktionsaufrufe in dem Offis-Automationstool. Unter Ansteuerung 

wird zum Einen die direkte Steuerung über Winkel und zum Anderen 

die Steuerung über Koordinaten des TCPs verstanden. Die dazu benötigte 

Kinematik wird auf dem PC in C++ realisiert. Das in dem Dokument zur 

Sprintplanung angekündigte Vorgehen, die Kinematik in Python zu realisieren, 

wurde zugunsten der Erschaffung eines Plugins in C++ für die 

Offis-Toolbox verworfen. Die spätere Portierung der Kinematik auf den 

FPGA ist ebenfalls ein Grund für eine Umsetzung in C++, da auf dem Microblazecore 

ebenfalls C++ verwendet wird. 

Zu diesem Zweck muss eine Kommunikation der kinematischen bzw. ansteuernden 

Algorithmen von dem PC mit dem FPGA realisiert werden (siehe 

Abbildung 2.34). Diese Kommunikation verläuft über die USB-Schnittstelle, 

wobei ein entsprechender USB-IP-Core bereits existiert. Sowohl auf dem 

PC als auch auf dem FPGA muss jedoch ein auf USB aufsetzendes Protokoll 

realisiert werden, welches die Kommunikationsmöglichkeiten zwischen 

Ansteuerungskommandos auf dem PC und dem FPGA als Befehlsempfänger 

definiert. Die fehlenden Elemente der Kommandokette sind in Abbildung 2.34 

in Form von rot markierten Schichten dargestellt. 

Unter Kinematik wird dabei sowohl die Vorwärts- als auch die Rückwärtskinematik 

verstanden, welche das Umrechnen von Winkelstellungen in 

Koordinaten Tool-Center-Point (Vorwärtskinematik) bzw. das Umrechnen 

von TCP Koordinaten in Winkelstellungen (Rückwärtskinematik) beinhaltet. 

Protokoll zwischen FPGA und PC 

Aufbauend auf dem USB-Protokoll existiert ein Protokoll (USB-Handler), 

über welches die Ansteuerung des FPGAs bzw. des Roboterarms mit dem 

112


Ansteuerung(Python) 

Kinematik(C + +) 

HAL(C + +) 

PC 

Treiber 

Hardware 

IP − Core(USB) 

USB − Handler(C + +) 

HAL(C + +) 

FPGA 

IP − Core(PPM) 

Roboterarm 

Abbildung 2.34: Steuerungsschichten des Roboterarms (rot markiert = In 

diesem Sprint entwickelt) 

PC ermöglicht. Die Implementierung des USB-Handlers ist dabei in C++ 

erfolgt. Die allgemeine Paketstruktur des entwickelten Protokolls hat folgende 

Struktur: 

type usertype flags servo1 servo2 servo3 servo4 servo5 servo6 

1 Byte 1 Byte 1 Byte 2 Byte 2 Byte 2 Byte 2 Byte 2 Byte 2 Byte 

servo1_fine servo2_fine servo3_fine servo4_fine servo5_fine servo6_fine 

1 Byte 1 Byte 1 Byte 1 Byte 1 Byte 1 Byte 

min max padding 

2 Byte 2 Byte 4 Byte 

Diese fest definierte Paketstruktur wird in folgenden Anwendungsfällen 

genutzt: 

Kalibrieren 

113


Sende zu FPGA: 

type usertype flags 

Calibrate ServoId {left, right, min, max, ranges, fpga} 

Erhalte von FPGA: 

type usertype flags min max 

Calibrate ServoId {min, max, ranges} Max-Grenze Min-Grenze 

Setze Millisekunden 


type servo1 servo2 servo3 servo4 servo5 servo6 

SetMs ms ms ms ms ms ms 

Setze einen Winkel 


type usertype servo1 servo1_fine 

SetAngle ServoId Winkel 

1 

19 

Winkel 

Setze alle Winkel 


type servo1 servo2 servo3 servo4 servo5 servo6 

SetAngles Winkel Winkel Winkel Winkel Winkel Winkel 

servo1_fine servo2_fine servo3_fine servo4_fine servo5_fine servo6_fine 

1 

19 Winkel 1 

19 

Winkel 

1 

19 

Winkel 

1 

19 

Winkel 

1 

19 

Winkel 

1 

19 

Winkel 

Setze Range 


type usertype min max 

SetRange ServoId Min-Grenze Max-Grenze 

114


Reset 

Dateien 


type 

Reset 

Die C++ Umgebung, welche mit den QT-Creator erstellt und 

bearbeitet wurde umfasst folgende Dateien: 

os-toolbox/plugins/automation/RoboArm/RoboArm.cpp 

Datei implementiert sämtliche Schnittstellen sowie die Kommunikation 

mit dem FPGA über USB. Des Weiteren werden die Kinematiken 

von dieser Klasse instanziiert. 

os-toolbox/plugins/automation/RoboArm/RoboArm.h 

Interface der o.g. Klasse, welche u.a. die Protokollheader als enum 

sowie die Schnittstellen zur Offis-Automation als public slot definiert. 

os-toolbox/plugins/automation/RoboArm/RoboArmGui.cpp 

Teil des Frameworks, welches Teilaufgaben für die Initialisierung der 

Schnittstellen übernimmt. 

os-toolbox/plugins/automation/RoboArm/RoboArmGui.h 

Interface des o.g. Frameworks. 

os-toolbox/plugins/automation/RoboArm/RoboArmGui.ui 

XML-Datei, welche der Klasse RoboArmGui angehört und der Konfiguration 

dient. 

os-toolbox/plugins/automation/RoboArm/RoboArmInterface.cpp 

In dieser Klasse werden die Namen und Beschreibungen der Methoden 

hinzugefügt, welche der Offis-Automation zur Verfügung gestellt 

werden soll. Neben den Methoden werden auch Konstanten für die 

Kalibrierung bekannt gegeben. Diese Klasse instantiiert die Klasse 

RoboArm als sog. lolec mit einer Konfigurationsdatei als Parameter. 

os-toolbox/plugins/automation/RoboArm/RoboArmInterface.h 

Interface zur o.g. Klasse. 

os-toolbox/plugins/automation/RoboArm/RoboArm.pro 

Projektdatei, welche den Pfad zur Offis-Automation enthält, sowie 

den Dateinamen aller in diesem Abschnitt genannten Klassen. 

115


os-toolbox/plugins/automation/RoboArm/usb/* 

Bereitgestellte Cypress USB-API. 

os-toolbox/projects/KinematikTest/cong/robo.ini 

Konfigurationsdatei, welche die Ranges der Servos, die Parameter für 

die Kinematik, die Anzahl der Links (Bezugssysteme) sowie die relativen 

Koordinaten des Tool-Center-Point im letzen Bezugssystem enthält. 

Die Offis-Automation, welche eine Python Umgebung bereit stellt, umfasst 

folgende Dateien: 

os-toolbox/projects/KinematikTest/robocrtl.py 

Testumgebung in Python, mit welcher der Roboterarm inklusive Kinematik 

über die in 2.2.3.2 und 2.2.3.3 definierten Schnittstellen gesteuert 

werden kann. 

os-toolbox/projects/KinematikTest/roboArm.pro 

Projektdatei, welche u.a. den Pfad zur Konfigurationsdatei enthält. 

os-toolbox/projects/KinematikTest/roboArm.oap 

Versionierungsdatei, ähnlich der Projektdatei 

os-toolbox/projects/KinematikTest/roboArm.ogr 

XML-Datei, welche zur Konfiguration der Olvis-Automation dient. 

Kongurationsdatei 

Die Kalibrierungswerte für die Servos sowie Parameter 

der Kinematik können in einer Konfigurationsdatei auf dem PC gespeichert 

und später wieder auf den FPGA geladen werden. Im Detail können 

folgende Werte gespeichert werden: 

• Für jeden Servo werden die Bewegungsbereiche (min und max) gespeichert, 

sowie die Denavit Hartenberg-Parameter. 

• Die Anzahl der Servos (Links) in dem Modell der Kinematik 

• Die relativen Koordinaten des Tool-Center-Point vom letzten Link 

Kalibrierung auf dem FPGA 

Um die Kalibrierung auf dem FPGA zu 

starten wird aus der Python-Umgebung die Funktion cal mit dem Servo 

und dem Modus FPGA als Parameter aufgerufen. Anschließend kann die 

Kalibrierung über die Buttons des FPGAs vorgenommen werden, wobei 

erst das Minimum und danach das Maximum eingestellt und mit dem 

116


mittleren Button des Tastenkreuzes bestätigt wird Genaueres ist im Abschnitt 

Schnittstellen unter dem Punkt FPGA beschrieben (siehe dazu Abbildung 

2.36). 

2.2.3.2 Vorwärtskinematik 

Die Vorwärtskinematik realisiert das Abbilden eines Winkelvektors des 

Roboarms auf den Koordinatenvektor des TCP [6] im Inertialsystem 13 . Die 

Anzahl der Komponenten im Winkelvektor entspricht dem Freiheitsgrad 

eines seriellen Roboters. Jeder Winkelwert entspricht einer Stellung des 

entsprechenden rotatorischen Gelenks. 

Kinematische Modell 

Das kinematische Modell des Roboterarms ist in 

Abbildung 2.35 gezeigt. Der Roboterarm besteht aus sechs Festkörpergliedern 

und vier Drehgelenke. Da die Drehung des letzten (in Abbildung 2.35 des 

obersten) Gelenks keine Auswirkung auf die Koordinate des Tool-Center- 

Point im Inertialsystem hat, wird dieses Gelenk im Modell vernachlässigt. 

Somit wird das vorletzte sowie das letzte Glied der kinematischen Kette 

als ein Glied am Ende der kinematischen Kette betrachtet. Die Längenund 

Winkelparameter (s i ), (d i ), (ϕ i ) sowie (ϑ i ) sind nach Denavit Hartenberg-Konvention 

[6] wie folgt gegeben: 

Kettenglied s i d i ϕ i ϑ i 

0 0.0 0.0 0.0 0.0 

1 20.0 0.0 0.0 90.0 

2 0.0 79.0 90.0 0.0 

3 0.0 78.5 0.0 0.0 

4 0.0 70.0 0.0 0.0 

5 0.0 0.0 0.0 0.0 

Die Zeile der Denavit Hartenberg-Tabelle entspricht dem ortsfesten unbeweglichen 

Anfangsglied der kinematischen Kette. Dieses steht in keiner 

Beziehung zu einem vorherigen Glied, weil es dieses nicht gibt. Darüber 

hinaus ist die erste Zeile der Tabelle mit Nullen gefüllt. Das letzte Festkörperglied 

wird mit dem Vorletzten wie ein Ganzes betrachtet. Darüber 

hinaus ist die letzte (fünfte) Zeile der DH-Tabelle wie die Erste mit Nullen 

gefüllt. 

13 Inertialsystem, auch das Weltkoordinatensystem genannt, ist das ortsfeste Koordinatensystem 

(Bezugssystem), in dem der Roboter beschrieben sowie identifiziert wird. Das 

Inertialsystem wird als Basiskoordinatensystem (Basisbezugssystem) dem ersten nicht 

beweglichen Teil des seriellen Roboter zugeordnet. 

117


• 

x 3 

180° 

0° 

y 3 z 3 

x 2 

0° 180° 

z y 

2 

2 

180° 

y 1 

0° 

z 1 

x 1 

y 0 

180° z 0 0° 

x 0 

O 0 

Abbildung 2.35: Kinematisches Modell des Roboarms 

Datenstruktur (extern) 

Für die Modellierung des Roboters wurde die 

Datenstruktur angelegt, die den kinematischen Aufbau eines seriellen Roboters 

repräsentiert. Die Klasse link repräsentiert einen starren Körper der 

kinematischen Kette, Klasse KinematicChain repräsentiert die starren Körper 

der kinematischen Kette und ihre räumliche Relationen. Die Initial- 

118


isierung eines seriellen Roboters mit einer kinematischen Kette erfolgt in 

der Klasse Roboarm, die zur Ansteuerung der Hardware über die USB- 

Schnittstelle mit FPGA kommuniziert. Die Roboterhardware ist direkt an 

das FPGA angeschlossen. 

Diese Parameter können gesetzt und gelesen werden. Folgende Dateien 

realisieren die Vorwärtskinematik: 

os-toolbox/plugins/automation/RoboArm/Link.h 

Interface des Modell eines Gliedes der kinematischen Kette. 

os-toolbox/plugins/automation/RoboArm/Link.cpp 

Implementierung des Modell eines Gliedes der kinematischen Kette. 

os-toolbox/plugins/automation/RoboArm/KinematicChain.h 

Interface der Vorwärtskinematik. 

os-toolbox/plugins/automation/RoboArm/KinematicChain.cpp 

Implementierung der Vorwärtskinematik. 

Datenstruktur (intern) 

Die Klasse Link beinhaltet folgenden Parameter: 

• Koordinatenvektor coord eines starren Körpers der kinematischen Kette 

im Inertialsystem 

• Koordinatenvektor des Tool-Center-Point (TCP), der innerhalb Festkörper 

eigenen Bezugssystem liegen kann. 

• DH-Parameter als Relationen zwischen Festkörper eigenen Bezugssysteme: 

s i (Abstand zwischen Ursprung des Festkörper eigenen Bezugssystem 

zur Verbindungsnormalren des nachfolgenden festen Körper), d i 

(Länge des festen Körper), ϕ (Winkel zwischen x-Achsen der Festkörper 

eigenen Bezugssysteme) sowie ϑ (Winkel zwischen den Drehachsen 

der Gelenke). 

Die Klasse KinematicChain beinhaltet als Parameter allgemeine parametrisierbare 

Transformationsmatrix und ein Feld von Links. Die Methoden dieser 

Klasse realisieren den Algorithmus zu Berechnung des Koordinatenvektors 

des Tool-Center-Point. 

119


Algorithmus 

Die Vorgehensweise zur Bestimmung der Koordinaten des 

Tool-Center-Point im Inertialsystem basiert auf der Umrechnung des Ortsvektor 

des Tool-Center-Point im Festkörpersystem des letzten Gliedes der kinematischen 

Kette in den Ortsvektor des Inertialsystems [13]. 

Abbildung 2.35 zeigt die Bezugssysteme jedes einzelnen Festkörpergliedes 

der kinematischen Kette. Ein Ortsvektor ⃗r wird im Allgemeinen in einem 

anderen Bezugssystem identifiziert, in dem der Ortsvektor mit Hilfe einer 

Multiplikation mit Transformationsmatrix T aus seinem Koordinatensystem 

i in das Andere i ′ umgerechnet wird. Die allgemeine Formel hierzu 

lautet [13] 

⃗r i = T i ·⃗r i−1 (2.1) 

Die algorithmische Umrechnung in der Klasse KinematicChain erfolgt durch 

die sequentielle Umrechnung des Ortsvektors aus dem Koordinatensystem 

i + 1 in das i, mit 0 ≤ i ≤ 3 und i ∈ N. Hierbei ist das Bezugssystem mit 

Index i = 0 das Inertialsystem. 

Für jede Transformation muss es eine bestimmte Transformationsmatrix T i 

geben. In dem Fall mit Roboarm wird die allgemeine Tranfsformationstatrix 

T i aus Gleichung 2.2 eingesetzt. Die Werte aus der Denavit-Hartenberg 

Tabelle werden für die jeweilige Transformation (aus i + 1 in das i) in 

die Matrix eingesetzt. Folgende Matrix ist das allgemeine Matrix für die 

Drehungen und Verschiebungen nach DH-Konvention [13]: 

⎛ 

⎞ 

1 0 0 0 

T i = ⎜d i · cos(ϕ i ) cos(ϕ i ) − sin(ϕ i ) cos(ϑ i ) sin(ϕ i ) sin(ϑ i ) 

⎟ 

⎝d i · sin(ϕ i ) sin(ϕ i ) cos(ϕ i ) cos(ϑ i ) − cos(ϕ i ) sin(ϑ i ) ⎠ (2.2) 

s i 0 sin(ϑ i ) cos(ϑ i ) 

Durch das Einsetzen von Werten aus Denavit Hartenberg-Tabelle wird die 

allgemeine Transformationsmatrix T i für jede Transformation parametrisiert. 

Durch die Parametrisierung dieser Matrix entsteht für jedes Paar der Bezugssysteme 

der kinematischen Kette (i, i + 1) die entsprechende Transformationsmatrix 

für die jeweilige Vektortransformation. Der Vektor r i+1 ⃗ wird durch 

Ausführung der in der Gleichung 2.1 definierten Operation zum Vektor 

⃗r i transformiert und auf dem Koordinatensystem i identifiziert. Der neu 

identifizierter Vektor ⃗r i wird in der entsprechenden Instanz von Link abgespeichert 

und für die weitere Transformation benutzt. Die Winkel ϑ 0 bis 

ϑ 3 werden einmalig ausgerechnet und für die gegebene Hardwarekonfiguration 

stets festgehalten. Die Winkel ϕ 0 bis ϕ 3 sind dagegen variabel. [13] 

Diese geben zu einer Stellung des Roboterarms einen Winkelvektor an. 

120


Einschränkungen der Hardware 

Durch die Einschränkungen der Hardware 

entspricht das kinematische Modell, das durch die DH-Tabelle beschrieben 

ist, nicht direkt der echten kinematischen Kette des Roboters. Um trotzt 

dieser Diskrepanz dennoch den richtigen Ortsvektor aus den Winkelvektoren 

anzugeben, werden die Winkel ϕ i , die für die Hardware gelten, auf 

die Winkel des Modells abgebildet. Die fett markierten Kurven in Abbildung 

2.35 bezeichnen die Drehrichtung der Servos. Daraus wird deutlich, 

dass beispielhaft ein Winkel von 90 ◦ um die Achse z 3 des Modells nicht 

dem Winkel von 90 ◦ des Servomotors entspricht, der die Drehung um die 

Achse z 3 realisiert. 

Die Diskrepanz kommt dadurch zustande, dass die Hardware von dem 

Kunden/Benutzer fertig vorgegeben und nicht zuvor modelliert wurde. 

Der konventionelle Maschinenbau vor allen der Maschinenbau der seriellen 

Roboter erfolgt angefangen mit einem Modell [6]. Im Fall mit Roboarm 

musste die gegebene Hardware nach modelliert werden. Dies ist mit Hilfe 

von DH-Konventionen und der Abbildung von realen Winkel auf die vom 

Modell gelungen. Der Koordinatorvektor des Tool-Center-Point wird durch 

den oben geschriebenen Algorithmus zu jedem zulässigen Winkelvektor 

angegeben. 

Schnittstellen 

In dem C++ Hostsystem werden diverse Methoden als 

Schnittstelle zu Python bereitgestellt, mit denen der Roboterarm gesteuert 

werden kann. Diese Methoden sind in der oben beschriebenen Datei RoboArmInterface 

als Schnittstelle angegeben und im folgenden erläutert. 

void acquireHardware () ; 

Stellt eine Verbindung zur Hardware her und setzt die Denavit Hartenberg-Parameter 

sowie den Tool-Center-Point. Der Aufruf dieser Methode 

zu Beginn der Steuerung des Roboterarms ist zwingend erforderlich. 

void releaseHardware () ; 

Schließt die Verbindung zur Hardware. Nach dem Aufruf dieser Methode 

werden keine anderen Kommandos außer acquireHardware akzeptiert. 

void setServoMs ( RcRepeatable < int , 1, 6> list ); 

Setzt die Servoposition in Mikrosekunden. Wenig erfahrende Benutzer sollen 

statt dessen die Methode setAngel(s) verwenden. 

121


void calibrate ( int servoId , int mode ); 

Kalibriert einen einzigen Servo. Diese Methode benötigt eine spezielle Markierung, 

welche den Kalibrierungsmodus codiert (siehe Kalibrierungsmarkierung 

später im Text). 

void setAngle ( int servoId , double angle ); 

Setzt den Winkel eines einzelnen Servos in Grad. Der Wertebereich eines 

Winkels geht von 0 bis 195 Grad und die feinen Winkel von 0.0 bis 0.99 

Grad. 

void setAngles ( RcRepeatable < double , 1, 6> angles ); 

Setzt die Winkel von jedem Servo in Grad. Der Wertebereich ist der gleiche 

wie bei der Methode setAngle. 

void reset () ; 

Sendet ein Reset für alle Servo-IP-Cores an den FPGA. 

void setRange ( int servoId , int min , int max ); 

Setzt den minimalen und maximalen Bewegungsbereich von einem Servo. 

Der Bereich wird in Mikrosekunden angegeben. 

void loadRanges () ; 

Lädt die Bewegungsbereiche von allen Servos von der Datei robi.ini und 

sendet diese an den FPGA. Die Methode acquireHardware führt loadRanges 

aus und lädt die Bewegungsbereiche bereits zur Startzeit. 

void saveRange ( int servoID , int min , int max ); 

Schreibt den Bewegungsbereich (min bis max) eines Servos in die Konfigurationsdatei 

robo.ini. 

void saveRangesFromFPGA () ; 

Fragt den Bewegungsbereich aller Servos vom FPGA ab und schreibt diese 

in die Konfigurationsdatei robo.ini 

void setDHParameters ( int index , double si , double di , 

double phi , double theta ); 

122


Setzt die Denavit Hartenberg-Parameter für die Kinematik. Zu setzen sind 

der Index des Links, der Gelenkabstand, die Länge eines Links, die Rotation 

der x-Achse (Gelenkwinkel) und die Rotation der Z-Achse (Verwindung). 

void setLastLinkTCP ( double x , double y , double z); 

Setzt den Tool-Center-Point des letzten Links. Der TCP ist der relative Vektor 

des letzten Bezugssystems. 

QVector3D getTCP () ; 

Gibt die Koordinaten des TCPs als Vektor (x, y, z) im Intertialsystem zurück. 

Darüber hinaus sind folgende Kalibrierungsmarkierungen als Konstanten 

im Python benutzbar: 

Min Bestätigt Minimalwert eines Servos. Entspricht Ok-Button für linksseitige 

Kalibrierung. 

Max Bestätigt Maximalwert eines Servos. Entspricht Ok-Button für rechtsseitige 

Kalibrierung. 

Left Fährt den Servo um 50µs nach links (Addiert µs). 

Right Fährt den Servo um 50µs nach rechts (Subtrahiert µs). 

Initpos Fährt den Servo auf eine Initialposition (approximierte Mitte) 

Fpga Ermöglicht eine Kalibrierung über die Tasten des FPGAs (erst links, 

dann rechts kalibrieren). Abbildung 2.36. 

Mit der Markierung Fpga wird der Kalibrierungsmodus auf dem FPGA 

aktiviert. Die obere und unteren Tasten des Tastenkreuzes auf dem FPGA- 

Board stehen jeweils für eine Erhöhung und Verringerung des PPM-Signals 

um 100µs, was einer approximierten, empirisch festgestellten Drehung des 

Gelenks um einem Grad (+/- 10 ◦ ) entspricht. Die linke und rechte Tasten 

bewirken jeweils eine Erhöhung und Verringerung des PPM-Signals 

um 10µs, was einer approximierten, empirisch festgestellten Drehung des 

Gelenks um ein zwanzigstel eines Grades (+/- 1 ◦ ) entspricht. Die mittlere 

Taste (OK) steht für Bestätigung des PPM-Signals. 

Das Protokoll für diese Kalibrierung sieht wie folgt aus: Durch die USB- 

Message wird die Nummer des zu kalibrierenden Servo und der Markierung 

123


y 3 

x 3 

• 

z 3 

x2 

z2 

y2 

FPGA 

y 1 

z 1 

x 1 

y 0 

OK 

Atlys-Board 

- 100µS ( -10°) 

-10µS ( -1°) 

+ 100µS ( +10°) 

+10µS ( +1°) 

z 0 

O 0 

x 0 

Abbildung 2.36: Kalibrierung der Drehwinkel der Gelenke mit den Tasten 

auf dem FPGA-Board. 

Fpga zum USB-Chip des FPGA-Boards geschickt. Durch das Betätigen der 

Tasten wird das PPM-signal für den Servo angepasst. Der Servo stellt sich 

entsprechend dem PPM-Signal in eine bestimmte Winkelstellung hin. Nach 

dem ersten Betätigen der Taste OK wird das aktuelle PPM-Signal und für 

die Stellung von 0 ◦ auf dem FPGA festgehalten. Nach dem zweiten Betätigen 

der Taste OK wird das aktuelle PPM-Signal für die Stellung von 190 ◦ 

festgehalten. 

2.2.3.3 Rückwärtskinematik 

Ziel der Rückwärtskinematik ist eine Umrechnung eines gegebenen TCPs 

in Winkelstellungen der Gelenke des Roboterarms. Dabei muss über die 

Pythonumgebung der Offis-Toolbox auf die errechneten Winkel zugegriffen 

werden können. Im Folgenden werden unter anderem das Funktionsprinzip, 

der Algorithmus, verwendete Datenstrukturen sowie aufgetretene 

Probleme erläutert. 

124


Funktionsprinzip 

Die Winkel der Gelenke werden in der aufsteigenden Reihenfolge (von 0 

bis 3) durch die Buchstaben α, β, γ sowie δ bezeichnet. Jede Drehachse Z 

in Abbildung 2.35 entspricht einem Gelenkwinkel. Denn die Drehung im 

Roboarm erfolgt stets um die Z-Achsen. 

Die Rückwärtskinematik wird in der Regel durch die algebraische Methode 

realisiert. Hier wird durch die Rücktransformation des Ortsvektor und der 

Lage des Tool-Center-Point aus dem Inertialsystem in die nachfolgenden 

Koordinatensysteme i, i + 1, · · · n auf den Winkelvektor abgebildet. 

Der Roboarm besitzt höchstens fünf Freiheitsgrade. die Abbildung 2.35 

zeigt jedoch, dass der fünfte Freiheitsgrad keinen Einfluss auf die Position 

des TCP hat. Dadurch ist der Roboarm als serieller Roboter ein 4 

Freiheitsgrade degradierter Roboter. Aufgrund dieser Tatsache lässt sich 

die Lage des TCP für die Rückwärtskinematik nicht festlegen, was bei der 

Berechnung der Rückwärtskinematik der Fall ist. Die Recherche und die 

Rechnerische Bestimmung der möglichen Lage ist aufgrund des großen 

Zeitaufwandes innerhalb der Sprintregelzeit nicht machbar. Außerdem zeigte 

die Berechnung der ersten Transformationsmatrizen, dass nicht einmal die 

doppelte Zeit dafür ausreichen wird. Zusätzlich existiert die Gefahr, dass 

eine algebraische Lösung eine sehr eingeschränkte Anfangslage des TCP 

zulässt, sodass die zu Verfügung stehenden Freiheitsgrade nicht im vollen 

Umfang benutzt werden können. 

Aufgrund der o. g. Tatsachen wird zu der geometrischen Lösung gegriffen. 

Die geometrische Lösung liefert im Falle mit dem Roboarm sofort aus 

der TCP den ersten Winkel α der kinematischen Kette. Da die restlichen 

Drehachsen bis auf die Drehachse des TCP zueinander parallel sind, wird 

die Bestimmung der Winkel β, γ sowie δ auf ein planares Problem reduziert. 

Abbildung 2.37 zeigt den Drehwinkel α des ersten Gelenks des Roboters. 

Der Tool-Center-Point ist im Raum durch den Koordinatenvektor/seinen 

Ortsvektor (X, Y, Z) identifiziert. Um das Problem der Winkelbestimmung 

auf ein planares Problem zu reduzieren, wird der ganze Roboarm um die 

z-Achse des Inertialsystems virtuell gedreht. Die Drehung erfolgt immer in 

eine Richtung (im Uhrzeiger Sinn). 

Dabei erfolgt die Drehung um genau den Winkel, so dass der Tool-Center- 

Point sich genau über der x-Achse nach der Drehung befindet. Wenn die 

y-Koordinate des TCP positiv ist, dann wird die Drehung um den Winkel α 

ausgeführt. Falls die y-Koordinate des TCP negativ ist, die Drehung wird 

125


z 0 

x 0 

. 

y 0 

• 

. 

. 

⍺ 

Abbildung 2.37: Der TCP befindet sich im 3D-Raum. Der Winkel α wird 

geometrisch bestimmt. 

z 0 

x 0 

135° 

45° 

225° ≡ 45° 

315° ≡ 135° 

Abbildung 2.38: Winkeläquivalenz für die virtuelle Drehung. 

um den Winkel (180 ◦ − α) ausgeführt. In Abbildung 2.38 ist die Äquivalenz 

der der Winkel in unterschiedlichen Quadranten gezeigt. Der Winkel 

zwischen TCP-Lot und x-Achse muss für die zueinander diagonal liegenden 

Quadranten stets gleich sein. Denn die Hardware des Roboarm nur in 

oberen beiden Quadranten agiert. 

Nach der Drehung um die z-Achse sieht der Roboarm beispielhaft wie in 

Abbildung 2.39 aus. Wegen der Parallelität aller Drehachsen der Gelenke 

kann der Winkel α des Roboarms nach der Drehung vernachlässigt werden. 

Durch die Drehung um die z-Achse wurde es erreicht, dass ausschließlich 

126


z 0 

x 0 

γ 

δ 

• 

β 

Abbildung 2.39: Nach der Drehung um die z-Achse befindet sich der TCP 

genau über der x-Achse. Der TCP ist im 2D-Raum 

die Winkel β, γ sowie δ die Position des Tool-Center-Point beeinflussen. 

Die y-Koordinate des TCP ist damit stets gleich Null. Die Bestimmung 

der Winkel β, γ sowie δ für die gegebene Position des TCP ist jetzt ein 

zweidimensionales Problem auf der planaren Ebene, die durch die Achsen 

x und z aufgespannt wird. 

Algorithmus 

1. Sobald die inverse Kinematik mit einem Configfile initialisiert ist, 

kann über die Methode getAnglesFromTCP ein Tool-Center-Point übergeben 

werden. Dieser wird zunächst bezüglich seiner Gültigkeit geprüft. 

Befindet sich der TCP außerhalb der Reichweite oder zu nahe an dem 

Roboterarm, ist der TCP als ungültig zu bewerten und der Algorithmus 

bricht mit einer Fehlermeldung und der Übergabe von Nullwerten 

für alle Winkel ab. Die Nullwinkel sind eine valide Winkelstellung 

an denen ein Fehler auch ohne Debug-Ausgabe erkannt werden 

kann. 

2. Ist der TCP valide, wird zunächst der unterste Drehwinkel α (vgl. 

Abbildung 2.37) berechnet und global gespeichert. Die Berechnung 

erfolgt anhand einer Sicht von oben auf den Roboterarm, sodass sich 

aus der Ursprungspunkt und der TCP mit Hilfe eines weiteren Punktes 

auf der x-Achse ein rechtwinkliges Dreieck konstruieren lässt. Al- 

127


pha ergibt sich also aus: 

α = cos −1 Ankathete 

( 

Hypothenuse ) (2.3) 

Die Hypothenuse ist die Strecke vom TCP zum Basispunkt, während 

die Ankathete die Strecke vom TCP zur x-Achse darstellt. Bei der 

Berechnung von α tritt eine Besonderheit auf, wenn der TCP im negativen 

y-Bereich liegt. Ist dies der Fall wird der Winkel anhand eines 

negierten X-Wertes berechnet. Damit ist sichergestellt, dass sich der 

Roboterarm von den zwei Drehmöglichkeiten die kürzeste aussucht, 

wobei die kürteste aufgrund der eingeschränten Servos (maximal ca. 

180°) gleichzeitig die einzig mögliche ist. Ein Winkel von nicht erreichbaren 

315°wird beispeisweise auf einen Winkel von 135°umgerechnet. 

Die Abbildung 2.38 verdeutlicht die Äquivalenz zwischen den beiden 

unterschiedlichen Winkelstellungen, in Anbetracht der Tatsache, dass 

sich der Roboterarm in beide Richtungen bewegen bzw. beugen (vgl. 

Abbildung 2.39) kann. 

3. Ist der Drehwinkel α bestimmt, wird der dreidimensionale TCP um 

den negierten Winkel α mit Hilfe einer Rotationsmatrix gedreht, sodass 

seine y-Koordinate Null ergibt. Ab sofort kann der TCP als 

zweidimensionaler Punkt (x, z) aufgefasst werden. Aus der Abbildung 

2.39 geht hervor, dass zur Bestimmung der Winkel β, γ, δ eine 

planaren Ebene ausreicht. Das gesamte dreidimensionale Problem 

wird in ein planares, zweidimensionales Problem transformiert. 

4. Ausgehend von dem planaren System werden zwei Kreise gebildet, 

wobei sich ein Kreis K TCP um den TCP mit dem Radius (Abstand 

TCP zum Mittelpunt des vierten Gelenks) befindet. Der zweite Kreis 

K Base liegt um den Mittelpunkt des zweiten Gelenks. 

5. Anschließend wird die kürzeste Strecke zwischen den beiden Kreisen 

anhand der Schnittpunkte einer Geraden durch die Kreismittelpunkte 

berechnet. 

Die Formel ergibt sich aus dem Gleichsetzen der Geradengleichung 

sowie der Kreisgleichung 

y = mx + b (2.4) 

r 2 = (x − x m ) 2 + (y − y m ) 2 (2.5) 

128


Kreis K TCP 

thirdframeRadius 

• 

TCP 

• 

P inters2 

• 

P δ1 

P δ3 

secondFrameOrigin 

• 

P γ2 

•• 

• 

• 

• 

P γ1 

P inters1 

P δ2 

Abstand d s 

zw. 

Kreisen 

• P δ4 


baseRadius 

Kreis K Base 

Abbildung 2.40: Fall 1: Kreis um TCP (grün) und Basis (schwarz) überlappen 

sich nicht 

, wobei (x m /y m ) den Kreismittelpunkt definiert. Durch das Gleichsetzen 

ergibt sich nach Umstellung folgende Gleichung für x-Koordinaten 

beider Schnittpunkte: 

x 1,2 = ±√ −b 2 −2bmx m +2by m −m 2 x 2 m+m 2 r 2 +2mx m y m −y 2 m+r 2 −bm+my m +x m 

m 2 +1 

Die y-Koordinaten dieser Schnittpunkte werden durch Einsetzen in 

2.4 ermittelt. Dadurch werden zwei Schnittpunkte vom Kreis und 

Gerade eindeutig bestimmt, welche im nächsten Schritt Verwendung 

finden. Da die Gerade durch die Mittelpunkte zweier Kreise verläuft, 

hat die Gleichung immer zwei Lösungen. Sollte die Gerade vertikal 

verlaufen, wäre sie nicht durch die Gleichung y = mx + b beschreibbar, 

da ein x-Wert auf unendlich viele y-Werte abbildet. Um dieses 

Problem zu lösen, werden in diesem Fall die x- und y-Werte der beiden 

Kreismittelpunkte vertauscht und später für die Schnittpunkte 

wieder zurückgetauscht. 

6. Danach wird eine Fallunterscheidung durchgeführt. Die Abbildung 2.40 

(Fall 1) und Abbildung 2.41 (Fall 2) verdeutlichen die beiden Fälle. 

Im ersten Fall haben die beiden Kreise K Base und K TCP keinen oder 

129


einen Schnittpunkt, währen sich die Kreise in dem zweiten Fall in 

zwei Punkte schneiden, der TCP also nahe an der Basis liegt. Die 

Schnittpunkte zweier Kreise werden bestimmt durch: 

dx = KreisB x − KreisA x (2.6) 

dy = KreisB y − KreisA y (2.7) 

Damit kann die Entfernung d der Kreismittelpunkte berechnet werden: 

d = √ dx · dx + dy · dy (2.8) 

Der Pythagoras zwischen beiden Radien der Kreise und Abstand 

zwischen den Kreismittelpunkten: 

a = radius A · radius A − radius B · radius B + d · d 

2 · d 

(2.9) 

Die Hordale h, welche eine Gerade darstellt, die über die Schnittpunkte 

der Kreise verläuft. 

h = √ radius A · radius A − a · a (2.10) 

Die zwei Schnittpunkte ergeben sich dann aus: 

• X-Wert: S 1,2 = KreisA x + a d · dx ± h d · dy 

• Y-Wert: S 1,2 = KreisA y + a d · dy ± h d · dx) 

Fall 1 (Kreise überlappen sich nicht) 

• Um die obigen Schnittpunkte aus der Formel werden in 

diesem Schritt Kreise mit dem Radius thirdFrameRadius (Länge 

des Verbindungsstücks zwischen dritten und viertem Link) 

gelegt. 

Diese Kreise werden mit dem Kreis K Base geschnitten und 

man erhält zwei Lösungen für den Punkt des dritten Links 

(Gamma) P γ 

• Um die beiden Gammapunkte P γ1 und P γ2 werden wiederum 

Kreise mit dem Radius thirdFrameRadius (Länge des Verbindungsstücks 

zwischen dem zweiten und dritten Link) gelegt. Diese beiden 

Kreise werden mit dem Kreis um den TCP K TCP geschnitten. 

Insgesamt ergeben sich daraus vier Schnittpunkte, welche 

130


mögliche Lösungen für den Punkt des vierten Links (Delta) 

P δ ergeben. 


• 

Kreis K TCP 

• 

• 

• 

• 

TCP 

secondFrameOrigin 

• 

• 

• 


baseRadius 

• 

Kreis K Base 

„Notbremsekreis“ 

Abbildung 2.41: Fall2: Kreis um TCP (grün) und Basis (schwarz) überlappen 

sich 

Fall 2 (Kreise überlappen sich) 

• Zuerst wird zu der Verbindungsgeraden zwischen den Kreismittelpunkten 

von K Base und K TCP eine orthogonale Gerade 

berechnet. 

• Es folgt eine Berechnung der Schnittpunkte zwischen der orthogonalen 

Gerade und dem Kreis K TCP . Die Schnittpunkte 

ergeben die beiden möglichen Punkte des vierten Links P δ . 

• Um die beiden Punkte P delta1 und P delta2 wird jeweils ein 

Kreis mit dem Radius thirdFrameRadius (Länge des Verbindungsstücks 

zwischen dritten und viertem Link) gelegt. 

Anschließend werden die Schnittpunkte der beiden Kreise 

mit dem Kreis K Base berechnet. 

• Sollte es keine Schnittpunkte geben wird die Orthogonale 

so lange in Richtung des Basispunkts (secondFrameOrigin) 

131


bewegt, bis es entweder Schnittpunukte gibt oder die Gerade, 

btw der TCP zu naha an den Basispunkt herankommt 

(Notbremse), vgl. Abbildung 2.41. Daraus resultieren die vier 

möglichen Lösungen für die Punkte des dritten Links 

(Gamma) P γ . 

7. Aus den soeben berechneten Punkten können im Anschluss Lösungen 

für die Winkel berechnet werden. Abbildung 2.42 zeigt die resultierenden 

Punkte aus dem Schneiden der Kreise. 

P γ2 

• 

γ 

P δ2 

P δ3 

P δ1 

• 

δ 

• 

δ‘ 

P 

• δ4 

• 

β 

• 

β‘ 

P γ1 

• γ‘ 

Abbildung 2.42: Winkelberechnung aus den Ergebnispunkten 

Anhand der Abbildung 2.42 wird das Hauptproblem der Rückwärtskinematik 

verdeutlicht: Es gibt mehrere Möglichkeiten die Links des 

Roboters anzuordnen um den vorgegebene Position des Tool-Center- 

Point zu erreichen. Die unterschiedlichen Varianten sind mit den unterschiedlichen 

Farben dargestellt. Aus den Punkten werden die Winkel 

berechnet. Zu jeder Variante existiert dann ein Winkelvektor. Maximal 

gibt es bei der oben beschriebenen Lösung vier Winkelvektoren. Die 

unzulässigen Winkelvektoren werden mit Kostenfunktion verworfen 

sowie aus den zulässigen der beste Winkelvektor ausgewählt. Die 

Kostenfunktion wird später ausführlicher beschrieben. 

Die Berechnung der Winkel erfolgt mit Hilfe einer trigonometrischen 

Funktion. Dabei muss berücksichtigt werden, wie die Punkte liegen, 

sodass ggf. 360°- Winkel gerechnet werden muss. Abbildung 2.42 

zeigt z. B. die Winkel λ und λ ′ . Dabei wird der Winkel stets gegen 

132


den Uhrzeiger Sinn gemessen. Es ist nicht leicht zu unterscheiden, ob 

der innere oder der äußere Winkel genommen wird. 

Die Berechnung des Winkels durch die unten beschrieben Funktion 

liefert stets den kleinsten (inneren) Winkel zwischen zwei Links (Kettenglieder). 

Dieses Problem ist in der Sektion Probleme 2.2.3.3 (dritter 

Punkt) erläutert. Die Formel zum Berechnen der Winkel ist der Kosinussatz, 

der sich bei drei bekannten Punkten (jedoch drei unbekannten 

Winkeln) eines Dreiecks anbietet. Die Seiten a, b, c ergeben sich 

aus dem Abstand der Punkte zueinander: 

Winkel = cos −1 ( a2 + b 2 − c 2 

) (2.11) 

2ab 

8. Die verschiedenen Lösungswinkel werden, bevor die günstigste Lösung 

herausgefiltert wird, vom Modell auf die Hardware (Servos) 

umgerechnet. Dabei wird die Drehrichtung der einzelnen Servos gemäß 

Abbildung 2.35 berücksichtigt, sodass ein Wertebereich von 0°bis 180°entsteht. 

9. Um die günstigste Lösung für Menge an Lösungswinkeln für β, γ, δ 

zu finden, werden zunächst im Rahmen einer Kostenfunktion alle von 

den Servos nicht erreichbare Winkel aussortiert. Anschließend wird 

die Summe der ursprünglichen und der möglichen neuen Winkel 

berechnet und verglichen. Das Tupel von Winkel, welches den niedrigsten 

Abstand aufweisen bleibt zusammen mit dem bereits verwendeten 

Winkel α als finale Lösung übrig. 

Der errechnete Winkelvektor kann anschließend über die Schnittstelle zum 

setzen der Winkel an den RoboterArm übergegeben werden. 

Datenstruktur (extern) 

os-toolbox/plugins/automation/RoboArm/InverseKinematic.h 

Interface der Rückwärtskinematik. 

os-toolbox/plugins/automation/RoboArm/InverseKinematic.cpp 

Implementierung der Rückwärtskinematik. 

Datenstruktur (intern) 

Die Rückwärtskinematik rechnet mit diversen geometrischen Objekten, dessen 

Datenstruktur im Folgenden erläutert wird. Die planare y-Koordinate entspricht 

der z-Koordinate des Intertialsystems gemäß Abbildung 2.35. Sämtliche in 

unten genannter Datenstruktur gespeicherten Werte sind vom Typ double. 

133


Kreis 

Kreise werden als QVector3D in der Form (x, y, r) gespeichert, wobei 

x, y die planaren Koordinaten des Kreismittelpunktes sind und r den 

Radius des Kreises darstellt. 

Punkt 

Punkte werden als QVector2D in der Form (x, y) dargestellt, wobei 

es sich dabei um planare Koordinaten handelt. Globale Punkte sind 

beispielsweise secondFrameOrigin, thirdFrameOrigin sowie f ourthFrame- 

Origin, welche den Ursprung der Bezugssysteme für das zweite, dritte 

bzw. vierte Gelenk bilden. 

Winkel 

Winkel werden als QVector3D bzw. QVector4D in der Reihenfolge 

α, β, γ, δ dargestellt, wobei der Winkel α lediglich in dem QVector4D 

kodiert ist. Da für α lediglich eine Lösung berechnet wird, befindet 

sich in der globalen Variable QVector < QVector3D > solutions eine 

Sammlung möglicher Lösungen für die Winkel β, γ, δ (siehe Abbildung 

2.39). 

Schnittstelle 

QVector4D getAngleVector ( double x , double y , double z); 

Diese Schnittstelle zur Rückwärtskinematik erlaubt die Übergabe eines Tool- 

Center-Point in Form von dreidimensionalen Koordinaten. Die Reihenfolge 

der Koordinaten ist in Abbildung 2.35 festgelegt und bezieht sich 

auf das Intertialsystem. Zurückgegeben wird ein QVector4D, in welchem 

die Winkel mit der Reihenfolge α, β, γ, δ kodiert sind, wobei in Bezug auf 

den Roboterarm von unten nach oben gezählt wird, sodass α den untersten 

Drehwinkel des Roboterarms repräsentiert. 

Probleme 

Im Rahmen dieses Arbeitspakets ergaben sich folgende Problematiken für 

die Vorwärtskinematik: 

• Die Einarbeitung in das Qt-Framework, welches via USB mit dem 

FPGA kommuniziert stellte sich als zeitaufwändig heraus 

• Die Aufstellung der Transformationsmatrix wurde in der Fachliteratur 

unterschiedlich dargestellt 

134


Bei der Entwicklung der Rückwärtskinematik sind folgende Probleme aufgetreten: 

Im Allgemeinen hat es lange gedauert, bis das Konzept der Rückwärtsrechnung 

vollständig geklärt war und ein algebraisches Realisierunskonzept 

erarbeitet wurde. Hierfür sind folgende Schritte notwendig: 

1. Die Matrizen für Rückwärtsrechnung für jeden Winkel aufstellen. 

2. Diese Matrizen multiplizieren und daraus die allgemeine inversen 

Matrix T bestimmen. 

3. Matrizen der Vorwärtsrechnung miteinander multiplizieren zur allgemeinen 

Matrix T. 

4. Den Ortsvektor des Tool-Center-Point mit der allgemeinen inversen 

Matrix T multiplizieren. 

5. Die Lage des TCP bestimmen und als Zahlenmatrix angeben. 

Die obigen Schritte kosten sehr viel Zeit, weil sie manuell berechnet werden 

mussten. Durch die Fehleranfälligkeit der Berechnung großer Matrizen 

mussten einige Rechnungen verworfen und neu angefangen werden. Da 

die Rechenschritte sehr stark voneinander abhängen ist kein einziger Fehler 

zulässig. Um den mathematischen Zeitaufwand zu reduzieren wurden elektronischen 

Hilfsmittel hinzugezogen. Als erste Hilfsmittel hat der Internetdienst 

www.wolframalpha.com fungiert, was unglücklicherweise durch 

maximale Zeichen in der Eingabe beschränkt war. Daraufhin wurde eine 

Testversion des mathematischen Tools Matlab installiert, welches die dynamische 

Berechnung der Matrizen erheblich beschleunigt hat. Weitere 

Schritten sind: 

6. Die allgemeine Matrix T mit dem Lagevektor und mit dem TCP multiplizieren 

und rechnerisch als Zahlenmatrix angeben. 

7. Das Ergebnis der Multiplikation mit T (−1) · TCP gleichsetzen 

Schritte 5. und 6. waren aufgrund der sehr oberflächlichen Beschreibungen 

aus der Fachliteratur kaum ersichtlich. Dieser Schritt wurde erst klar, nachdem 

zur Verifizierung der bis zum genannten Schritte eine akademisch 

ausgebildete Fachperson zur Hilfe gerufen wurde. Bis zu diesem Zeitpunkt 

wurde versucht die Gleichung gemäß der Fachliteratur zu lösen. Die letzten 

Schritte: 

135


8. Das Gleichsetzen ergibt ein nichtlineares Gleichungssystem mit mehreren 

Additiven Terme, die sich mit Kosinus- und Sinusfunktionen der zu 

bestimmenden Winkel in nicht trivialen Zusammenhängen befinden. 

9. Dieses Gleichungssystem muss nach den Kosinusse und Sinusse der 

gesuchten Winkel aufgelöst werden. 

10. Nachdem die Sinusse und Kosinusse bestimmt sind, sind die Winkel 

mit Hilfe der Funktion Atan2 zu berechnen. 

Schritt 8 lässt sich laut verschiedenen Fachliteraturquellen auf keine konventionelle 

Art und Weise realisieren. Diese Operation ist dem mathematischen 

Wissen des Entwicklers überlassen. Bei der Ausführung von 

Schritt 8 hat es sich herausgestellt, dass aufgrund der Degradiertheit des 

Roboters die Lage des TCP nicht beliebig gewählt werden darf, wie es bei 

den Robotern mit 6 Freiheitsgraden der Fall wäre. Laut fachlichen Literaturquellen 

ist es nicht auszuschließen, dass ein serieller Roboter durch 

seine Konstruktion oder degradierten Freiheitsgarde keine Lösungen im algebraischen 

Verfahren haben kann. Anschließend wurde die Kinematik des 

Roboters erneut (ohne Fachliteratur) untersucht und festgestellt, dass das 

Problem der Rückwärtskinematik durch eine komplett geometrische Lösung 

lösbar ist. Der Algorithmus wurde hierfür entworfen und begonnen 

diesen mit ersten Teilerfolgen zu implementieren. Auch diese Lösung musste 

im Anschluss noch einmal komplett umgestellt werden, wobei die Methoden, 

wie z.B. Kreisschnittpunkte beibehalten wurden, jedoch im Rahmen 

eines neuen Algorithmus. 

Bei der finalen Lösung waren hauptsächlich folgende Probleme zu lösen: 

• Abhängig von der Lage des TCPs wurden zwei Fälle identifiziert, die 

einer unterschiedlichen Strategie bedürfen (siehe Abbildung 2.40 und 

Abbildung 2.41). Zu diesem Zweck wird ein Kreis um den Basispunkt 

(Ursprung des zweiten Gelenks) mit dem Radius der Länge zwischen 

Basispunkt und dem Ursprung das nächsten Bezugssystems gelegt 

und ein weiterer Kreis um den Tool-Center-Point mit dem Radius der 

Länge zwischen TCP und dem letzten Gelenk bzw. Bezugssystems. 

Sollten sich die Kreise nicht schneiden, liegt Fall 1 vor, scheiden sich 

die Kreisen in zwei Punkten, liegt Fall 2 vor. Zuvor wurde versucht 

den zweiten Fall mit den Methoden des ersten Falles zu lösen, was 

nicht gelang und aus der die oben beschriebene Fallunterscheidung 

resultierte. 

136


• Bei dem zweiten Fall (Kreisüberlappung) existiert ein Spezialfall, welcher 

durch das Testen von Randfällen ermittelt wurde. Dieser Fall muss 

im Rahmen des 2. Falls gesondert berücksichtigt werden, um ein korrektes 

Ergebnis zu gewährleisten. Er tritt genau dann auf, wenn sich 

die Kreise (um die Basis und den TCP) zwar überlappen, aber die 

Hilfskreise welche um die Schnittpunkte der Orthogonalen mit dem 

TCP-Kreis gelegt werden sich nicht mit dem Basiskreis schneiden. 

Diesen Sonderfall tritt auf wenn sich der TCP nicht nahe genug an 

dem Basisradius befindet, aber auch nicht zu weit entfernt ist, um in 

Fall 1 behandelt zu werden. Um dieses Problem zu lösen wird die orthogonale 

Gerade, welche den TCP schneidet immer weiter zu dem 

Mittelpunkt das Basiskreises verschoben, solange bis die Hilfskreise 

einen Schnittpunkt mit dem Basiskreis haben oder der TCP zu nahe 

an der Basis liegt um erreicht zu werden. 

• Ein weiteres Problem ist bei der Implementierung der Funktion, welche 

aus drei Punkten einen Winkel bestimmen sollte aufgetreten. Da das 

Modell auch Winkel über 180°zulässt, muss bei einer Winkelberechnung 

entschieden werden, ob der Winkel über oder unter 180°um 

einem Punkt berechnet werden soll (siehe Abbildung 2.43). Dieses 

Problem entsteht bei der Berechnung der Winkel γ und δ, da dort 

die Lage des Dreiecks (aus drei Bezugspunkten entstanden) sehr dynamisch 

ist. Um dieses Problem zu lösen, wurden zwei Hilfswinkel 

(virtuell und real) eingeführt (siehe Abbildung 2.44). Beide Winkel 

beginnen bei einem festen Punkt des Dreiecks, welcher der Punkt des 

untersten Gelenks des Roboterarms ist. An diesem Punkt wird eine 

virtuelle x-Achse gelegt, welche die 0°Line der beiden Hilfswinkel 

angibt. Der virtuelle Winkel bildet die Drehung von der (virtuellen) 

x-Achse zur Verdindungsline der beiden Punkte, welche nicht an dem 

zu bestimmenden Winkel liegen. Der reale Winkel bildet die Drehung 

zu der Verbindungsline zwischen dem Punkt auf der (virtuellen) x- 

Achse und dem Punkt an welchem der zu bestimmende Winkel liegt. 

Abhängig von der Lage der Punkte zueinander (Fallunterscheidung) 

müssen diese Hilfswinkel umgerechnet bzw. von 360°abgezogen werden. 

In Anschluss wird geprüft, ob der virtuelle Winkel größer ist als 

der reale Winkel und ggf. der zu bestimmende Winkel von 360°abgezogen. 

Dieses Problem wurde zunächst versucht vektoriell zu lösen, hatte 

aber auch hier das Problem, das nicht eindeutig war, ob der ausgerechnete 

Winkel oder der (360°-Winkel) berechnet werden musste. 

137


C‘ 

• 

C‘ 

• 

• 

γ‘‘ 

⍺ R ‘ 

γ‘ 

B 

• 

γ 

• 

B 

• 

C 

• 

• 

⍺ V ‘ 

A 

• 

A 

⍺ V 

Abbildung 2.43: Problem der Auswahl der korrekten Winkels 

C‘ 

• 

γ‘‘ 

⍺ R ‘ 

C 

• 

B 

• 

γ 

C 

• 

• 

• 

B 

• 

⍺ R 

P TCP2 

A 

⍺ V ‘ 

P base2 

β 

γ 

⍺ V 

P base1 

• 

x β‘ 0 

Abbildung 2.44: Lösung der Auswahl der korrekten Winkels mittels Hilfswinkel 

(real r/virtuell v) 

γ‘ 

β 

Testen 

Der Algorithmus der Vorwärtskinematik hat bei den geometrischen Lösungen 

als Test zum Überprüfen des Tool-Center-Point fungiert. Dabei werden 

die von der Rückwärtskinematik (anhand eines frei gewählten TCP) 

berechneten Winkel in die Vorwärtskinematik weitergegeben und der dort 

γ 

138 

• 

δ‘ P 

• TCP4 

P TCP2 

P TCP1 

δ 

P base1 

• γ‘ 

• • 

• •


errechnete TCP mit dem ursprünglichen TCP verglichen, der als Parameter 

für die Rückwärtskinematik fungiert hat. Der beschriebene Testfall wird in 

Python wie folgt umgesetzt: 

1 # TCP uebergeben und Winkel zurueck bekommen 

2 angles = robi . getAngleVector (TCP [ 0 ] , TCP [ 1 ] , TCP [ 2 ] ) 

3 

4 # Zurueckbekommende Winkel setzen 

5 robi . setAngles ( [ angles . x , angles . y , angles . z , angles .w, 0 . 0 , 

0 . 0 ] ) 

6 

7 # TCP anhand a k t u e l l e r Winkel e r m i t t e l n 

8 p r i n t robi . getTCP ( ) 

Ausblick 

Aus diesem Arbeitspaket resultieren weitere Aufgaben: 

• Der Roboterarm soll zum Nachzeichnen eines Gesichts eine Linie abfahren. 

Dafür müssen die Punkte zwischen dem Start- und Zielpunkt 

approximiert bzw. interpoliert werden. 

139


2.2.4 Objektverfolgung 

Das Ziel des Arbeitspaketes Objektverfolgung ist einen Arm zu erkennen. 

Dabei sollen am Arm die Winkel der einzelnen Gelenke berechnet 

werden. Der zu erkennende Arm befindet sich dabei vor einem Hintergrund, 

der einen guten Kontrast zum Akteur bietet. Zur Unterscheidung 

der einzelnen Gelenke des Arms dürfen Markierungen verwendet werden. 

Die Erkennung des Arms soll am Computer mit Hilfe des OFFIS Automation 

Framework durchgeführt werden. Zur Aufnahme der Szenerie wurde 

eine Webcam 14 , sowie eine Industriekamera 15 verwendet. Die Erkennung 

der Winkel des Arms sowie des Arms selber erfolgt dabei zweidimensional. 

Die zwei Dimensionen prägen sich in Breite und Höhe aus. 

Ein erstes Teilziel ist es, die Hand des Akteurs zu erkennen und eine 

entsprechende Bewegung dieser nachzuvollziehen, dieses wird im nächsten 

Unterabschnitt beschrieben. Danach wird die Erkennung des Arms 

und die Berechnung der Winkel erläutert. 

2.2.4.1 Bewegungsrichtungserkennung der Hand 

Ein erster Schritt zur Realisierung eines Verfahrens zur Objektverfolgung 

ist die Erkennung der Bewegungsrichtung der Hand. Zu diesem Zweck 

wurden diverse Videos mit Hilfe der unterschiedlichen Kameras aufgenommen. 

Hierbei wurde darauf geachtet, dass verschiedene Entfernungen und 

Hintergründe untersucht wurden. Ebenfalls wurden unterschiedliche Belichtungsverhältnisse 

und Materialien zur Markierung untersucht. Auf diesen 

Videos bewegt ein entsprechender Akteur seinen Arm und damit auch 

seine Hand. 

Zunächst wurde mit Hilfe von QT 16 ein Filter geschrieben, welcher den 

Hintergrund aus dem Video subtrahieren kann. Dies geschieht indem die 

Szenerie, das erste Bild im Video, als Hintergrund angenommen wird. 

Diese Herangehensweise hat jedoch folgende Nachteile: 

• Farben des Hintergrundes werden auch vom Akteur abgezogen. Ist 

Rot im Hintergrund, so wird dieses auch anteilig vom Akteur abgezogen. 

• Durch die automatische Helligkeitsanpassung und / oder Schwankungen 

bei der Belichtung entstehen Artefakte im Hintergrund. 

14 Logitech c270: http://www.logitech.com/de-de/product/hd-webcam-c270?crid=34 

15 FireWire CCD Color Camera: http://www.theimagingsource.com/en_US/products/ 

cameras/firewire-ccd-color/dfk31af03/ 

16 C++ Klassenbibliothek: http://de.wikipedia.org/wiki/Qt_Bibliothek 

140


Aus diesen Gründen wird eine Extrahierung von zum Beispiel einer Farbe 

schwierig, siehe Abb. 2.45. Der Ansatz über die Subtraktion des Hintergrundes 

musste daher verworfen werden. Sobald die Tiefeninformationen 

durch die 3D-Kamera hinzukommt, ist das Extrahieren des Hintergrundes 

einfacher zu realisieren, z.B. mit Hilfe eines Schwellwertes über die Tiefeninformationen. 

Abbildung 2.45: Beispielbild: Probleme durch Extraktion des Hintergrundes 

Über die Extrahierung der Farbe Rot wurde versucht die Haut des Akteurs 

zu detektieren. Die Farbe Rot wurde ausgewählt, da sie sich gut detektieren 

lässt. Dieses hat sich jedoch ebenfalls durch sich ändernde Lichtverhältnisse 

als schwierig erwiesen. Ebenfalls ist die Erkennung von zum Beispiel 

Köpfen nicht zu vermeiden. Dies ist hinderlich bei der definierten Erkennung 

der Hand. Um dieses Problem zu lösen wurde dazu übergegangen 

141


einen roten Handschuh als Markierung für die Hand zu verwenden, siehe 

Abb. 2.46. 

Abbildung 2.46: Beispielbild: Verfolgung der Hand mit Hilfe von Schwerpunkten 

innerhalb einer Kontur. 

Mit Hilfe einer Bildverarbeitungskette, siehe Abb. 2.47, konnte die Position 

der Hand ermittelt werden. Dazu wurde die Extraktion des roten 

Farbkanals durchgeführt. Diese überführt gleichzeitig das RGB-Bild in ein 

Graustufenbild. Um nun Bereiche mit hohen Rotwerten zu isolieren, wurde 

das Bild über einen Schwellwertfilter binarisiert. Artefakte ließen sich durch 

entsprechende morphologische Operationen nach dem Schwellwertfilter 

herausfiltern. Als Punkt, welcher verfolgt wird, wurde für die Trajektorie 

der Schwerpunkt der jeweiligen resultieren Flächen verwendet. Die Trajektorie 

beinhaltet eine geordnete Liste der über die Zeit bekannten Schwerpunkte. 

Hierbei wurde zwecks Speicherplatzbegrenzung nur dann ein 

142


Punkt hinzugefügt, wenn er eine minimale Distanz zu seinem Vorgänger 

hat. Ebenfalls existiert eine Methode in der zu definierten Zeitpunkten für 

jedes Gelenk ein Wert gespeichert wird, sodass es möglich ist aus diesen 

Werten Gesten zu rekonstruieren. 

Abbildung 2.47: Bildverarbeitungskette: Verfolgung der Hand mit Hilfe 

von Schwerpunkten innerhalb einer Kontur 

Datenstruktur 

sprint2/objekt_tracking/paket1/objekt_tracking_hand.pro : OFFIS Automation 

Framework Projektdatei 

sprint2/objekt_tracking/paket1/bildverarbeitungskette_hand.ogr : Bildverarbeitungskette 

für die Erkennung der Hand und der Darstellung 

der ermittelten Position / Trajektorie. 

sprint2/objekt_tracking/paket1/objekt_tracking_hand.py : Automationsprogramm 

zum Erhalt der Positions der Hand. 

sprint2/objekt_tracking/paket1/Handverfolgung mit Handschuh.avi : Beispielvideo 

für die Verfolgung der Hand. 

143


2.2.4.2 Arm mit Winkeln 

Aufbauend auf der vorher erstellten Lösung zur Verfolgung einer Hand 

wird nun die Erkennung des Arms erläutert. Beim Arm sollen die Winkel 

der Gelenke ausgegeben werden, so dass sie in einem weiteren Schritt, 

siehe Arbeitspaket 2.2.5, dem Roboterarm übergeben werden können. Der 

strukturelle Verlauf entspricht dabei der im folgenden aufgeführten Grafik. 

Ansteuerung(Python) 

Winkelberechnung(Python) 

Kalibrierung(Python) 

Bildverarbeitung(Python) 

Bildvorverarbeitung(OFFISAutomationToolbox) 

Bildaquise(Webcam) 

Abbildung 2.48: Aufbau des resultierenden Ergebnisses 

Zunächst wurde hierzu eine Methode geschrieben, welche eine Kalibrierung 

auf dem Akteur in der Szene und dem Algorithmus zur Erkennung der 

Gelenke vornimmt, siehe Abb. 2.49. Dieser erwartet einen horizontal ausgestreckten 

Arm mit den entsprechenden Markierungen und weist je nach 

Entfernung zur Y-Achse dem Schwerpunkt ein Gelenk zu. Wie in Abschnitt 

2.2.4.1, werden rote Markierungen verwendet, da sich diese stabil 

extrahieren lassen. 

144


Abbildung 2.49: Beispielbild: Kalibrierung des Systems auf die Gelenke des 

Akteurs 

Auch hier wurde vorwiegend mit Videomaterial gearbeitet. Um den Arm 

zu erkennen, wurde ähnlich wie bei der Handerkennung mit Hilfsmitteln 

gearbeitet. Statt mit einem Handschuh zu arbeiten wurden die Gelenke 

des Akteurs mit roten Markierungen umwickelt. Rotes Klebeband stellte 

sich hierbei als unzureichend heraus, da es nur sehr schlecht erkannt wird. 

Dies liegt an der Reflektion der Lichtes durch das glatte Material. siehe 

Abb. 2.50. 

145


Abbildung 2.50: Beispielbild: Trennung der Kontur durch Reflekton des 

Lichtes am Klebeband 

Papierstreifen sind jedoch gut wahrnehmbar, haben jedoch das Problem, 

dass sie im Gelenk oft vom Arm zusammengedrückt werden, siehe Abb. 

2.50. Dies führt dazu, dass die Flächen verzerrt werden oder verschwinden. 

Daher wurde ein anderer Ansatz gewählt. Die Streifen wurden nun um 

den Arm jeweils vor und nach den Gelenken gewickelt. Lediglich an der 

Schulter wurde auf einen Streifen vor der Schulter verzichtet. Jedoch ist es 

auch hier möglich, dass sich diese Flächen verändern. Problematisch ist es, 

sobald sich die Flächen berühren und als eine Fläche erkannt werden. Nun 

kann nur noch schwer ermittelt werden, welche Fläche zu welchem Gelenk 

führt, siehe Abb. 2.51. 

146


Abbildung 2.51: Beispielbild: Zusammenfließen der Konturen durch 

Berührung 

147


Diese fünf Markierungen wurden zunächst auch mit der selben Bildverarbeitungskette 

bearbeitet und ihre Schwerpunkte für die Berechnungen 

herangezogen. Um die Berechnungen zu vereinfachen wurde der Filter zur 

Erkennung von Konturen durch einen zur Erkennung von BLOBs, steht für 

Binary Large Objects, ausgetauscht siehe Abb. 2.52. Der Vorteil liegt darin, 

dass man hier eine Pose2D erhält. In dieser sind X- und Y-Koordinaten 

sowie der Winkel Phi enthalten. Dieser Winkel wird intern durch eine 

Hauptkomponentenanalyse errechnet, siehe Abb. 2.55. 

Abbildung 2.52: Bildverarbeitungskette: Verfolgung des Arms mit Hilfe 

von Posen 

Die hierbei gewonnen Punkte alleine reichten jedoch nicht aus, um die 

Winkel der Gelenke stabil zu bestimmen. Daher wurden nicht mehr die 

Schwerpunkte sondern Posen verwendet. Posen haben den Vorteil, das 

neben den Punktinformationen auch noch die Richtung der Hauptachse 

der Markierung angegeben wird. Da in unserem Fall Streifen verwendet 

werden liegt die Hauptachse immer orthogonal zur Achse des Ober- oder 

148


Unterarms. Dies ermöglicht sowohl die Koordinaten der Gelenke als Schnittpunkt 

der Geraden zu bestimmen als auch die Bestimmung des Winkels der Vektoren 

zueinander. 

Ein Problem bei der Verwendung von Posen ist die Richtung des Winkels. 

Dieser steht ja nach Stauchung des Papierstreifens in unterschiedliche Richtungen, 

siehe Abb. 2.50 und Abb. 2.53. Diese auf immer die selbe Richtung 

zu normieren gestaltete sich ebenfalls als schwierig. Aus diesem Grund 

wurde die Richtung aus den Berechnungen genommen. 

Abbildung 2.53: Beispielbild: Springen der Posen 

In einem Weiteren Schritt wurden die Markierungen auf drei Streifen in 

der Mitte von Oberarm, Unterarm und Hand reduziert. Dies reicht bei der 

vorhin betrachteten Vorgehensweise aus, um alle Gelenke zu bestimmen. 

Die endgültige Lösung bestimmt die Winkel indem zuerst die Orthogonalen 

(im Bild o1 und o2, siehe Abb. 2.54) der Posen bestimmt werden. 

Diese dürfen für eine Schnittpunktberechnung ungerichtet sein. Nach- 

149


dem der Schnittpunkt (im Bild das gelbe Kreuz, siehe Abb. 2.54) errechnet 

wurde, werden die gerichteten Vektoren aus den Punkten vor und nach 

dem Gelenk zusammen mit dem Schnittpunkt bestimmt (im Bild v1 und 

v2, siehe Abb. 2.54). Diese Vektoren haben einen Winkel untereinander, 

der durch Kreuzprodukt(v1, v2)/Norm(v1) ∗ Norm(v2) gefunden werden 

kann. Da der resultierende Winkel zwischen 0 Grad und 360 Grad liegen 

soll, wird der Winkel noch dahingehend bestimmt, ob der Kleinere (0 Grad 

+ alpha) oder der Größere (360 Grad - alpha) gesucht. 

Abbildung 2.54: Beispielbild: Berechnung der Winkel mit Hilfe des 

Schnittpunktes der Orthogonalen zu Phi 

Das sich aus der Bildvorverarbeitung, -verarbeitung und den Berechnungen 

ergebende Resultat kann im folgender Abbildung 2.55 betrachtet werden. 

150


Abbildung 2.55: Beispielbild: Verfolgung des Arms mit Hilfe von Posen 

151


Datenstruktur 

sprint2/objekt_tracking/paket2/object_tracking_arm.pro : OFFIS Automation 

Framework Projektdatei 

sprint2/objekt_tracking/paket2/bildverarbeitungskette_arm.oap : Bildverarbeitungskette 

für die Erkennung des Arms und der Berechnung 

der entsprechenden Winkel zwischen den Gelenken. 

sprint2/objekt_tracking/paket2/object_tracking_arm.py : Automationsprogramm 

zum Erhalt der Positions der Hand. 

sprint2/objekt_tracking/paket2/Armverfolgung 5 Markierungen.avi : Beispielvideo 

für die Verfolgung des Arms und die Berechnung der Winkel. 

152


2.2.5 Zusammenführung von Objektverfolgung und 

Roboterarmsteuerung 

Ziel dieses Arbeitspaketes ist es die Ansteuerung des Roboterarms, siehe 

Abschnitt 2.2.3, mit Hilfe der in der Objektverfolgung, siehe Abschnitt 2.2.4, 

gewonnenen Daten durchzuführen. Am Ende des Paketes soll es einer beliebigen 

Person mit Hilfe seines Arms und entsprechender Markierungen 

möglich sein, den Roboterarm zu bewegen. 

Vorausgesetzt wird dabei die selbe, definierte Umgebung wie in den entsprechenden 

Arbeitspaketen. Wichtig ist hierbei, dass sich keine zu roten Gegenstände 

im Wahrnehmungsbereich der Kamera befinden. Gegenstände sind 

zu rot, sobald sie sich zu Nahe am Rotwert der Markierung befinden oder 

diese diesen sogar überschreiten. Ebenfalls darf sich der Akteur nicht zu 

weit von der Kamera entfernen, da die dann erkannten Regionen für die 

Einstellungen der Bildverarbeitungskette zu klein sind. 

2.2.5.1 Integration von Objektverfolgung und Roboterarmsteuerung 

Um die Integration von Objektverfolgung und Ansteuerung des Roboterarms 

durchführen zu können, muss zunächst eine entsprechende Schnittstelle 

existieren. Diese Schnittstelle existiert in Form eines Treibers, welcher als 

RCUnit eingebunden wird. 

Dieser musste jedoch zunächst auf die aktuelle Version der OFFIS Automation 

Toolbox angepasst werden. Ebenfalls mussten entsprechende Treiber 

für die Verwendung des FPGAS’s installiert werden. Danach ermöglicht 

der Treiber die direkte Übermittlung der Winkel an die Ansteuerung des 

Arms. Die Übergabe Dieser erfolgt hierbei in Form von Angaben in Grad. 

Es besteht zwar die Möglichkeit alle Motoren des Roboters anzusprechen, 

jedoch werden nur die Winkel verwendet, welche durch das zweidimensionale 

Verfahren erkannt werden können. 

Nach der Integration der bestehenden Arbeitspakete haben sich verschiedene 

Probleme ergeben. Das größte Problem ergab sich durch die Reaktionszeit 

des Roboterarms. Dies wurde behoben durch die direkte Verwendung des 

Treibers, der RCUnit. Ebenfalls wurde eine Debug-Ausgabe, welche über 

die Hardware lief, entfernt. Diese Änderungen führt zu einer signifikanten 

Verbesserung der Performanz des Systems. 

2.2.5.2 Erstellung eines stabilen Demonstators 

Das letzte Teilziel dieses Arbeitspakets ist ein stabiler Demonstrator. Hier 

soll dafür gesorgt werden, dass eine möglichst beliebige Person, mit Hilfe 

153


entsprechender Markierungen, den Roboterarm bewegen kann. 

Zur Verbesserung der Bedienung wurde eine zusätzliche grafische Oberfläche 

erstellt, mit welcher es möglich ist die Skripte für die Steuerung des 

Roboterarms zu steuern. Hier wurde die Möglichkeit gegeben zu wählen 

ob der Akteur den Roboterarm mit seinem linken oder rechten Arm steuern 

möchte. Ebenfalls wird dem Akteur die Zeit gegeben sich nach dem Start in 

die entsprechenden Position zur Steuerung des Roboterarms zu begeben, 


Abbildung 2.56: Grafische Oberfläche für die Interaktion mit dem Skript 

Da die WebCam jedoch nur eine Wiederholrate von maximal 15 Bildern pro 

Sekunde erreicht, sind schnelle Bewegungen durch die Bildverarbeitung 

nicht zu erkennen. Dies liegt daran, dass das Bild verschwimmt und sich 

die entsprechenden Rotwerte über einen breiteren Bereich verteilen und 

somit unterhalb des Schwellwertfilters liegen, siehe Abb. 2.57. 


Während der Integration von der Ansteuerung des Roboterarms und der 

Objektverfolgung haben sich verschiedene Schwachpunkte des Systems offenbart. 

Diese sind zum Einen die relativ geringe Geschwindigkeit der 

Kamera und die daraus resultierenden Verwischungseffekte, zum Anderen 

die geringe Anzahl an Bildern pro Sekunde. Dies ist gerade für die Bildverarbeitung 

ein entscheidender Faktor, da bei vielen Bildern bessere Mittelwerte 

gebildet werden können. Ebenfalls können bei vielen Bildern Ausreißer 

aus der Berechnung ausgenommen werden, zum Beispiel durch die 

Verwendung eines Medians. 

Ein weiterer Schwachpunkt ist die Hardware des Roboterarms. Dieser verfügt 

über ein hohes Maß an Spiel innerhalb der verschiedene Gelenke, was 

sich gerade über die Länge des Arms zum Ende hin stark auswirkt. Zudem 

bieten auch die vorhandenen Servos eine eingeschränkte Genauigkeit, sodass 

sich auch dies auf die Länge des Arms zum Ende hin stark auswirkt. 

154


Abbildung 2.57: Verwischungseffekt bei schnellen Bewegungen durch die 

geringe Geschwindigkeit der WebCam 

Die Montage neuer Servomotoren, sowie die Montage stabilerer Teile am 

Roboterarm innerhalb der Gelenke, sollte zu einer signifikanten Verbesserung 

der Bewegungspräzision führen. 

2.2.6 Fazit und Ausblick 

Die im Sprint 2 gesetzten Ziele wurden erfolgreich umgesetzt. Es erfolgten 

sowohl Anbindung des Kameramoduls sowie die USB-basierte Anbindung 

an die OFFIS-Automation-Toolbox. Die Objektverfolgung ergab 

eine Bildvor- und Bild-verarbeitungskette von Filtern sowie einen Algorithmus 

zur Verfolgung der Objekte. Dieser Algorithmus wurde in der Skriptsprache 

Python umgesetzt. Die Entwicklung der Vorwärtskinematik wurde 

als OFFIS-Automation-Toolbox-Plugin fertiggestellt, so dass die Objektverfolgung 

mit der Vorwärtskinematik zusammengeführt werden konnte. Die 

Entwicklung der Rückwärtskinematik dagegen ergab sich zum kritischen 

Pfad, da für diesen am meisten Zeit aufgewendet wurde. Nach dem die 

Entwicklung der Rückwärtskinematik durch den klassischen Ansatz über 

algebraische Lösung zeitlich nicht umsetzbar war, wurde eine geometrische 

Lösung entwickelt und implementiert. 

Das Ergebnis der Machbarkeitsstudie für das Eye-Tracking zeigt, dass eine 

155


praktische Umsetzung auf dem FPGA möglich ist, jedoch die Genauigkeit 

der Erkennung der Blickrichtung nicht ausreichend für das Projekt ist. Aus 

diesem Grund wird von der Verwendung dieser Technologie im Projekt 

RoboArm abgesehen. 

Des Weiteren wird ein neuer Sprint geplant, der als Schwerpunkt die Bildvorverarbeitung 

sowie die Evaluation und Umsetzung der Ausgabemöglichkeiten 

hat. 

156



In diesem Sprint wird der Schwerpunkt auf Bildvorverarbeitung gelegt. 

Die Entwicklung und Integration der Filterketten, des ImageBusSwitches 

sowie des Histogramms soll eine Grundlage zur anschließenden Bildverarbeitung 

und Extraktion der Umgebungsinformationen aus dem Bild darstellen. 

Der ImageBusSwitch sowie der HDMI sind zur Demonstration und dem 

Darstellen von Debug-Informationen. Das Umschalten zwischen dem Bildstrom 

ohne Verarbeitung (Urbild) und dem Bildstrom, der bearbeitet wurde, 

stellt eine hervorragende Möglichkeit dar, die Unterschiede dieser Bildströme 

zu vergleichen und über die Qualität sowie Erfolg der Bildverarbeitungskette 

Aussagen zu treffen. 

Die HDMI-Ausgabe erlaubt darüber hinaus diverse Kontrollausgaben sowie 

Benutzerinformationen auszugeben. 

2.3.1 Image Bus Switch 

Ein Ziel dieses Arbeitspaketes ist es, einen ImageBusSwitch zu realisieren, 

welcher zwischen den zwei Signalen der Kameras umschalten kann. 

Hierzu muss ein IP-Core erstellt werden, welcher auf dem FPGA entscheiden 

kann, welches der Signale über die USB-Schnittstelle versendet wird. 

Weiterhin muss dieser IP-Core Softwareseitig steuerbar sein, daher wird 

ein Treiber implementiert. 

Weiteres Ziel des Arbeitspaketes ist eine Erweiterung des bereits vorhandenen 

Kameratreibers. 

Die erweiterte Funktionalität umfasst dabei Konfigurationsmöglichkeiten 

des Treibers zur Laufzeit sowie die Implementierung einer Sleep Funktion, 

welche die bis dahin Verwendete ersetzt. 

In der ersten Woche soll der IP-Core inklusive Treiber fertiggestellt werden. 

Außerdem soll ein Timer IP-Core zum Projekt hinzugefügt werden, sowie 

ein Treiber für diesen, der eine sleep Methode bereit stellt. 

In der zweiten Woche soll der Kamera Treiber aus dem letzten Sprint so 

erweitert werden, dass die Konfiguration über den Aufruf von dokumentierten 

Methoden erfolgen kann. 

In der dritten Woche sollen die einzelnen Komponenten integriert werden. 

Ziel ist es, dass die OFFIS-Automation-Toolbox Bilder abwechselnd von der 

linken und rechten Kamera empfängt. 

157


2.3.2 Filter Cores 

Im vorherigen Sprint 2 haben die Arbeitspakete Eye-Tracking und Objektverfolgung 

Filterketten in der AMiR Automation Toolbox erzeugt. Diese 

Filterketten waren dabei Softwarekomponenten. Da die Objekterkennung 

später auf dem FPGA durchgeführt werden muss, müssen diese Filterketten 

auf den FPGA übertragen werden. Hierzu müssen IP-Cores erstellt werden, 

die die unterschiedlichen Komponenten der Filterketten umsetzten. Es 

wurden dabei vier Filter identifiziert, die für die Filterketten unerlässlich 

sind: Es handelt sich um einen Rot-Grün-Blau zu Grau, einen Schwellwertfilter 

und zwei Morphologie Filter. 

Im ersten Teil des Arbeitspakets sollen der RGB2Grey- sowie der Schwellwertfilter 

als IP-Core implementiert werden. Hierzu steht eine Arbeitswoche 

zur Verfügung. 

Der RGB2Grey Filter soll einen 24-Bit breites RGB888 Farbsignal als Eingabe 

entgegennehmen sowie dieses in ein 8-Bit breites Graustufensignal umwandeln 

und anschließend ausgeben. 

Der Schwellwertfilter soll hingegen ein 8-Bit breites Graustufensignal und 

einen 8-Bit breiten Schwellwert als Eingaben erhalten und ein 1-Bit breites 

Signal ausgeben. Dabei wird der Ausgang auf 0 gezogen, sollte das 

Graustufensignal kleiner als der Schwellwert sein, und auf 1 gezogen, sollte 

das Graustufensignal größer oder gleich dem Schwellwert sein. 

Im zweiten Teil des Arbeitspakets soll ein Morphologiefilter als IP-Cores erstellt 

werden. Diese bestehen aus zwei unterschiedlichen Filtern und werden 

in zwei gesonderten IP-Cores implementiert. Der eine IP-Core wird 

eineDilatationsoperation implementieren, welcher auf einer 3x3 Nachbarschaft 

arbeitet. Der andere IP-Core wird eine Erosionsoperation implementieren, 

welcher ebenfalls auf einer 3x3 Nachbarschaft arbeitet. Für diesen Teil des 

Arbeitspakets steht eine Wochen zur Verfügung. 

Für die Integration des Arbeitspaketes ist eine Arbeitswoche geplant. In 

dieser sollen die erstellten Filter in das bestehende System integriert werden. 

Um dies zu erreichen, werden die erstellen IP-Cores in ein bestehendes 

Projekt für den entsprechenden FPGA eingebettet. Mit Hilfe der Kamera 

bzw. der Simulationsumgebung können die Filter nun verifiziert werden. 

Dies geschieht anhand definierter Referenzbilder, welche dem System 

über die virtuelle Kamera übergeben werden sowie über die OFFIS- 

Automation-Toolbox wieder ausgegeben werden. 

158


2.3.3 HDMI Analyse 

Ziel dieses Arbeitspaketes ist eine Machbarkeitsstudie im Sinne einer Zeiteinschätzung 

für eine Bildausgabe eines Image Busses via HDMI. Da für 

die Ausgabe über HDMI ein Framebuffer nötig ist wird ausserdem eine 

Zeiteinschätzung für die Realisierung eines Image-Cache IP-Core durchgeführt. 

Dazu sollte sich das Projekt atlys_hdmi_plb_demo von Digilent angeschaut 

werden. 

Nach der ersten Woche muss dieses Arbeitspaket beendet sein und eine 

Analyse vorliegen. 

159


2.3.4 Histogramm 

Dieses Arbeitspaket hat zum Ziel, ein Histogramm dynamisch von einem 

Bildstream zu erstellen. Das erstellte Histogramm soll ausgewertet werden 

um Informationen für einen Schwellenwertfilter bereitzustellen, damit 

dieser unter anderem besser auf Helligkeitsänderungen reagieren kann. 

Das erstellen des Histogramms sowie das Auswerten der erzeugten Informationen 

wird mit zwei IP-Cores realisiert, so dass die Möglichkeit besteht, 

weitere verarbeitende Schaltungen zu entwickeln, die auf das erstellte Histogramm 

zurückgreifen. Für die Lösung dieser Aufgaben stehen insgesamt 

3 Wochen zur Verfügung. 

Der erste Abschnitt des Arbeitspakets besteht darin, das Design und die 

Implementierung des Histogramms umzusetzen, wobei das Histogramm 

als eigenständiger IP-Core geplant ist. Hierzu ist eine Woche Zeit gegeben. 

Die für den dynamischen Schwellenwert benötigte Berechnung basierend 

auf den Daten des Histogramms wird separat in einem eigenen IP-Core 

untergebracht. Die erstellten Daten werden dem Schwellenwertfilter bereitgestellt 

um eine dynamische Filterung zu ermöglichen. Dies sollte nach 

der zweiten Woche geschehen sein. 

Die dritte Woche wird zur Integration und zur eventuellen Anpassung der 

einzelnen Komponenten genutzt. 

160


2.3.5 Notwendigkeit eines Histogramms 

Dieses Arbeitspaket hat zum Ziel, die Notewendigkeit eines Histogramms 

zur dynamischen Helligkeitsanpassung des Bildstreams zu evaluieren. Da 

die eingesetzte Kamera bereits über eine histogrammbasierte Helligkeitsanpassung 

verfügt, werden für diesen Zweck Vergleichsmessungen bei 

unterschiedlichen Umgebungsparametern durchgeführt. Somit kann ermittelt 

werden, ob der Einsatz eines zusätzlichen Histogrammfilters für eine 

stabiliere Filterkette sorgen kann. Für die Messungen wird in erster Linie 

der Histogrammfilter der OFFIS IDE eingesetzt. Für die Lösung dieser 

Aufgaben stehen insgesamt 2 Wochen zur Verfügung. 

Der erste Abschnitt des Arbeitspakets besteht darin, das Design auf dem 

Atlys Board anzupassen und eine definierte Arbeitsumgebung zu schaffen. 

Weiter wird ein Messaufbau umgesetzt, mit dem die benötigten Messwerte 

ermittelt werden. Dabei werden Werte mit ein- / ausgeschalteter Autokorrekturfunktion 

der Kamera in Kombination mit der in VHDL implementierten 

sowie der OFFIS IDE Filterkette aus dem zweiten Sprint gesammelt. 

Auf Basis der gesammelten Messwerte erfolgt ein Vergleich des Bildstreams 

mit und ohne zusätzlichem Histogrammfilter. Als Ergbnis liefert das Arbeitspaket 

eine Aussage über die Vor- / Nachteile eines möglichen (zusätzlichen) 

Histogramms in der Filterkette. 

161


2.4 Sprint 3 

Im Folgenden werden die ausführlichen Ziele sowie Erfolge und Probleme 

der einzelnen Arbeitspakete vorgestellt. 

2.4.1 Image Bus Switch 


simple_i2c 

simple_i2c 

VmodCam Cam A 

VmodCam Cam B 

cam_data 

cam_data 





image_bus_switch 

cam_usb 

usb_driver 

PC 

Abbildung 2.58: Aufbau mit ImageBus Schalter IP-Core 

Das Ziel dieses Arbeitspaketes ist es, Daten von beiden Kameras über die 

162


USB Schnittstelle schicken zu können, ohne eine Synthese durchführen zu 

müssen. Hierzu soll ein IP-Core entwickelt werden, welcher zwei ImageBus 

Eingänge, jedoch nur einen ImageBus Ausgang hat. Dieser IP-Core soll 

über den PLB so konfiguriert werden können, dass er je einen der beiden 

Eingänge auf den Ausgang weiterleitet. Abbildung 2.58 stellt den geplanten 

Aufbau dar. 

Desweiteren soll ein Timer IP-Core zum Design hinzugefügt werden und 

für diesen ein Treiber, welcher eine Funktion zum warten einer bestimmten 

Zeit zur Verfügung stellt. 

Diese Funktion soll dann im Kamera-Treiber verwendet werden. An dieser 

Stelle soll auch der Treiber verbessert werden, so dass dieser stabiler läuft 

und abstraktere Methoden zur Konfiguration der Kamera bereitstellt. 

2.4.1.1 image_bus_switch 1.00.a 

PLB 

ImageBus In 1 


ImageBus Out 

ImageBus In 2 

Abbildung 2.59: Blockschaltbild des ImageBusSwitch IP-Cores 

Dieser IP-Core dient zum Umschalten zwischen zwei ImageBus Signalen. 

Das Umschalten erfolgt über ein, über den PLB erreichbares, Register. Der 

IP-Core soll hauptsächlich dazu dienen um die Bildquelle, welche an den 

Rechner weitergeleitet wird, ändern zu können, ohne eine erneute Synthese 

zu benötigen. Er kann z.B. genutzt werden um sowohl ein Bild von der 

linken, als auch ein Bild von der rechten Kamera (mit kleinem zeitlichen 

Versatz) zum PC zu übertragen. Er kann aber ebenfalls benutzt werden, 

um die Bildendaten vor und nach einem Filter IP-Core am PC miteinander 

zu vergleichen. Abbildung 2.59 stellt ein Blockschaltbild für den IP-Core 

dar. 

Der Treiber stellt eine C++ Klasse zur Steuerung dieses IP-Cores zur Verfügung. 

Dieser besteht aus dem Konstruktur, welchem die Basisadresse 

des IP-Cores übergeben werden muss, sowie einer weiteren Methode, mit 

welcher der Schalter eingestellt werden kann: 

163


1 void set ( enum CAM cam ); 

2.4.1.2 xps_timer 1.02.a 

CaptureTrig0 

GenerateOut0 

CaptureTrig1 

Freeze 

xps_timer 

GenerateOut1 

PWM0 

PLB 

Interrupt 

Abbildung 2.60: Blockschaltbild des xps_timer IP-Cores 

Bei xps_timer handelt es sich um einen von Xilinx bereitgestellten IP-Core, 

welcher zwei Timer unabhängig voneinander hoch & runterzählen kann, 

ein PWM Signal generieren und auf externe Ereignisse reagieren kann. Als 

Schnittstelle zum Microblaze dienen zum einen der PLB und zum anderen 

ein Interrupt-Pin. In Abbildung 2.60 ist ein Blockschaltbild des IP-Cores 

dargestellt. 

Für unser Design wurde nur der PLB und der Interrupt-Pin verbunden 

(im Blockschaltbild in fetter Schrift). Die PWM Funktionalität, sowie die 

Möglichkeit auf externe Ereignisse zu reagieren werden nicht genutzt. 

Der neu erstellte Treiber greift auf den von Xilinx bereitgestellten Treiber 

zurück, stellt jedoch eine abstraktere API bereit: 

1 Timer :: Timer ( u32 baseaddr ); 

Der Konstruktor muss die Basisadresse des IP-Cores übergeben bekommen. 

Bevor das Objekt benutzt werden kann, muss dann setup_interrupts 

aufgerufen werden. 

1 void Timer :: setup_interrupts ( XIntc * interruptController , u32 

interrupt_pin ); 

Diese Methode erwartet ein initialisierte XIntc Struktur als Parameter, sowie 

den Interrupt-Pin des xps_timer IP-Cores. Die Methode aktiviert dann den 

Interrupt im Interrupt-Controller und setzt eine klasseninterne Funktion 

als Interrupthandler. Zusätzlich wird der IP-Core initialisiert. 

1 void Timer :: usleep ( u32 microseconds ); 

164


Nachdem die Klasse initialisiert ist und das Interrupt-Setup durchgeführt 

wurde, kann die usleep Methode benutzt werden. Diese blockiert den Prozessor 

die übergebene Anzahl an Mikrosekunden. Dabei kann die maximale 

Wartezeit wie folgt berechnet werden: 

max = 4294967296000000 µs 

BUS_TAKT 

Bei einer Taktung von 100 MHz entspricht die maximale Wartezeit z.B.: 

4294967296000000 

µs = 42.95s 

100000000 

Wird ein zu großer Wert angegeben, gibt es einen Überlauf und es wird 

weniger Zeit gewartet! 

Außerdem stellt der Treiber die Definition für eine usleep Methode außerhalb 

irgendeiner Klasse bereit. Diese Methode ist jedoch nicht Teil des 

Treibers. Stattdessen sollte bei verwendung des Treibers wie folgt vorgegangen 

werden: 

1 /* Benutzung vom ersten xps_timer IP - Core im System */ 

2 Timer t (0) ; 

3 

4 /* Bereitstellung einer globalen usleep Methode */ 

5 void usleep ( u32 microseconds ) { 

6 t. usleep ( microseconds ); 

7 } 

8 

10 

9 // ... 

11 int main () { 

12 /* setup interrupt controller */ 

13 // ... 

14 

15 /* setup timer interrupts */ 

16 t. setup_interrupts (& interruptController , 

XPAR_XPS_INTC_0_XPS_TIMER_0_INTERRUPT_INTR ); 

17 

18 // ... ( ab hier kann einfach usleep aufgerufen werden ) 

19 } 

2.4.1.3 simple_i2c 2.00.a 

Der IP-Core wird in diesem Arbeitspaket unverändert übernommen, der 

Treiber zur Konfiguration der Kamera wird jedoch um folgende Funktionen 

erweitert: 

165


1 void reset ( u8 N , u8 M); 

Reset führt die Reset-Sequenz für die Kamera aus. Hierbei wird eine Verzögerung 

von mindestens 15ms genutzt. Die Parameter N und M werden genutzt, um 

anhand der Formel 

PCLK = MCLK ∗ M/(N + 1)/8 

die Pixelclock (PCLK) zu berechnen. MCLK ist hierbei in unserem System 

durch ein Virtel der Busclock gegeben. 

Es muss darauf geachtet werden, dass PCLK zwischen 6Mhz und 80 Mhz 

liegt. M muss kleiner als 256 und N kleiner als 64 sein. 

Die Bestimmung von M & N kann z.B. mittels der Formel aus Codeausschnitt 

2.1 durchgeführt werden (MCLK und PCLK müssen entsprechend 

eingesetzt werden). 

1 solve (PCLK = (MCLK/4) * M / (N+1) / 8) with 0 < M < 256 

2 and 0 < N < 64 over the i n t e g e r s 

Codeausschnitt 2.1: Formel zur Bestimmung von M & N für WolframAlpha 

1 bool identify () ; 

Diese Methode liefert einen Wert, der angibt ob die Kamera angeschlossen 

ist. 

1 void setup_defaults () ; 

Diese Methode setzt die Kameras auf eine vordefinierte Konfiguration. 

Dabei ist das Ausgabeformat für beide Kameras RGB565: Es sind histogrammbasierter 

Weißabgleich, aktivierte automatische Belichtung sowie der deaktivierte 

Autofokus. In Kontext A wird eine hohe Auflösung (1600x1200) 

ausgegeben, in Kontext B eine niedrigere (800x600). Standardmäßig ist 

Kontext B aktiviert. 

1 void set_capture_params ( bool hg , bool awb , bool ae , bool af ); 

Diese Methode stellt Automatismen der Kamera an oder aus. hg steht für 

Histogramm, damit wird bestimmt, ob beim Weißabgleich ein Histogramm 

oder ein Beleuchtungsverhältnis verwendet werden soll. awb steht für den 

automatischen Weißabgleich, er kann aktiviert oder deaktiviert werden. ae 

bezeichnet die automatische Einstellung der Belichtungszeit. Bei niedriger 

oder sehr hoher Umgebungshelligkeit kann dies erwünscht sein. af stellt 

den Autofokus ein oder aus. 

1 void set_resolution ( enum CONTEXT , u16 x , u16 y); 

166


Diese Methode darf nur einmal beim Systemstart aufgerufen werden. Weitere 

Aufrufe bleiben ohne Wirkung, lassen potentiell die Kamera abstürzen. 

In dieser Methode wird die Auflösung eines Kontextes konfiguriert. 

1 void set_mode ( enum sequencer_command cmd ); 

Diese Methode wird verwendet, um dem internen Sequencer der Kamera 

bestimmte Befehle zu geben. Hierbei kann man dem Sequencer die Befehle 

erteilen, um die Kamera in den Modus preview, capture oder standby zu 

versetzen. Es sollte darauf verzichtet werden, den Standby aufzurufen, da 

dieser nicht konfiguriert ist. Dieser ist im Rahmen der Projektgruppe auch 

nicht relevant. Weitere Befehle, die ausgeführt werden können, sind refresh 

und refresh mode. Beide dienen dazu, verschiedene Änderungen ins Kamerasystem 

zu übernehmen. Der Befehl do lock verhindert Veränderungen 

an der Kameralinse durch z.B. den Autofokus. Es gibt auch den Befehl run, 

welcher die normale Ausführungsroutine der Kamera übernimmt. Nach 

Ausführung eines beliebigen anderen Befehls versetzt sich die Kamera selbstständig 

in diesen Modus. 

1 void refresh () ; 

In dieser Methode werden refresh und refresh mode ausgeführt, um Änderungen 

in die Kamera zu übernehmen. 

1 void set_context ( enum CONTEXT context ); 

Diese Methode soll den genutzten Kontext vorgeben, indem ein entsprechendes 

Register gesetzt wird. Dies bleibt jedoch ohne Wirkung, daher hat auch 

die Methode keinen Nutzen. 

1 void set_special_effects ( enum CONTEXT , u8 

solarization_threshold , enum DITHER_LUMA_ONLY dither , u8 

bit_width_of_dither , enum SPECIAL_EFFECT_SELECTION selection 

); 

In dieser Methode können besondere Effekte auf die Ausgabe der Kamera 

angewendet werden. Die verschiedenen Parameter werden nur für einzelne, 

bestimmte Effekte verwendet. selection bestimmt dabei den Effekt. Eingestellt 

werden können Deaktiviert(disabled), Monochrom, Sepia, Negativ und Solarization 

(mit positivem oder negativem UV-Einfluss). 

1 u16 get_frame_counter () ; 

Diese Methode liefert die Anzahl der Frames, welche die Kamera bereits 

gesendet hat. Achtung: Dieser Wert läuft bei 2 1 6 Frames über. 

1 u16 get_line_counter () ; 

Diese Methode liefert die Anzahl der Zeilen, welche die Kamera bereits 

gesendet hat. Achtung: Dieser Wert läuft bei 2 1 6 Zeilen über. 

167


1 void set_read_mode ( enum CONTEXT , bool xbinEnable , bool 

xybinEnable , u8 xoddIncrement , u8 yoddIncrement , bool 

verticalFlip , bool horizontalFlip ); 

Die Methode bestimmt, auf welche Weise die Kamera ausgelesen werden 

soll. Hierbei gibt xbinEnable an, ob die Kamera analoges binning in X Richtung 

ausführen soll. xybinEnable gibt an, ob analoges binning in X und 

Y Richtung ausgeführt werden soll. Binning ist das Zusammenfassen von 

Pixeln auf Sensorebene. xoddIncrement ermöglicht das Überspringen von 

Pixelreihen in X Richtung. yoddIncrement ermöglicht das Überspringen von 

Pixelreihen in Y Richtung. Hierbei sind nur Werte von 1, also alle Reihen 

werden gelesen, und 3, nur jede zweite Zeile wird gelesen. Es ist möglich, 

das Ausgegebene Bild horizontal und vertikal zu spiegeln, dies geht durch 

verticalFlip und horizontalFlip. 

1 void set_output_format ( enum CONTEXT , bool processedBayerMode , 

RGBOutFormat format , RGBYUV rgbORyuv , bool useCCIR656 , bool 

monochromeOut , bool progressiveBayer , bool swap2 , bool swap1 

); 

Diese Methode bestimmt das Ausgabeformat für einen Kontext. Hierbei 

wird durch processedBayerMode festgelegt, ob bereits ein De-Bayer aussgeführt 

wird. Weiterhin wird das Ausgabeformat (RGB565, RGB555, RGB444x, 

RGBx444) festgelegt. Der Parameter rgbORyuv bestimmt ob RGB oder YUV 

verwendet wird. Durch den Parameter useCCIR656 wird bestimmt, ob analoge 

Hilfssignale nicht digitalisiert übertragen werden sollen (für uns nicht notwendig). 

Die nächsten zwei Parameter (monochromeOut und progressiveBayer) bestimmen, 

ob schwarz/weiß übertragen werden soll und ob ein progressiver 

Bayer verwendet wird. swap1 bestimmt, ob bestimmte Bytes getauscht werden 

sollen. Im RGB-Modus sind dies gerade und ungerade Bytes, im YUV- 

Modus sind dies die Bytes für Farbwert und Helligkeit (engl. chrominance, 

luminance). swap2 bestimmt, ob bestimmte Farbkanäle getauscht werden 

sollen. Im RGB-Modus werden der Rote und der Blaue Kanal getauscht, 

im YUV-Modus werden die Kanäle für Rot- und Blaudifferenz getauscht. 

2.4.1.4 Toolbox Plugin 

Das VmodCam Plugin für die OFFIS-Automation-Toolbox aus dem letzten 

Sprint wurde modifiziert, so dass es jetzt eine weitere Eingabe hat, mit der 

die Kamera ausgewählt werden kann. 

168


2.4.1.5 Dateistruktur 

• pcores/image_bus_switch_v1_00_a: ImageBusSwitch IP-Core. 

• pcores/image_bus_switch_v1_00_a/hdl/vhdl/image_bus_switch.vhd: 

Äußeres Modul vom ImageBusSwitch IP-Core. Automatisch generiert 

vom Xilinx Peripheral Wizard. 

• pcores/image_bus_switch_v1_00_a/hdl/vhdl/user_logic.vhd: User Logic 

Modul vom ImageBusSwitch IP-Core. Automatisch generiert vom 

Xilinx Peripheral Wizard. Enthält die Logik für das PLB Register. 

• pcores/image_bus_switch_v1_00_a/hdl/vhdl/switch.vhd: Hauptmodul 

vom ImageBusSwitch IP-Core. Diese Datei stellt die eigentliche 

Funktionalität zur Verfügung. 

• drivers/image_bus_switch_v1_00_a: Treiber für ImageBusSwitch IP- 

Core. 

• drivers/image_bus_switch_v1_00_a/src/image_bus_switch.h: C++ Header 

Datei des Treibers. 

• drivers/image_bus_switch_v1_00_a/src/image_bus_switch.cpp: C++ 

Datei mit der Implementation des Treibers. 

• drivers/sleep_v1_00_a: Treiber für xps_timer IP-Core. 

• drivers/sleep_v1_00_a/src/sleep.h: C Header Datei des Treibers. 

• drivers/sleep_v1_00_a/src/sleep.c: C Datei mit der Implementation 

des Treibers. 

2.4.1.6 Aufgetretene Probleme 

Während des Sprints sind unter anderem die folgenden Probleme aufgetreten: 

• Beim Schreiben für die usleep() Methode im Treiber des Timers wird 

eine Variable durch einen Interrupt-Handler modifiziert. Der Compiler 

hat hiervon keine Kenntnis und deshalb eine Schleife, die auf die 

Modifikation durch den Interrupt wartet in eine Endlosschleife “optimiert”. 

Abhilfe schaffte das C-Schlüsselwort volatile, welches dem 

C-Compiler mitteilt, dass sich eine Variable durch externe Ereignisse 

ändern kann. 

169


• Beim letzten Arbeitspaket VmodCam wurde ein Pin des cam_bootloader 

IP-Cores auf dem Genesys-Board nicht richtig mit der Kamera verbunden. 

Dies führte zu einem unvollständigem Resetsequenz. 

2.4.1.7 Ergebnis 

Die folgenden Bilder von der linken und rechten Kamera wurden über 

die OFFIS-Automation-Toolbox empfangen. Zu sehen ist, dass die Kameras 

nicht nur ein leicht versetztes Bild, sondern auch ein leicht verdrehtes Bild 

liefern. Zudem sind die automatische Farbkorrektur und der automatische 

Weißabgleich beider Kameras komplett unabhängig voneinander, was zu 

leicht unterschiedlichen Farben führt. 

Abbildung 2.61: Bilder von linker und rechter Kamera 

170


2.4.2 Filter Cores 

Ziel dieses Arbeitspaketes ist die Umsetzung der Algorithmen, welche 

zur Erkennung des Arms notwendig sind, dazu wurden drei IP-Cores erstellt. 

Diese setzen vier verschiedene Bildoperationen um, welche für die 

Erkennung des Arms bzw. der entsprechenden Markierungen zur Erkennung 

des Arms notwendig sind. Es wurden dabei ein Schwellwertfilter, ein 

RGB888 zu Graustufen Konverter und zwei morphologische Filter erstellt. 

Bei den morphologischen Filtern sollten die Erosion und die Dilatation 

umgesetzt werden. 

2.4.2.1 schwellwertlter_v1_00_a 

Der Schwellwertfilter verwendet ein 8Bit breites Signal, in welchem ein 

Graustufenbild codiert ist. Die Größe des Schwellwertes wird dabei durch 

einen Generic nach Außen geführt und kann somit bei der Verknüpfung 

der IP-Cores eingestellt werden. 

Hierbei wurde absichtlich auf die Verwendung eines PLB verzichtet. Es 

wurden verschiedene Versuche durchgeführt, welche gezeigt haben, dass 

eine dynamische Anpassung des Schwellwertes zur Laufzeit nicht notwendig 

ist. Dabei wird weder ein über Software einstellbarer Schwellwert noch 

ein dynamischer Schwellwert über einen anderen IP-Core-Core benötigt. 

Die automatische Korrektur der Helligkeit der verwendeten Kamera sorgt 

dafür, dass das Histogramm sich in Richtung des eingestellten Schwellwertes 

verschiebt. Zur initialen Einstellung des Schwellwertes kann es später 

von Nutzen sein, diesen dennoch mit dem PLB zu verbinden. 

Am Ausgang des Filters wird ein binäres Signal ausgegeben. Dabei werden 

alle Werte des eingehenden 8Bit Signals des Graustufenbildes mit dem 

Schwellwert verglichen. Sollten die 8Bit des Graustufenbildes größer oder 

gleich dem Schwellwert sein, so wird am Ausgang einen ’1’ angelegt. Andernfalls 

wird eine ’0’ angelegt. Somit kann eine Segmentierung durchgeführt 

werden. Im Folgenden wird das Blockschaltbild des Filters dargestellt, 


171


pixel_clk 

frameValid 

lineValid 

dataValid 

data[7:0] 

schwellwertfilter_v1_00_a 

frameValid 

lineValid 

dataValid 

data_out 

Abbildung 2.62: Blockschaltbild des Schwellwertfilters 

Dateistruktur 

• pcores/schwellwertfilter_v1_00_a: Schwellwertfilter IP-Core 

2.4.2.2 rgb2grey_v1_00_a 

Für die Umsetzung der Armerkennung, welche für die Steuerung des Roboters 

notwendig ist, wird unter Anderem ein Filter benötigt, welcher aus 

einem Farbbild ein Graustufenbild berechnet. Diese Graustufenbilder sollen 

jedoch nicht die Helligkeiten im Bild repräsentieren, sondern das Rot im 

Bild. Dies ist wichtig aufgrund der roten Markierungen, welche für die 

Erkennung des Arms verwendet werden. Darum wird ein gewichteter Graustufenfilter 

verwendet, siehe Abb. 2.63. 

Das von der Kamera gelieferte Farbbild, welches durch die IP-Cores der 

Arbeitsgruppe VModCam bereits aufbereitet wurde, steht für die Implementation 

des RGB2Grey-Filters als RGB888 Signal zur Verfügung. Der 

RGB888 zu Graustufenwandler nimmt dieses 24Bit breite Signal entgegen 

und wandelt es in ein 8Bit breites Signal um. Der IP-Core verwendete für 

die Umwandlung des RGB888 in ein gewichtetes Graustufenbild zunächst 

folgende Formel: 

R − B 2 − G di f f (B − G) 

− (2.12) 

2 2 

R, G und B stehen dabei für die Farbkanäle rot, grün und blau. Die Diff- 

Operation ist dabei eine Subtraktion, welche einen Absolutwert liefert. 

Während der Testphase des Filters mit der Referenzsoftware, Filter der 

OFFIS-Automation-Toolbox, hat sich herausgestellt, dass diese nicht die 

oben beschriebene Formel umsetzen, obwohl diese vom Filter angezeigt 

wird, siehe Abb. 2.64. Durch Sichtung des Programmquelltextes der Filter 

der OFFIS-Automation-Toolbox hat sich ergeben, dass hier folgende 

Formel umgesetzt wurde: 

R − B 2 − G 2 

− di f f (B − G) (2.13) 

172


Da sich die Tests der Armerkennung mit Hilfe des Software-Prototypen auf 

diese Formel beziehen, wurde der IP-Core nun ebenfalls umgeschrieben, 

sodass er dem Filter in der zur Armerkennung verwendeten Bildverarbeitungskette 

passt. 

Der Vorteil dieser Implementierung des gewichteten RGB2Grey-Filters ist, 

dass zum Beispiel die Farbe Orange, siehe Abb. 2.64 nicht mehr als helles 

Grau auftaucht. Bei der Anwendung des Filters in der Kette zur Erkennung 

des Arms, hat dies den Vorteil, dass weniger Objekte im Hintergrund 

erkannt werden, welche einen geringeren Anteil an Rot haben. 

pixel_clk 

frame_Valid_in 

line_Valid_in 

data_Valid_in 

pixel_data_in[23:0] 

rgb2grey_v1_00_a 

frame_Valid_out 

line_Valid_out 

data_Valid_out 

pixel_data_out[7:0] 

Abbildung 2.63: Blockschaltbild des RGB888 zu Graustufenwandler 

Ein weiteres Problem, welches sich während der Implementierung ergeben 

hat, war die Testumgebung. Der zur Verfügung gestellte Image-HIL hatte 

diverse Fehler. Zum einen konnte dieser zu Beginn keine Bilder mit 

aufgeben, wenn die Bitbreite der eingehenden Daten nicht zur Bitbreite 

der ausgehenden Daten passte. Ebenfalls gab es Probleme mit der Wahl 

der Farbkanäle. Hier wurde kein RGB888-Signal übertragen, sondern ein 

BGR888-Signal. 

173


Abbildung 2.64: Testbilder rgb2grey_v1_00_a in AMiR Automation Toolbox, 

Quellbild (link oben), Ergebnis Toolbox (rechts oben), 

Ergebnis Hardware (links unten), Ergebnis modifizierter 

Toolbox Filter (rechts unten) 

Dateistruktur 

• pcores/rgb2grey_v1_00_a: RGB888 zu Graustufenwandler IP-Core 

174


2.4.2.3 morphology_v1_00_a 

Bei der Morphologie wurden zwei Operationen umgesetzt, die Erosion 

und die Dilatation. Da beide Operationen auf einer Nachbarschaft arbeiten 

und sich invers zueinander verhalten, wurden sie in einem IP-Core zusammengefasst. 

Um die Operation, welche der IP-Core ausführt, auswählen zu 

können, wurde diese Option über einen Generic nach außen geführt. Hier 

kann somit ausgewählt werden, ob eine Dilatation oder Erosion durchgeführt 

werden soll, siehe Abb. 2.66. 

Der Filter arbeitet dabei auf Graustufen und führt eine sogenannte Graustufenmorphologie 

durch. Dies hat den Vorteil, dass auch ohne einen Schwellwertfilter 

gearbeitet werden kann. Hier werden je nach Wahl der Operation 

das Maximum der gefundenen Grauwerte erweitert oder das Minimum. 

Da beide Operationen eine Nachbarschaft benötigen, verfügt der IP-Core 

über einen Linienspeicher der entsprechend der Größe der Nachbarschaft 

angelegt ist. Der entsprechende IP-Core nimmt am Eingang ein beliebig 

breites Signal an, welches ein Graustufenbild repräsentiert. Der Ausgang 

ist ein dem Eingang entsprechend breites Signal, auf dem das verarbeitete 

Signal ausgegeben wird, siehe Abb. 2.65. 

pixel_clk 


line_valid_in 

data_valid_in 

data_in[7:0] 

morphphology_v1_00_a 




data_out[7:0] 

Abbildung 2.65: Blockschaltbild des Morphologiefilter 

Bei der Erstellung des IP-Cores für die morphologischen Operationen ergaben 

sich verschiedene Probleme. Zunächst sollte der Random Access 

Memory (RAM) aus einem existierenden IP-Core übernommen werden. 

Diese Herangehensweise ergab sich jedoch als wenig erfolgreich, sodass ein 

neuer RAM generiert werden musste. Da es zu diesem Zeitpunkt keine Testumgebung 

gab, wurde dies innerhalb der Integrationsumgebung durchgeführt. 

Hier kam ein stärkerer FPGA zum Einsatz als innerhalb der Testumgebung. 

Dies führte dazu, dass für die Testumgebung der RAM erneut 

erstellt werden müsste. 

Danach wurde mit Hilfe einer Simulation der Hardwarekomponente festgestellt, 

dass die Ansteuerung des RAM, welche ebenfalls aus einem existierenden 

Modul entnommen werden sollte, nicht korrekt funktioniert. 

175


Sodass eine Umstellung von den generierten RAM-Modulen auf die Language 

Templates erfolgte. 

Abbildung 2.66: Konfigurationsoberfläche des Morphologiefilter 

Dateistruktur 

• pcores/morphology_v1_00_a: Morphologiefilter IP-Core 

176


2.4.3 HDMI Analyse 

Ziel dieses Arbeitspaketes ist eine Machbarkeitsstudie im Sinne einer Zeiteinschätzung 

für eine Bildausgabe eines ImageBuses via HDMI. Da für die 

Ausgabe über HDMI ein Bildpuffer nötig ist, wird ausserdem eine Zeiteinschätzung 

für die Realisierung eines ImageCache IP-Core durchgeführt. 

Dazu wurde sich das Projekt atlys_hdmi_plb_demo von Digilent angeschaut. 

Dieses Projekt besteht aus einem Microblaze, via Multi-Port Memory Controller 

(MPMC) angebundenen RAM und dem eigentlichen HDMI Teil. Der 

HDMI Teil besteht aus einem IP-Core hdmi_in, welcher über VFBC 2D Bilddaten 

in dem RAM schreibt, sowie einem IP-Core hdmi_out welcher diese 

Bilddaten liest und an einer HDMI-Schnittstelle ausgibt. 

2.4.3.1 hdmi_out 

PXLCLK_I 

PXLCLK_2X_I 

PXLCLK_10X_I 

LOCKED_I 

VFBC_OUT 

hdmi_out 

TMDS[3:0] 

TMDSB[3:0] 

Abbildung 2.67: Blockdiagramm vom IP-Core hdmi_out 

In diesem Teilpaket sollte sich der IP-Core hdmi_out angesehen werden, da 

dieser die Ausgabe von Daten aus dem Speicher an die HDMI-Schnittstelle 

übernimmt. 

Die hierfür verwendete HDMI-Schnittstelle auf dem ATLYS hat den Bezeichner 

J2. An den im Diagramm 2.67 mit TMDS[3:0] und TMDSB[3:0] bezeichneten 

Ausgaben ist dieser HDMI-Ausgang angeschlossen. 

Das Beispielprojekt ist für ein ATLYS ausgelegt, wo ein berechnetes HDMI 

Signal direkt an den HDMI Anschluss gegeben werden kann. Dieses HDMI 

Signal wird vom hdmi_out berechnet. 

Bei einer Überführung auf ein GENESYS müsste der IP-Core um- oder 

neugeschrieben werden, da beim GENESYS die HDMI-Schnittstelle nicht 

direkt am FPGA angeschlossen ist, sondern über ein Chrontel CH7301C DVI 

transmitter device. 

177


An die drei Eingaben PXLCLK_I, PXLCLK_2X_I und PXLCLK_10X_I kann 

man einen pll_module IP-Core anschliessen, so dass die Geschwindigkeiten 

korrekt sind. 

Die Eingabe LOCKED_I ist letztendlich ein Zurücksetzen, welches dafür 

sorgt, dass ein schwarzes Bild ausgegeben wird. An VFBC_OUT ist der 

VFBC angeschlossen. 

Der IP-Core hdmi_out benutzt den VFBC, um Frames aus dem RAM zu 

lesen. Dabei benötigt er eine Basis Adresse, die Auflösung sowie die Breite 

einer Zeile im Speicher. Alle drei notwendigen Einstellungen werden durch 

Generic zur Designzeit festgelegt. 

Die möglichen Auflösungen sind im IP-Core hdmi_out fest konfiguriert, 

wobei nur 640x480 und 1280x720 benutzbar sind. 

Um weitere Auflösungen zu unterstützen, müsste der hdmi_out IP-Core 

angepasst werden, welcher größtenteils in Verilog implementiert ist. Nur 

die Schnittstelle zum Xilinx Platform Studio (XPS) ist in VHDL implementiert. 

Der IP-Core kommt aufgrund der Generics ohne einen Treiber aus. Zudem 

benutzt der IP-Core den PLB nicht. 

Die Frames, welche ausgegeben werden, werden im Demo Projekt durch 

den IP-Core hdmi_in in den RAM geschrieben. Der hdmi_in verwendet 

ebenfalls einen zweiten VFBC Port. 

In unserem Projekt müssen die Frames mit Hilfe eines eigenen IP-Core 

ebenfalls über VFBC in den RAM geschrieben werden. 

2.4.3.2 VFBC 

Der hdmi_out IP-Core verwendet Arbeitsspeicher als Framebuffer. Zur Anbindung 

an den Speicher wird der MPMC IP-Core benutzt, welcher auch 

die Speicheranbindung des PLB zur Verfügung stellt. Die Dokumentation 

dieses IP-Cores befindet sich in [18]. 

Der MPMC IP-Core stellt insgesamt bis zu acht unabhängige Schnittstellen 

zur Verfügung, von denen, in Microblaze basierten Designs, einer für den 

PLB belegt ist. Der MPMC IP-Core hat für jede Schnittstelle einen Controller 

definiert, der für diese Schnittstelle verwendet werden soll. Diese 

heißen Personality Interface Modules (PIM). 

Zum Beispiel wird standardmäßig der erste Port für den PLB, welcher ein 

spezieller PLB PIM ist. Andere verfügbare PIMs sind: 

• Xilinx Cache PIM 

• Soft Direct Memory Access Controller PIM 

178

X-Ref Target - Figure 38 


• PLB PIM 

• PowerPC 440 Processor Memory Controller PIM 

• VFBC PIM 

• Native Port Interface PIM 

• MCB PIM 

NPI 

VFBC 

Command 

Fetch 

Command 

FIFO 

Interface 

Command 

Signals 

NPI 

Signals 

NPI 

Formatter 

Read Data 

FIFO 

Interface 

Read Data 

Signals 

Burst Controller 

Write Data 

FIFO 

Interface 

Write Data 

Signals 

Abbildung 2.68: Blockdiagramm vom VFBC 

Der hdmi_out IP-Core benutzt die VFBC Schnittstelle des MPMC. Diese ist 

ein PIM, welcher explizit für das Zwischenspeichern von 2D Daten gedacht 

ist. Eine einzelne VFBC Schnittstelle hat insgesamt drei verschiedene FI- 

FOs. Eine für Kommandos, eine Lese-Queue und eine Schreib-Queue. Das 

Blockdiagramm in Abbildung 2.68 beschreibt den Aufbau des VFBC. 

Der VFBC sieht vor, dass mit einem Bild mit definierter Größe in einem 2D 

Speicherbereich gearbeitet wird. In Abbildung 2.69 ist ein Beispiel für ein 

Bild der Größe 640x480 Pixel, welches in einem Speicherbereich der Größe 

1920x1080 Pixel liegt. 

In diesem Beispiel verwendet der VFBC den Speicher ab der Adresse 0x10000000. 

Es existieren 2 Bildausschnitte. Für das größere 1920x1080 Bild wird die X 

Size auf 1920 multipliziert mit der Anzahl an Bytes pro Pixel gesetzt. Für 

179

X-Ref Target - Figure 42 


1920 

Origin Byte 

Address 

0x1000_0000 

120 

1080p Video Frame Stored in External Memory 

640 

360 

VGA Read Transfer Region 

480 

1080 

Abbildung 2.69: VFBC: VGA Fenster in 1080p Frame 

die Y Size wird die Bildhöhe minus 1 gesetzt, also 1079. Die Stride ist in 

diesem Fall identisch zur X Size. 

Für das kleinere Bild wird X Size auf 640 multipliziert mit der Anzahl an 

Bytes pro Pixel und Y Size=479 gesetzt. Die Stride wird auf die X Size vom 

1920x1080 Bild gesetzt. 

Dies ermöglicht es ein kleineres Bild aus dem größeren Bild herauszuschneiden. 

Für die Einstellung der Parameter wird die Kommando-Queue benutzt. 

Das Format für die Steuerpakete ist in Tabelle 2.5 dargestellt. 

Kommando Steuerpaket 

Wort 0 Wort 1 Wort 2 Wort 3 

31:15 14:0 31 30:0 31:24 23:0 31:24 23:0 

Reserved X Size Write_NotRead Start Address Reserved Y Size Reserved Stride 

Tabelle 2.5: VFBC Steuerpaket 

2.4.3.3 Ergebnis HDMI 

Um es zu Ermöglichen einen ImageBus über HDMI auszugeben, kann der 

existierende hdmi_out IP-Core benutzt werden. Dieser liest ein 1280x720 

Pixel Bild über einer VFBC Schnittstelle aus dem Arbeitsspeicher. Für die 

Ausgabe eines ImageBus Signals muss also dieses in den Arbeitsspeicher 

geschrieben werden. Hierfür kann z.B. eine zweite VFBC Schnittstelle 

benutzt werden. 

180


Für ein Arbeitsmodul, welches das ImageBus Signal über HDMI ausgeben 

soll wären also die folgenden Arbeitsschritte nötig: 

1. hdmi_out IP-Core in das Design einbauen 

• Hängt vom pll_module ab, welches ebenfalls hinzugefügt werden 

muss 

• Verknüpfung mit einem der HDMI Ports in der User Constraint 

File (UCF) Datei 

2. Implementation eines neuen IP-Cores, welcher ein ImageBus Signal 

mittels eines VFBC Ports in den Speicher schreibt 

Auf Grund dieser Ausgangslage schätzen wir, dass ein Arbeitspaket, welches 

zum Ziel hat das ImageBus Signal via HDMI auszugeben, ca. 60 Arbeitsstunden 

benötigt. Davon 20 Arbeitsstunden für die Integration des existierenden 

hdmi_out IP-Cores, sowie 40 Arbeitsstunden für die Implementation 

des IP-Cores zum Speichern des ImageBus Signals in den Speicher. 

Diese Abschätzung bezieht sich auf eine Implementierung, welche ausschliesslich 

auf dem ATLYS laufen muss. Für das GENESYS würde aufgrund 

des in Abschnitt 2.4.3.1 erwähnten Zusatzchips weiterer Aufwand 

nötig. 

2.4.3.4 Ergebnis ImageCache 

Für ein ImageCache IP-Core eignet sich die VFBC nicht für den allgemeinen 

Fall. Die VFBC Schnittstelle arbeitet auf ganzen Bildern und nicht 

auf einzelnen Pixeln, deshalb ist ein Zugriff auf zufällige Pixel im Bild nicht 

einfach möglich. 

Ein ImageCache, der nur als Zwischenspeicher dienen soll, ließe sich jedoch 

verhältnismäßig einfach mittels der VFBC-Schnittstelle realisieren. 

Ein solcher wäre z.B. für die Übertragung von Daten über die langsame 

USB-Schnittstelle nützlich. 

Für einen ImageCache, der randomisierten Zugriff auf den Speicher ermöglichen 

soll, wäre ein Zugriff über den PLB, oder, alternativ, ein Zugriff 

über die NPI Schnittstelle vom MPMC nötig. Dies ist jedoch deutlich 

aufwendiger. 

181


2.4.4 Histogramm 

Ergebnis dieses Arbeitspakets sollte die Implementierung eines Histogramm 

IP-Cores sein, um eine Weiterverarbeitung der erhobenen Daten zu ermöglichen 

sowie damit dynamisch auf Änderungen in der Umgebung 

reagieren zu können. 

2.4.4.1 Umsetzung 

Der erste Teil dieses Arbeitspakets beinhaltet die Implementierung des Histogramms 

als IP-Core. Dazu wurde versucht eine Teststrecke den zur Verfügung 

gestellten Hilfsmitteln aufzubauen, wie sie in der Einführungsphase 

der Projektgruppe bereits genutzt wurde. Dazu wurden folgende Hilfsmittel 

eingesetzt. 

• Cosynth-Plugin für die OFFIS-Automation-Toolbox 

• XPS Template Projekt für das Nexys Board 

Hier stießen wir auf das Problem, das die Nutzung der gegebenen Werkzeuge 

nicht ohne Anpassung in unserer Konfiguration funktionierte. Es wurden 

mehrere Stunden in die Problemanalyse investiert, welche Ergebnislos 

blieb. 

Es wurde der Entschluss gefasst, eine Teststrecke mit bereits von der Projektgruppe 

entwickelten IP-Cores und dem für Projekt RoboArm angepassten 

OFFIS-Automation-Toolboxplugin umzusetzen, da diese Elemente leichter 

angepasst werden können und nötige Dokumentation existiert. Dazu wurde 

das Atlysboard von Digilent als alternative Zielplattform ausgewählt. Hierfür 

musste das XPS- Projekt zum auslesen von Kamerabildern auf das 

ATLYS-Board portiert werden, da dieses nur auf dem Genesysboard entwickelt 

und getestet wurde. Dabei stießen wir erneut auf zusätzliche Aufgaben, 

die nicht mit in die Aufgabenplanung einbezogen wurden. Dazu 

zählt das Anpassen der einzelnen IP-Cores, da diese mit speziell für das 

Genesys-Board erstellem RAM arbeiten, der vom Atlys-Board nicht unterstützt 

wird. 

Bei der tieferen Betrachtung der nötigen Arbeitsschritte für die Umsetzung 

des Histogramms sind mehrere Fragen aufgetreten. Es wurde das Versäumnis 

festgestellt, das der Wert für den dynamischen Schwellenwertfilter 

182


nicht spezifiziert und keine Anforderungen formuliert wurden. Des Weiteren 

stellte sich die Frage nach der generellen Notwendigkeit eines Histogramms, 

da die im zweiten Sprint erstellten Filterketten ohne ein solches 

auskamen. Ebenso ist die Kamera selber in der Lage, das erzeugte Kamerabild 

dynamisch den Umgebungsverhältnissen anzupassen, basierend 

auf einer Histogramm Auswertung die vom Kameramodul durchgeführt 

wird. Aufgrund dieser Überlegungen wurde die Implementierung des Histogramms 

ausgesetzt. Weitere Arbeitsstunden wurden aufgewandt um der 

Arbeitsgruppe "Filter Cores" bei der Integration ihres Systems zu helfen. 

Die ausstehenden Arbeitsziele wurden neu geplant, da die Notwendigkeit 

eines Histgrogramms zu diesem Zeitpunkt noch nicht ausreichend diskutiert 

wurde. Dieser Umstand folgt aus einer ungenügenden Arbeitspaket- 

Beschreibung während der Sprintplanung. Die Arbeitsplanung wurde daher 

überarbeitet um die Notwendigkeit eines Histogramm IP-Core zu evaluieren. 

183


2.4.5 Notwendigkeit eines Histogramms 

Dieses Arbeitspaket hat zum Ziel, die Notwendigkeit eines Histogramms 

zur dynamischen Helligkeitsanpassung des Bildstreams zu evaluieren. Da 

die eingesetzte Kamera bereits über eine histogrammbasierte Helligkeitsanpassung 

verfügt, werden für diesen Zweck Vergleichsmessungen bei 

unterschiedlichen Umgebungsparametern durchgeführt. Somit kann ermittelt 

werden, ob der Einsatz eines zusätzlichen Histogrammfilters für eine 

stabilere Filterkette sorgen kann. Für die Messungen wird in erster Linie 

der Histogrammfilter der OFFIS IDE eingesetzt. Für die Lösung dieser 

Aufgaben stehen insgesamt 2 Wochen zur Verfügung. 

2.4.5.1 Evaluation 

Die Evaluation wurde mit Hilfe des Atlys Boards umgesetzt und eine 

definierte Arbeitsumgebung eingerichtet. Weiter wurde ein Messaufbau 

umgesetzt, mit dem die benötigten Messwerte ermittelt wurden. Dabei 

wurden die Werte mit ein- / ausgeschalteten Autokorrekturfunktionen der 

Kamera in Kombination mit der OFFIS IDE Filterkette gesammelt. Die Filterkette 

entspricht der des Arbeitspakets Öbjekterkennung". Als Ergebnis 

liefert das Arbeitspaket eine Aussage über die Vor- / Nachteile der Autokorrekturfunktionen 

der Kamera und eine Empfehlung über die Notwendigkeit 

eines zusätzlichen Histogramms in der Filterkette. 

2.4.5.2 Beschreibung Der Arbeitsumgebung 

Zur Bildaufnahme wurde die VModCam in zwei unterschiedlichen Konfigurationen 

genutzt. Zu den Autokorrekturfunktionen zählen dabei die 

Belichtungszeit in Form von Helligkeitsanpassung sowie ein automatischer 

Weißabgleich. Die Übertragung der Kamerabilder an den PC erfolgte mit 

Hilfe des Atlys-Boards, wobei ein Bild ohne weitere Änderungen übertragen 

und von der OFFIS-Automation-Toolbox entgegengenommen wurde. 

Auf diesem Bildstream wurde daraufhin die im vorherigen Sprint erarbeitete 

Filterkette zur Objekterkennung eingesetzt und deren Ergebnisse bei 

unterschiedlichen Lichtverhältnissen aufgenommen. Die Filterkette selbst 

besteht aus der Extraktion des gewichteten Rotwertes sowie darauffolgendem 

Schwellenwert, einer Opening und Closing Operation. Auf dem 

Ergebnis wird im Folgenden eine BLOB-Detektion durchgeführt. 

Im Weiteren werden die Unterschiede der Kamerabilder bei ein- und ausgeschalteten 

Autokorrekturfunktionen in Bezug auf die unterschiedlichen 

184


Lichtverhältnisse Hell, Mittel und Dunkel dargestellt. 

2.4.5.3 Aufnahmen und Ergebnisanalyse 

Im Weiteren werden die Bilder, welche mit der VModCam aufgenommen 

wurden, miteinander verglichen. Diese Bilder wurden aufgenommen, während 

die Helligkeit variiert und die Kamera mit und ohne Autokorrekturfunktionen 

eingesetzt wurde. 

Dunkle Umgebung mit und ohne Autokorrekturfunktionen 

In den Abbildungen 

2.70(a) und 2.70(b) ist auf der linken Seite die Aufnahme dargestellt, 

die bei dunkler Umgebung und mit eingeschalteten Autokorrekturfunktionen 

gemacht wurde. Aus dieser Aufnahme konnten mit der gegebenen 

Filterstrecke zuverlässig die gesuchten Objekte erkannt sowie als Polygone 

dargestellt werden. Rechts ist das zugehörige Histogramm dargestellt, in 

dem die Farbintensitäten dargestellt sind. 

(a) Ergebnispolygone 

(b) Histogramm 

Abbildung 2.70: Aufname mit Autokorrekturfunktionen bei dunklen 

Lichtverhältnissen 

In den Abbildungen 2.71(a) und 2.71(b) ist im linken Bild die Aufhame 

dargestellt, die bei einer dunklen Umgebung und ausgeschalteten Autokorrekturfunktionen 

gemacht wurde. Diese Aufnahme zeigt, das bei der gegebenen 

Filterstrecke keine Flächen erkannt werden konnten. Auch aus dem 

zugehörigen Histogramm lässt sich ablesen, dass es eine starke Verschiebung 

der Intensitäten im Vergleich zur Abbildung 2.70(b) gibt. 

185




Abbildung 2.71: Aufname ohne Autokorrekturfunktionen bei dunklen 


Helle Umgebung mit und ohne Autokorrekturfunktionen 

Das Bild 2.72(a) 

zeigt eine Aufnahme bei heller Umgebung und eingeschalteten Autokorrekturfunktionen. 

Es wurden deutlich drei Flächen erkannt und in der 

Darstellung kenntlich gemacht. Das Histogramm in Abbildung 2.72(b) zeigt 

für ein Intensitätsintervall ein hohes aufkommen der Farbe Rot. 



Abbildung 2.72: Aufname ohne Autokorrekturfunktionen bei durchschnittlichen 


Für die Aufnahme in Abbildung 2.73(a) wurden die Autokorrekturfunktionen 

der Kamera deaktiviert und die Aufnahme erfolgte bei gleicher Umgebungshelligkeit 

wie in Abbildung 2.72(a). Im Vergleich zur Aufnahme mit 

Autokorrekturfunktionen ist deutlich zu sehen, dass die Erkennung der 

186


roten Flächen deutlich unzuverlässiger ist. Neben den erwarteten Flächen 

wurden auch weitere unerwünschte Polygone als Ergebnis ausgegeben. 

Dies lässt sich durch den fehlenden Weißabgleich in dem Bild 2.73(a) erklären, 

da hierdurch Flächen eine falsche Farbzusammensetzung und damit 

unter anderem einen zu hohen Rotanteil besitzen. Das Histogramm in Abbildung 

2.73(b) zeigt im Vergleich mit 2.72(b) eine deutliche Verschiebung 

der Intensitätskurven von allen Farben. 



Abbildung 2.73: Aufname ohne Autokorrekturfunktionen bei durchschnittlichen 


Durch die oben dargestellten Vergleiche wird deutlich, dass die Autokorrekturfunktionen 

der VModCam einen wesentlichen Vorteil für die Erkennung 

der roten Objekte im Bild liefert. Aufgrund dieser Erkenntnisse wird 

empfohlen, vorerst von einer Implementierung eines Histogramms in Form 

eines IP-Core abzusehen, da die eingesetzte Filterkette mit den Autokorrekturfunktionen 

der Kamera bereits stabile Ergebnisse erzeugt. 


In diesem Sprint wurden die Bildvorverarbeitungsketten getestet und als 

IP-Cores umgesetzt. Das Histogramm wurde nicht als IP-Core implementiert, 

da die vorhandenen Mittel eine dynamische Anpassung an das Umgebungslicht 

nicht erfordern. Die Machbarkeitsstudie der Umsetzung von 

Ausgaben über eine HDMI-Schnittstelle wurde durchgeführt und die Zeit 

für eine solche Umsetzung wurde eingeschätzt. 

Das Hauptziel des Sprints, eine Grundlage für die nachfolgende Bildverarbeitung 

als Bildvorverarbeitung umzusetzen, wurde erreicht. 

Des Weiteren wird ein neuer Sprint geplant, in dem die Algorithmen zur 

Auswertung der Bildinformationen entwickelt und umgesetzt werden. Diese 

187


werden auf dem Bildstrom aus der Bildvorverarbeitung aufsetzen. 

188



Der Sprint 4 verfolgt weitere Ziele auf dem Weg zur Umsetzung der Anwendungsfälle 

Roboter steuern durch alternative Gesten und Armhaltung nachahmen. 

Für die alternative Gestensteuerung wird ein Softwareprototyp umgesetzt, 

der die Steuerung des Roboters durch Kopfbewegungen realisiert. Für 

Nachahmung der Armhaltung wird, aufbauend auf der im Sprint 2 umgesetzten 

Filterkette der Bildvorverarbeitung, die Tiefenerkennung als OFFIS- 

Automation-Toolbox-Plugin realisiert. Dieses soll die Tiefeninformationen 

der am menschlichen Arm erkannten Punkte liefern. Dadurch soll die Steuerung 

des Roboters im dreidimensionalen Räumen ermöglicht werden. Außerdem 

wird die Ausgabe auf HDMI umgesetzt. Damit wird eine Ausgabe 

direkt durch den FPGA, gesteuert über den Microblaze, ermöglicht. Diese 

Ausgabe ist schneller und direkter als die bisherige, über USB angesteuerte, 

Ausgabe. 

Um die Tiefenerkennung auf der Hardware umsetzen zu können, wird der 

zur Verfügung gestellte BLOB-IP-Core in das bisher erzeugte Hardwareprojekt 

eingebunden. Außerdem wird eine Interrupt-Routine auf dem Microblaze 

umgesetzt, welche die durch den BLOB-IP-Core erkannten Punkte 

zur Verfügung stellt. Diese Punkte werden mit ihren Koordinaten und 

ihren Schwerpunkt-Information am Microblaze für weitere Bildverarbeitung 

zur Verfügung gestellt. Auf der Microblazeebene sollen die Winkel zwischen 

den BLOBs bereitgestellt werden. In der OFFIS-Automation-Toolbox 

wird hierzu eine Visualisierung implementiert, welche die Schwerpunkte 

der erkannten Punkte darstellt. 

2.5.1 Softwareprototyp Kopfsteuerung 

Vorbedingungen 

• OFFIS-Automation-Toolbox 

• OFFIS-Automation-Toolbox-Plugin zur Ansteuerung des Roboterarms 

Arbeitspaketbeschreibung 

Ziel des Arbeitspaketes ist es den Roboterarm mittels einer alternativen 

Gestensteuerung anzusteuern. Diese alternative Gestensteuerung soll auf 

Kopfbewegungen reagieren (siehe Lastenheft). 

189


Die alternative Gestensteuerung soll in diesem Arbeitspaket als Bildverarbeitungskette 

in der OFFIS-Automation-Toolbox erstellt werden. Dabei soll 

jedoch darauf geachtet werden, dass sich die Bildverarbeitungskette auf 

das ATLYS-Board mit angemessenem Aufwand portieren lässt. 

Um dieses Ziel zu erreichen wird zunächst analysiert welche Kopfbewegungen 

zuverlässig erkannt werden. Für diese Arbeit werden ca. 2 Wochen 

veranschlagt. Am Ende dieser Unteraufgabe soll eine Bildverarbeitungskette 

für die OFFIS-Automation-Toolbox zuverlässig Kopfbewegungen erkennen, 

die später auf Roboterarmbewegungen abgebildet werden können. 

Die erkennbaren Kopfbewegungen sind dabei auf 2D-Bewegungen eingeschränkt. 

Aufbauend darauf wird eine Abbildung der Gesten auf die Gelenke des 

Roboterarms vorgenommen. Dies beinhaltet die Ansteuerung des Roboterarms 

über das bereits vorliegende OFFIS-Automation-Toolbox Plugin. Diese 

Abbildung soll als Python Skript implementiert werden. Am Ende dieser 

Teilaufgabe soll der Roboterarm mittels Kopfbewegungen gesteuert werden 

können. 

Deadlines 

• 17.04.2013 12:00 Analyse + OLVIS Bildverarbeitungskette 

• 01.05.2013 12:00 Ansteuerung durch Kinematik + Pythonskripte 

• 08.05.2013 12:00 Integration & Dokumentation 

Personen 



Aufwand 

• 8 PT Analyse + OLVIS Bildverarbeitungskette 

• 8 PT Ansteuerung durch Kinematik + Pythonskripte 

• 4 PT Integration & Dokumentation 

190


Lieferumfang 


• OFFIS-Automation-Toolbox-Plugin zur Ansteuerung des Roboterarms 

• OLVIS-Bildverarbeitungskette inkl. Pythonskripte 

• Dokumentation für die Bildverarbeitungskette 

191


2.5.2 Tiefenerkennung 


• Filterkette der Objekterkennung (Sprint 2) 

• Bilder der linken u. rechten Kamera (Sprint 2 und 3) 

• Ansteuerung Roboterarm (Sprint 1 und 2) 


Ziel dieses Arbeitspaketes ist die Erkennung von Punkten und Winkeln im 

dreidimensionalen Raum anhand von 3D-Kameradaten. Zu diesem Zweck 

muss zunächst eine Methode ausgewählt werden, mit der Tiefeninformationen 

zuverlässig aus zwei stereoskopischen Kamerabildern extrahiert werden 

können. Diese Lösung muss anschließend in die OFFIS-Automation- 

Toolbox integriert werden. Dabei soll die vorhandene 2D-Verarbeitungskette 

für die Tiefenerkennung optimiert werden. 

Unter Tiefeninformation werden dabei dreidimensionale Koordinaten verstanden, 

welche die rote Markierungen an dem Arm der Testperson repräsentieren. 

Anders als bei der zweidimensionalen Armerkennung reichen hier 

drei Markierungen nicht aus. Eine vierte muss am Torso der Testperson 

hinzugefügt werden. Die Tiefe dieses Punktes im Raum repräsentiert den 

Ursprung. Aus diesen Raumpunkten müssen mit Hilfe der Python Automation 

die Gelenkpositionen der Testperson im Raum bestimmt werden. 

Anhand dieser können im Anschluss die Winkel der Gelenke berechnet 

werden, dies geschieht ebenfalls in der Python Automation. 

Am Ende des Arbeitspaketes steht somit ein Demonstrator, welcher einer 

beliebigen Testperson ermöglicht den Roboterarm, innerhalb seiner Freiheitsgrade, 

zu steuern. Diese muss dazu die entsprechenden roten Markierungen 

in Form von Armbinden verwenden. Eine entsprechende Evaluationsstrategie 

der Punkte und Winkel muss gefunden und umgesetzt werden. 

Bei der Umsetzung der Softwareprototypen für die dreidimensionale 

Steuerung des Roboterarms muss speziell darauf geachtet werden, dass die 

verwendeten Algorithmen auf in Hardware bzw. auf dem FPGA umsetzbar 

sind. 

Deadlines 

• 24.04.13 12:00 Analyse 3D Info + Punkte im 3D Raum 

192


• 08.05.13 12:00 Integration in die OFFIS-Automation-Toolbox + Winkelberechnung 

• 15:05.13 12:00 Dokumentation 

Personen 



Aufwand 

• 12 PT - Analyse 3D Info + Punkte im 3D Raum 

• 8 PT - Integration in die OFFIS-Automation-Toolbox + Winkelberechnung 

• 4 PT - Dokumentation 

Lieferumfang 

• OFFIS-Automation-Toolbox-Projekt: 

– Verarbeitungskette zur Objekterkennung 

– Verarbeitungskette zur Tiefenerkennung 

– Automationsskript zur Winkelberechnung 

• Microblaze-Code zur Ansteuerung des Roboterarms 

• Algorithmen zur Erkennung von Punkten und Winkeln 

• Dokumentation für die Verarbeitungskette und Algorithmen 

193


2.5.3 Echtzeitbildausgabe auf HDMI 


• Atlys-Projekt aus Sprint 2 

• hdmi_out IP-Core der Fa. Digilent 

• Image-Switch IP-Core aus Sprint 3 

• MPMC IP-Core der Fa. Xilinx 

• ImageBus-IP-Core aus Sprint 2 

• Evaluation aus vorherigem Sprint 


Ziel des Arbeitspakets ist es eine Echtzeit-Ausgabe über den HDMI Port 

des ATLYS -Boards zu ermöglichen. Dies beinhaltet im ersten Schritt die 

Integration des hdmi_out IP-Cores in das Design des ATLYS-Boards, welches 

außerdem das Hinzufügen eines pll_modules beinhaltet. Im folgenden 

Schritt soll ein neuer IP-Core implementiert werden, welcher ein ImageBus- 

Signal über den VFBC in den RAM schreibt. Der Image Switch IP-Core wird 

durch zusätzlichen Microblaze-Code um eine HW-Ansteuerung erweitert, 

um bspw. durch Tastendruck auf dem ATLYS-Board zwischen gefiltertem 

und Originalbild umschalten zu können. Hierzu wird ein Push_Button IP- 

Core zum Projekt hinzugefuegt. Um ein Bild aus dem RAM über USB an 

einen PC schicken zu können soll weiterhin ein Memory-to-ImageBus IP- 

Core erstellt werden. Alle IP-Cores werden in VHDL implementiert. Für 

das Arbeitspaket stehen insgesamt 6 Wochen zur Verfügung. 

Deadlines 

• 17.04.2013 12:00 ImageBus-to-Memory 

• 24.04.2013 12:00 HW-Schalter Implementierung 

• 08.05.2013 12:00 Memory-to-ImageBus 

• 15.05.2013 12:00 Integration & Dokumentation 

194


Personen 

• Fabian Diefenbach 


Aufwand 

• 8PT - ImageBus-to-Memory 

• 4PT - HW-Schalter Implementierung 

• 8PT - Memory-to-ImageBus 

• 4PT - Integration & Dokumentation 

Lieferumfang 

• Image-Switch Microblaze-Code 

• Angepasstes Atlys-Projekt inkl. neuer IP-Cores 

– Push_Button IP-Core 

– ImageBus-to-Memory IP-Core 

– Memory-to-ImageBus IP-Core 

• Dokumentation 

195


2.5.4 Hardware Umsetzung der Bewegungserkennung 


• OFFIS-Toolbox 

• OLVIS Bildverarbeitungskette Armbewegung (Sprint 2) 

• Threshold-, RGB2Grey-, Morphologie- und Blob-IP-Core 


Ergebnis dieses Arbeitspakets soll es sein, die gesamte Bildverarbeitungskette, 

die zum Erkennen von roten Flächen eingesetzt wurde, auf einem 

FPGA zu realisieren. Die Bildverarbeitungskette wurde im zweiten Sprint 

evaluiert und umgesetzt. 

Die Hardwarebeschreibung wird mit VHDL in der XPS Umgebung von Xilinx 

realisiert und für das ATLYS-Board ausgerichtet werden. Hierfür wird 

uns ein Blob IP-Core bereitgestellt mit dem wir uns vertraut machen. Für 

die Auswertung der erkannten Flächen muss ein weiterer IP-Core designet 

werden, der die gegeben Informationen des Blob-IP-Core nutzt und sein 

Ergebnis an den PC weiterleitet. 

Im nächsten Schritt werden alle Komponenten zu einem Gesamtsystem auf 

dem ATLYS-Board integriert, so dass Bilder mit der VmodCAM aufgenommen 

werden und mit der erstellten Filterkette rote Flächen in diesen erkannt 

werden. 

Das Ergebnis soll an einen Computer mittels USB übertragen werden und 

von der OFFIS-Toolboox visualisiert werden. Hierfür wird ein Übertragungsprotokoll 

konzeptioniert und ein OLVIS Plugin erstellt. Das Plugin 

soll die durch die Filterkette erkannten roten Flächen in dem ebenfalls 

übertragenen Bild markieren und kenntlich machen. Das Übertragungsprotokoll 

soll die Kamerabilder und die Informationen über die erkannten 

Flächen übertragen, so dass sie Ausgewertet werden können. 

Deadlines 

• 10.04.2013 12:00 Einarbeitung in Blob-IP-Core 

• 17.04.2013 12:00 Schwerpunktberechnung mit Hilfe des Blob-IP-Core 

• 01.05.2013 12:00 Fertigstellung u. Integration der IP-Cores 

196


• 08.05.2013 12:00 Erstellen eines Übertragungsprotokoll & Anpassung 

des OLVIS Plugin 

• 14.05.2013 12:00 Gesamtintegration & Dokumentation 

Personen 


• Markus Müller 

Aufwand 

• 4 PT Einarbeitung in Blob-IP-Core 

• 4 PT Schwerpunktberechnung mit Hilfe des Blob-IP-Core 

• 8 PT Fertigstellung u. Integration der IP-Cores 

• 4 PT Erstellen eines Übertragungsprotokoll & Anpassung des OLVIS 

Plugin 

• 4 PT Gesamtintegration & Dokumentation 

Lieferumfang 

• OFFIS-Toolbox 

• OFFIS-Toolbox-Plugin zum Empfangen der Filterinformationen 

• AtlysBoard inklusive XPS Projekt 

• Angepasster Blob-IP-Core, angepasste IP-Core, erstellte IP-Core 

197


2.6 Sprint 4 

Des Weiteren werden die Arbeitspakete ausführlich beschrieben. Die Ergebnisse 

sowie die bei der Umsetzung entstandenen Probleme werden vorgestellt. 

2.6.1 Softwareprototyp Kopfsteuerung 

Ziel dieses Arbeitspaketes ist es den Roboterarm mittels einer alternativen 

Gestensteuerung anzusteuern. Diese soll auf Kopfbewegungen reagieren 

(siehe 1.2.3.3). 

2.6.1.1 1. Ansatz: Kopfsteuerung ohne Markierungen 

Im ersten Kopf-Tracking Ansatz wird versucht den Kopf aus den Videodaten 

zu extrahieren. Dazu wird die Bildverarbeitungskette aus Abbildung 

2.74 verwendet. 

Zunächst wird eine Region of interest (ROI) auf das Bild angewendet, um 

den zu analysierenden Bildbereich einzuschränken und mögliche Störungen 

durch den Hintergrund zu minimieren. Die ROI wird dabei so konfiguriert, 

dass in ihr der Kopf, inklusive der Schultern, zu sehen ist. 

Um den Kopf aus den Bilddaten zu extrahieren, wird das Bild mit dem 

Equalizer-Histogramm-Filter der OFFIS-Toolbox in ein Graubild umgewandelt. 

Auf dem entstanden Graubild wird ein Schwellwertfilter (Threshold), 

angewendet. Dieser wird manuell auf die bedienende Person und die 

Lichtverhältnisse angepasst. Abschließend wird ein BLOB-Erkennungsfilter 

auf dem Bild angewendet, welche den Kopf identifiziert (siehe Abbildung 

2.75). 

Der Ansatz wurde mit verschiedenen Testpersonen und unter verschiedenen 

Lichtbedingungen getestet. Dabei wurde festgestellt, dass der Ansatz 

nicht stabil und robust genug ist. Zudem ist die Menge an extrahierbaren 

Daten für ein Mapping auf die Kinematik nicht ausreichend. Daher wurde 

dieser Ansatz verworfen und ein neuer Ansatz entwickelt, welcher in Abschnitt 

2.6.1.2 beschrieben wird. 

2.6.1.2 2. Ansatz: Kopfsteuerung mit Markierungen 

Da die roten Markierungen am Arm bereits gut funktioniert haben, werden 

von uns ähnliche Markierungen im Gesicht befestigt. Das Ziel ist es, diese 

Markierungen im Bild zu finden und nur mit diesen zu arbeiten. 

198


Abbildung 2.74: OLVIS-Bildverarbeitungskette zum Ansatz 1 

Da eine seitliche Kopfneigung festgestellt werden soll, werden oben und 

unten im Gesicht rote Punkte befestigt. Diese beiden Punkte sollen über 

die Kombination aus einem RGB2Grey-Filter, welcher einen gewichteten 

Rotkanal extrahiert und einem Threshold-Filter herausgestellt werden. Zum 

Schluss wird eine BLOB-Erkennungsfilter eingesetzt um Koordinaten für 

die Punkte zu erhalten. 

Moduswechsel mit Augenerkennung 

Da sich aus den zur Verfügung stehenden Daten keine Tiefeninformation 

gewinnen lässt, muss eine Möglichkeit entwickelt werden, um mehr Informationen 

zu erhalten. Dies ist notwendig, da die bisher erfasste Neigung 

nur ausreicht um eine Dimension zu kontrollieren. Zu diesem Zweck 

wird ein Modussystem implementiert. Dabei werden mehr Informationen 

199


Abbildung 2.75: Ergebnis der OLVIS-Bildverarbeitungskette zum Ansatz 1 

erzeugt um die Dimensionen zu kontrollieren, da eine Geste für mehrere 

Dimensionen verwendet werden kann. 

Um den Modus zu wechseln muss eine Geste erkannt werden. Hierzu wird 

eine Erkennung der Augen entwickelt. Es wird dabei lediglich überprüft, 

ob bei einer senkrechten Kopfhaltung die Augen geöffnet oder geschlossen 

sind. Die Augen werden dabei in einer ROI gesucht, welche anhand der 

roten Punkte, die zur Erkennung der Kopfhaltung verwendet werden, ausgerichtet 

wird. 

Die ROI ist dynamisch implementiert, sodass sich die Größe der ROI automatisch 

an den Abstand des Bedieners zur Kamera anpasst. Eine Reihe 

von Tests mit verschiedenen Testpersonen hat ergeben, dass die Erkennung 

des Zustandes der Augen ohne Infrarotbeleuchtung nicht praktikabel ist. 

Im Rahmen der Tests wurde zudem festgestellt, dass die für die FPGA- 

Implementation verwendete Kamera über einen Infrarot-Cutter verfügt. 

Dadurch ist die Verwendung von Infrarotbeleuchtung ausgeschlossen. 

Moduswechsel durch Drehung des Kopfes 

Da sich die Steuerung des Modus durch die Erkennung der Augen als 

200


nicht umsetzbar herausgestellt hat, wurde ein alternativer Ansatz verfolgt. 

Dabei soll eine Drehung des Kopfes erkannt werden. Hierzu wird von 

uns eine grüne Markierung in der Nähe der Ohren befestigt. Diese grüne 

Markierung ist nur sichtbar, wenn der Kopf gedreht ist. Zur Erkennung 

wird das Verfahren für die roten Markierungen benutzt. Um statt der roten 

Markierungen die grüne zu finden wird nur eine Änderung des RGB2Grey- 

Filters benötigt, welcher anstatt des gewichteten Rotkanals, einen gewichteten 

Grünkanal extrahiert. 

Abbildung 2.76: OLVIS-Bildverarbeitungskette zum Ansatz 2 

Die resultierende Bildverarbeitungskette, zu sehen in Abbildung 2.76, liefert 

als Ausgabe die Position von den roten und grünen Markierungen zur 

weiteren Analyse. Eine Beispielausgabe lässt sich in Abbildung 2.77 sehen. 

Um aus diesen die Kopfneigung zu bestimmen wird überprüft ob sich die 

obere rote Markierung links oder rechts von der unteren roten Markierung 

201


befindet. Wenn sich beide ungefähr übereinander befinden ist der Kopf 

gerade. 

Zur Bestimmung, ob der Kopf gedreht ist, wird überprüft ob eine grüne 

Markierung gefunden wird. Wenn dies der Fall ist, muss der Kopf gedreht 

sein. Im anderen Fall ist der Kopf nicht gedreht. 

(a) Bild ohne Kopfdrehung 

(b) Bild mit Kopfdrehung 

Abbildung 2.77: Ausgaben der OLVIS-Bildverarbeitungskette zum Ansatz 

2 

Dateistruktur 

• offis-toolbox/HeadTracking/HeadTracking/HeadTracking.oap: Toolbox 

Projektdatei 

• offis-toolbox/HeadTracking/HeadTracking/HeadTracking.ogr: Toolbox 

Projektdatei 

• offis-toolbox/HeadTracking/HeadTracking/magic.py: Python Code für 

Automation 

• offis-toolbox/HeadTracking/HeadTracking2/HeadTracking2.oap: Toolbox 

Projektdatei 

• offis-toolbox/HeadTracking/HeadTracking2/HeadTracking2.ogr: Toolbox 

Projektdatei 

• offis-toolbox/HeadTracking/HeadTracking2/magic2.py: Python Code 

für Automation 

202


• offis-toolbox/HeadTracking/HeadTracking2/roboarm.ini: Konfigurationsdatei 

für Kinematik 

2.6.1.3 Servo IP-Core 

Da für die Entwicklung der Rückwärtskinematik kein ATLYS-Board zur 

Verfügung stand, wurde stattdessen das GENESYS-Board verwendet. Hierzu 

musste zunächst der Servo IP-Core angepasst werden, um mit der 

geänderten Taktfrequenz zu funktionieren. Dies wurde zum Anlass genommen 

den IP-Core zu überarbeiten und zu dokumentieren. 

Blockschaltbild 

clk 

reset 

reg[0:31] 

servo_v1_00_a 

output 

Abbildung 2.78: Blockschaltbild des Servo IP-Core 

Beschreibung 

20ms 

1ms 1.5ms 2ms 

Abbildung 2.79: Servo Signal 

Der Servo-IP-Core ist zuständig für die Ansteuerung eines Servos. Dazu 

muss ein Pulspositionsmodulation-Signal, wie in Abbildung 2.79 zu sehen, 

203


generiert werden. Der IP-Core generiert alle 20 Millisekunden einen Puls, 

dessen Länge über den PLB vom Microblaze aus einstellbar ist. Der Servo 

stellt sich auf ca. 0 ◦ , wenn ein Puls von einer Millisekunde verwendet 

wird. Wenn ein Puls von zwei Millisekunden empfangen wird, stellt sich 

der Servo auf ca. 180 ◦ . Zwischen diesen Zeiten existiert eine lineare Abbildung 

von Zeiten auf Winkel. Zum Beispiel stellt eine Pulsdauer von 1, 5 

Millisekunden den Winkel auf 90 ◦ dar, also die Mitte. 

Für die Implementation wurde ein Zustandsautomat verwendet. Dieser ist 

in Abbildung 2.80 abgebildet. Dabei bezeichnet register den Wert aus dem 

PLB-Register, welcher die Pulslänge in µs enthält. Im Resetzustand wird 

das Register auf 1500µs gesetzt, so dass der Servo sich nach einem Reset 

ungefähr in einer mittleren Stellung befindet. 

Der Zustand st1_high setzt das Signal. Während dieses Zustands wird der 

Puls gesendet. Der folgende Zustand st2_low generiert die dazugehörige 

Pause. 

register µs 

40ms 

start st0_reset 

st1_high st0_low 

20ms − register µs 

Abbildung 2.80: Zustandsautomat im Servo IP-Core 

Die Servo IP-Core Implementation unterstützt eine Bustaktung von maximal 

1 GHz. 

Treiber 

Der Treiber des IP-Core verfügt über acht Methoden mit denen Werte gesetzt 

und gelesen werden können, sowie über drei Konstruktoren zur Initialisierung. 

Die unterschiedlichen Konstruktoren benötigen unterschiedliche 

Parameter bei der Initialisierung. 

Servo () ; 

Der erste Konstruktor verfügt über keine Parameter und setzt feste Werte 

für die Variablen min, max und base. Es werden dabei für min 0, für max 

3000 und als base 0 verwendet. min und max begrenzen die Range in denen 

204


der Servo angesteuert werden kann und base bezeichnet die Basisaddresse 

des Servo. 

Servo ( unsigned int base_address ); 

Dem zweite Konstruktor wird die Basisaddresse als Parameter übergeben. 

Die Basisadresse ist dabei vom Typ unsigned integer. 

Servo ( unsigned int base_address , unsigned short minimum , 

unsigned short maximum ); 

Dem dritten Konstruktor wird die Basisaddresse, sowie Werte für die Range 

des Servo übergeben. Die Range wird als Typ unsigned short angegeben. 

Diese Methode setzt zusätzlich den Winkel des Servo auf 90 Grad. 

unsigned int getBase () ; 

Mit der parameterlosen Methode getBase kann die Basisaddresse ausgelesen 

werden. Diese wird dabei als Rückgabewert vom Typ unsigned integer 

zurückgegeben. 

void reset () ; 

Die Methode reset setzt auf XIo_Out32 den Wert base+0x100, 0x0a. 

unsigned short get () ; 

Die Methode get gibt die Basisaddresse auf XIo_In32 aus. 

void set_range ( unsigned short minimum , unsigned short maximum 

); 

Die Methode set_range kann verwendet werden um die Range des Servo 

einzustellen, in welcher sich die Werte bei der Ansteuerung des Servo bewegen 

dürfen. Wenn diese Methode nicht ausgeführt wird, werden für min 

und max die Werte aus dem Konstruktor verwendet. 

void set ( unsigned short microseconds ); 

Die Methode set verfügt über einen Parameter microseconds vom Typ unsigned 

short. Es wird intern die Methode set(unsigned short ms, bool ignore_minmax) 

mit den Parametern microseconds und false aufgerufen. Mit dieser Methode 

kann ein Winkel in Mikrosekunden gesetzt werden. 

205


void set ( unsigned short microseconds , bool ignore_range ); 

Eine zweite Methode set des Treibers wird mit zwei Parametern aufgerufen. 

Die Parameter sind von den Typen unsigned short und bool. Der Parameter 

vom Typ unsigned short ist identisch zu dem Parameter der vorherigen set- 

Methode. Der Parameter von Typ bool ersetzt den Parameter false, welcher 

in der vorherigen set-Methode übergeben wurde. Er bewirkt, dass die min 

und max Einstellungen der Range ignoriert werden. 

void set_angle ( unsigned short degree ); 

Die Methode set_angle kann verwendet werden um den Servo einen Winkel 

anfahren zu lassen. Im Gegensatz zur set-Methode wird hierbei der Winkel 

in Grad angegeben. 

unsigned short get_angle () ; 

get_angle gibt den aktuellen Winkel des Servo, der im Treiber gespeichert 

ist, in Grad zurück. 

Dateistruktur 

• ip-cores/drivers/servo_v1_00_a/data/servo_v2_1_0.mdd: Generiert von 

Xilinx 

• ip-cores/drivers/servo_v1_00_a/data/servo_2_1_0.tcl: Generiert von Xilinx 

• ip-cores/drivers/servo_v1_00_a/data/src/servo.cpp: Cpp-Datei mit Implementierung 

• ip-cores/drivers/servo_v1_00_a/data/src/servo.h: Cpp-Datei mit Prototypendefinition 

Änderungen in diesem Sprint 

• Das Generic für die Taktfrequenz vom Clock-Pin wird jetzt verwendet. 

Zuvor musste der IP-Core angepasst werden, wenn die Taktfrequenz 

vom Bus geändert wird. Jetzt geschieht die Anpassung über 

das Generic, welches von der Xilinx Toolchain automatisch angepasst 

wird. 

206


• Der IP-Core wurde optimiert, so dass er statt einer 18-Bit Multiplikation 

zwei Zähler benutzt. Da der Servo IP-Core mehrfach instantiiert 

wird, werden sonst sehr viele, in ihrer Anzahl begrenzten, Multiplikationseinheiten 

benötigt. 

2.6.1.4 USB Driver IP-Core 

Der USB Driver IP-Core stellt eine Abstraktion der USB-Schnittstelle zur 

Verfügung. Der IP-Core wird über den PLB konfiguriert und liefert USB- 

Steuernachrichten ebenfalls an diesen. Für jede ankommende Steuernachricht 

löst der USB Driver einen Interrupt am Microblaze aus. 

Für größere Datenmengen existiert des weiteren eine Abstraktion für USB- 

Bulkdaten. Diese können in einen FIFO-Speicher geschrieben werden. 


debug[0:15] 

interrupt 

SPLB 

usb_driver 

bulk_in 

bulk_out 

ext_usb 

Abbildung 2.81: Blockschaltbild des USB Driver IP-Core 

Treiber 

Der USB-Driver Core Treiber stellt eine Wrapperklasse um die usb_driver.h 

dar. Die usb_driver.h wurde zur Verfügung gestellt und stellt Methoden für 

die Kommunikation über die USB-Verbindung zur Verfügung. Der Wrapper 

besitzt, neben einem Konstruktor, fünf Methoden um Interrupts über 

die USB-Verbindung zu senden und empfangen. 

USB ( u32 base_address , bool debug = false ); 

Dem Konstruktor der Klasse muss beim Aufruf die Basisaddresse übergeben 

werden. Der zweite Parameter debug, ist standardmäßig auf false gesetzt. 

Dies bedeutet, dass der Interrupt-Handler keine seriellen Ausgaben generiert. 

Diese Ausgabe sollte nur verwendet werden, wenn garantiert werden 

207


kann, dass weniger als ein Interrupt pro Sekunde generiert wird. 

bool debug ; 

Um den Parameter debug auf true zu setzen, kann dieser direkt gesetzt werden, 

da es sich hier um eine public-Variable der Klasse handelt. 

void setup_interrupts ( XIntc * interruptController , u8 pin ); 

Die Methode setup_interrupts erstellt den Interruptkontroler für die USB- 

Interrupts. Hierzu muss ein Zeiger auf den Interruptcontroller und der 

Interrupt-Pin übergeben werden. 

void register_handler ( UsbMessageType type , UsbHandler handler 

); 

Mit der Methode register_handler wird ein neuer Handler erzeugt. Es muss 

hierzu der UsbMessageType übergeben werden, auf welchen der Handler 

reagieren soll, sowie ein UsbHandler, der zuvor erzeugt wurde. 

void unregister_handler ( UsbMessageType type ); 

Um einen Handler zu deaktivieren gibt es die Methode unregister_handler. 

Dieser wird der UsbMessageType übergeben. Nach Aufruf dieser Methode 

ist der Handler gelöscht. 

void send ( const UsbMessage & msg , int len = 8) ; 

Um Nachrichten über USB zu senden, wird die Methode send zur Verfügung 

gestellt. Dieser wird eine Referenz auf eine erstellte USB-Message 

übergeben. Der zweite Parameter der Methode ist fest eingestellt und wird 

intern von der Methode verwendet und braucht nicht angegeben zu werden. 

Intern leitet die Methode die Daten an eine Methode der 

usb_driver.h weiter. 

void interrupt_handler () ; 

Die Methode interrupt_handler wird aus technischen Gründen public zur 

Verfügung gestellt, wird aber ausschließlich intern verwendet und sollte 

NICHT verwendet werden. 

Dateistruktur 

• ip-cores/drivers/usb_driver_v2_00_a/src/usb.h: Cpp-Datei mit Prototypendefinition 

208


• ip-cores/drivers/usb_driver_v2_00_a/src/usb_message_type_decoder.cpp: 

Cpp-Datei mit Implementierung 

2.6.1.5 Cam-USB IP-Core 

Der Cam-USB IP-Core verbindet einen ImageBus mit dem USB-Driver IP- 

Core. Dies erfordert, dass mit geringer Taktung gearbeitet wird, da der 

IP-Core nicht überprüft, ob der FIFO-Speicher voll ist. 


pixel_clock 

direct_wrClk 

PLB 

IMAGE_BU 

S 

cam_usb 

direct_wrReq 

direct_wrData[31:0] 

Abbildung 2.82: Blockschaltbild des Cam USB IP-Core 

Treiber 

Der USB Cam Treiber implementiert die Aktivierung und Deaktivierung 

der Kameras. Der Treiber stellt hierzu einen Konstruktor und zwei Methoden 

zur Verfügung. Dem Konstruktor muss die Basisaddresse als Parameter 

übergeben werden. 

CamUSB ( u32 base_address ); 

Mit der Methode enable kann die Kamera aktiviert werden. Diese Methode 

muss beim erzeugen des Handlers für den USB-Message-Type 

USB_TYPE_IMAGE_START aufgerufen werden. Durch den Aufruf wird 

der Wert 0xffffffff in das Register der Basisaddresse geschrieben. 

void enable () ; 

Die Methode disable deaktiviert die Kamera. Dabei wird der Wert 0x00000000 

in das Register der Basisaddresse geschrieben. Diese Methode muss vom 

Handler für den USB-Message-Type USB_TYPE_IMAGE_STOP aufgerufen 

werden. 

void disable () ; 

209


Dateistruktur 

• ip-cores/drivers/camusb_v1_00_a/src/cam_usb.cpp: Cpp-Datei mit Implementierung 

• ip-cores/drivers/camusb_v1_00_a/src/cam_usb.h: Cpp-Datei mit Prototypendefinition 

2.6.1.6 VmodCam 

Das VmodCamPlugin muss angepasst werden, um die Veränderungen am 

USB-Driver und die Einführung der neuen USB-Message-Types zu verwenden. 

Zum diesem Zweck wurde die usb_message_type.h erstellt. In dieser 

Datei werden die Datenstrukturen der Message-Types definiert. Es werden 

derzeit die folgenden Message-Types unterstützt: 

1 class SizePacket 

2 class StartPacket 

3 class StopPacket 

4 class ImageBusSwitchPacket 

Im Rahmen der Anpassung an die neuen Message-Types wurden die 

usb_message_type.h und die CypressUsb.h in der Dateistruktur in eine höhere 

Ebene verschoben. Hierbei wurden ebenfalls die Dateipfade in der QT- 

Projektdatei angepasst. Das Verschieben der Dateien wurde vorgenommen, 

da die betroffenen Dateien nicht projektgebunden sind, sondern für alle 

QT Projekte mit USB-Kommunikation benötigt werden. Hierdurch wird 

Dateiredundanz vermieden. 

Dateistruktur 

• plugins/vision/VmodCamPlugin/VmodCamPlugin.pro: QT-Projektdatei 

• offis-toolbox/plugins/CypressUsb.h: CypressUsb.h Cpp-Datei 

• offis-toolbox/plugins/usb_message_type.h: Cpp-Datei mit MessageType- 

Definition 

2.6.1.7 Kinematik 

An der Kinematik wurden eine Reihe von Änderungen durchgeführt. Zunächst 

wurde die USB-Kommunikation auf die neuen USB-Message-Typen umgestellt. 

210


Hierzu wurde die CypressUsb.h aus dem Projekt und der Dateistruktur 

gelöscht und die Pfade im QT-Projekt auf die neue Datei, welche außerhalb 

des Projekts angelegt wurde angepasst. Diese Anpassung ist notwendig 

aufgrund der Änderungen, welche bereits im VmodCam-Plugin begonnen 

wurden, siehe 2.6.1.6. In der usb_message_type.h wurden die folgenden Message- 

Types angelegt: 

class 

class 

ServoAnglePacket 

ServoAnglesPacket 

RoboArm.h 

Die Kinematik wurde im Rahmen der Einführung der neuen USB-Kommunikation 

unstrukturiert. Dabei wurden zunächst die alten Message-Type-Definitionen 

aus der RoboArm.h entfernt. Außerdem wurde das Interface der Kinematik 

aufgeräumt und einige Funktionen entfernt, welche von der neuen USB- 

Kommunikation nicht mehr berücksichtigt oder nicht mehr benötigt werden. 

Das Interface wurde dabei auf die folgenden Methoden reduziert: 

1 void acquireHardware () ; 

2 void releaseHardware () ; 

3 void setAngle ( int servoId , double angle ); 

4 void setAngles ( RcRepeatable < double , 1, 6> angles ); 

5 void createRoboter ( int links ); 

6 void setLastLinkTCP ( double x , double y , double z); 

7 void setDHParameters ( int index , double si , double di , double 

phi , double theta ); 

8 QVector3D getTCP () ; 

9 QVector4D getAngleVector ( double x , double y , double z); 

RoboArm.cpp 

Aus der RoboArm.cpp wurden die Teile der Implementierung entfernt, welche 

die alten Message-Types implementierten. Zudem wurden alle Bestandteile 

entfernt, die nicht mehr von der neuen USB-Kommunikation berücksichtigt 

oder nicht mehr benötigt werden. Es wird nur noch, dass in Abschnitt 

2.6.1.7 definierte Interface implementiert. Außerdem wurde in allen Methoden 

die USB-Kommunikation auf den neuen Standard umgestellt. 

Die Methode acquireHardware() wurde überarbeitet, und implementiert jetzt 

ausschließlich die Funktionen zur Erstellung der USB-Kommunikation 

und zur Initialisierung des Modells des Roboterarms. 

OFFIS-Toolbox Interface 

Das Interface der Kinematik wurde überarbeitet und aufgeräumt. Dabei 

211


wurden eine Reihe von Funktionen entfernt die nicht mehr von der Kinematik 

unterstützt werden. Die im Interface verbliebenen Methoden sind: 

Die Funktionen acquireHardware und releaseHardware werden benötigt um 

den Roboterarm und die USB-Kommunikation zu Initialisieren und zu 

beenden. 

acquireHardware 

releaseHardware 

Um den Winkel eines Servo in Grad einzustellen, wird die Methode setAngle 

zur Verfügung gestellt. 

setAngle 

Die Methode setAngles kann verwendet werden, um die Winkel aller Servos 

in Grad zu setzen. 

setAngles 

Zum setzen der Denavit Hartenberg-Parameter der Kinematik existiert nach 

wie vor die Methode setDHParameters. Zu setzen sind der Index des Links, 

der Gelenkabstand, die Länge eines Links, die Rotation der x-Achse (Gelenkwinkel) 

und die Rotation der Z-Achse (Verwindung). 

setDHParameters 

Mit der Methode getAngleVector wird die Rückwärtskinematik aufgerufen. 

Diese liefert für eine übergebene Tool-Center-Point-Position die Winkel für 

die Servo zurück. 

getAngleVector 

Dateistruktur 

• offis-toolbox/plugins/automation/RoboArm/RoboArmInterface.cpp: 

Interface der Kinematik für die OFFIS-Toolbox 

• offis-toolbox/plugins/automation/RoboArm/RoboArm.pro: QT-Projektdatei 

• offis-toolbox/plugins/usb_message_type.h: Cpp-Datei mit MessageType- 

Definition 

• offis-toolbox/plugins/automation/RoboArm/RoboArm.h: Cpp-Datai 

mit Prototypendefinition der Kinematik 

• offis-toolbox/plugins/automation/RoboArm/RoboArm.cpp: Cpp-Datei 

mit Implementierung der Kinematik 

212


2.6.1.8 Anbindung an die Rückwärtskinematik 

Für die Ansteuerung des Roboterarms wird die zuvor überarbeitete Kinematik 

verwendet. Dabei wird die Rückwärtskinematik, über das in Kapitel 

2.6.1.7 beschriebene Interface angesprochen. 

Die Rückwärtskinematik liefert zu dem übergebenen Tool-Center-Point die 

Winkel für den Roboterarm zurück. Diese Art der Steuerung des Tool- 

Center-Point ist dadurch möglich, da eine definierte Ausgangsposition des 

Roboters im Koordinatensystem besteht. 

Die Bewegungen des Kopfes verändern hierbei nur die Position des Tool- 

Center-Point bei jeder Messung mit einer konstanten Rate. Da zum Zeitpunkt 

der Erstellung des Algorithmus nur 2D Daten zur Verfügung standen, 

werden nur seitliche- und dreh-Bewegungen des Kopfes ausgewertet. 

Um den Tool-Center-Point in allen Dimensionen bewegen zu können, wird 

ein Modussystem verwendet. Dabei wird die Drehung des Kopfes durch 

die zusätzliche Markierung am Kopf erkannt. Es kann somit durch die 

verschiedenen Steuerungsmodi gewechselt werden. 

Die Implementierung sieht drei Modi vor. Dabei stellt ein Modus jeweils 

eine Bewegung des Tool-Center-Point in einer Dimension dar. Derzeit sind 

die Modi für die Steuerung der x- ,y- ,z-Achse vorgesehen. 

Für die Steuerung des Greifers müsste ein zusätzlicher Modus eingeführt 

werden. Dieser wurde nicht berücksichtigt, da die Implementierung äquivalent 

zu den Achsen erfolgen würde und der Greifer zum Zeitpunkt der 

Implementierung defekt war. 

213


2.6.2 Tiefenerkennung 

Ziel des Arbeitspaketes ist eine Extraktion von Tiefeninformationen. Dies 

geschieht in Form von Punkten aus einem Datenfluss von Stereobildern 

eines makierten menschlichen Arms. Anhand der extrahierten Punkte werden 

die Winkel der Gelenkstellungen des Arms im dreidimensionalen Raum 

berechnet. Die Tiefenerkennung dieses Arbeitspaketes wird unter der Voraussetzung 

durchgeführt, dass sich die Armbinden nicht überlagern. Trotzdem 

wird mit Hilfe unterschiedlicher Armbinden versucht Ansätze für ein 

Überlappungsproblem zu testen. 

2.6.2.1 Vorgehen 

• Ausgangspunkt sind die berechneten Schwerpunkte der erkannten 

roten Regionen der Armbinden. Diese Regionen werden auch als 

BLOBs bezeichnet. Wie im Arbeitspaket Objekterkennung 2.2.4, wird 

zunächst der Rotkanal des Bildes durch den gewichteten Farbfilter 

RGB2Grey der OFFIS-Automation-Toolbox gefiltert. Das resultierende 

Graustufenbild wird dann durch einen Schwellwertfilter geschickt. 

Dieses binäre Bild wird nun, wie oben beschrieben, durch die BLOB- 

Erkennung verarbeitet, sodass die Koordinaten der Schwerpunkte der 

erkannten Regionen vorliegen. 

• Entfernungstests werden mit Hilfe eines Versuchsaufbaus durchgeführt. 

Dieser beinhaltet eine (später mehrere) Armbinden, sowie die 

Stereokamera. Diese ist über den FPGA mit der OFFIS-Automation- 

Toolbox verbunden, siehe Abbildung 2.83. 

214


Abbildung 2.83: Testumgebung 

2.6.2.2 Planungsphase: identizierte Aufgaben 

Bei den vorangegangenen Überlegungen zur Tiefenerkennung ergaben sich 

folgende Aufgaben: 

• Um zu verhindern, dass sich überlappende Armbinden als nur eine 

erkannt werden, können unterschiedlich gefärbte Armbinden verwendet 

werden. Da nur drei Grundfarben existieren, aber vier Makierungen 

benötig werden, müssten zwei Makierung die gleiche Farbe verwenden. 

Dazu bietet sich die Makierung am Torso und an der Hand 

an, da sich der Torso kaum bewegt und weit von der Hand entfernt 

ist. Damit ist eine Überdeckung unwahrscheinlicher als an anderer 

Stelle. 

• Innerhalb der bisher durchgeführten Arbeitspakete hat sich ergeben, 

dass eine der beiden Kameras auf der Platine gedreht ist. Hier könnte 

sich ein Problem ergeben, da die Tiefenerkennung auf geringe Unterschiede 

der Distanz reagiert. OpenCV ermöglicht eine Berechnung 

215


der Drehung, jedoch wird ein Testbild zunächst manuell gedreht, um 

ein potentielle Verbesserung zu prüfen. 

• Die Bilder der Kameras kommen gleichzeitig auf den FPGA an. Die 

Bildwiederholungsrate ist jedoch mit 1,5 Bilder pro Sekunde (fps) 

sehr niedrig. Hinzu kommt, dass die beiden Kameras ihre jeweiligen 

Aufnahmen nicht synchron senden. 

– Zu diesem Zweck müsste ein IP-Core geschrieben werden, um 

die Kameras zu synchronisieren. 

– Alternativ kann der zu erkennende Arm auch langsam bewegt 

werden, um die geringe Bildwiederholungsrate auszugleichen. 

• Es muss eine definierte Testumgebung erstellt werden. Hierzu werden 

feste Abstände zwischen den gleichgroßen Armbinden eingestellt. 

Die Testumgebung muss so eingerichtet werden, dass je ein Bild von 

den beiden Kameras nacheinander aufgenommen wird. Zwischen 

den beiden Aufnahmen darf sich die Szene nicht ändern. 

• Die Pixel auf dem Sensor in einen Abstand in Millimeter in Abhängigkeit 

der aktuellen Tiefe und maximalen Auflösung umrechnen. 

2.6.2.3 Tiefenberechnung 

Folgende Konstanten der Kamera sind bei der Tiefenberechnung zu beachten: 

• Kameraabstand (Stereo baseline), b = 63 mm 17 

• Brennweite (Focal Length), f = 3.79 mm (+/-0.1 mm) 18 

Mit Hilfe dieser Werte lässt sich die Tiefe eines Punktes im Raum berechnen, 

siehe Abbildung 2.84, 2.85, 2.86 : 

Tie f enwert = 

f · b 

|∆x 1 − ∆x 2 | 

(2.14) 

∆x 1 und ∆x 2 sind dabei die Entfernungen von dem Bildpunkt auf dem 

Sensor zum Brennpunkt bzw. Mittelpunkt des Sensors: 

17 http://www.aptina.com/assets/downloadDocument.do?id=790 

18 http://www.datasheet.co.kr/datasheetdownload.php?id=638699 

216


x−Au f loesung y−Au f loesung 

M( 

2 

/ 

2 

) 

Abbildung 2.84: Skizze zur Tiefenberechnung 


217



2.6.2.4 Tests 

Die Testbilder werden nacheinander aufgenommen und jeweils durch folgende 

Bildverarbeitungsketten in der OFFIS-Automation-Toolbox verarbeitet. 

Dabei wird eine Armbindenerkennung, sowohl mit als auch ohne Morphologiefilter, 

durchgeführt, siehe Abbildung 2.87 bzw. Abbildung 2.88. 

218


Abbildung 2.87: Bildverarbeitungskette mit BLOB-Erkennung (ohne Morphologiefilter) 

219


Abbildung 2.88: Bildverarbeitungskette mit Morphologiefilter 

220


Abbildung 2.89: Bildverarbeitungskette mit mehreren Morphologiefiltern 

Die folgenden Tests zeigen die Erkennung und damit die Benutzbarkeit 

der Armbinden. 

1. Der erste Test erfolgte mit geringer Entfernung: 39 cm Tiefe berechnet 

und 65 cm Tiefe in der Realität gemessen (Berechnung entspricht 

60% der Realität). Ein Tauschen der Kamerabilder (rechts/links) hat 

ein geändertes Vorzeichen zur Folge, welches im Quelltext mathe- 

221


matisch durch eine Betragsfunktion ausgeglichen wurde. Selbst nach 

manuellem Ausgleich (Bildbearbeitungsprogramm IrfanView 19 ) der 

Drehung zwischen den Bildern (siehe Abbildung 2.90) weicht die 

berechnete Entfernung um weniger als 3 cm vom alten berechneten 

Wert ab. Die Drehung kann daher als Hauptfehlerquelle ausgeschlossen 

werden. Damit bleibt die unterschiedliche automatische Anpassung 

der Helligkeit der Kameras als potentielle Fehlerquelle bestehen. 

Abbildung 2.90: Stereobildpaar der Armbinde (Bild manueller Drehung 

beider Bilder) 

2. Der zweite Test wurde mit größerer Entfernung durchgefürt: 111 cm 

Tiefe berechnet und 185 cm in der Realität gemessen (Berechnung 

entspricht 60% der Realität). Die minimale Größe, in Pixel, der zu 

erkennenden Regionen musste von 10000 auf 1000 heruntergesetzt 

werden, um korrekte Polygone zu erkennen. 

3. Der nächste Test besteht aus zwei roten Armbinden mit 50 cm Tiefenunterschied 

(siehe Abbildung 2.91). Ergebnis: Berechnet werden 139 cm 

und gemessen 240 cm (Berechnung entspricht 58% der Realität). Zweite 

Armbinde: Berechnet werden 125 cm und gemessen 190 cm (Berechnung 

entspricht 65% der Realität). 

19 http://www.irfanview.com/ 

222


Abbildung 2.91: Zwei rote Armbinden mit unterschiedlicher Tiefe 

4. Folgender Testfall erfolgt mit einer roten und einer blauen Armbinde 

ohne automatische Korrekturfunktion, siehe Abbildung 2.92. Zu diesem 

Zweck muss es statt einer Bildverarbeitungskette pro Kamera zwei 

Verarbeitungsketten pro Kamera geben, eine für die blaue und eine 

für die rote Armbinde mit dem gewichteten Farbfilter RGB2Grey. 

Abbildung 2.92: Stereobilder mit blauer und roter Armbinde ohne automatische 

Helligkeitsanpassung 

Ergebnis: Die blaue Armbinde kann mit Hilfe des blau gewichteten 

Farbfilters nicht stabil erkannt werden. Insbesondere bei starker Belichtung 

kann die blaue Binde nicht mehr von dem weißen Hintergrund 

unterschieden werden. Der Einsatz eines Morphologiefilters 

mit Erosion und Dilatation bringt keine signifikante Verbesserung. 

5. Anschließender Testfall wird mit einer roten und einer blauen Armbinde 

mit automatische Korrekturfunktion durchgeführt, siehe Abbildung 

2.93. Obiger Testfall wurde mit der automatische Korrektur 

223


der Kamera wiederholt. Wie Abbildung 2.93 zu entnehmen ist, kann 

die blaue Armbinde mit Hilfe eines Morphologiefilters gut erkannt 

werden. 

Abbildung 2.93: Stereobilder mit blauer und roter Armbinde mit automatische 

Helligkeitsanpassung 

Die Parameter sind stark von den Lichtverhätnissen abhängig und 

sind wie folgt gesetzt: 

Schwellwert (Rotlter): 25 

Schwellwert (Blaulter): 30 

Morphologielter: 2 Iterationen (Erosion und Dilatation) 3 × 3 

6. Folgender Testfall wird mit einer grüner Armbinde (dargestellt durch 

ein eingefärbtes Papier) durchgeführt, siehe Abbildung 2.94. Bei der 

linken Kamera (gute Lichtverhälnisse) wird die grüne Armbinde ohne 

Morphologiefilter erkannt. Die rechte Kamera (schlechte Lichtverhältnisse) 

erkennt die Armbinde selbst mit Morphologiefilter nur fehlerhaft. 

224


Abbildung 2.94: Bildverarbeitungskette mit heller grüner Armbinde in 

Form eines angemalten Papiers 

7. Anschließend wird der vorherige Testfall leicht modifiziert, diesmal 

mit drei Morphologiefiltern und einem angepassten Schwellwertfilter 

durchgeführt. Die grüne Armbinde wird bei beiden Kameras erkannt, 

jedoch aufgrund unterschiedlicher Belichtung mit unterschiedlichem 

Schwellwert pro Kamera, siehe Abbildung 2.95. 

225


Abbildung 2.95: Bildverarbeitungskette mit grüner Armbinde und 

mehreren Morphologiefiltern 

8. Ein vielfacher Einsatz des Morphologiefilters bei einer großen Zahl 

von Iterationen ist in Bezug auf eine spätere Hardwareimplementierung 

nicht performant. Des Weiteren ist die vollständige Bewertung 

der Erkennung von farbigen Armbinden nicht Teil dieses Arbeitspaketes, 

weshalb mit der Optimierung der Erkennung von roten 

Armbinden aus dem dritten Test fortgefahren wird. 

Um die 60% Differenz zwischen dem gemessenen und dem berechneten 

Wert zu erklären, wurde die Formel zur Tiefenberechnung nochmals 

überarbeitet und Programmfehler (teilweises Rechnen mit Ganzzahlen 

statt mit Fließkommazahlen) korrigiert. Dabei ändern sich Testwerte 

226


wie folgt (BLOB-Erkennung mit dynamischen Schwellwert, Werte gerundet): 

Messwert Berechneter Wert %-Anteil mit Morph. %-Anteil 

50 cm 45 cm 94% 58 cm 116% 

75 cm 67 cm 89% 29 cm 39% 

100 cm 113 cm 113% 95 cm 95% 

125 cm 176 cm 140% 439 cm 351% 

150 cm 53110 cm 35406% 9575 cm 6383% 

175 cm 784 cm 448 % 775 cm 443% 

200 cm - - - - 

Bei 200 cm konnte auf einem Kamerabild kein Objekt erkannt werden. 

Die Berechnung der Schwerpunkte hängt stark vom Schwellwert 

ab, der sich zwischen 0 und 15 befindet. Die Fehler dieser Testreihe 

können auf schlechte Lichtverhältnisse (Licht von der Seite) zurückgeführt 

werden. Daher soll in der nächsten Testreihe die Kamera das 

Licht hinter sich haben, sodass beide Kamerabilder ein möglichst gleichwertigen 

Lichteinfall erhalten. 

9. Aufgrund der verbesserten Lichtverhältnisse kann der Schwellwert 

bei allen Messungen statisch auf den Wert Zehn gesetzt werden. Es 

bedarf demnach nicht zwingend eines Morphologiefilters. Abbildung 2.96 

zeigt eine Erkennung des BLOBs (Armbinde) mit dem Schwerpunkt 

auf 200 cm. Die Werte weichen im entfernteren Bereich nicht mehr so 

stark ab und es gibt eine lineare Abweichung von ca. 50%. 

Messwert Berechneter Wert %-Anteil Messwert 

50 cm 36 cm 72% 

75 cm 38 cm 51% 

100 cm 48 cm 48% 

125 cm 61 cm 49% 

150 cm 74 cm 49% 

175 cm 85 cm 49% 

200 cm 102 cm 51% 

Die Abweichung von ca. 50% ist nach Prüfung der Arbeitsweise der 

Stereokamera und den Umrechnungsschritten auf folgendes zurückzuführen: 

Wenn die Kamera mit weniger als der maximalen Auflösung 

betrieben wird, beschränkt sich die Kamera auf einen Bildauss- 

227


chnitt, nimmt also nicht jedes x-te Pixel. Das erklärt des Weiterten, 

warum die Szene bei einer Auflösung von 800x600 Pixel stets links 

oben anstatt direkt vor der Stereokamera zu plazieren ist. Abbildung 2.97 

zeigt ein Fehlerbild welches den gesamten Sichtbereich der Stereokamera 

bei voller Auflösung zeigt. Der Bildbereich oben links entspricht 

einem Bild der Auflösung von 800x600 Pixel. Daher muss bei der 

Berechung der Pixelgröße durch die gesamte Auflösung geteilt werden 

(nicht durch den Ausschnitt): 

Pixelgroesse = Sersorbreite 

Au f loesung = 3.56mm 

1600px 

= 0.002225 

mm 

px 

= 2.225 

µm 

px 20 

Nach der obigen Formel verdoppeln nun sämtliche Tiefenwerte der 

obigen Tabelle. Nun liegen die Werte sehr dicht an der realen Tiefe. 

20 Sensorbreite aus: http://www.aptina.com/assets/downloadDocument.do?id=790 

228


Abbildung 2.96: Testbilder mit rückwärtiger Beleuchtung und BLOB- 

Erkennung 

229


Abbildung 2.97: Fehlerbild mit voller Kameraauflösung 

10. Um den Abstand zweier Schwerpunkte zu berechnen werden von 

zwei Armbinden die Tiefenwerte bestimmt, um im Anschluss die 

Entfernung zwischen diesen Gelenken zu berechnen, siehe Abbildung 

2.98. Dies geschieht unter anderem mit der Formel zur Berechnung 

der realen Breite, siehe Abschnitt 2.6.2.7. Die Tiefenwerte weichen 

kaum von den gemessenen Werten ab: 

Armbinde Messwert Berechneter Wert %-Anteil Messwert 

1 212 cm 214 cm 99% 

2 220 cm 233 cm 95% 

Der Abstandsvektor (x, y, z) T beträgt in cm: (30.7, −0.5, −18.9) T . Daraus 

resultiert der Abstand zwischen den Armbinden in Form des 

Betrags dieses Vektors welcher ca. 36 cm beträgt. Der gemessene Abstand 

beträgt 32 cm, was etwa 90% des berechneten Wertes entspricht. 

Die Breitenwerte basieren dabei auf dem Bild der linken Kamera. Bei 

230


Verwendung des Bildes der rechten Kamera wird ein Abstand von 

36.7 cm, also eine Abweichung von 1.8% berechnet. 

Abbildung 2.98: Abstandsmessung bei zwei Armbinden 

2.6.2.5 Probleme in der Testphase 

Beim Testen der Aufnahme und Erkennung der Armbinden ergaben sich 

folgende Probleme: 

• Um die grüne Armbinde zu erkennen wurden drei Morphologiefilter 

mit insgesamt zwei mal Dilatation, drei mal Erosion und neun mal 

231


Dilatation benötigt, siehe Abbildung 2.89. Für die spätere Umsetzung 

auf dem FPGA müsste das Bild nach jeder Iteration der Filtern zwischengespeichert 

werden. Dazu werden ca. 210 Kilobyte benötigt. Da 

der Bildspeicher (ImageCache) Daten direkt auf dem FPGA speichert, 

kann dies zu einem Platzproblem führen. 

• Die Lichtwerte der zwei Kameras sind bei gleicher Szene unterschiedlich, 

was die Konfiguration der Filter für beide Kameras erschwert. Um 

überhaupt eine funktionierende Tiefenerkennung durchführen zu können 

wird eine äußerst gleichmäßige Beleuchtung benötigt. Während 

der Aufnahmen zu den verschiedenen Testläufen hat sich dieser Punkt 

als eine Hauptproblemquelle herausgestellt. 

• Zur Winkelberechnung wird die reale Breite einer Armbinde benötigt, 

welche in Abhängigkeit vom Abstand zu der Kamera jedoch eine unterschiedliche 

Pixelgröße aufweist. Daher muss eine Umrechnung gefunden 

werden, die aus der Tiefe und der Pixelbreite die reale Breite 

in Zentimeter berechnet. 

2.6.2.6 Vergleich mit OpenCV 

Zur Überprüfung der Tiefeninformation werden die aufgenommenden Bilder 

mit einem auf OpenCV basierenden Algorithmus getestet. 21 Der Algorithmus 

berechnet aus zwei Stereobildern eine Tiefenkarte. 

21 https://sites.google.com/site/elsamuko/c-cpp/opencv-depthmap 

232


Abbildung 2.99: Beispielstereobild. 22 

Abbildung 2.100: Beispieltiefenbild zu Abbildung 2.99. 23 

22 Quelle: http://farm4.static.flickr.com/3435/3875966714_b80886eac7.jpg 

23 Quelle: https://ae346056-a-62cb3a1a-s-sites.googlegroups.com/site/elsamuko/ 

c-cpp/opencv-depthmap/depth_fruit.jpg 

233


Selbiger Algorithmus wird auf selbst aufgenommene Bilder der Armbinden 

angewendet. Um die Drehung als potentielle Fehlerquelle auszuschließen, 

werden beide um wenige Grad (links um 1 ◦ , rechts um ca. 2 ◦ ) gedreht bzw. 

einander angeglichen. 

Abbildung 2.101: Tiefenbild zu Abbildung 2.90 

2.6.2.7 Problemlösungen 

Drehung Da die Drehung nicht die Berechnung des Schwerpunktes und 

Tiefenwertes beeinflusst, siehe Abschnitt 2.6.2.4, kann diese für die 

weitere Betrachtung ignoriert werden. 

Verarbeitungskette Für die Erkennung von roten Armbinden bei guten 

Lichtverhätnissen reicht eine BLOB-Erkennung mit Schwellwertfilter 

aus. Als gute Lichtverhältnise wird eine sehr helle Tageslicheinstrahlung 

an einem sonnigen Tag betrachtet. Dabei sollte die Stereokamera 

so ausgerichtet sein, dass sich die Lichtquelle möglichst genau 

hinter der ihr befindet. 

Reale Breite Die Formel zur Umrechnung zwischen relativer Pixelbreite 

und realer Breite lautet: 

Breite real = Breite Pixel · Breite au f Sensor · 

Tie f e 

Brennweite 

Diese Formel geht aus folgender Abbildung 2.102 hervor: 

(2.15) 

234


Abbildung 2.102: Aufnahme eines Bildes durch eine der beiden Kameras. 

Verhältnis von Breite auf dem Sensor zur Brennweite verhält 

sich wie das Verhältnis der realen Breite zur realen 

Tiefe im Raum. 

2.6.2.8 Implementierung 

Folgende Dateien sind bei der Implementierung entstanden: 

os-toolbox/projects/Tiefenerkennung/opencv/opencv-depthmap.cpp 

Externes C++-Testprogramm welches aus zwei Stereobildern eine Tiefenkarte 

erzeugt. 24 

os-toolbox/projects/Tiefenerkennung/3d/main.py Dieses Pythonskript 

startet die Olvis-Bildverarbeitungskette und übergibt diese an die neu 

erzeugte Stereoskopie und die Winkelberechnung. Anschließend werden 

die Schwerpunkte von den BLOB der beiden Kameras gespeichert, 

sortiert und der jeweilige Tiefenwert berechnet. Aus den entstandenen 

3D-Vektoren werden schließlich die Winkel im Raum berechnet 

und an die Ansteuerung des Roboterarms weitergeleitet. 

os-toolbox/projects/Tiefenerkennung/3d/Stereoscopy.py Diese Datei 

beinhaltet Algorithmen zur Tiefenberechnung und berechnet 3D-Vektoren 

der Schwerpunkte der Armbinden. 

os-toolbox/projects/Tiefenerkennung/3d/Stereoscopy.ogr XML-Datei, 

welche zur Konfiguration der OFFIS-Automation-Toolbox dient. In 

dieser Datei ist die Bildverarbeitungskette gespeicht. 

24 Quelle: https://sites.google.com/site/elsamuko/c-cpp/opencv-depthmap 

235


os-toolbox/projects/Tiefenerkennung/3d/Stereoscopy.oap Versionierungsdatei, 

welche der Projektdatei zugehörig ist. 

os-toolbox/projects/Tiefenerkennung/3d/AngleCalculation.py Diese Datei 

beinhaltet Funktionen zur Winkelberechnung. Die Schwerpunkte werden 

sortiert, in Dreiecken zusammengefasst und die Winkel berechnet. 

Stereoscopy 

Die Klasse Stereoscopy beinhaltet folgende Funktionen: 

def __init__ ( self , olvis ): 

Initialisierung globaler (innerhalb des Programmkontextes allgemeingültiger) 

Variablen, z.B. der globalen Kamerakonstanten. 

def calcHypothenuse ( self , pixelX , pixelY ): 

Berechnung der Hypothenuse mit Hilfe des Satzes des Pythagoras, welche 

zwei 2D-Vektoren zu einem Dreieck ergänzt. 

def calcDepthPoint ( self , left , right ): 

Berechnet die Tiefe eines Punktes anhand der stereoskopischen Tiefenformel. 

def getAllDepths ( self , cogListLeft , cogListRight ): 

Berechnet iterativ die Tiefe aller Schwerpunkte anhander der Funktion 

getAllDepths. 

def calcCogVectors ( self , coglist , depthlist ): 

Berechnet anhand einer gegebenen Tiefenliste eine 3D-Vektor aller Schwerpunkte 

in Millimeter. Dabei werden die Pixelangaben für die Höhe und 

Breite anhand der Tiefeninformation in Millimeter umgerechnet. 

def getPixelSize ( self ): 

Gibt die gespeicherte Konstante Pixelgröße (Sensorgröße geteilt druch die 

maximale Auflösung) zurück. 

def getFocallength ( self ): 

Gibt die Brennweite, welche durch eine Konstante repräsentiert wird, der 

Stereokamera zurück. 

236


Winkelberechnung 

Die Klasse Winkelberechnung beinhaltet folgende Funktionen: 

def __init__ ( self , olvis ): 

Initialisierung globaler (innerhalb des Programmkontextes allgemeingültiger) 

Variablen. 

def sortPoints ( self , cogList ): 

Sortierung der Listen der Schwerpunkte der Armbinden in X-Richtung. 

def getSortedPose2DList ( self , cogList ): 

Verfolgung der Schwerpunkte anhand der minimalen Distanz zum Schwerpunkt 

des letzten Bildes. 

def calcAngles ( self , depth ): 

Trigonometrische Berechnung der Winkel anhand von 3D-Vektoren. 

def convert ( self , angles ): 

Wenn mindestens drei Winkel berechnet wurden, also alle Winkel des Roboterarms 

vorhanden sind (der Drehwinkel darf fehlen), dann werden die berechneten 

Winkel auf die Servomotoren umgerechnet. Dies betrifft den letzten 

und vorletzten Winkel. Prüfe schließlich die Winkel anhand von minimalen 

und maximalen Werten. 

def calcAngleFromTriangle ( self , side ): 

Berechnung eines Winkels anhand eines Dreiecks, mit Hilfe des Cosinissatzes. 

def scalarProduct ( self , v1 , v2 ): 

Berechnung des Skalarproduktes zweier Vektoren. 

def crossProduct ( self , v1 , v2 ): 

Berechnung des Kreuzproduktes anhand zweier Vektoren. 

def deriveHyperPlaneNormalForm ( self , linkPosition , a , b 

): 

237


Berechnet eine Ebene im Raum und gibt diese in der Normalform zurück. 

def decideSide ( self , plane , x): 

Berechnet auf welcher Seite der Ebene der jeweilige Punkt x liegt. Diese 

Funktion ist notwendig, um zu sicherzustellen, dass alle Winkel von der 

selben Drehrichtung aus bestimmt werden. Ohne diese Funktion würde 

immer der kleinere Winkel (unter 180 Grad) berechnet werden. Ein Winkel 

über 180 Grad, der am Arm anliegt würde also seine Größe ändern (360 

Grad minus dem Winkel). Dies wird durch oben aufgeführte Funktionen 

verhindert bzw. herausgerechnet. 

238


2.6.3 Echtzeitbildausgabe auf HDMI 

Das Arbeitspaket gliedert sich in drei Teilziele. Im ersten Schritt wurde daher 

ein hdmi_out IP-Core 25 in das Projekt integriert, welcher ein im RAM 

abgelegtes 2D-Bild mit definierter Auflösung über den HDMI-Port ausgibt. 

Daraufhin wurde der image_bus_switch IP-Core und dessen Treiber 

dahingehend erweitert, dass nun ein Umschalten zwischen den Kameras 

über den Center-Button auf dem Board möglich ist. Um abgelegte Bilddaten 

aus dem RAM zu lesen und an den USB-Treiber weiterzuleiten wurde 

ein memory_to_usb IP-Core geschrieben, sodass eine Ausgabe des Bildes 

mit Hilfe der OFFIS Toolbox ermöglicht wird. 

image_bus_to_memory_v1_00_a 

Dieser in Abbildung 2.103 dargestellte 

IP-Core dient dem Schreiben von Daten eines image_bus IP-Cores in den 

RAM. Hierbei werden 8/16/24 Bit breite Daten von einem image_bus gelesen 

und im Format RGB565 im RAM abgelegt. Dazu wird das VFBC Interface 

des MPMC IP-Cores genutzt 26 . 


pixel_clk 

IMAGE_BUS 

image_bus_to_memory 

VFBC 

Abbildung 2.103: Blockschaltbild des imagebus_to_memory IP-Core 

Beschreibung 

Tabelle 2.6 zeigt alle Parameter, welche nach Hinzufügen des IP-Core zum 

Design zur Konfiguration des VFBC-Moduls angegeben werden können. 

Diese entscheiden in welchem Speicherbereich ein Bild entsprechender Auflösung 

abgelegt wird. 

Die implementierte Befehlsabfolge um ein Bild über den VFBC anzufordern 

basiert auf dem in Abbildung 2.104 dargestellten Zeitverhalten. 

25 Dokumentiert in Abschnitt 2.4.3.1 

26 siehe Sprint 3, Arbeitspaket HDMI-Analyse: 2.4.3.2 

239


GENERIC default 

FRAME_BASE_ADDR 0x00000000 

LINE_STRIDE 0x0000800 

IMAGE_WIDTH 0x0500 

IMAGE_HEIGHT 0x02D0 

IMAGE_BUS_WIDTH 16 

Tabelle 2.6: Parameter für eine Auflösung von 1280x720 im Speicherbereich 

0x00000000. 

Abbildung 2.104: VFBC Write Timing 

Quelle: MPMC Dokument V6.06 

Im write_stream Prozess wird die Write-FIFO des VFBC mit den entsprechenden 

Eingangsdaten des ImageBusses gefüllt. Trifft ein valides Pixel ein, 

wird der vorhandene Wert wie im folgenden Quelltextauszug zu sehen auf 

write_data gelegt. 

1 −− write data when incoming p i x e l i s valid 

2 w r i t e _ v a l i d


Probleme 

Der wd_reset Befehl leert nicht, wie in der Dokumentation des MPMC 27 

angegeben, die Write-FIFO und den Write-Befehl aus der Command-FIFO 

des VFBC. Um dies zu erreichen müssen zusätzlich der wd_flush und 

cmd_reset Befehl angelegt werden. 

Dateistruktur 

• pcores/image_bus_to_memory_v1_00_a/: ImageBusToMemory IP-Cores. 

• hdl/vhdl/image_bus_to_memory.vhd: Enthält den implementierten 

IPCore 

• hdl/vhdl/tb/test.vhd: Enthält die Testbench 

• devl/ImageBus2Memory/ImageBus2Memory.xise: ISE Projektdatei 

• data/image_bus_to_memory_v2_1_0.mpd: Enthält das PORT-Mapping 

• data/image_bus_to_memory_v2_1_0.pao: Enthält eingebundenen Bibliotheken 

image_bus_switch_v1_00_a 

Um ein Umschalten zwischen den Kameras 

ohne PC zu ermöglichen, wurde das Design um einen Hardware- 

Schalter erweitert. Dazu wurde dem Projekt ein Push_Buttons_5Bits IP- 

Core aus der Xilinx Bibliothek hinzugefügt, welcher dem Microblaze über 

eine Interruptleitung einen Tastendruck signalisiert. Um einen Tastendruck 

auszuwerten wurde der Treiber des image_bus_switch IP-Core erweitert. 

Mit Hilfe einer Maske wird der den Interrupt auslösende Button erkannt 

und die Kamera gewechselt. Dabei muss darauf geachtet werden, dass 

mehr als ein Interrupt gesendet wird, da die Taster hardwareseitig nicht 

entprellt sind. 

Weiterhin wurde der image_bus_switch IP-Core auf eine in Abbildung 

2.105 dargestellte State-Machine umgestellt, um einen Kamerawechsel zu 

garantieren, welcher nur bei vollständigen Bildern stattfindet. 

Ein Wechsel der Kameras erfolgt somit nur noch nach auf Basis des jeweiligen 

frame_valid Signals. 

27 Vergleich Dokumentation des MPMC 6.06 auf Seite 179 

241


switch 

Leave A 

frame_valid 

A low 

Enter B 

frame_valid 

B low 

Cam A 

Cam B 

frame_valid 

A low 

Enter A 

frame_valid 

B low 

Leave B 

switch 

Abbildung 2.105: Zustandsautomat des image_bus_switch IP-Cores 

Dateistruktur 

• pcores/image_bus_switch_v1_00_a: ImageBusSwitch IP-Core. 

• /hdl/vhdl/image_bus_switch.vhd: Äußeres Modul vom image_bus_switch 

IP-Core. Automatisch generiert vom Xilinx Peripheral Wizard. 

• /hdl/vhdl/user_logic.vhd: User Logic Modul vom image_bus_switch 


• /vhdl/switch.vhd: Hauptmodul vom ImageBusSwitch IP-Core. Diese 

Datei stellt die eigentliche Funktionalität zur Verfügung. 

• /hdl/vhdl/sim/sim.vhd: Enthält die Testbench 

• /devl/projnav/image_bus_switch.xise: ISE Projektdatei 

• /data/image_bus_switch_v2_1_0.mpd: Enthält das PORT-Mapping 

• /data/image_bus_switch_v2_1_0.mpd: Enthält eingebundene libs 

• pcores/drivers/image_bus_switch_v1_00_a: image_bus_switch Treiber 

• /src/image_bus_switch.cpp: C++ Datei mit der Implementation des 

Treibers. 

• /src/image_bus_switch.h: C++ Header Datei des Treibers. 

memory_to_usb_v1_00_a Der memory_to_usb IP-Core liest ein 2D- 

Bild aus einem RAM und reicht es an einen usb_driver IP-Core 28 weiter. 

28 Siehe Abschnitt 2.2.2 

242


Dies ermöglicht eine Ausgabe des im Speicher vorhandenen Bildes mit 

Hilfe der OFFIS Toolbox und dem VmodCam Plugin 29 . Der folgende Abschnitt 

beschreibt den finalen IP-Core des Arbeitspakets. 


Der IP-Core stellt Eingänge für die Leseoperationen über einen VFBC sowie 

ein Signal über den Zustand der usb_driver IP-Core FIFO zur Verfügung. 

Um den IP-Core mit dem VmodCam Plugin zu synchronisieren, ist eine 

Anbindung an den PLB nötig. Die Ausgänge dienen dem Senden der Bilddaten 

an den usb_driver IP-Core. 

Zur Konfiguration des VFBC-Moduls können beim Hinzufügen des IP- 

Core die nötigen Parameter gesetzt werden. 

pixel_clk 

direct_wrAlmostFull 

PLB 

VFBC 

memory_to_usb 

direct_wrClk 

direct_wrReq 

direct_wrData[31:0] 

Abbildung 2.106: Blockschaltbild des memory_to_usb IP-Core 

Beschreibung 

Die Logik des IP-Core setzt sich im Wesentlichen aus einem data_decode 

Prozess sowie einem ungetakteten VFBC_RD_READ Signal zum VFBC 

zusammen. Dieser Aufbau wurde gewählt, um rechtzeitig auf eine volle FI- 

FO des usb_driver IP-Cores reagieren zu können und zusätzliche Verzögerungen 

zu vermeiden. Der Folgende Quelltextauszug zeigt die Implementierung 

des VFBC_RD_READ Signals. 

1 −− read data i f USB FIFO i s not almost f u l l ( and only i f VFBC i s 

not in setup stage ) 

2 VFBC_RD_READ


Der data_decode Prozess setzt im ersten Schritt, wie bereits im hdmi_out 

IP-Core 30 , die nötigen Befehle für den VFBC auf, um ein Bild aus dem 

RAM zu lesen. Das zu verwendende Zeitverhalten zum Ansprechen des 

VFBC für eine Leseoperation wurde dem MPMC Dokument entnommen 

und ist in Abbildung 2.107 dargestellt. 

Abbildung 2.107: VFBC Read Timing 

Quelle: MPMC Dokument V6.06 

Daraufhin kann auf Anforderung des VmodCam Plugins ein Bild ausgelesen 

und an den usb_driver IP-Core weitergeleitet werden. Nach jedem 

übertragenem Bild wird auf eine erneute Anforderung, in Form eines 

definierten Registerwerts, seitens des Plugins gewartet. Gearbeitet wird 

dabei mit einem Zähler, der sich aus der zu lesenden Bildgröße berechnet. 

Bei einem Lesevorgang wird in jedem Takt ein Bildpixel vom VFBC 

angefordert und mit einem Takt Verzögerung in die usb_driver IP-Core FI- 

FO geschrieben. Da Daten wesentlich langsamer in die usb_driver IP-Core 

FIFO geschrieben, als aus dem RAM gelesen werden können, wird der Lesevorgang 

pausiert, sobald die FIFO des usb_driver IP-Cores vollständig 

gefüllt ist. 

Abbildung 2.108 veranschaulicht die Zusammenhänge zwischen dem ungetakteten 

RD_READ an den VFBC und dem direct_wr Signal zum Anlegen 

der gelesenen Daten an die FIFO des usb_driver IP-Cores. 

Unter Benutzunng des entwickelten IP-Cores wurde die Unterstützung folgender 

Auflösungen mit entsprechenden Bildwiederholraten verifiziert 31 : 

ca. 6 fps bei 1280x720 sowie ca. 3 fps bei 1600x1200. 

Treiber 

Die Implementierung des memory_to_usb Treibers konnte vom CAM_USB 

30 Beschrieben in Sprint 3, Arbeitspaket HDMI Analyse: 2.4.3.1 

31 entnommen aus den Bildinformationen der OFFIS Toolbox 

244


Clk 

cmd_idle 

direct_wrAlmostFull 

VFBC_RD_READ 

direct_wrReq 

Abbildung 2.108: Timing der Lese-/Schreiboperationen 

IP-Core v_2_00 32 übernommen werden. Damit kann zum Einen sichergestellt 

werden, dass die FIFO initial vom VModCam Plugin geleert werden kann 

und zum Anderen neue Bilder auf Anforderung des Plugins in die USB 

FIFO geschrieben werden. 

Probleme 

Vor der Realisierung des finalen IP-Cores wurde ein weiterer Ansatz verfolgt. 

Der IP-Core basierte dabei auf dem in Abbildung 2.109 dargestellten 

Zustandsautomat. Dieser Ansatz erwies sich jedoch als unnötig komplex 

zur Lösung der gestellten Aufgabe. Weiterhin ergaben sich zahlreiche 

Probleme aufgrund der eingebrachten Verzögerungen des Systems, welche 

durch die zeitliche Abstimmung der Lese-Operationen am VFBC sowie der 

Schreib- und Warte-Operationen am USB-Treiber entstanden. Aufgrund 

dessen wurde ein weiterer Ansatz erstellt, der den im vorherigen Abschnitt 

vorgestellten IP-Core als Endprodukt des Arbeitspakets liefert. 

Im Zuge dieser Umstellung erwies sich auch ein memory_to_imagebus IP- 

Core als nicht sinnvoll, da die Bilder nicht ohne Weiteres verifiziert werden 

können. Dies liegt an der eingeschränkten Anzahl von Schnittstellen, die 

der MPMC bereitstellt. Bei vier bereitgestellten Schnittstellen wird eines für 

den PLB, eines zum Schreiben in den RAM und eines zum Auslesen des 

RAMs benötigt. Die verbleibende Schnittstelle reicht nicht aus, um Daten 

des ImageBusses zu verifizieren. Daher fiel die Entscheidung auf einen IP- 

Core, welcher Bilder aus dem RAM direkt an den USB Treiber weiterleitet. 

Um Fehler leichter zu finden, wurde in einem ersten Schritt ein bestimmtes 

Testbild gesendet, in dem nur das erste Pixel Weiß ist und alle anderen 

32 Dokumentiert in Kapitel 2.2.2 

245


write 

CMDs 

cmds done 

& 

usb Packet done 

frame done 

read 

frame 

usb FIFO not full 

line done 

read 

line 

usb FIFO full 

suspend 

line 

usb FIFO full 

usb FIFO not full 

Abbildung 2.109: Zustandsautomat zum ersten Ansatz des IPCores 

Schwarz. Dies ist losgelöst vom VFBC und ermöglicht zuerst Fehler im 

Quelltext zu finden, ohne das potentiell das Protokoll des VFBC falsch 

genutzt wird. So ist bewusst, ob Zähler und Verzögerungen passen, bevor 

man mit den Daten aus dem RAM arbeitet. Im Anschluss wurde dann der 

VFBC angeschlossen und das Protokoll stetig angepasst, da viele ungenaue 

oder auch falsche Angaben zum VFBC im MPMC Dokument stehen. 

• Nach dem Lesen eines Bildes aus dem RAM muss ein länger als 

angegebenes Reset der Cmd und Read FIFOs durchgeführt werden 

(min. 3 Takte). 

• Um stabile Bilder aus dem RAM lesen zu können, müssen nach Schreiben 

der Befehle wesentlich mehr (aktuell 245) Takte gewartet werden, bis 

das erste Pixel gelesen werden kann, anders als in der Dokumentation 

angegeben. 

Dateistruktur 

• pcores/memory_to_usb_v1_00: Memory to USB IP-Core. 

• /hdl/vhdl/mem_to_usb.vhd: Enthält den implementierten IP-Core 

• /hdl/vhdl/memory_to_usb.vhd: Äußeres Modul vom memory_to_usb 


246


• /hdl/vhdl/user_logic.vhd: User Logic Modul vom memory_to_usb IP- 

Core. Automatisch generiert vom Xilinx Peripheral Wizard. 

• /hdl/vhdl/sim/tb.vhd: Enthält die Testbench 

• /data/memory_to_usb_v2_1_0.mpd: Enthält das PORT-Mapping 

• /data/memory_to_usb_v2_1_0.pao: Enthält eingebundene libs 

247


2.6.4 Hardware Umsetzung der Bewegungserkennung 

Im Sprint 2 wurde eine Bildverarbeitungskette entworfen und mittels Software 

umgesetzt. Dieses Arbeitspaket beinhaltet die Umsetzung der Algorithmen, 

die während des Sprints in dem Arbeitspaket Objektverfolgung 

erarbeitet wurden. Für die Objektverfolgung wurden Bildverarbeitungsfilter 

in der OFFIS-Automation-Toolbox benutzt, sowie ein Verarbeitungsalgorithmus 

in Python entwickelt. 

Die Bildverarbeitungskette wird von uns aus mehreren hintereinander geschalteten 

IP-Cores realisiert, die bereits in vorherigen Sprints realisiert wurden. 

Die mit der Programmiersprache Python umgesetzte Verfolgung des Arms 

anhand der roten Binden wird in die Sprache C++ übersetzt, damit das 

ausführen des Algorithmus auf dem Microblaze möglich ist. 

Das Ergebnis der Objekterkennung auf dem FPGA soll in der OFFIS-Automation- 

Toolbox dargestellt werden. Dafür soll sowohl das Kamerabild als auch die 

Gelenke in der OFFIS-Automation-Toolbox sichtbar sein. 

2.6.4.1 Umsetzung der Bildverarbeitungskette auf dem FPGA 

Aufbauend auf das Arbeitspaket Ansteuerung der VmodCam von Digilent 

aus dem Abschnitt 2.2.2 wird die Bildverarbeitungskette mit der Vmod- 

Cam realisiert. Die Bildverarbeitungskette aus dem Abschnitt 2.2.4 Objektverfolgung, 

dargestellt in Abbildung 2.47 wurde von uns wie in Abbildung 

?? dargestellt umgesetzt. 

simple_i2c 


VmodCam 

schwellwertfilter 

blob_detection 

cam_data 


busConverterToRGB888 

rgb2grey 


cam_usb 

usb_driver 

VmodCam 

Abbildung 2.110: Auf dem FPGA realisierte Bildverarbeitungskette mit IP- 

Cores 

Es ist zu erwähnen, das die in der Softwarelösung benutzen Morphologiefilteroperationen 

hier nicht zum Einsatz kamen, da diese noch nicht 

248


vollständig als IP-Cores umgesetzt wurden. In den weiteren Versuchen hat 

sich gezeigt, das auch ohne diese Filter ein Ergebnis möglich ist. 

Die in Programmiersprache Python umgesetzte Verfolgung der Armgelenke 

und Berechnung der Winkel zwischen den Armgelenken wurde von 

uns in die Programmiersprache C++ übersetzt. Dafür wurde eine Klasse 

namens ArmDetection eingerichtet, welche die Algorithmen bereitstellt 

Die Gelenke werden initial von oben nach unten im Bild zugeordnet, so 

dass initial davon ausgegangen wird, das der Arm des Benutzers nach 

oben ausgerichtet im Bild vollständig zu sehen ist. Zwischen zwei aufgezeichneten 

Bildern werden die Abstände unter allen Punkten gebildet um 

daraus schließen zu können, welches Gelenk sich wohin im Bild bewegt 

hat. Die Zuordnung der Gelenk ist entscheidend für die Berechnung der 

Winkel zwischen den Armgelenken. 

α 

β 

Schultergelenk 

Handgelenk 

Ellenbogengelenk 

Abbildung 2.111: Schematische Darstellung des aufgezeichneten Arms 

und der berechneten Winkel 

Die Abbildung ?? zeigt die Punkte die zu ermitteln sind, sowie die zu 

berechnenden Winkel α und β. Die Winkel können dann im Weiteren benutzt 

werden um den Roboterarm zu steuern. 

Die Darstellung der Position der ermittelten Punkte zusammen mit dem 

Kamerabild erfolgt in der OFFIS-Automation-Toolbox mittels einer von 

uns erstellten Erweiterung VmodCamBlob. Diese Erweiterung empfängt 

die Kamerabilder und zusätzlich die vom FPGA gesendeten Positionen der 

Gelenke, die von der Bildverarbeitungskette ermittelt wurden. Das Ergebnis 

ist in Abbildung ?? dargestellt. 

Im weiteren werden die Komponenten näher beschrieben, die für die Umsetzung 

erstellt oder angepasst wurden. Es wird zu erst auf die IP-Cores 

249


Abbildung 2.112: Ergebnisaufnahme mit der VmodCamBlob Erweiterung 

für die OFFIS-Automation-Toolbox 

eingegangen die für die Bildverarbeitungskette benutzt wurden. Anschließend 

wird die Armerkennung vorgestellt und folgend die visuelle Darstellung 

mittels der OFFIS-Automation-Toolbox. 

2.6.4.2 Anpassung des Schwellwertlter IP-Core 

Der im vorherigen Sprint im Arbeitspaket Filter-Cores erstellte Schwellwertfilter 

wird von uns um Funktionalität erweitert. Für unseren Einsatz ist 

es nötig den Schwellwert dynamisch zu verändern, was eine Anbindung an 

den Microblaze des FPGA nötig macht. Dadurch wird es möglich mittels 

eines von uns geschriebenen Softwaretreibers den Schwellwert über den 

PLB zu setzen. Eine schematische Darstellung des überarbeiteten IP-Cores 

findet sich in Abbildung ?? 

PLB 

pixel_clock 

framevalid_in 

linevalid_in 

datavalid_in 

data_in [mode] 


v2_00_a 

framevalid_out 

linevalid_out 

datavalid_out 


Abbildung 2.113: Schwellwertfilter mit Anbindung an den Microblaze 

Die entwickelte Treiberklasse Schwellwertfilter besitzt zwei Methoden, welche 

250


die wesentlichen Aufgaben übernehmen. Das Setzen des Schwellwertes erfolgt 

über die Funktion “set“. 

bool set ( Xuint8 schwelle ); 

Der Schwellwert wird als Wert in der Treiberklasse gespeichert und kann 

bei Bedarf über die Funktion “get“ abgefragt werden. 

int get ( void ); 

Dateistruktur 

• ipcores/pcores/schwellwertfilter_v2_00_a/hdl/vhdl/schwellwert.vhd: 

Hardwarebeschreibung des Buskonvertierers 

• ipcores/pcores/schwellwertfilter_v2_00_a/hdl/vhdl/... 

schwellwertfilter.vhd: Äußeres Modul vom Schwellwertfilter IP-Core. 

Automatisch generiert vom Xilinx Peripheral Wizard. 

• ipcores/pcores/schwellwertfilter_v2_00_a/hdl/vhdl/user_logic.vhd: 

User Logic Modul vom Schwellwertfilter IP-Core. Automatisch generiert 

vom Xilinx Peripheral Wizard. Enthält die Logik für das PLB Register. 

2.6.4.3 IP-Core ImageBusConverter 

Im Laufe des Aufbaus der Bildverarbeitungskette auf dem FPGA wurde 

schnell klar, das ein zusätzlicher IP-Core von benötigt wird. Dieser soll die 

Fähigkeit besitzen aus verschiedenen Eingangssignalen ein 24 Bit RGB Signal 

zu generieren. Als mögliche Eingangssignalformate sollen 1 Bit Schwarzweiß, 

8 Bit Grau und 16 Bit RGB 565 in ein 24 Bit RGB kompatibles Bildformat 

gebracht werden. 

Dieser IP-Core wird nötig, da der IP-Core welcher die Daten an den PC 

mittels USB überträgt ausschließlich Bildströme im 24 Bit RGB Format annimmt. 

Um jedoch das Bild visualisieren zu können, das von dem Schwellwertfilter 

erzeugt wurde, ist eine Konvertierung nötig. Dieser IP-Core stellt 

eine Erweiterung zu dem aus Sprint 2 bekannten IP-Core 

cam_rgb565_to_rgb888 dar. 

Das Eingangs- und Ausgangssignal sind Imagebus-Signale, welche die üblichen 

Signale Framevalid,Linevalid, Datavalid und die Bilddaten selbst data besitzen. 

Die Datenbreite des Eingangssignals wird durch einen Generic festgelegt. 

Ein Generic ist ein einstellbarer Parameter der bei erstmaliger Nutzung 

251


pixel_clock 

framevalid_in 

linevalid_in 

datavalid_in 



v1_00_a 


linevalid_out 

datavalid_out 


Abbildung 2.114: IP-Core ImageBusConverter mit 24 Bit RGB Ausgangssignal 

des IP-Cores gesetzt werden muss und damit angibt, welches Eingangssignal 

in das 24-Bit breite Ausgangssignal gewandelt wird. 

In der Abbildung ?? ist die zusätzliche Funktionalität des IP-Core dargestellt, 

die im Vergleich zum cam_rgb565_to_rgb888 IP-Core dazu gekommen ist. 

1 Bit Schwarzweiß 

Schwarzweiß Modus: 

S/W 

S/W S/W S/W S/W 



8Bit Rot 

8Bit Grün 

8Bit Blau 

8 Bit Grau 

Grau Modus: 

G7 

G6 

G5 

G4 

G3 

G2 

G1 

G0 

G7 G6 G1 G0 

G7 G6 G1 G0 

G7 G6 G1 G0 

8Bit Rot 

8Bit Grün 

8Bit Blau 

Abbildung 2.115: IP-Core ImageBusConverter Signalkonvertierung 

Dateistruktur 

• ipcores/pcores/busConverterToRGB888_v1_00_a/hdl/vhdl/... 

busConverterToRGB888.vhd: Hardwarebeschreibung des Buskonvertierers 

252


• ipcores/pcores/busConverterToRGB888_v1_00_a/devl/... 

busConverterToRGB888/busConverterToRGB888_tb.vhd: Definierte 

Testumgebung für den Buskonvertierer 

2.6.4.4 IP-Core Erkennung von Regionen in Bildern 

Für die Erkennung von Flächen beziehungsweise Regionen in Bildern wurde 

der Projektgruppe ein IP-Core inklusive Treiber bereitgestellte, der aus der 

Projektgruppe yaDAS “FPGA-basiertes Echtzeit-Kamerasystem für Fahrerassistenz“ 

hervorgegangen ist. Dieser IP-Core ordnet Bildpunkte einer bestimmten 

Region zu, so dass zusammengehörige Flächen ausgegeben und 

weiterverarbeitet werden können. Die Funktionsweise, Aufbau sowie die 

Ansteuerung ist in der Projektgruppenarbeit zu finden [20]. 

Abbildung 2.116: Erkannte Regionen in einem Bild mit ihren eingezeichneten 

Schwerpunkten 

Der Bereitgestellte IP-Core wertet das Bild nach dem Schwellwertfilter aus 

und liefert zu jeder gefunden Region Informationen. Die für uns Wichtigen 

ermöglichen uns, die mittleren Schwerpunkt zu bestimmen, so dass 

diese in einem Bild zugeordnet werden können. In Abbildung ?? ist das 

Bild nach dem Schwellwertfilter dargestellt inklusive der Schwerpunkte 

der einzelnen Regionen. 

253


2.6.4.5 Armerkennung und Verfolgungstreiber 

Die Armerkennung und Verfolgung der Armgelenke basiert auf Erkennung 

von roten Flächen in einem Bild. Die Erkennung erfolgt mit dem in 

Abschnitt 2.6.4.4 erwähnten IP-Core. Die von uns entwickelte Klasse stellt 

eine zusätzliche Abstraktionsschicht bereit. 

Das Zuordnen und Verfolgen der Armgelenke erfolgt ähnlich den vorherigen 

Sprints. Es musste jedoch bei der Umsetzung berücksichtigt werden 

das einige Informationen, die genutzt wurden auf unserer Plattform nicht 

zur Verfügung standen. Resultierend daraus haben wir uns auf drei Rote 

Armbinden beschränkt, statt der fünf. Diese wurden direkt über den jeweiligen 

drei Gelenke positioniert. 

Vorstellung des Armerkennungstreibers 

Für die Verfolgung und Berechnung 

der Position sowie Winkel des Arms wurden folgende Methoden 

angelegt, die im Einzelnen vorgestellt werden. 

ArmDetection ( u32 baseAddress ); 

Der Konstruktor dieser Klasse muss die Basisadresse des blob_detection_v2_10_a 

IP-Cores übergeben bekommen. Bevor das Objekt benutzt werden kann, 

muss die setup_interrupts Methode in der Hauptfunktion aufgerufen werden. 

void setup_interrupt ( XIntc * interruptController , u8 pin ); 

Mittelpunkte erhalten 

Zuordnung der Punkte 

zu Gelenken 

Reihenfolge sortieren 

Winkel der Armstellung 

berechnen 

für nächsten Vergleich 

speichern 

Abbildung 2.117: Vereinfachter Ablauf der Unterbrechungsroutine 

254


Durch den Aufruf der setup_interrupts Methode wird der Interrupt-Pin 

des blob_detection_v2_10_a IP-Cores mitgeteilt und der Interrupt zugelassen. 

void isr () ; 

Diese Methode wird bei einem Interrupt aufgerufen und liest die erkannten 

Regionen und ihre Parameter aus. Ebenfalls wird das Verfolgen der 

Regionen und die Berechnungen der Winkel veranlasst. Eine vereinfachte 

Darstellung der durchgeführten Operationen ist in Abbildung ?? zu sehen. 

usb_data_arm_blobset_points getCenterOfGravatie () ; 

Diese Funktion gibt die ermittelten Schwerpunkte der Region in der Form 

zurück, so dass sie von dem USB Protokoll direkt übertragen werden können. 

void setMinBlobSize ( u8 size ); 

Der Aufruf dieser Funktion ermöglicht es die minimale Pixelmenge der zu 

sammelnden Regionen zu setzen, damit diese nur die Flächen der Armbinden 

erfasst. 

ArmAngleSet getArmPositionSet () ; 

Durch diese Funktion werden die berechneten Winkel abgefragt, sowie die 

X-Y-Position der Gelenke. 

~ ArmDetection () ; 

Der Dekonstruktor gibt die bereitgestellten Speicherstellen wieder frei. 

Die im weiteren Aufgeführten Methoden stehen nur innerhalb der Klasse 

bereit. 

void calcArmAngelSet ( CenterOfGravity * cog ); 

Diese Funktion berechnet aus drei den gegebenen Gelenkpunkten die jeweiligen 

Winkel. 

void calcTracking ( CenterOfGravity * cogAct , CenterOfGravity 

* cogOld ); 

Durch diese Funktion ist es möglich den neu ausgelesenen drei Mittelpunkten 

den jeweiligen Gelenken zuzuordnen. 

void sortCOG ( CenterOfGravity * cogAct ); 

Es wird von anderen Funktionen erwartet das die Punkte der Gelenke in 

folgender Reihenfolge angelegt sind: 

1. Handgelenk 

255


2. Ellenbogen 

3. Schulter 

Um dies sicherzustellen wird die Funktion sortCOG aufgerufen, nach dem 

den Punkten durch die calcTracking() Funktion die jeweiligen Gelenke zugeordnet 

wurden. 

void saveCOG ( CenterOfGravity * cogAct , CenterOfGravity * 

cogOld , int length ); 

Es werden immer die letzten empfangenen Mittelpunkte der Gelenke gespeichert 

um die Zuordnung der neuen Mittelpunkte zu ermöglichen. 

char getPointToLinePosition ( CenterOfGravity *a , 

CenterOfGravity *b , 

CenterOfGravity *c); 

Um die Position von drei Punkten in Relation zu einander auswerten zu 

können wird diese Funktion aufgerufen. Die Funktion gibt einen negativen 

Wert zurück, wenn sich der Punkt a links von der Linie befindet, welche 

durch die Punkte b und c verläuft, sowie der Punkt a 1 in der Abbildung 

??. Liegt der Punkt a auf der Linie ist der Rückgabe wert 0 und liegt der 

Punkt rechts der Linie wird eine positive Zahl zurück geliefert. 

a 2 

a 1 

a 3 

b 

c 

Abbildung 2.118: Mögliche Lage von drei Punkten zueinander 

Dateistruktur 

• microblazecode/camera/src/armDetection.h: C++ Header Datei der 

Armerkennung und Verfolgung. 

• /microblazecode/camera/src/armDetection.cpp: C++ Implementierung 

der Armerkennung und Verfolgung 

256


2.6.4.6 Übertragung und Darstellung der Armposition mit der 

OFFIS-Automation-Toolbox 

An den PC werden Informationen der Gelenkpositionen mittels USB übertragen 

und dort verarbeitet. Die Verarbeitung erfolgt mit einer Erweiterung 

für die OFFIS-Automation-Toolbox. Als Grundlage für die Erweiterung 

wurde das VmodPlugIn 2.2.2 benutzt und für unsere Aufgabe erweitert. 

Es wurde ein weiterer USB-Nachrichtentyp definiert, der für die Übertragung 

der Gelenkposition zuständig ist. Der Nachrichtentyp wird von uns 

als USB_TYPE_BLOB_ARMSET bezeichnet und beinhaltet folgende Struktur. 

1 int handx ; 

2 int handy ; 

3 int elbowx ; 

4 int elbowy ; 

5 int shoulderx ; 

6 int shouldery ; 

Die X-Y-Positionen der einzelnen Gelenke werden von der Erweiterung 

VmodCamBlob in der OFFIS-Automation-Toolbox dargestellt. Dafür wurde 

ein weiterer Ausgang definiert, der eine Liste von 2D-Punkten übergeben 

bekommt, welche über das empfangende Kamerabild gelegt werden. In 

der nächsten Abbildung ?? ist das Resultat des Schwellwertfilters zu sehen, 

über das die Gelenkpositionen, im Bild die grünen Punkte, gelegt wurden. 

Abbildung 2.119: Visualisierung der Gelenkpositionen durch die Vmod- 

CamBlob Erweiterung 

257


Dateistruktur 

• offis-toolbox/plugins/usb_message_type.h: 

Enthält die USB-Nachrichtentypen 

• offis-toolbox/plugins/vision/VmodCamBlob/src/VmodCamBlob.h: C++ 

Header Datei der Erweiterung. 

• offis-toolbox/plugins/vision/VmodCamBlob/src/VmodCamBlob.cpp: 

C++ Datei mit der Implementation der Erweiterung. 

2.6.4.7 Schwierigkeiten 

Für dieses Arbeitspaket stellte sich besonders die Abhängigkeit zu bereits 

erstellten IP-Cores als Schwierigkeit heraus. Der Morphologiefilter war 

noch nicht auf der eigentlichen Zielplattform getestet worden. Es stellte 

sich heraus das dieser nicht benutzbar ist. Zusätzlich stellte die Regionserkennung, 

für Bilder mit Auflösungen die größer als 800x600 Pixel sind, 

ein Problem dar. Diese Hardwarekomponente wurde noch nicht für den 

Einsatz auf Bilder dieser Größe vorbereitet. 

2.6.4.8 Fazit 

Eine Armerkennung ist Teilweise auf dem FPGA umgesetzt worden. Allerdings 

fehlt noch die Bestimmung der Ausrichtung von der Hand um den 

Winkel für das Handgelenk zu bestimmen. Dies ist mit der drei Bindentechnik 

in der Form aktuell nicht möglich. Es muss dafür folglich noch ein 

stabiles Konzept erarbeitet werden um diese Informationen zu bestimmen. 

Die bereits errechneten Winkel lassen sich nun auf den Roboterarm übertragen 

und damit ist eine vom PC unabhängige Steuerung möglich. 

Diese Erkennung des menschlichen Arms ist aktuell auf den zweidimensionalen 

Raum beschränkt. 

258



Die im Sprint 4 gesetzten Ziele wurden erfolgreich umgesetzt. Die Kopfbewegungen 

werden erkannt und es wird deutlich zwischen den Zuständen 

Kopf grade halten, nach rechts und links Neigen des Kopfes deutlich unterschieden. 

Die erkannten Zustände werden in Signale umgewandelt und 

an den Roboterarm weiter geschickt. Die Bewegungen des Kopfes werden 

durch mehrere Markierungen am Kopf erkannt. Der Prototyp dient einer 

Grundlage für die Umsetzung des entsprechenden Anwendungsfalles in 

Hardware. 

Die Tiefeninformationen werden aus der Tiefenerkennung geliefert. 

Die Echtzeitausgabe über HDMI wurde ebenso umgesetzt. 

Der zur Verfügung gestellte BLOB-IP-Core wurde erfolgreich in das bestehende 

Projekt eingebunden sowie die hierzu benötigte Interruptroutine 

umgesetzt. Die Winkel zwischen den erkannten Punkten werden auf der 

Microblazeebene bereitgestellt. Die Bestimmung der Ausrichtung der Hand, 

um den Winkel für das Handgelenk zu bestimmen, fehlt allerdings noch. 

Diese soll bei der Anbindung der dreidimensionalen Erkennung des Arms 

berücksichtigt werden. 

Des Weiteren wird ein neuer Sprint geplant, der einen Softwareprototyp 

der Handsteuerung sowie eine Überarbeitung der Dokumentation vorsieht. 

259



In dem Sprint 5 wird das Hauptziel auf die Umsetzung des Softwareprototyps 

der Handsteuerung gesetzt. Hierbei soll eine OFFIS-Automation- 

Toolbox-Bildverarbeitungskette erstellt werden, die das Öffnen und Schließen 

der menschlichen Hand erkennen soll. 

Des Weiteren wird eine Überarbeitung der Dokumentation vorgenommen, 

welche die Korrekturvorschläge des Auftragsgebers für das Lastenheft übernehmen 

soll. Außerdem werden die formalen Regeln für das Dokumentieren festgelegt. 

Die Leitpfade zu den formalen Regeln werden im PG-Wiki veröffentlicht 

und sollen zukünftig bei dem Dokumentieren beachtet werden. 

2.7.1 Softwareprototyp Handsteuerung 




Ziel des Arbeitspaketes ist es das Öffnen und Schließen einer menschlichen 

Hand mittels einer OLVIS-Bildverarbeitungskette zu erkennen. Dabei soll 

darauf geachtet werden, dass sich die Bildverarbeitungskette auf das ATLYS- 

Board mit angemessenem Aufwand portieren lässt. 

Deadlines 

• 22.05.2013 12:00 Bildverarbeitungskette inkl. Dokumentation 

Personen 



Aufwand 

• 8 PT OLVIS Bildverarbeitungskette + Dokumentation 

260


Lieferumfang 

• OLVIS-Bildverarbeitungskette inkl. Pythonskripte 

• Dokumentation für die Bildverarbeitungskette 

261


2.7.2 Überarbeitung der Dokumentation 


• Lastenheft 

• Dokumentation 


Ziel des Arbeitspaketes ist eine Überarbeitung des Lastenheftes und der 

Dokumentation. Das Lastenheft muss gemäß den Korrekturvorschlägen 

des Kunden überarbeitet werden. Für die Dokumentation soll zunächst ein 

Leitfaden erarbeitet werden, der formale Regeln zum Dokumentieren festlegt. 

Dieser Leitfaden wird im PG-Wiki veröffentlicht und muss zukünftig 

beim Dokumentieren beachtet werden. Die bis zu Beginn des Arbeitspakets 

vorliegende Dokumentation muss anhand des Leitfadens überarbeitet werden. 

Deadlines 

• 29.05.2013 12:00 Überarbeitetes Lastenheft und Leitfaden für die Dokumentation 

• 12.06.2013 12:00 Dem Leitfaden entsprechend überarbeitete Dokumentation 

Personen 



Aufwand 

• 4 PT Überarbeitung des Lastenheftes 

• 4 PT Entwicklung eines Leitfadens für die Dokumentation 

• 8 PT Überarbeitung der Dokumentation anhand des Leitfadens 

262


Lieferumfang 

• Korrigiertes Gesamtdokument, bestehend aus dem Lastenheft und 

der Dokumentation, mit dem Leitfaden im PG-Wiki 

263


2.8 Sprint 5 

In diesem Sprint werden die Ergebnisse der Umsetzung des Softwareprototyps 

für Handsteuerung sowie der Überarbeitung der Dokumentation 

vorgestellt. 

2.8.1 Softwareprototyp Handsteuerung 

In diesem Abschnitt wird die Erkennung der Gesten der menschlichen 

Hand behandelt. Diese Erkennung ist notwendig, da mittels Gesten der 

Hand die Steuerung des Greifers erfolgen soll. Zu diesem Zweck wird 

zunächst eine Recherche durchgeführt. Bei Dieser wird nach bestehenden 

Ansätzen für die Erkennung von Gesten der menschlichen Hand gesucht. 

Die gefundenen Ansätze werden im folgenden Unterkapitel kurz hinsichtlich 

ihrer Relevanz und Verwendbarkeit analysiert. 

Danach soll auf Basis der Recherche eine Implementierung als OLVIS- 

Bildverarbeitungskette erfolgen. 

2.8.1.1 State-of-the-Art 

Im Rahmen der durchgeführten Recherche wurden verschiedene Ansätze 

gefunden. Bei der Analyse dieser Ansätze werden zwei Aspekte betrachtet: 

Erstens wird die Menge an Informationen, welche der Ansatz liefert, untersucht. 

Diese ist entscheidend für ein mögliches Mapping von Gesten und 

der Qualität der Ansteuerung des Greifers. 

Abbildung 2.120: Hand in farbigem Handschuh. 33 

264


Der zweite Aspekt ist die technische Machbarkeit im Rahmen der Projektgruppe. 

Hierbei wurden die, von den Ansätzen verwendeten, Techniken 

untersucht. Der Hauptaspekt ist dabei die Umsetzbarkeit auf der FPGAbasierten 

Zielplattform. 

Der erste Ansatz, der untersucht wurde, ist ein Projekt vom MIT [17]. In 

diesem Projekt wird ein Handschuh verwendet, an welchem die einzelnen 

Bereiche und Gelenke der Hand mit unterschiedlichen Farben gekennzeichnet 

sind. Der Handschuh ist in Abbildung 2.120 zu sehen. Für die Erfassung 

des Handschuhs wird eine Kinect verwendet. Auf dem Kamerabild 

wird eine Bildverarbeitungskette angewendet, um die einzelnen, farblich 

markierten, Bereiche der Hand separieren. Zusätzlich wird die Tiefeninformation 

verwendet, welche die Kinect liefert. Aufbauend auf diesen Informationen 

wird die genaue Position und Haltung der Hand, sowie der 

Finger berechnet. 

Ein weiterer Ansatz, der betrachtet wurde, stammt von der Universität Kreta. 

Dieser verwendet, wie schon der erste Ansatz [17], eine Kinect für die 

Datenaquise. Dieser Ansatz wurde in die Untersuchung einbezogen, weil 

er keine weiteren Hilfmittel benötigt. 

Abbildung 2.121: Hand-Erkennung. 34 

33 Quelle: http://people.csail.mit.edu/rywang/hand/glove.png 

265


Um die genaue Haltung der Hand zu berechnen verwendet der Ansatz 

ein mathematischen Modell der Hand. Dieses Verfügt über 26 Freiheitsgrade 

und wird zusätzlich von einer Heuristik unterstützt. Die Heuristik 

wird verwendet um die Haltung der Hand zu berechnen, wenn diese durch 

Gegenstände teilweise verdeckt wird. Das Ergebnis der Berechnungen ist 

in Abbildung 2.121 zu sehen. 

Die Ansätze [12] und [17] sind weit vorgeschrittene Forschungsprojekte. 

Sie zeichnen sich beide durch einen sehr hohen Informationsgehalt aus, 

welcher es ermöglicht Handgesten und selbst die Haltung einzelner Finger 

zu erkennen. Der Ansatz [12] ist sogar in der Lage mittels Heuristiken die 

Stellung der Hand trotz starker Überdeckung durch Objekte korrekt zu 

berechnen. 

Ein Nachteil den beide Projekte teilen, ist der hohe Bedarf an Rechenleistung. 

Beide Systeme benötigen leistungsstarke Hardware, welche unsere 

Zielplattform nicht bereitstellen kann. 

Zudem benötigen beide Ansätz zusätzliche Sensorik. Der Ansatz [12] benötigt 

ein Array aus 8 Kameras um die Hand zu erkennen. Bei dem Ansatz [17] 

wird eine Kinect, sowie eine aufwendige Bildverarbeitungskette verwendet. 

2.8.1.2 Ansatz zur Handsteuerung 

Da die in Abschnitt 2.8.1.1 durchgeführte Recherche keinen verwertbaren 

Ansatz ergeben hat, wurde eine eigene Umsetzung entwickelt, welche eine 

vereinfachte Form des farbigen Handschuhs darstellt. Dieser Ansatz verwendet 

eine Bildverarbeitungskette, welche mit der OFFIS-Automation Toolbox 

implementiert wurde. Die Verarbeitung der Daten der Bildverarbeitungskette 

erfolgt durch ein Python Skript. 

Um die Hand zu erkennen, werden an dieser farbige Markierungen angebracht, 

welche mittels eines BLOB-Filters gefunden werden sollen. Zunächst 

wurde probiert eine einzelne Markierung an der Handinnenseite zu befestigen. 

Diese ist im geschlossenen Zustand nicht sichtbar. Dies schränkt die 

verwendbaren Perspektiven stark ein, da die Handinnenseite aus vielen 

Richtungen nicht deutlich zu erkennen ist. 

Abhilfe schafft eine zweite Variante, bei der jeweils eine Markierung an 

Daumen und Zeigefinger angebracht wird (siehe Abbildung 2.123). Ob die 

Hand als geöffnet oder geschlossen angesehen wird, hängt davon ab, wie 

34 Quelle: http://www.openni.org/files/3d-hand-tracking-library/ 

266


nah Daumen und und Zeigefinger zueinander sind. Befinden sich die beiden 

erkannten BLOBs nah beieinander, oder wird gar nur ein großer BLOB 

erkannt, so wird die Hand als geschlossen betrachtet. Falls die BLOBs einen 

großen Abstand zu einander haben wird die Hand als geöffnet angesehen. 

Diese Methode setzt voraus, dass die beiden Finger sich nicht gegenseitig 

verdecken, da sonst nur ein BLOB erkannt wird (vergleiche Abbildung 

2.123). 

267


Abbildung 2.122: OLVIS Bildverarbeitungskette 

268


Bildverarbeitungskette 

Bei der Bildverarbeitungskette wurde darauf geachtet, dass alle verwendeten 

Filter in Hardware implementierbar sind. Darüber hinaus wurde versucht 

mit Filtern zu arbeiten, welche bereits als Hardwareimplementierung 

vorhanden sind. 

Auf Grundlage dieser Vorgaben, wurde die in Abbildung 2.122 dargestellte 

Filterkette entworfen. Es wird ein RGB-zu-Graustufen-Filter, welcher eine 

Gewichtung auf dem Grünkanal durchführt, verwendet. Auf dem entstandenen 

Graustufenbild wird ein Schwellwert-Filter angewendet, um binäre 

Daten zur weiteren Analyse per BLOB-Filter zu erhalten. 

Da die Farbe der Markierung, wie in Abbildung 2.123 zu sehen, grün ist, 

wird sie durch den gewichteten RGB-zu-Graustufen-Filter stark hervorgehoben. 

Dies macht eine Erkennung der Markierung durch die nachgeschaltete 

BLOB-Detektion möglich. Die Daten der BLOB-Detektion werden im 

Folgendem von einem Pythonskript weiter verarbeitet. 

Phython-Skript 

Im Abschnitt 2.8.1.2 wurde Bildverarbeitungskette beschrieben, welche mit 

Hilfe verschiedener Filter Objekte im Kamerabild erkennt. Da die, in der 

Bildverarbeitungskette verwendete, BLOB-Detektion lediglich Informationen 

zu allen im Bild gefunden Objekten ausgibt, müssen diese Daten in 

einem weiteren Schritt analysiert werden. Diese Analyse erfolgt durch ein 

Pythonskript. 

Im ersten Schritt wird die Anzahl der im Bild gefundenen Objekte untersucht. 

Dabei werden Datensätze, verworfen, welche keine oder mehr als 

zwei Objekte enthalten. 

Sollte sich nur ein Objekt im Bildbefinden befinden, wird eine 1 vom Skript 

zurückgeliefert. Dabei wird angenommen, dass in diesem Fall die beiden 

Objekte verschmolzen sind und die Hand folglich geschlossen ist. 

Wenn zwei Objekte gefunden werden, wird der euklidische Abstand der 

Schwerpunkte berechnet. Sollte dieser einen experimentell bestimmten Schwellwert 

übersteigen, so wird die Hand als geöffnet angesehen, andernfalls gilt 

sie als geschlossen. 

Der Schwellwert wurde experimentell erhoben, da zum Zeitpunkt der Erstellung 

des Skripts keine 3D-Daten zur Verfügung standen. Mit 3D-Informationen 

kann die Position der Objekte im Raum bestimmt werden, und die Geste 

genauer erkannt werden. 

269


(a) frontal, geöffnet 

(b) frontal, geschlossen 

(c) seitlich, geöffnet 

(d) seitlich, geschlossen 

(e) nicht erkennbar 

Abbildung 2.123: Erkennung des Schließzustandes der Hand mittels 

Markierungen an den Fingerkuppen von Zeigefinger und 

Daumen 

270



Die Ergebnisse des Sprint 5 erfüllten die gesetzten Ziele mit folgendem 

Erfolg: Die formalen Regeln für das Dokumentieren wurden erstellt und 

im PG-Wiki veröffentlicht. Die Dokumentation wurde gemäß den neuen 

Regeln überarbeitet. Die Korrekturvorschläge des Arbeitsgebers wurden 

für das Lastenheft übernommen. 

Für die Umsetzung des Softwareprototyps wurde zunächst eine State-of- 

The-Art Recherche vorgenommen. Der Ansatz der farbigen Markierung 

wurde auch im Projekt RoboArm verwendet. Die Umsetzung des Softwareprototyps 

erfolgte durch Einsatz der BLOB-Erkennung. Die Fingerspitzen 

des Daumens und des Zeigerfingers wurden mit grünen Markierungen 

versehen, so das der geschlossener Zustand entweder als ein BLOB oder 

als zwei sehr nah an einander befindenden BLOBs und der geöffneter 

Zustand als zwei deutlich voneinander entfernten BLOBs erkannt wird. 

Dieser Ansatz setzt allerdings voraus, dass die Fingerspitzen mit keinem 

anderen Teil des menschlichen Arms verdeckt sein dürfen. Ansonsten ist 

keine Erkennung der Fingerspitzen möglich. Dies schränkt die verwendbaren 

Perspektiven zwar ein, jedoch ermöglicht eine relativ einfache Umsetzung 

der Handsteuerung und muss bei der Bedienung des Roboters 

beachtet werden. 

Der nächste Sprint verfolgt viele Teilziele der Neuentwicklung, Implementierung 

sowie des Portierens der bestehenden Projekte auf Hardware. 

271



In diesem Sprint ist die Erstellung und Anbindung mehrerer Hardwarekomponenten 

geplant. Der Aufbau der dreidimensionalen Bildverarbeitungskette 

muss umgesetzt werden. Da das Drehgelenk der menschlichen Schulter 

mehr Freiheitsgrade als der Roboterarm besitzt, muss ein Softwareprototyp 

zur Interpolation der erkannten Bewegungen am Drehgelenk erstellt 

werden. Außerdem sollen die Untersuchung und Verbesserungen der 

Schwächen von erstellten Prototypen sowie Portierungen der Softwareprototypen 

auf Microblaze vorgenommen werden. In diesem Sprint werden 

auch die Hardware-Komponente ImageBus-Overlay sowie der Softwareprototyp 

Trajektorienführung umgesetzt. Aufgrund der Ungenauigkeit der 

Roboterhardware wird ein neuer Roboterarm spezifiziert. 

2.9.1 ImageBus Overlay 


• Hardware-in-the-Loop (HIL) 

• Experte mit VFBC Kenntnissen 


In diesem Arbeitspaket soll ein IP-Core entwickelt werden, der ein im RAM 

gespeichertes Bild über den Datenstrom von einem ImageBus legt. Das im 

RAM gespeicherte Bild wird ab sofort als Overlay bezeichnet. In diesem 

werden pro Pixel 24-Bit Farbinformationen und 8-Bit Transparenzinformationen 

gespeichert. Der RAM wird per VFBC angebunden. 

Das Bild im RAM soll von dem Microblaze über die PLB-Schnittstelle 

verändert werden können. Dazu soll ein Treiber entwickelt werden, der 

Text darstellen können soll. Außerdem soll er die Informationen des BLOB- 

IP-Core hervorheben können. 

Aufwand 

• 12 PT IP-Core 

• 8 PT Microblaze-Code 

272


Lieferumfang 

• ATLYS-Design mit HIL 

273


2.9.2 3D Armerkennung - Portierung auf den Microblaze 


• OFFIS Implementierung der 3D-Erkennung 

• Hardwarebildkette (BLOB-Detection) 

• Roboteransteuerung (Servo-IP-Core + Treiber) 


Ziel des Arbeitspakets ist eine dreidimensionale Erkennung und Winkelberechnung 

eines menschlichen Arms von dem vorhandenen Pythonskript 

auf den Microblaze zu portieren. Die berechneten Winkel müssen auf den 

Roboterarm umgerechnet werden. Dies gilt insbesondere für den Drehwinkel 

des Roboterarms. Die Ausgangsdaten bestehen aus einer doppelte Bildverarbeitungskette 

der Stereokamera, welche synchronisiert werden müssen. 

Aufwand 

• 3W (12 PT) 3D Code von Peter & Patrick mit 2D Microblazecode von 

Markus & Vitaly zusammenführen 

• 2W (8 PT) Doppelte Bildverarbeitungsketten (Synchronisation) 

• 2W (8 PT) Mapping auf die Drehung von Schultergelenk zu Roboterarm 

• 1W (4 PT) Verbindung mit Servos (Integration) 

Lieferumfang 

• ATLYS-Projekt mit neuer Microblazesoftware (Handgelenk wird nicht 

unterstützt) 

274


2.9.3 Aufbau der dreidimensionalen 



• Einzelkomponenten in Form von IP-Core für Hardware vorhanden 


Ziel dieses Arbeitspaketes ist es, eine doppelte Bildverarbeitungskette aufzubauen, 

so dass dreidimensionales Erkennen und Winkelberechnung eines menschlichen 

Arms ausschließlich auf dem Microblaze möglich wird. Die Bildverarbeitung 

findet mittels eines bereits erstellten IP-Core statt, wobei die 

Berechnung der Winkel und Armstellung in Software auf dem Microblaze 

berechnet werden soll. 

Für diesen Aufbau wird es nötig sein einen weiteren IP-Core zu entwickeln, 

der ein Bildstream in Höhe und Breite halbiert und somit die Anzahl der 

Pixel viertelt. Dies soll durch Zeilen- und Pixelsprünge realisiert werden. 

Aufwand 

• 1W (4 PT) Aufbau einer doppelte Bildverarbeitungskette 

• 1W (4 PT) Integration des dreidimensionalen Armerkennungssoftware 

Lieferumfang 

• ATLYS-Projekt mit dreidimensionaler Bildverarbeitungskette und Software 

zur Erkennung der Armstellung im dreidimensionalen Raum. 

275


2.9.4 Spezikation eines neuen Roboterarms 


• Kinematik aus Sprint 2 

• aktueller Roboterarm 


Ziel des Arbeitspakets ist die Erstellung eines neuen Roboterarms. Dabei 

sollen soweit wie möglich die am aktuellen Roboterarm festgestellten Mängel 

analysiert und bei der Konstruktion des neuen Arms mit einbezogen 

werden. Im ersten Abschnitt des Pakets erfolgt daher die Entwicklung 

möglicher Ansätze sowie eine darauffolgende Spezifikation des neuen 

Arms. Auf Basis der Spezifikation wird die Entscheidung über die Fortsetzung 

des gesamten Arbeitspakets getroffen. 

Der nächste Abschnitt behandelt die Erstellung eines CAD-Designs für den 

neuen Roboterarm. Dabei müssen die in der vorherigen Phase festgelegten 

Spezifikationen beachtet werden. Die Fertigung des CAD-Designs durch 

die CNC-Fräse erfolgt extern und nicht im Rahmen des Arbeitspakets. 

Um eine Rückkopplung von den Servos zu erhalten soll im nächsten Teilpaket 

eine Platine zur Strommessung entwickelt werden. Die Fertigung der 

Platine auf Basis des erstellten Layouts erfolgt dabei extern und nicht im 

Rahmen des Arbeitspakets. 

Endprodukt des Arbeitspakets ist der neue Roboterarm. 

Deadlines 

• 05.06.2013 12:00 Spezifikation 

• 19.06.2013 12:00 CAD-Design 

• 17.07.2013 12:00 Outsourced: Fertigung des CAD-Designs 

• 31.07.2013 12:00 Entwicklung einer Platine zur Strommessung 

• 28:08.2013 12:00 Outsourced: Lieferung der Platine 

Personen 

• Spezifikationsphase 

– Vitaliy Beguchiy 

276


– Tobias Schüürhuis 

• CAD-Design 

• Platinenentwurf 

Aufwand 

• 8PT - Spezifikationsphase 

• 8PT - CAD-Design 

• 0PT / 4W - Outsourced: Fertigung des CAD-Designs 

• 4PT - Entwicklung der Platine zur Strommessung 

• 0PT / 4W - Outsourced: Lieferung der Platine 

Lieferumfang 

• Spezifikation 

• CAD-Design 

• Gerber-Daten + Platine 

• Roboterarm 

277


2.9.5 Erweiterung des Servo-IP-Cores 


• Servo-IP-Core 

• Testbench für Servo-IP-Core 

• Rückwärtskinematik 


Ziel des Arbeitspakets ist die Erstellung eines erweiterten Servo-IP-Cores, 

sowie die Erweiterung der Rückwärtskinematik. Die Erweiterung des Servo-IP-Core 

soll die Bewegungen des Roboterarms weicher bzw. fließender 

gestaltet. Der vorhandene IP-Core soll für die Ansteuerung der Servos 

angepasst werden, sodass ruckartige Bewegungen vermeiden werden. Endprodukt 

soll ein neuer Servo-IP-Core sein. 

Die Erweiterung der Rückwärtskinematik soll die Drehachse des Roboterarms 

aus den Berechnungen ausschließen, sodass sich der Roboterarm 

lediglich in der x und y-Achse bewegt. Ausserdem soll die Kinematik ermöglichen 

in einer planaren Ebene einer Trajektorie zu folgen. Die Trajektorie 

soll dabei durch eine Liste von Punkten repräsentiert werden. 

Personen 

• Implementierungsphase Servo-IP-Core 

– Matthias Stasch 

– Patrick Elfert 

• Trajektoriensteuerung und Integration 

Aufwand 

• 8PT - Erweiterung Servo IP-Core mit Rampen 

• 12PT - Trajektoriensteuerung und Integration 

Lieferumfang 

• Erweiterter Servo-IP-Core 

• Erweiterte Rückwärtskinematik 

278


2.9.6 Entwicklung einer Trajektorienführung 



• Rückwärtskinematikplugin inkl. Python-Schnittstellen 

• Xilinx-Projekt(Genesys) inkl. Servo IP-Core 

• GENESYS FPGA-Board 



Ziel dieses Arbeitspaketes ist die Entwicklung und Umsetzung eines Algorithmus 

zur Trajektorienführung auf einer Ebene, welche in erster Linie im 

Anwendungsfall „Skizze zeichnen“ eingesetzt werden soll. Dies ist nötig, 

da die entwickelte Rückwärtskinematik alleine zur Ansteuerung eines eingegebenen 

Punktes dient. Damit wird zu diesem Zeitpunkt jedoch noch nicht das 

Abfahren einer vorgegebenen Strecke, also einer Trajektorie, realisiert. 

Durch Eingabe einer Punktliste können somit auf einer Ebene geometrische 

Formen wie z. B. Geraden mit dem Roboterarm abgefahren werden. Dafür 

soll in diesem Arbeitspaket die in Sprint 2 Abschnitt 2.2.3.3 erarbeitete 

Rückwärtskinematik genutzt und falls nötig angepasst werden, sodass das 

Abfahren der Trajektorien keine unerwünschten Sprünge beinhaltet. 

Das Ergebnis dieses Arbeitspakets ist ein zusätzliches Plugin für die OFFIS- 

Automation-Toolbox, welches aus einer Menge von Punkten als Eingabe 

eine Trajektorie interpoliert. Als Demonstrator wird ein Python-Skript implementiert, 

welches Trajektorienführung und Rückwärtskinematik kombiniert, 

sodass die errechneten Steuerwinkel über die USB-Schnittstelle und 

den FPGA an die Servos des realen Roboterarms weitergeleitet werden 

können. 

Deadline 

03.07.2013 12:00 

Personen 



279


Aufwand 

5 Persontage 

Lieferumfang 

• Plugin zur Trajektorienberechnung für die OFFIS-Automation-Toolbox 

• Python-Skript zur Verbindung von Trajektorienführung und Rückwärtskinematik 

– Vollständiger Aufbau zum Zeichnen planarer geometrischer Formen: 

Rechteck, Dreieck, Kreis 

280



des Zig-Zag Verhaltens 




• Trajektorienführungsplugin inkl. Python-Schnittstellen 





Im Abschnitt 2.10.6 wurden die Probleme mit dem Zeichenbereich sowie 

mit dem Zig-Zag mäßigen (zitternden) Verhalten festgestellt. Das Ziel dieses 

Arbeitspaketes ist das Programm der Rückwärtskinematik insofern nachzubessern, 

dass der Wechsel der Strategie so spät wie möglich erfolgt. Die Idee dabei 

ist, für die Punkte im Arbeitsbereich, die von beiden Strategien erreichbar 

sind, weiterhin mit der ersten Strategie die Winkelstellungen zu berechnen. 

Außerdem muss in diesem Arbeitspaket festgestellt werden, woher 

das oben beschriebene Verhalten beim Abfahren der geradlinigen Trajektorien 

stammt. Zusätzlich soll das Verhalten des Roboterarms beim Abfahren 

der Trajektorie „Von Punkt zum Punkt“ ohne Interpolation getestet 

werden. 

Deadline 

10.07.2013 12:00 

Personen 

Vitaliy Beguchiy 

Aufwand 

3 Persontage 

281


Lieferumfang 

• Ein Demonstrator des verbesserten Arbeitsbereiches 

• Bericht über Grund des Zig-Zag mäßigen Verhalten des Roboterarms 

282


2.9.8 Drehgelenk 






zur Abbildung des menschlichen Schultergelenks auf dem Roboterarm. 

Zu diesem Zweck muss anhand der Tiefeninformation die Drehung 

des menschlichen Armes auf zwei Servomotoren abgebildet werden. Mit 

Realisierung des Drehgelenks wird der Anwendungsfall „Armbewegung 

nachahmen“ funktional vervollständigt. Das Ergebnis dieses Arbeitspakets 

ist eine Implementierung in Python bzw. der OFFIS-Automation-Toolbox, 

welche im Anschluss auf den Microblaze poriert werden kann. 

Deadline 

26.06.2013 12:00 

Personen 



Aufwand 

8 Personentage 

Lieferumfang 

• Python-Algorithmus für die OFFIS-Automation-Toolbox 

283


2.9.9 Referenztakt für den cam_bootloader 


• cam_bootloader IP-Core 

• Experte für den cam_bootloader 


In diesem Arbeitspaket soll der bestehende cam_bootloader IP-Core derart 

geändert werden, dass ein fest bestimmter Referenztakt angelegt werden 

muss. Dieser Takt soll ermöglichen, dass die Parameter N und M 

des Treibers camcfg fest gewählt werden können. Des Weiteren kann eine 

Lookup Tabelle hinterlegt werden, so dass die Parameter für verschiedene 

Kamerageschwindigkeiten nachgeschaut werden können. 

Aufwand 

• 4 PT Integration 

Lieferumfang 

• Der cam_bootloader IP-Core bekommt eine externe Referenz Clock 

für die Kamera 

• Der angepasste camcfg Treiber 

284


2.10 Sprint6 

Im Folgenden werden die Ergebnisse der einzelnen Arbeitspakete sowie 

die dabei entstandenen Probleme ausführlich vorgestellt. 

2.10.1 ImageBus Overlay 

In diesem Arbeitspaket soll ein IP-Core entwickelt werden, der ein im RAM 

gespeichertes Bild über den Datenstrom von einem ImageBus legt. Das im 

RAM gespeicherte Bild wird ab sofort als Overlay bezeichnet. In diesem 

werden pro Pixel 24-Bit Farbinformationen und 8-Bit Transparenzinformationen 

gespeichert. Der RAM wird per VFBC angebunden. 

Das Bild im RAM soll von dem Microblaze über die PLB-Schnittstelle 

verändert werden können. Dazu soll ein Treiber entwickelt werden, der 

Text darstellen können soll. Außerdem soll er die Informationen des BLOB- 

IP-Core hervorheben können. 

Zunächst wird ein FIFO-Modul implementiert, welches im Overlay-IP-Core 

benutzt wird. 

2.10.1.1 FIFO-VHDL-Modul 

Für den Overlay-IP-Core wurde zunächst ein VHDL-Modul erstellt, welches 

eine FIFO bereitstellt. Dieses verwendet das Blockram VHDL-Modul, 

welches für den Morphologie-IP-Core erstellt wurde. Die Daten- und Addressbreite 

des FIFO-VHDL-Modul lässt sich über Generics anpassen. Außerdem 

existiert ein Port, welcher gesetzt wird, wenn die FIFO fast leer ist. 

Auch dieser Port lässt sich über ein Generic konfigurieren. Das VHDL- 

Modul verfügt über einen Reset-Eingang, welcher die FIFO zurücksetzt. 

Falls während der Resetphase gleichzeitig Daten in die FIFO geschrieben 

werden sollen, werden diese als erstes Element in der FIFO aufgenommen. 

Auf die Verwendung des von Xilinx bereitgestellten FIFO-IP-Core wurde 

verzichtet, da dieser nur als Netzliste verfügbar ist. Dies führt zu erhöhtem 

Aufwand beim Portieren zwischen den verschiedenen Boards (ATLYS, GENESYS). 


285


clk 

reset 

push 

pop 

in_data 

FIFO 

almost_empty 

empty 

full 

out_data 

Abbildung 2.124: Blockschaltbild des FIFO-VHDL-Modul 

Dateistruktur 

• ipcores.git/pcores/image_bus_overlay_v1_00_a/hdl/vhdl/blockram.vhd 

Blockram VHDL-Quelltext, welcher von dem FIFO-Modul benutzt 

wird. Dieses wurde aus dem Morphologie-Filter übernommen. 

• ipcores.git/pcores/image_bus_overlay_v1_00_a/hdl/vhdl/block_ram_tb.vhd 

Testbench für das Blockram-Modul. Diese wurde aus dem Morphologie- 

Filter übernommen. 

• ipcores.git/pcores/image_bus_overlay_v1_00_a/hdl/vhdl/fifo.vhd 

VHDL-Quelltext für das FIFO-Modul. 

• ipcores.git/pcores/image_bus_overlay_v1_00_a/hdl/vhdl/fifo_tb.vhd 

Testbench für das FIFO-Modul. 

2.10.1.2 image_bus_overlay_1_00_a 

Der Overlay-IP-Core soll auf einen ImageBus ein Overlay legen können. 

Er besteht also im Wesentlichen aus einem ImageBus Ein- und Ausgang, 

sowie einer Schnittstelle zum Speicher, in welchem sich das Overlay befindet. 

Dieser Speicherbereich kann dann vom Microblaze über den PLB modifiziert 

werden. 


286


clk 

reset 

vfbc 

img_bus_in 

PLB 

image_bus_overlay 

img_bus_out 

Abbildung 2.125: Blockschaltbild des ImageBus-Overlay-IP-Core 

Funktionsweise 

clk 

reset 

vfbc 

merge 

img_bus_out 

img_bus_in 

PLB 

FIFO 

Abbildung 2.126: Schematischer Aufbau des ImageBus-Overlay-IP-Core 

Der ImageBus-Overlay-IP-Core bekommt als Eingaben einen RGB565-ImageBus 

und eine VFBC-Schnittstelle, über die er aus einem Speicherbereich im 

RAM das Overlay als RGBA888 ausliest. 

Um dem IP-Core die Konfiguration der VFBC-Schnittstelle zu ermöglichen 

werden die ankommenden ImageBus-Daten zunächst in eine FIFO geschrieben. 

Dazu wird das VHDL-Modul aus Abschnitt 2.10.1.1 verwendet. 

Sobald auf dem ImageBus das frame_valid Signal auf ’1’ steht, wird die 

FIFO und die VFBC-Schnittstelle zurückgesetzt. Anschließend wird mit 

der Konfiguration der VFBC-Schnittstelle begonnen. Diese Konfiguration 

benötigt ca. 256 Takte. Während dieser Zeit werden alle ankommenden 

Daten des ImageBus in der FIFO gesammelt. Die Länge der Konfiguration 

ist kurz genug, so dass keine Daten verloren gehen. Dies liegt daran, dass 

die vorgeschaltete FIFO genug Daten speichern kann, bis die Konfiguration 

des VFBC geschehen ist. Danach kommen von der Kamera nur in jedem 

zweiten Takt Daten, so dass diese FIFO nach und nach geleert wird. Da 

287


ein vollständiges Bild wesentlich größer ist als 512 Pixel, wird dies nicht zu 

einem Problem führen. 

Nachdem die Konfiguration abgeschlossen ist werden jeweils zeitgleich 

Daten aus der FIFO und der VFBC-Schnittstelle abgefragt. Im folgenden 

Takt werden die Farbinformationen mittels der Alpha-Kanal-Information 

gewichtet zusammengerechnet. 

Dazu wird die folgende Formel jeweils auf dem roten, grünen und blauen 

Farbkanal ausgeführt: 

channel_out = channel_in · (255 − alpha) + channel_v f bc · alpha 

Der resultierende ImageBus-Datenstrom wird, ebenfalls RGB565 formartiert, 

auf dem image_bus_out Port ausgegeben. 

Eine schematische Darstellung des internen Aufbaus ist in Abbildung 2.126 

zu sehen. 

PLB Register 

Zur Konfiguration des IP-Cores existieren drei 32-Bit Register, welche mittels 

des Microblaze eingestellt werden müssen. Der Aufbau dieser Register 

ist in Tabelle 2.7 dargestellt. 

Register Bit 31 Bit 30-16 Bit 15-0 

Register 0x00 Base Address 

Register 0x04 Height Width 

Register 0x08 enable - Line Stride 

Tabelle 2.7: Image Bus Overlay PLB Register 

Der IP-Core verarbeitet keine Daten bis das “enable” Bit aktiviert wird. In 

diesem Fall wird auch der eingehende ImageBus-Datenstrom nicht weitergegeben. 

“Base Address” ist die Adresse im Arbeitsspeicher von der das Overlay 

gelesen werden soll. Das Register erwartet eine Hardwareadresse, es muss 

also von Microblazeadressen zunächst das PLB-Offset abgezogen werden. 

Auf dem ATLYS wird dieses als “XPAR_MCB_DDR2_MPMC_BASEADDR” 

in der xparameters.h definiert. 

Die “Height” und “Width” Angaben werden in Pixel gesetzt und müssen 

der Auflösung des anliegenden ImageBus-Datenstroms entsprechen. 

288


Das “Line Stride” Register muss mindestens der Breite des Bildes entsprechen. 

Falls das Register größer als die Breite des Bildes ist werden ggf. Pixel im 

Speicher übersprungen. 

Bei der Konfiguration muss beachtet werden, dass an der “Base Address” 

ausreichend Speicher zur Verfügung steht. Das Overlay arbeitet mit 32-Bit 

Pixeldaten. Damit entspricht die minimal benötigte Speichermenge: 

Probleme 

SIZE = Line_Stride · 4 · Height 

Um eine möglichst kleine Verarbeitungskette auf dem FPGA zu erhalten, 

wurde in einem ersten Schritt versucht den Image-HIL auf dem GENESYS 

zu nutzen. Da dieser aber leider nicht funktionierte wurde im Weiteren ein 

ATLYS-Projekt mit Kamera und USB-Ausgabe an die OFFIS-Automation- 

Toolbox verwendet. 

Ein weiteres Problem war das Zeitverhalten des ImageBus-Overlay-IP-Core. 

Es musste genau darauf geachtet werden, wann an den beiden FIFOs die 

pop-Signale anliegen, da die Daten beider FIFOs erst verzögert valide sind. 

Der Microblaze schreibt Daten mit einer anderen Byte-Reihenfolge in den 

RAM, als der VFBC den RAM ausliest. Dies führte zu verkehrten Alphaund 

Farbwerten, behoben wurde dies dadurch, dass die Lese-Reihenfolge 

im IP-Core angepasst wurde. 

Dateistruktur 

Das Basis-Verzeichnis für alle beschriebenen Dateien ist: 

ipcores.git/pcores/image_bus_overlay_v1_00_a. 

• ./hdl/vhdl/blockram.vhd 

Blockram VHDL-Quelltext, welcher von dem FIFO-Modul benutzt 

wird. Dieses wurde aus dem Morphologie-Filter übernommen. 

• ./hdl/vhdl/fifo.vhd 

VHDL-Quelltext für das FIFO-Modul. 

• ./hdl/vhdl/image_bus_overlay.vhd 

VHDL-Quelltext, welcher die Logik der Einblendung von Pixeln beinhaltet. 

289


• ./hdl/vhdl/overlay_tb.vhd 

Testbench für den image_bus_overlay-IP-Core. 

2.10.1.3 Overlay Microblaze Code 

Um dem ImageBus-Overlay-IP-Core Daten über den Microblaze zu geben, 

wird ein Treiber für diesen entwickelt. Dieser Treiber schreibt die benötigten 

RGBA888 Daten in einen Speicherbereich im RAM. Die Adresse dieses Speicherbereichs, 

zusammen mit der Auflösung und dem Line-Stride werden 

dem ImageBus-Overlay-IP-Core in Registern bereitgestellt. Der Treiber ist 

weiterhin in der Lage einfache geometrische Objekte und RGBA888-Bilder 

darzustellen. Des Weiteren soll der ImageBus-Overlay in der Lage sein Text 

darzustellen. Hierfür wird eine weitere Klasse erstellt und eine Basisschriftart 

zur Verfügung gestellt. 

Um die Erstellung von den benötigten Bitmap-Schriftarten zu vereinfachen 

wurde auf das Fontbuilder-Projekt von Andry Black [4] zurückgegriffen. 

Dieses Qt basierte Projekt generiert Bitmap-Schriftarten aus TrueType-Schriftarten. 

Zusätzlich zu der Bilddatei mit den Schriftzeichen werden außerdem Metadaten 

zu der Schrift und den enthaltenen Zeichen exportiert. Hier bietet die 

Software verschiedene XML-Exporter, sowie einen Lua-Exporter an. Von 

uns wird ein C-Exporter hinzugefügt. 

ImageBus-Overlay-API 

Im Folgenden werden zuerst alle erstellten Strukturen erklärt, dann die 

API des Overlay Treibers und im Anschluss die API des Text_Renderers. 

1 enum Direction { 

2 HORIZONTAL , 

3 VERTICAL 

4 }; 

Dieser Enum gibt eine Ausrichtung an. Wird z.B. in draw_line verwendet 

1 struct Position { 

2 unsigned int x; 

3 unsigned int y; 

4 }; 

In dieser Struktur ist die Position eines Pixels gespeichert. Dabei wird i.d.R. 

die obere linke Ecke als 0, 0 interpretiert. Die Zeilennummer ist äquivalent 

zu y, die Spaltennummer zu x. 

290


1 struct Dimensions { 

2 unsigned int w; 

3 unsigned int h; 

4 }; 

Diese Struktur gibt die Größe eines Objektes an. Für die Breite wird w, für 

die Höhe h verwendet. 

1 struct Color { 

2 unsigned char r; 

3 unsigned char g; 

4 unsigned char b; 

5 unsigned char a; 

6 }; 

Mit dieser Struktur wird eine RGBA888 Farbe gekapselt. 

Overlay ( unsigned int base_addr , Dimensions d); 

Dies ist der Konstruktor der Klasse. Die Klasse interagiert mit dem ImageBus-Overlay-IP-Core. 

Sie ist in der Lage einfach geometrische Objekte 

zu rendern. Als Parameter sind die PLB-Basisadresse und die Größe 

anzugeben. 

~ Overlay () ; 

Da im Konstruktor ein Speicherbereich mittels calloc gesichert wird, muss 

dieser im Destruktor wieder freigegeben werden. 

void clear () ; 

Diese Methode macht den gesamten Overlay transparent. Hierbei gehen 

vorherige Daten verloren. 

bool copy ( Position p , Dimensions d , const unsigned char * data ); 

Mithilfe dieser Methode können Bilddaten auf den Overlay kopiert werden. 

Data muss dabei aus RGBA888 Bilddaten bestehen. Diese können z.B. 

mithilfe von GIMP 35 als Header Datei exportiert werden. Als Parameter 

werden die Zielposition, Größe und Daten des Bildes benötigt. Die Zielposition 

ist dabei die obere linke Ecke des Bildes. 

35 http://www.gimp.org/ 

291


inline bool is_valid ( Position p) { 

return !( p.x >= width || p.y >= height ) ? true : false ; 

} 

Damit nicht ausserhalb des validen Speicherbereichs geschrieben wird gibt 

diese Methode an, ob eine Position im validen Bereich des Bildes liegt. 

inline void draw_pixel ( Position p , Color c) { 

base_address [p.y * line_stride + p.x] = c; 

} 

Setzt einen Pixel an Position p auf die Farbe c. 

inline Color get_pixel ( Position p) { 

return base_address [p.y * line_stride + p.x ]; 

} 

Gibt die Farbe eines Pixels an Position p zurück. 

1 inline Color merge_colors ( Color a , Color b , unsigned char alpha 

) { 

2 Color result ; 

3 

4 result .r = (a.r * (255 - b.a) + b.r * b.a) >> 8; 

5 result .g = (a.g * (255 - b.a) + b.g * b.a) >> 8; 

6 result .b = (a.b * (255 - b.a) + b.b * b.a) >> 8; 

7 result .a = alpha ; 

8 

9 return result ; 

10 } 

Diese Funktion verrechnet zwei Farbwerte zu einem Farbwert zusammen. 

Der Alpha Kanal beider Farben wird dabei berücksichtig, obwohl die resultierende 

Farbe das Alpha des Parameters hat. 

Dimensions get_resolution () ; 

Gibt die Auflösung des Overlay zurück. 

bool draw_line ( Position from , Position to , Color c); 

Mit dieser Funktion kann eine farbige Linie zwischen zwei beliebigen Punkten 

auf dem Overlay gezeichnet werden. Der Hierfür verwendete Algorithmus 

ist Bresenham’s Linien Algorithmus [5]. 

292


bool draw_line ( Position p , int length , Direction d , Color c); 

Mit dieser Funktion können farbige Linien in horizontaler und vertikaler 

Richtung mit bestimmter Länge gezeichnet werden. 

bool draw_area ( Position p , Dimensions d , Color c); 

Diese Funktion füllt einen Bildbereich des Overlay ab einer Position p mit 

der Größe d in der Farbe c. 

bool draw_box ( Position p , Dimensions d , Color c); 

Mit dieser Funktion kann eine Box gezeichnet werden, deren Inhalt nicht 

weiter angepasst wird. Die Box wird ab einer Position p mit der Größe d 

in der Farbe c gezeichnet. 

bool draw_circle ( Position p , int radius , Color c); 

Diese Funktion zeichnet einen nicht gefüllten Kreis ab einer Position p mit 

dem Radius radius in der Farbe c. Der Hierfür verwendete Algorithmus ist 

Bresenham’s Kreis Algorithmus [5]. 

void blt () ; 

Der Overlay füllt einen Speicherbereich, der nicht direkt auf den ImageBus 

geschrieben wird. Dies ist dazu da, lange Speicheroperationen dem Nutzer 

nicht sichtbar zu machen. Nachdem die Zeitaufwändige Operation beendet 

wurde, kann blt aufgerufen werden um diesen gerade beschriebenen 

Speicher sichtbar zu machen. blt steht für block line transfer. 

TextRenderer ( Overlay * ov ); 

Diese Klasse ist in der Lage Text auf einen Overlay zu zeichnen. Hierbei 

muss der Overlay übergeben werden. 

struct Dimensions get_dimensions ( char * text ); 

Diese Funktion gibt die Größe eines Textes an, dabei wird der Text nicht 

gezeichnet. 

void print ( struct Position p , char * text , struct Color c); 

Mit dieser Funktion wird farbiger Text auf dem Overlay gezeichnet. Dabei 

ist die Position die obere linke Ecke des Textes. Unterstützt werden dabei 

alle ASCII Zeichen sowie ein Zeilenumbruch (\n). 

293


void set_font ( const struct font_metadata * font , const unsigned 

char * data ); 

Hiermit wird die zu verwendende Schriftart festgelegt. Standardmäßig ist 

bereits eine Schriftart ausgewählt. 

Font-API 

Die API eines Schriftzuges besteht aus zwei Teilen. Zum Einen den Metainformationen 

und zum Anderen den RGBA888 Daten der einzelnen Buchstaben. 

1 struct char_metadata { 

2 const char character ; 

3 const unsigned char advance ; 

4 const char ox ; 

5 const char oy ; 

6 const unsigned char x; 

7 const unsigned char y; 

8 const unsigned char w; 

9 const unsigned char h; 

10 }; 

11 

12 struct font_metadata { 

13 const struct { 

14 const char * family ; 

15 const char * style ; 

16 const unsigned char size ; 

17 } font ; 

18 


20 const char ascender ; 

21 const char descender ; 

22 const unsigned char height ; 

23 } metric ; 

24 


26 const char * filename ; 

27 const unsigned char width ; 

28 const unsigned char height ; 

29 } file ; 

30 

31 const struct char_metadata * chars ; 

32 }; 

Die Metainformationen geben Auskunft über die einzelnen Buchstaben in 

einer Schriftart, sowie der Schriftart selbst. Es werden Name, Typ und 

294


Schriftgröße der Schriftart gespeichert. Auch der Abstand einzelner Buchstaben 

untereinander ist hier abgelegt. Für jeden einzelnen Buchstaben 

wird zusätzlich noch gespeichert, an welchen Koordinaten er in den Daten 

zu finden ist, wie breit und hoch er ist, sowie Verschiebungen nach Unten, 

nach Oben und zur rechten Seite. 

1 static const struct { 

2 unsigned int width ; 

3 unsigned int height ; 

4 unsigned int bytes_per_pixel ; /* 2: RGB16 , 3: RGB , 4: RGBA */ 

5 unsigned char pixel_data [152 * 147 * 4 + 1]; 

6 } 

Die eigentlichen Daten der Schriftart sind in einem C-Struct gespeichert, 

welches z.B. durch GIMP 36 aus einem Bild generiert werden kann. Die Informationen 

hier beziehen sich auf die Größe des Bildes sowie der Anzahl 

an Bytes, die pro Pixel benötigt werden. Da wir ein RGBA888 Bild erwarten 

werden immer 4 Bytes pro Pixel angenommen. Die Schriftart wird dann im 

Text_Renderer mittels der Funktion set_font festgelegt. 

Generierung von kompatiblen Schriftdaten 

Die beschriebenen Schriftart-Metadaten können mittels des von uns geschriebenen 

C-Exporters im Fontbuilder-Projekt [4] erstellt werden. Dazu kann 

in dem Tool eine beliebige TrueType-Schriftart ausgewählt werden. Unter 

dem “Characters”-Tab sollten alle ASCII-Zeichen von Leerzeichen bis “~” 

in der korrekten Reihenfolge stehen. Schließlich kann im “Output”-Tab der 

C-Exporter gewählt werden. Der C-Exporter unterstützt alle Features der 

anderen Exporter mit Ausnahme der Unterschneidung-Informationen. 

Dateistruktur 

Das Basis-Verzeichnis für alle beschriebenen Dateien ist: 

ipcores.git/drivers/image_bus_overlay_v1_00_a. 

• ./data/image_bus_overlay_v2_1_0.mdd 

Eine von Xilinx generierte Datein, bedarf keiner Beschreibung. 

• ./data/image_bus_overlay_v2_1_0.tcl 

TCL-Skript zum Image Bus Overlay. 

36 http://www.gimp.org/ 

295


• ./src/image_bus_overlay.h 

Die Headerdatei zum Overlay. Diese Klasse beinhaltet Funktionalität 

zum Zeichnen von geometrischen Objekten. 

• ./src/image_bus_overlay.cpp 

Die Quellcodedate zum Overlay. In dieser Datei wird die Programmlogik 

des Overlays beschrieben. 

• ./src/text_renderer.h 

Die Headerdatei zum Text-Overlay. Diese Klasse beinhaltet die Funktionalität 

zum Zeichnen von Texten und Buchstaben. 

• ./src/text_renderer.cpp 

Die Quellcodedatei zum Text-Overlay. Diese Datei beinhaltet die Programmlogik 

des Text-Overlays 

• ./src/font_info.h 

Beinhaltet die Meta-Informationen des Fonts. Dieses existiert, damit 

beliebige Fonts ausgewählt werden können, ohne das diese zur Laufzeit 

bekannt sein müssen. 

• ./src/dejavu_sans_mono_bold_16_data.h 

Dies ist eine konkrete Umsetzung einer Font. 

• ./src/dejavu_sans_mono_bold_16_info.h 

Zusätzlich zur konkreten Umsetzung benötigte Informationen sind 

hier enthalten. 

296


2.10.2 3D Armerkennung - Portierung auf den 

Microblaze 

Ziel dieses Teilpaketes ist die Portierung des 3D-Armerkennungsalgorithmus 

aus dem Abschnitt 2.6.2 für den Microblaze des FPGA in die Programmiersprache 

C++. Genutzt wird dafür die bereits umgesetzte Armerkennung in 

zweidimensionalen Ebene aus dem Kapitel 2.6.4. 

2.10.2.1 Datenstrukturen der Armerkennung 

Für die Umsetzung waren mehrere Datenstrukturen nötig, die von uns 

angelegt wurden. 

Datenstrukturen der Klasse Stereoscopy 

In der Klasse Stereoscopy wurden 

folgende zusätzliche Datenstrukturen angelegt, die für die Umsetzung 

nötig waren. 

struct TwoDVector { 

float x; 

float y; 

}; 

Dieses Konstrukt repräsentiert einen zweidimensionalen Vektor 

struct CenterOfGravityList { 

std :: vector < TwoDVector > cogVectors ; 

}; 

Eine Liste von zweidimensionalen Vektoren, die Schwerpunkte beinhaltet. 

struct DepthList { 

std :: vector < float > values ; 

}; 

Dieses Datenmodel wird im Weiteren benutzt um Tiefeninformationen abzubilden. 

Datenstrukturen der Klasse AngleCalculation 

Für die Implementierung 

der Klasse AngleCalculation wurden zu den bereits vorhandenen Datenstrukturen 

weitere angelegt. 

struct ArmAngleSet { 

std :: vector < float > angles ; 

}; 

Die Winkel der Armgelenke werden in dieser Liste gespeichert. 

297


struct ThreeDVector { 

float x; 

float y; 

float z; 

}; 

Die Abbildung von dreidimensionalen Vektoren wird mittels dieser Struktur 

vorgenommen. 

struct Plane { 

ThreeDVector a; 

ThreeDVector n; 

}; 

Für die Berechnung der Tiefe und der Winkel sind Ebenenmodelle nötig, 

welche mit dieser Datenstruktur abgebildet werden. 

2.10.2.2 Klassen der Armerkennung 

Die Funktionalität wurde in zwei Klassen umgesetzt. Die Eine stellt Methoden 

zur Berechnung der Winkel bereit und die Andere berechnet die 

Tiefenwerte. 

Klasse der Stereoscopy 

Die Klasse Stereoscopy beinhaltet folgende Funktionen: 

Stereoscopy :: Stereoscopy () 

Leerer Konstruktor. 

float Stereoscopy :: calcHypothenuse ( float pixelX , float 

pixelY ) 

Berechnung der Hypothenuse mit Hilfe des Satzes des Pythagoras, welche 

zwei 2D-Vektoren zu einem Dreieck ergänzt. 

float Stereoscopy :: calcDepthPoint ( TwoDVector left , 

TwoDVector right ) 

Berechnet die Tiefe eines Punktes mit Hilfe der stereoskopischen Tiefenformel 

anhand zweier Center-of-Gravities. 

DepthList Stereoscopy :: getAllDepths ( CenterOfGravityList 

cogListLeft , CenterOfGravityList cogListRight ) 

298


Berechnet iterativ die Tiefe aller Schwerpunkte an Hand der Funktion calcDepthPoint. 

CenterOfGravityList Stereoscopy :: calcCogVectors ( 

CenterOfGravityList coglist , DepthList depthlist ) 

Berechnet anhand der Center-of-Gravity-Liste einer Kamera und der dazugehörigen 

Tiefenliste eine 3D-Vektorliste aller Schwerpunkte in Millimeter. 

Dabei werden die Pixelangaben für die Höhe und Breite anhand der Tiefeninformation 

in Millimeter umgerechnet. 

Klasse der Winkelberechnung 

folgende Funktionen: 

Die Klasse Winkelberechnung beinhaltet 

AngleCalculation :: AngleCalculation () 

Konstrukter, Initialisierung der Zustandsvariablen. 

CenterOfGravityList AngleCalculation :: sortPoints ( 

CenterOfGravityList cogList ) 

Sortierung der Listen der Schwerpunkte der Armbinden in Y-Richtung. 

CenterOfGravityList AngleCalculation :: getSortedPose2DList ( 

CenterOfGravityList cogList ) 

Verfolgung der übergebenen Schwerpunkte anhand der minimalen Distanz 

zum Schwerpunkt des letzten Bildes. 

ArmAngleSet AngleCalculation :: calcAngles ( FloatList 

depthlist ) 

Diese Funktion ermittelt Winkel mit Hilfe von trigonometrischen Berechnungen 

und 3D-Vektoren. 

VectorListContainer prepareVectors ( FloatList depthlist ); 

Für die Berechnung der Winkel ist eine Vorverarbeitung der Vektoren nötig. 

Dies wird mit dieser Funktion, welche als Hilfsfunktion von der calcAngles 

aufgerufen wird. 

std :: vector < ThreeDVector > calcTriangleList ( std :: vector < 

ThreeDVector > linkVectors ); 

299


Die Tiefeninformationen werden mittels Dreiecken berechnet, die aus den 

3D-Vektoren gebildet werden. 

ArmAngleSet AngleCalculation :: convertAngles ( ArmAngleSet 

angleList ) 

Wenn mindestens drei Winkel berechnet wurden, also alle Winkel des Roboterarms 

vorhanden sind (der Drehwinkel darf fehlen), dann werden die berechneten 

Winkel auf die Servomotoren umgerechnet. Dies betrifft den letzten 

und vorletzten Winkel. Die Winkel werden übergeprüft anhand von minimalen 

und maximalen Werten. 

float AngleCalculation :: calcAngleFromTriangle ( ThreeDVector 

side ) 

Berechnung eines Winkels anhand eines Dreiecks, mit Hilfe des Kosinussatzes. 

Der Parameter side beinhaltet die drei Seitenlängen des Dreiecks. 

float AngleCalculation :: scalarProduct ( ThreeDVector v1 , 

ThreeDVector v2 ) 

Berechnung des Skalarproduktes zweier Vektoren. 

ThreeDVector AngleCalculation :: crossProduct ( ThreeDVector v1 

, ThreeDVector v2 ) 

Berechnung des Kreuzproduktes anhand zweier Vektoren. 

Plane AngleCalculation :: deriveHyperPlaneNormalForm ( 

ThreeDVector linkPosition , ThreeDVector a , ThreeDVector 

b) 

Berechnet eine Ebene im Raum und gibt diese in der Normalform zurück, 

welche den Normalenvektor und einen Stützvektor der Ebene beinhaltet. 

char AngleCalculation :: decideSide ( Plane plane , ThreeDVector 

x) 

Berechnet auf welcher Seite der Ebene der jeweilige Punkt x liegt. Diese 

Funktion ist notwendig, um sicherzustellen, dass alle Winkel von der selben 

Drehrichtung aus bestimmt werden. Ohne diese Funktion würde immer 

der kleinere Winkel (unter 180 Grad) berechnet werden. Ein Winkel 

über 180 Grad, der am Arm anliegt würde also seine Größe ändern (360 

Grad minus dem Winkel). Dies wird durch oben aufgeführte Funktionen 

300


verhindert bzw. herausgerechnet. Neben den Werten 0 und 1 (Punkt befindet 

sich rechts bzw. links von der Ebene) ist lediglich der Rückgabewert -1 

(Punkt liegt in der Ebene) valide. 


Im Zuge dieses Arbeitspaketes wurden folgende Dateien angelegt. 

• microblazecode/camera/src/main.cc: Programmcode, der die erstellten 

Klassen funktional testet. 

• microblazecode/camera/src/Stereoscopy.h: C++ Header Datei der Tiefenerkennung. 

• microblazecode/camera/src/Stereoscopy.cpp: C++ Datei mit der Implementation 

der Tiefenerkennung. 

• microblazecode/camera/src/AngleCalculation.h: C++ Header Datei 

der Winkelberechnung. 

• microblazecode/camera/src/AngleCalculation.cpp: C++ Datei mit der 

Implementation der Winkelberechnung. 

• microblazecode/camera/src/lscript.ld: Anpassung der Heap- und Stackgröße 

301


2.10.3 Aufbau der dreidimensionalen 


Dieses Arbeitspaket sieht den Aufbau einer Bildverarbeitungskette vor, 

welche auf dem FGPA umgesetzt wird und zwei Bilddatenströme verarbeitet. 

Dieser Aufbau soll die Daten von der VModCam entgegennehmen. 

Der dafür nötige Aufbau wird aus dem Abschnitt 2.2.2 Ansteuerung der 

VModCam genutzt. Ebenso wurde die Bildverarbeitungskette aus dem Kapitel 

2.6.4 Hardware Umsetzung der Bewegungserkennung verwendet. 

2.10.3.1 Bildgröÿen Anpassung 

In der Bildverarbeitungskette werden Bilder von der Kamera verarbeitet, 

welche in der Breite 1600 Pixel und in der Höhe 1200 Pixel groß sind. 

Für die Objekterkennung reichen jedoch Bilder mit der Dimension von 800 

Pixel in der Höhe und 600 Pixel in der Breite in ihrer Genauigkeit aus, 

was bereits bei der Erstellung der Bildverarbeitungskette für die zweidimensionalen 

Armerkennung erkannt wurde. In dem Arbeitsabschnitt 2.6.4 

Hardware Umsetzung von Algorithmen wurde bereits mit kleineren Bildern 

gearbeitet und das Ergebnis der Armerkennung war für die gestellten Anforderungen 

ausreichend. 

1600 pixel 

800 pixel 

1200 pixel 

600 pixel 

Abbildung 2.127: Funktionsweise des pixelSkipping IP-Cores 

Durch das Beschränken auf kleinere Bilder für die Objekterkennung werden 

Ressourcen auf den FPGA eingespart, da weniger Information gespeichert 

werden müssen und somit die Speicher selber kleiner dimensioniert 


302


Für diesen Zweck wurde der pixelSkipping IP-Core erstellt. Dieser Verarbeitet 

einen Bildstrom, so dass dieser anschließend nur noch die halbe 

Höhe und die halbe Breite besitzt. Das wird erreicht in dem jedes zweite 

einkommende Pixel ignoriert wird und ebenfalls jede zweite Zeile. Beispielhaft 

ist das Vorgehen in der Abbildung 2.127 dargestellt. Es werden die 

dunkel markierten Zeilen und Spalten verworfen. 

Der entworfene IP-Core arbeitet auf Bildströmen mit variabler Datenbreit. 

Diese kann mittels des Generics mode gesetzt werden, dabei stehen folgende 

Datenbreiten zur Verfügung. 

• 1 Bit für Schwarzweißbilder 

• 8 Bit für Graubilder 

• 16 Bit für Farbbilder mit RGB555 

• 24 Bit für Farbbilder mit RGB888 

Das Blockschaltbild für den entwickelten IP-Core ist in folgender Abbildung 

2.128 zu sehen. 

pixel_clock 

framevalid_in 

linevalid_in 

datavalid_in 


pixelSkipping_v1_00_a 


linevalid_out 

datavalid_out 

data_out [mode] 

Abbildung 2.128: Blockschaltbild des pixelSkipping IP-Cores 

2.10.3.2 Dreidimensionale Hardware Bildverarbeitungskette 

Die resultierende Bildverarbeitungskette, umgesetzt auf dem FPGA, ist 

schematisch in der Abbildung 2.129 dargestellt. Dabei ist zu sehen, dass der 

von uns für diesen Arbeitsschritt entwickelte IP-Core nach dem Schwellenwert 

IP-Core und vor dem Objekterkennungs IP-Core eingesetzt wird. Der 

Microblaze verarbeitet dann im weiteren die Information über Lage und 

Position der erkannten Objekte. 

303


simple_i2c 


simple_i2c 

VmodCamA 

VmodCamB 

cam_data 

cam_data 





rgb2grey 

rgb2grey 



pixelSkipping 

pixelSkipping 



Interruptcontroller 

Microblaze Microcontroller 

Abbildung 2.129: Bildverarbeitungskette für zwei Kamerabildströme 


Für die Umsetzung dieses Arbeitspaketes wurden folgende Dateien angelegt. 

• ip-cores/pcores/pixelSkipping_v1_00_a/hdl/vhdl/pixelSkipping.vhd: 

Bildverkleinerungs-IP-Core. 

• ip-cores/pcores/pixelSkipping_v1_00_a/hdl/vhdl/simulation/ 

pixelSkipping_tb.vhd: Testbench für den erstellten Bildverkleinerungs- 

IP-Core. 

304


2.10.4 Spezikation eines neuen Roboterarms 

In diesem Teil des Arbeitspakets soll die Spezifikation für einen neuen 

Roboterarm erarbeitet werden. 

Der Beweggrund für dieses Arbeitspaket ist der durch den vorhandenen 

Roboterarm stark eingeschränkte Arbeitsbereich, sodass der aktuelle Aufbau 

weitestgehend unbrauchbar für eine Pick & Place Operation ist. Ziel 

ist es einen Roboterarm zu spezifizieren, mit dem das System in der Lage 

ist, Figuren auf einem Schachbrett Kachel genau zu verstellen. Im Verlauf 

des Pakets werden daher mit Blick auf die Schwachstellen des aktuellen 

Roboterarms Änderungen sowie Verbesserungsvorschläge angegeben. 

Dafür werden in den ersten Abschnitten die nötigen Grundlagen zum Bau 

eines Roboterarms behandelt und im Anschluss auf eine konkrete Spezifikation 

hingearbeitet. 

Auf Basis der gesammelten Daten werden daraufhin mögliche neue Ansätze 

entwickelt und zuletzt die Spezifikation erstellt, welche ebenfalls der 

Entscheidung über die Umsetzung der Folgepakete dient. 

2.10.4.1 Schwachstellen der aktuellen Konguration 

Neben dem eingeschränkten Arbeitsbereich wurden noch weitere Schwachstellen 

ermittelt, welche die instabile Konstruktion und starke Ungenauigkeit 

des Roboterarms verursachen. Diese Schwachstellen sollen daher bei der 

Spezifikation eines neuen Roboterarms mit einbezogen werden. 

• Die Teilarme besitzen an vielen Stellen nicht den gewünschten Winkel 

von 90 Grad. 

• Es entsteht großes Spiel dadurch, dass das Gegenlager eines Teilarms 

einfach in das dünne Kunstoffgehäuse des Servos geschraubt ist, welches 

ebenfalls zu einer niedrigen Wiederholgenauigkeit führt. 

• Da jeder Servo eine eigene Leitung bis zum Hauptcontroller besitzt, 

entsteht eine unstrukturierte Verkabelung. 

• Der Greifer besitzt mehrere mm Spiel in alle Richtungen. 

• Es existiert keine Datenrückmeldung vom Servo des Greifers, sodass 

ein Objekt oder ein Servo im Greifprozess beschädigt werden könnte. 

305


• Der aktuelle kinematische Aufbau erschwert die Berechnung der Rückwärtskinematik. 

Aus diesem Grund wurde statt einer algebraischen 

eine alternative geometrische Lösung entwickelt. Diese bringt jedoch 

eine hohe Komplexität für die Umsetzung auf dem FPGA mit sich. 

Die Portierung der vorhandenen geometrischen Lösung ist daher wesentlich 

fehleranfälliger als eine Umsetzung der Rückwärtskinematik durch 

einen klassischen algebraischen Ansatz. 

2.10.4.2 State of the Art 

In diesem Unterabschnitt werden kurz einige Roboterarmkonfigurationen 

aus den ersten Recherchen vorgestellt, die in Bezug auf eine Pick & Place 

Anwendung interessant sind. 

Kuka 

Bei einem Kuka 37 , dargestellt in Abbildung 2.133, handelt es sich um einen 

Roboterarm mit sechs Freiheitsgraden 38 . Die Konfiguration der Gelenke ist 

bei diesem Roboter so gewählt, dass maximal zwei parallel aufeinanderfolgende 

Gelenkachsen vorhanden sind. 

Puma 

Der Aufbau des in Abbildung 2.131 Puma 39 Manipulators ähnelt dem des 

’Kuka’ und wird ebenso in der Industrie eingesetzt. Dieser besitzt ebenso 

sechs Freiheitsgrade und maximal zwei aufeinanderfolgende parallelen 

Drehgelenke. 

Anmerkung: Die starren Glieder der genannten Manipulatoren sind in der 

Regel wesentlich größer als die länge der Greiferkonstruktion. 

Die Wahl der Größen der Verbindungsstücke bezüglich des Greifers deutet 

auf die Optimierung des Arbeitsbereichs des Manipulators hin. Die Anordnung 

der parallelen Drehgelenke des Roboters vereinfachen im Regelfall 

die Berechnung einer Rückwärtskinematik. 

37 Quelle: OpenRave Model 

38 entspricht einem freien Objekt im Raum 

Quelle: http://curiosityintheclassroom.com/media/pdf/ 

Calculating-Degrees-of-Freedom_HS.pdf 

39 Quelle: OpenRave Model 

306


Abbildung 2.130: Modell des Industrieroboterarms KUKA KR5 

Quelle: OpenRave Model 

Abbildung 2.131: Modell des Industrieroboterarms Puma 

307


Scara 

Der Manipulator von SCARA 40 ist ein kinematisch sehr einfach aufgebauter 

Roboter und eignet sich besonders für Pick & Place Anwendungen. 

Dieser Besitzt zwei parallelen Rotationsgelenke und ein lineares Gelenk. 

Abbildung 2.132 zeigt einen solchen Roboter. 

Abbildung 2.132: Pick & Place Roboter der Fa. SCARA 

Die Einfachheit dieses Roboters ist nicht nur durch Kinematik, sondern 

auch durch die Belastung der Motoren gegeben. Da die Rotationsachsen 

der Motoren parallel zur Gewichtskraft angeordnet sind, entsteht, bis auf 

die Zentrifugalkraft, keine zusätzliche Last beim Bewegen des Armes aus 

der Ruhelage. 

Oomlout Thingiverse Hobby Arm 

Ein Hobby Roboterarm der Manipulator von Thingiverse 41 mit vier Freiheitsgraden. 

Dieser besitzt im Gegenteil zu den vorgestellten Industrierobotern 

drei parallele Gelenkachsen. 

Eine solche Achsenparallelität erschwert in den meisten Fällen die Entwicklung 

einer kinematischen Rückwärtsrechnung und ist daher sehr rechenaufwendig 

und ggf. ohne einen geometrischen Ansatz gar nicht lösbar. Diese Probleme 

des aktuellen Roboterarms in Bezug auf die Kinematik wurden bereits in 

Sprint 2 im Abschnitt 2.2.3 beschrieben. 

40 Quelle: http://img.directindustry.de/images_di/photo-g/scara-roboter-12225- 

2810261.jpg 

41 Thingiverse: http://www.thingiverse.com/thing:387 

308


Abbildung 2.133: Modell des Hobby Roboterarms Oomlout Thingiverse 

2.10.4.3 Anforderungen 

Im Folgenden werden die funktionalen und nicht-funktionalen Anforderungen 

erhoben. Diese setzen sich aus den bereits im Lastenheft festgelegten 

Anforderungen sowie den ermittelten Schwachstellen zusammen. Weiter 

muss der festgelegte Pick & Place Demonstrator, die Bewegung einer 

Schachfigur auf einem Schachbrett, berücksichtigt werden. 

Funktional 

Im Folgenden sind die Eigenschaften aufgelistet, welche der Roboterarm 

besitzen muss. 

F1 Der Roboterarm muss mit einem Greifer als TCP ausgestattet sein. 

F2 Der Roboterarm muss eine Standard-Schachfigur 42 heben und ablegen 

können. 

F3 Die Wiederholgenauigkeit muss ausreichen, um die Figuren kachelgenau 

zu positionieren. 

F4 Der Greifer muss über eine Datenrückleitung für den aktuellen Stromverbrauch 

verfügen. 

42 Die maximalen Größe und Gewicht der Schachfigur wird im Weiteren definiert 

309


Nicht-Funktional 

Folgender Abschnitt definiert die Rahmenbedingungen der oben beschriebenen 

Eigenschaften. 

• Benutzbarkeit 

NF 1.1 Die Plattform des Roboterarms muss an einer senkrechten, 

stationären Befestigung fixiert werden können. Durch diese Befestigung 

ist der Roboterarm um 90 Grad in die Waagerechte 

gedreht. 

NF 1.2 Es existieren nicht mehr als zwei parallele Achsen der hintereinander 

folgenden Gelenke. 

NF 1.3 Objekte werden nur von Oben gegriffen und abgesetzt. 

• Effizienz 

NF 1.2 Der Roboterarm muss Objekte mit einem Gewicht von mindestens 

50g tragen können. 

NF 1.3 Der Roboterarm muss ein Objekt mit einer Mindestgröße von 

5mm ∗ 5mm ∗ 5mm und einer Maximalgröße von 95mm ∗ 40mm ∗ 

40mm greifen können. 

NF 1.4 Der Roboterarm muss einen Arbeitsbereich besitzen, der mindestens 

die durchgehende Fläche eines Schachfelds von 46, 4cm ∗ 

46, 4cm abdeckt 43 . 

NF 1.5 Der Roboterarm muss in der Lage sein, eine Figur zu versetzen, 

ohne dabei die Position anderer Figuren zu verändern. 

sowie die Schachfiguren über den anderen darauf stehenden Figuren 

auf einen Sicheren Abstand hochheben kann. Der Sichere 

Abstand ist der, bei dem durch das Verschieben der Schachfigur 

keine auf dem Brett stehenden Figuren getroffen werden. 

NF 1.6 In Verbindung mit dem Gesamtsystem darf eine Latenz von 

500ms nicht überschritten werden. 

NF 1.7 Es existieren nicht mehr als zwei parallele Achsen der hintereinander 

folgenden Gelenke. 

• Änderbarkeit 

NF 1.8 Der Greifer des Roboterarms muss austauschbar sein. 

43 Quelle: http://de.wikipedia.org/wiki/Schachbrett - Material der Schachbundesliga 

310


80° 

0° 

180° 

0° 

0° 

180° 

0° 

180° 

0° 

x 

180° 

NF 1.9 Die Servos müssen durch alternative Motoren mit den selben 

Abmessungen austauschbar sein. Hierzu muss jedoch eventuell 

die Regelungselektronik entsprechend angepasst werden. 

2.10.4.4 Erarbeitung der Grundlagen 

G5 

l 

G 5 

5 G 4 

In diesem Abschnitt sollen die bei der Spezifikation eines Roboterarms 

wichtigen Teilgebiete analysiert werden. Auf der geschaffenen 

w 

Basis werden 

daraufhin 0° mögliche Lösungen entwickelt. w 3 

6 

4 w w 5 w G4 

w G3 

180° 

Arbeitsbereich 

l G 

l 6 

l7 

G 

w 

6 w G6 

7 

G 

Im Folgenden werden die Kriterien an den Arbeitsbereich festgelegt. 

Der Arbeitsbereich des aktuellen Roboterarms, beschrieben in 2.35, deckt 

die Fläche des in den Anforderungen festgelegten Schachbretts nicht ab. 

Aus diesem Grund muss der neue Roboterarm einen größeren Arbeitsbereich 

besitzen, so dass in der horizontalen Ebene die komplette Fläche 

eines Schachbretts umschlossen werden kann. 

w G5 

l 4 

G 3 

l 3 

w 2 

w G1 

w 1 

w G2 

G 2 

G3 

l 1 

l 2 

G 1 

l B 

+10% 

y 

x 

Abbildung 2.134: Schachbrett der Standard-Größe innerhalb des Arbeitsbereiches 

Die grün gestrichelten Kurven in Abbildung 2.134 zeigen die minimale 

äußere und innere Grenze des benötigten horizontalen Arbeitsbereichs. 

Dabei muss bei der Berechnung der minimalen Gesamt-Armlänge auch 

der Abstand vom Sockel bis zum Schachbrett (x) beachtet werden. 

311


Aus der Größe des Schachbretts sowie einem Erreichbarkeitspuffer von 

10% kann daraufhin die benötigte Gesamt-Armlänge berechnet werden. 

Diese Länge wird verwendet, um im späteren Verlauf die Maße der starren 

Glieder des Roboterarms sowie die Drehmomente der einzusetzenden 

Servos ermitteln zu können. 

Abbildung 2.135 zeigt beispielhaft den resultierenden horizontalen Arbeitsbereich 

bei einer an den Kuka Roboter 2.133 angelehnten Gelenkkonfiguration. 

Abbildung 2.135: Arbeitsbereich des Roboterarms 

Kinematischer Aufbau 

Die aktuell eingesetzte Kinematik basiert auf dem zu Anfang des Projektes 

zur Verfügung gestellten Roboterarm RA1-PRO der Fa. Arexx. Dieser 

besitzt sechs starre Verbindungsstücke, fünf Gelenke sowie sechs Servos. 

Aus der Gelenkkonfiguration resultieren fünf Freiheitsgrade. Aufgrund der 

kurzen Teilarme ist der Roboterarm in der Erreichbarkeit von Punkten im 

Raum trotzdem sehr eingeschränkt: Der Arbeitsbereich ist mehrere Ordnungen 

kleiner, als für den o.g. Anwendungsfall benötigt ist. Die Verdrehung 

des Greifers bezüglich des Weltkoordinatensystems ist nur um 

eine Achse möglich, die parallel zum zweiten und dritten Gelenk verläuft. 

Die aktuelle Rückwärtskinematik basiert auf dem speziell für die vorhandene 

Gelenkkonfiguration entwickelten geometrischen Modell. Diese berück- 

312


sichtigt dabei nicht die Pose des Greifers, so dass ein Punkt im Arbeitsbereich 

erreicht wird, ohne dabei die Ausrichtung des Greifers bezüglich des 

Weltkoordinatensystems gezielt angeben zu können. Die Ausrichtung wird 

durch die aktuelle Rückwärtskinematik je nach der Lage des Punktes im 

Arbeitsbereich bestimmt. 

Abbildung 2.136: Arbeitsbereich des Roboterarms 

Aus diesem Grund ist die aktuelle Kinematik nicht für den Anwendungsfall 

„Schachfiguren auf dem Schachbrett bewegen“ geeignet, da das nötige 

Greifen von oben nicht möglich ist. Daher kann der in Abbildung 2.136 

dargestellte Fall auftreten und nicht beteiligte Schachfiguren können während 

eines Greifvorgangs umgekippt werden. 

Für die Spezifikation ergeben sich bzgl. der Rückwärtskinematik zwei Möglichkeiten. 

Beibehalten der aktuellen Kinematik 

In diesem Fall wird die vorhandene Kinematik weiterverwendet. Dies schließt 

jedoch jede Änderung von möglichen Gelenkkonfigurationen des Roboterarms 

aus. Es wäre jedoch weiterhin möglich die Verbindungsstücke zu verlängern, 

um einen größeren Arbeitsbereich zu erzielen. In diesem Fall muss 

die Rückwärtskinematik angepasst werden, damit der Roboter die Objekte 

von oben greifen kann. Somit müsste ein neuer Roboter gebaut werden. 

Wird der aktuelle Roboterarm beibehalten und die Rückwärtskinematik 

nicht angepasst, ist das Greifen der Figuren nur bedingt möglich, da die in 

der Nähe stehenden Schachfiguren leicht getroffen werden. 

313


Entwicklung einer neuen Kinematik 

Die zweite Möglichkeit lässt Freiraum für individuelle Gelenkkkonfigurationen, 

würde jedoch auch als Folgearbeitspaket die Entwicklung einer 

gänzlich neuen Vor- sowie Rückwärtskinematik nach sich ziehen. Aufgrund 

des Freiraums ist es aber auch möglich, eine Konfiguration zu wählen, 

sodass eine analytische bzw. numerische Lösung bei der Entwicklung einer 

Kinematik angesetzt werden kann. Diese sind gemeinhin einfacher zu 

ermitteln als eine spezialisierte geometrische Lösung. 

Aktorik 

Da seit Beginn der Projektgruppe bereits mehrere Servos aufgrund eines 

Defekts ausgetauscht werden mussten und der mitgelieferte Greiferaufbau 

starke Ungenauigkeiten mit sich bringt, werden in diesem Kapitel Anforderungen 

an die Aktorik gestellt und ggf. bereits Alternativen vorgestellt. 

Servos 

Da die Servos des Roboterarms einen entscheidenden Punkt zur Stabilität, 

Genauigkeit und Traglast beitragen, werden in diesem Kapitel Anforderungen 

sowie die Grundlagen zur Berechnung der nötigen Drehmomente behandelt. 

Anforderungen 

In diesem Abschnitt werden die ermittelten Anforderungen an die zu nutzenden 

Servos aufgeführt. 

• Um eine höhere Stabilität zu erreichen sollen die Servos mit der höchsten 

Belastung an beiden Seiten des Servos mit einer Befestigungsmöglichkeit 

ausgestattet sein. 

• Die genutzten Servos sollten mit den gleichen Spannungen arbeiten. 

• Die genutzten Servos sollen mindestens einen Betriebsbereich von 180 

Grad besitzen. 

• Das Drehmoment der Servos muss ausreichen, um einen Roboterarm 

zu konstruieren, welcher im definierten Arbeitsbereich operieren 

kann. 

314


• Die Genauigkeit der Servos muss ausreichen, um die in den Anforderungen 

an den Roboteram beschriebene Wiederholgenauigkeit 

erreichen zu können. 

• Die Geschwindigkeit der Servos muss ausreichen, um die in den Anforderungen 

beschriebene Latenzzeit einhalten zu können. 

• Aufgrund der höheren Stellkraft und Stellgenauigkeit, im Vergleich 

zur analogen Variante, werden digitale Servos verwendet. 

Anmerkung: Auf dem Markt existieren einige Servotypen, die eine serielle 

Datenrückführung besitzen. Bei Verwendung eines solchen Servo- 

Typs könnte die im Anschluss an dieses Arbeitspaket geplante Entwicklung 

einer Platine zur Strommessung entfallen. Jedoch würde stattdessen 

die Implementierung eines IP-Cores zur seriellen Kommunikation nötig. 

Berechnung der Traglasten für die Servos 

Nach der Festlegung der Längen der Verbindungsstücke sowie der Anordnung 

der Gelenke und des maximal zu hebenden Objektgewichts, w 3 

istG eine 

3 

passende Servoauswahl nötig. Der Rechenweg, um das nötige w 4 

Drehmoment 

zu ermitteln wird daher im Folgenden 

w 2 

erläutert. 

l 

M 

l 2 

l 1 

w 1 

G 2 

G 1 

M 

l 

Abbildung 2.137: Drehmoment (M) 

F 

F 

Das Drehmoment ist definiert als Produkt der Länge des Hebels und der 

momentan auf diesen Hebel wirkenden Punktkraft in einem Kreis mit dem 

Radius der Länge des Hebels. In Abbildung 2.137 ist die Wirkungsrichtung 

der Kraft und des Drehmoments veranschaulicht. 

Aus der Gleichung des Drehmoments 

M = ⃗ F · l (2.16) 

315


folgt, dass das benötigte Drehmoment einerseits von der Länge des Teilarms 

sowie von dessen und dem sich am Armende befindlichen Gewicht abhängt. 

Die allgemeine Berechnung des Drehmoments für einen Servo in 

einer kinematischen Kette ist definiert als Summe aller Drehmomente, die 

sich aus den Gewichten der jeweiligen Punkte und ihrer Entfernung vom 

tragenden Servo zusammensetzen. 

In Abbildung 2.138 ist beispielhaft die Formel für einen Teilarm vorgestellt. 

Das benötigte Drehmoment eines Servos in der kinematischen Kette ist 

l 2 

l 1 

w 3 

G 3 

w 1 

F 

w 4 

w 2 

G 2 

G 1 

Abbildung 2.138: Berechnung des Drehmomentes für den Servomotor G 2 

beispielhaft wie folgt gegeben: 

M = w 1 · l1 

2 + l 1 · w 2 + (l 1 + l 2 

2 ) · w 3 + (l 1 + l 2 ) · w 4 (2.17) 

Die Gleichung 2.17 zeigt die sequentielle Addition der Produkte von Länge 

und Gewicht des Punktes. Wobei w 1 und w 3 jeweils die Gewichte der 

Verbindungsstücke mit den Längen l 1 und l 2 sind. w 2 und w 4 stellen die 

Gewichte des Gelenks G 3 und des Endeffektors dar. Um den Gesamtmittelpunkt 

eine Verbindungsstücks anzunehmen, werden die Gewichte der 

Verbindungsstücke halbiert. Liegt der Gewichtsmittelpunkt nicht in der 

Mitte des Verbindungsstücks, so ist er zu bestimmen und anhand dessen 

die Entfernung des Gewichtsmittelpunktes zur Drehachse des Servos zu 

berechnen. Die Gewichte von Servos, Endeffektor und der Teilarme sind 

nicht direkt in die Gleichung 2.16 einsetzbar. Daher wird für w i angenommen, 

dass w i eine Schwerkraft besitzt, die sich aus dem Produkt der Masse 

m i des jeweiligen Punktes und der Gravitationskonstante von 9, 81m/s 2 

bestimmen lässt. 

316


Servo-Überblick 

Die exakte Auswahl der Servos kann erst nach der Berechnung der benötigten 

Drehmomente für einen neuen Roboterarm erfolgen. In diesem Abschnitt 

wird daher ein kurzer Überblick über einige, im Bereich der Robotik genutzte, 

Servotypen gegeben. Diese sollen als Alternative zu den aktuell genutzten 

Servos in Tabelle 2.8 in Frage kommen. 

Benötigt werden Servos für die folgenden Bestandteile: 

• Servo für die Basis 

• Servos für Verbindungsstücke (möglichst mit bereits vorhandenem 

zweitem Lager auf der Servorückseite) 

• Servo für Greifer (möglichst mit Datenrückkanal) 

Hersteller von Servos für den Robotik Bereich sind unter Anderem die Fa. 

Hitec, Futaba oder auch Dynamixel. Im Folgenden Unterabschnitt erfolgt 

eine kurze Vorstellung der in Abbildung 2.139 dagrestellten Servos. 

Zur Vergleichbarkeit werden im Folgenden die wichtigsten Daten der aktuellen 

Servos aufgeführt. Beide Servos basieren dabei auf einem Metallgetriebe. 

Abbildung 2.139(a) zeigt den Stärkeren der beiden sich aktuell im 

Einsatz befindlichen Servos. 

44 45 

Typ Größe Gewicht 4.8 6V 

- mm gramm sek/60 ° kg-cm sek/60 ° kg-cm 

S05NF 28.8*13.8*30.2 20 0.20 2.8 0.18 3.2 

S06NF 40.4*20*37.6 56 0.18 13 0.16 13.5 

Tabelle 2.8: Servospezifikationen der Fa. Dago Metall 

• HSR-8498HB 46 

Abbildung 2.139(b) zeigt einen Servo der Fa. Hitec. Dieser besitzt ein Karbongetriebe 

und wird mit einer 2-seitigen Montagemöglichkeit geliefert. 

Der Betriebswinkel beträgt 0 - 180 Grad. 

44 S05NF: http://www.robotshop.com/s05nf-std-servo-motor-2.html 

45 S06NF: http://www.robotshop.com/s06nf-std-servo-motor-2.html 

46 Quelle: http://www.hitecrc.de/store/product.php?productid=21377&cat=312&page=1 

317


(a) S06NF 

(b) HSR-8489HB 

(c) AX-12A 

Abbildung 2.139: Servo-Überblick 

• HSR-5498SG 47 

Bei diesem Servo handelt es sich um eine stärkere Variante des HSR-8498SG 

Modells. Sie besitzt ein Metallgetriebe, 2-seitige Montagemöglichkeit und 

einen Betriebswinkel von 0 - 180 Grad. 

Beide Servos verfügen über eine Datenrückführung welche Strom, Spannung 

und Position beinhaltet. Eingesetzt wird dabei das serielle HITEC 

Multi-protocol interface (HMI). Tabelle 2.9 zeigt die Spezifikation beider 

Servos. 

Die Servos der der Fa. Dynamixel bieten ebenfalls eine Datenrückführung, 

besitzen jedoch mit Ausnahme der AX-Serie in der Regel ein sehr hohes 

Drehmoment und einen daraus resultierenden sehr hohen Stromverbrauch. 

Benötigt werden dabei Spannungen von um die 10V. Interessant ist die 

Möglichkeit der Serienschaltung dieser Servos. Somit muss vom Hauptcontroller 

lediglich ein Kabel zu einem im Netz vorhandenen Servo gelegt 

werden. Diese können daraufhin durch feste IDs über ein serielles Protokoll 

47 Quelle: http://www.hitecrc.de/store/product.php?productid=21392&cat=312&page=1 

318


Typ Größe Gewicht 6V 7.4V 

- mm gramm sek/60 ° kg-cm sek/60 ° kg-cm 

HSR-8498HB 40*20*47 55 0.2 7.4 0.18 9.0 

HSR-5498SG 40*20*37 59.8 0.22 11 0.19 13.5 

Tabelle 2.9: Servospezifikationen der Fa. Hitec 

angesteuert und ausgelesen werden. Weiterhin verfügen die Modelle über 

einen Betriebswinkel von 0 - 300 Grad. 

• AX-12A 48 

Dieser Servo, dargestellt in 2.139(c) besitzt ein vergleichsweise hohes Drehmoment, 

jedoch eine geringe Stellgeschwindigkeit gegenüber den Anderen 

hier aufgeführten Servotypen. In Tabelle 2.10 ist Spezifikation des Servos 

aufgeführt. 

Typ Größe Gewicht 12V 

- mm gramm sek/60 ° kg-cm 

AX-12A 32*50*40 54.6 0.08 15.29 

Tabelle 2.10: Servospezifikationen der Fa. Hitec 

Greifer 

In diesem Abschnitt werden die Anforderungen an den Greifer als Tool 

Center Point (TCP) gestellt und mögliche Greifertypen ermittelt. 

Anforderungen 

Der einzusetzende Greifer muss folgenden Anforderungen genügen. 

• Der Greifer muss in der Lage sein, jeden Schachfigur-Typ zu greifen. 

• Die maximale Breite des geöffneten Greifers soll die Länge der Diagonale 

einer Kachel nicht überschreiten. 

48 Quelle: http://www.robotis.com/xe/dynamixel_en 

319


• Der Greiferaufbau muss schmal genug sein, um eine einzelne Figur 

greifen und ablegen zu können. So wird das Treffen einer nebenstehenden 

Figur vermieden. 

• Das Greifen erfolgt über Kraftschluss. 

• Wenn nötig kann die Greifertechnik um Formschluss erweitert werden. 

320


Greifer-Überblick 

Da der gewählte Pick & Place Demonstrator keine hohe Komplexität an 

das Greiferdesign stellt, werden in diesem Abschnitt einige einfache Umsetzungen 

aufgeführt. 

(a) Gripper for Micro Robot Arm 

(b) Mini servo gripper Plate 

(c) Gripper for Multirotor 

Abbildung 2.140: Greifervarianten - Quelle: http://www.thingiverse.com 

Alle in Abbildung 2.140 dargestellten Greifervarianten 49 besitzen einen einfachen 

Aufbau und benötigen einen Servo zum Öffnen bzw. Schließen. 

Der erste Greifer 2.149(a) ist sehr einfach aufgebaut und weiterhin gut um 

Formschluss oder Kraftsensorik erweiterbar. Abbildung 2.149(b) stellt den 

Aufbau des aktuell eingesetzten Greifers dar. In 2.140(c) wird ein weiterer 

Greifertyp vorgestellt, der jedoch in Bezug auf den Anwendunsfall bereits 

ausgeschlossen werden kann, da das Greifen einer einzelnen Schachfigur 

schwieriger zu realisieren ist als mit den vorherigen vorgestelleten Greifern. 

49 Quelle: http://www.thingiverse.com/ 

321


Sensorik 

Die am Roboterarm geplante Sensorik betrifft in erster Linie eine Rückführung 

des Greiferzustands, um zu ermitteln, ob ein Objekt bereits gegriffen 

wurde. Zur Realisierung stehen unterschiedliche Ansätze zur Auswahl. 

• Rückkopplung durch Kraftmessung 

– In diesem Fall wird der Greifer mit zusätzlichen Sensoren zur 

Kraftmessung ausgestattet. 

• Servos mit Datenrückleitung 

– Wie in Abschnitt beschrieben, können Servos eingesetzt werden, 

bei welchen über einen Rückkanal unter Anderem der aktuelle 

Stromverbrauch ausgelesen werden kann. 

• Entwicklung einer Strommessplatine 

– Es wird eine zusätzliche Platine entwickelt, die eine Strommessung 

der Servos ermöglicht. Bei diesem Ansatz muss beachtet 

werden, dass die Platine im Design des Roboterarms berücksichtigt 

wird. 

2.10.4.5 Ansätze neuer Roboterkongurationen 

Ansatz 1: Roboterarm auf Basis des KUKA mit 6 Freiheitsgraden (DOF) 

Die Gelenkkonfiguration dieses Ansatzes basiert auf der Idee eines Kuka 

Roboterarms. Durch eine geschickte Anordnung und Wahl der Gelenkachsen 

wird in der Regel die Entwicklung der Kinematik stark vereinfacht. 

Da diese Konfiguration zur Umsetzung der meisten von der Projektgruppe 

definierten Demonstratoren genutzt werden kann, erfolgt in diesem Abschnitt 

eine genauere Spezifikation. Anmerkung: Die in den Grundlagenkapiteln 

erarbeiteten Inhalte können jedoch ebenso auf andere Konfigurationen angewendet 

werden. 

Aufbau 

In diesem Abschnitt wird die Konfiguration und der Aufbau des neuen 

Roboterarms vorgestellt. Abbildung 2.141 zeigt die kinematische Konfiguration 

des Roboters. 

322


Abbildung 2.141: Kinematische Konfiguration des neuen Roboarms 

Dieser besitzt sechs Gelenke, durch die der Roboterarm über sechs Freiheitsgrade 

verfügt. 

Eine solche Konfiguration wurde gewählt, um einerseits den beschriebene 

Pick & Place Anwendungsfall umzusetzen, den Roboterarm jedoch auch 

für die weiteren geplanten Demonstratoren nutzen zu können. Zusätzlich 

existieren für eine solche Gelenkkonfiguration bereits Kinematiklösungen, 

da es weniger Schwierigkeiten bei der Rückwärtsrechnung gibt als bei der 

Konfiguration des aktuellen Roboterarms. 

In Abbildung 2.142 sind die Winkelgrenzen der Rotations- und Torsionsgelenke 

veranschaulicht 50 . Die rot gestrichelte Linie entlang der Grenze 

des dritten Servos zeigt die mögliche Pose des Roboterarmes bei gestrecktem 

Teilarm ab dem dritten Gelenk. Der Teilarm darf nicht mit dem Nachbarteilarm 

kollidieren und sich bei voller Ausstreckung nicht weiter zum 

Ursprung des Weltkoordinatensystems (WKS) nähern. Daher wird der Servo 

am dritten Gelenk so angebracht, dass die beschriebene Pose direkt 

der Endlage des Servos entspricht. Die Pose folgt aus der Einschätzung 

der Position des Schachbretts zum Fußpunkt (Base) des Roboterarms. Der 

Abstand x zeigt den minimal möglichen Abstand des Schachbretts zum 

Roboterarm. 

Bestimmung der Längen 

Im Folgenden werden werden die Längen der Verbindungsstücke, des Greifers 

sowie die Drehmomente der Servos formalisiert. 

Für die Berechnung der Längen wird als Einstiegspunkt die Größe eines 

Standard-Schachbretts angenommen und in diesem Abschnitt mit dem 

Buchstaben b definiert. Die Länge des Greifers sowie die Höhe der Base 

50 Dabei werden Servos mit einem Betriebsbereich von 180 Grad angenommen 

323


0° 

180° 

0° 

0° 

180° 

180° 

0° 

180° 

0° 

0° 

180° 

x 

180° 

Abbildung 2.142: Ausrichtung der Arbeitsbereiche der Servos 

werden ausgehend von den Schachfigurhöhen, der Beschaffenheit des Greifers 

sowie seines Verbindungsstücks bestimmt. 

Anschließend werden die Längen der restlichen Verbindungsstücke ermittelt. 

Aus den Längen und Gewichten der Verbindungsstücke und des Greifers 

werden daraufhin die benötigten Drehmomente berechnet. 

In Abbildung 2.144 ist das Prinzip zur Bestimmung der Greiferlänge vorgestellt. 

l GrLot 

Greifmechanis 

mus 

+ 

Torsionsmecha 

nismus 

l mech 

G 5 

G 2 

G 6 

Greiferlänge 

l 

>0 

G 

F DIFF 

Baselänge l B 

G 1 

l Kopf 

Abbildung 2.143: Längen des Greifers und des Base 

Beim Greifen von kleinen Schachfiguren muss darauf geachtet werden, 

dass der Greifmechanismus nicht mit höheren Schachfiguren kollidiert. 

Aus diesem Grund muss die Greiferhöhe mindestens der Differenz F DIFF 

324


aus der höchsten und der niedrigsten Figur entsprechen. Weiter muss der 

Greifer in der Lage sein, den Kopf der kleinsten Schachfigur zu greifen. 

Daher wird die mittlere Höhe der Köpfe aller Figuren l Kop f hinzuaddiert. 

Die letzte Länge wird durch den Greifmechanismus selbst l mech sowie das 

Lot l GrLot des Verbindungsstücks zum fünften Gelenk bestimmt. Daraus 

ergibt sich die Gesamte Länge l G des Greifers wie folgt: 

l G = F DIFF + l Kop f + l mech + l GrLot (2.18) 

Die Länge l B des Base wird unter Berücksichtigung des Anwendungsfalls 

zum Greifen der niedrigsten Schachfigur berechnet. Sie setzt sich aus der 

Länge des Greifers l G und der Höhe der niedrigsten Schachfigur h klSch ohne 

Kopfhöhe l Kop f zusammen: 

l B = l G + h klSch − l Kop f (2.19) 

Angenommen werden Schachfigurhöhen von maximal 9cm und minimal 

4, 5cm, sowie eine Kopfhöhe von l Kop f = 1, 5cm. Weiter wird ein Schätzwert 

von l mech = 5cm für den Greifmechanismus sowie für die Strecke des Lots 

zum fünften Gelenk von l GrLot = 6cm gewählt. Somit ergeben sich für den 

Greifer eine Höhe von l G = 17cm und eine Höhe von l B = 20cm für den 

Base. 

Im Folgenden werden die Längen der restlichen Verbindungsstücke berechnet. 

+10% 

y 

b 

c 

x 

a 

Abbildung 2.144: Minimal benötigte Länge des Teilarmes. Sicht von oben 

325


Abbildung 2.144 zeigt das Schachbrett sowie den interessanten Teil des Arbeitsbereiches 

von oben. Da bei der festgelegten, senkrechten Greifertechnik 

die Längen des Greifers l G und der Base l B für die maximale Reichweite 

nicht relevant sind, werden diese zunächst vernachlässigt. Die Länge 

c ist die, vom Fußpunkt des Roboterarms gesehen, minimal zu erreichende 

Strecke, die benötigt wird, um den am weitesten entfernten Punkt des 

Schachbretts erreichen zu können. Diese wird mit dem Satz des Pythagoras 

als Hypotenuse eines rechtwinkligen Dreiecks bestimmt. Die Kathete 

b setzt sich aus der Brettseite y und dem minimalen Abstand x vom Brett 

zum Fuß des Roboters zusammen. Kathete a ist genau die Hälfte der Seitenlänge 

des Schachbretts y, also a = y/2. 

l L2 

l L1 

l G 

l B 

Abbildung 2.145: Längen der restlichen Verbindungsstücke 

In Abbildung 2.145 wird der Roboterarm nun seitlich zum Betrachter dargestellt. 

Die c muss sich daher aus der Summe der Teilstücke l L1 und l L2 zusammensetzen: 

c = l L1 + l L2 (2.20) 

Die Pose des Greifers in Abbildung 2.144 entspricht dem zum Fußpunkt 

des Roboters nahegelegendsten Punkt auf dem Schachbrett. Dabei gilt: 

Nach Umstellung der Gleichung 2.20 nach l L1 : 

l L1 + l B = l L2 + l G (2.21) 

l L1 = c − l L2 (2.22) 

326


und einsetzen dieser in die 2.21 ergibt sich: 

und folglich 

c − l L2 + l B = l L2 + l G (2.23) 

l L2 = c − l G + l B 

. (2.24) 

2 

Damit kann l L1 aus der gewonnenen Gleichung 2.22 ermittelt werden. 

Mit den erfassten Werten für l G = 17cm und l B = 20cm, dem geschätzten 

Abstand x = 10cm sowie der Seitenlänge des Bretts y ergeben sich die 

Werte für l L1 und l L2 . 

Bestimmung der Massen 

Nachdem alle Längen der Verbindungsstücke bekannt sind, werden die 

Massen der Verbindungsstücke bestimmt. Als Material wird Aluminium 

angenommen. Die Dicke der jeweiligen Verbindungsstücke werden jeweils 

mit 0.3cm und die Breite mit 4cm angenommen. Da ein Verbindungsstück 

so leicht wie möglich gestaltet werden soll, wird das errechnete Gewicht 

mit 2/3 multipliziert um sich dem realen Bauteil anzunähern. Aus der Aluminiumdichte 

von 2, 7 gr ergeben sich somit die Masse m 

cm 3 i der Verbindungsstücke 

i. In 2.25 wird beispielhaft die Masse für den Teilarm l 3 berechnet, siehe 

Abbildung 2.147. 

m 3 = 32, 05cm ∗ 4cm ∗ 0, 3cm ∗ 2, 7 gr ∗ (2/3) = 69, 228 (2.25) 

cm3 Da die ermittelten Werte der groben Bestimmung der benötigten Drehmomente 

dienen, werden diese jeweils aufgerundet. 

327


Abbildung 2.146 zeigt die bestimmten Längen und Massen. Der Rechenweg 

zur Bestimmung der Mindestdrehmomente erfolgt im nächsten Abschnitt. 

Abbildung 2.146: Berechnung der Drehmomente 

Bestimmung der Drehmomente 

Die benötigten Drehmomente werden durch die Schwerkräfte w i und die 

Längen l i bestimmt. In Abbildung 2.147 sind die relevanten Längen und 

Gewichtspunkte angegeben, die für Berechnung der Drehmomente der 

gewählten Roboterkonfiguration notwendig sind. Die Schwerkraft ⃗w i für 

die nachfolgenden Berechnungen ist definiert als eine Skalare Einheit und 

als Produkt der Masse und der Erdbeschleunigung von 9, 81 m/s 2 

w i = m · 9, 81 m/s 2 = kg · m/s 2 (2.26) 

Die Drehmomente werden hier nur für die Gelenke G 2 , G 3 , G 4 sowie G 5 

berechnet. Bei den Gelenken G 1 und G 6 handelt es sich um Torsionsgelenke, 

auf die verhältnismäßig wenig Last ausgeübt wird. Mit der grünen 

Farbe sind die Schwerkräfte der Verbindungsstücke und mit der schwarzen 

Farbe die Schwerkräfte der Gelenke gekennzeichnet. Die Längen sind mit 

roter Farbe gekennzeichnet. 

M G4 = (l 6 /2) · w 6 + l 6 · w G6 + (l 6 + l 7 /2) · w 7 + (l 6 + l 7 ) · w G (2.27) 

M G5 = M G4 (2.28) 

328


w G5 

l 5 

G 5 G 4 

l 4 

G 3 

l 3 

w G2 

G 2 

180° 

l G 

l 6 

l7 

w 6 

w 5 

G 

w 

6 w G6 

7 

G 

w G4 

w 4 

w G3 

w 3 

w 2 

w G1 

G3 

l 1 

w 1 

l 2 

G 1 

l B 

Abbildung 2.147: Modell der Gelenkgenkonfiguration mit Längen und 

Gewichten 

+20% 

M G3 =(l 4 /2) · w 4 + l 4 · w G4 + (l 4 + l 5 /2) · w 5 + 

(l 4 + l 5 ) · w G5 + (l 4 + l 5 + l 6 /2) · w 6 + 

y 

(2.29) 

(l 4 + l 

x 

5 + l 6 ) · w G6 + (l 4 + l 5 + l 6 + l 7 /2) · w 7 + 

(l 4 + l 5 + l 6 + l 7 ) · w G 

M G2 =(l 3 /2) · w 3 + l 3 · w G3 + (l 3 + l 4 /2) · w 4 + 

(l 3 + l 4 ) · w G4 + (l 3 + l 4 + l 5 /2) · w 5 + 

(l 3 + l 4 + l 5 ) · w G5 + (l 3 + l 4 + l 5 + l 6 /2) · w 6 + 

(2.30) 

(l 3 + l 4 + l 5 + l 6 ) · w G6 + (l 3 + l 4 + l 5 + l 6 + l 7 /2) · w 7 + 

(l 3 + l 4 + l 5 + l 6 + l 7 ) · w G 

Nach dem Einsetzen in die Gleichungen 2.27, 2.28, 2.29 sowie 2.30 ergeben 

sich folgende Drehmomente M Gi für die jeweiligen Gelenke G i mit i ∈ 

{2, 3, 4, 5}: 

M G5 = 0.361473Nm 

M G4 = 0.361473Nm 

M G3 = 1.759807Nm 

M G2 = 3.831772Nm 

Als Vergleich sowie zur Evaluierung der aufgestellten Formeln werden im 

Folgenden die Drehmomente für die Gelenke der aktuellen Roboterkonfiguration 

aus Abbildung 2.148 berechnet: 

329

l 6 

w 6 

w 5 

4 

2 

l7 

G 

w 

6 w G6 

7 

w G 


l G 

G 4 

l G 

G 5 

l 3 

w Gr w G5 w 3 

l 2 

w w 2 

G4 w G3 w 1 

G 3 

l 1 

G 2 

G 1 

Abbildung 2.148: Konfiguration des alten Roboterarms 

Die Massen sowie Längen wurden von der bestehenden Hardware abgemessen: 

l 1 = 10, 5cm, l 2 = 12cm, l 3 = 6cm, die Greiferlänge l G = 105cm. Die Massen 

sind m 1 = 24gr, m 2 = 26gr, l 3 = 15gr sowie Masse des Greifers l G = 90gr. 

Die Drehmomente werden nach dem Prinzip aus Abschnitt 2.10.4.4 berechnet: 

M aG4 = (l 3 /2) · (w 3 + w G5 ) + (l 3 + l G /2) · w G (2.31) 

M aG3 =(l 2 /2) · w 2 + l 2 ∗ w G4 + (l 2 + l 3 /2) · (w 3 + w G5 ) 

+ (l 2 + l 3 + l G /2) · w G 

(2.32) 

M aG3 =l 1 /2 · w 1 + l 1 · w G3 + (l 1 + l 2 /2) · w 2 + (l 1 + l 2 ) ∗ w G4 + 

(l 1 + l 2 + l 3 /2) · (w 3 + w G5 ) + (l 1 + l 2 + l 3 + l G /2) · w G 

(2.33) 

Nach dem Einsetzen in die Gleichungen 2.31, 2.32 sowie 2.33 ergeben sich 

folgende Drehmomente M aGi für die jeweiligen Gelenke aG i mit i ∈ {2, 3, 4, 5}: 

M aG4 = 0.193Nm 

M aG3 = 0.584Nm 

M aG2 = 0.988Nm 

Für das dem Fußpunkt am Nahegelegensten Gelenk G 2 wurde ein Drehmoment 

von M aG2 = 10.08kg/cm ermittelt. Dies ist der maximale Wert, der 

von dem in Tabelle 2.8 beschriebenen Servo S06NF aufgewendet werden 

muss. Für den Servo ergibt sich daher bei einem maximalen Drehmoment 

von 13, 5kg/cm ein Puffer von 3, 42kg/cm bzw. ca. 25%. 

Um den spezifizierten Roboterarm umsetzen zu können, müssen nun Servos 

mit den benötigten Drehmomenten ausgewählt werden. Diese werden 

dabei speziell auf jedes Gelenk angepasst und das Modell mit den neuen 

Servodaten neu simuliert. 

330


Die entsprechenden Servos werden den in Abbildung 2.147 benannten Gelenken 

zugeordnet. 

• Servos 

– G1: ab 10 bis 13 kg-cm, z.B. HSR-5498SG 

– G2: ab 42 bis 44 kg-cm, z.B. HS-7980TH 51 

– G3: ab 20 bis 25 kg-cm, z.B. HS-7954SH 52 



– G6: ab 3 bis 5 kg-cm, z.B. HSR-8498HB 

– Greifer-Servo: ab 3 bis 5 kg-cm, z.B. HSR-8498HB 

Diese hier aufgeführten Servos erfüllen die Anforderungen der Spezifikation. 

Für die Gelenke G 1 , G 4 bis G 6 würden bereits die aktuell genutzten Servos 

ausreichen. 

(a) HS-7954SH (bis 24 kgcm) 

(b) HS-7980TH (bis 44 

kg-cm) 

Abbildung 2.149: Leistungsstarken Servos HS-7954SH (a) und HS-7980TH 

(b) 

Für die Gelenke G 2 und G 3 müssen wesentlich leistungsstärkere Varianten 

eingesetzt werden. Die Kosten der in Abbildung 2.149 vorgestellten Servo- 

Modelle der Fa. Hitec belaufen sich auf ca. 175 ¿ für G 2 und ca. 100 ¿ für 

G 3 . Die Servos besitzen trotz ihrer schlanken Bauweise von 40mmx20mmx37mm 

(HS-7954SH) und 43.8mmx22.4mmx40mm (HS-7980TH) sowie den geringen 

Massen von jeweils 68gr und 78gr ein Drehmoment, welches dem für 

das jeweilige Gelenk maximal bestimmtem Drehmoment genügt. 

51 http://www.servocity.com/html/hs-7980th_servo.html 

52 http://www.servocity.com/html/hs-7954sh_servo.html 

331


Ansatz 2: Roboterarm Arexx R1-PRO mit 5 Freiheitsgraden (DOF) 

In diesem Fall würde die aktuelle Gelenkkonfiguration übernommen werden. 

Die Längen der Verbindungsstücke könnten vergrößert werden, um 

den Arbeitsbereich zu erhöhen. Die Entwicklung einer neuen Kinematik 

wäre jedoch trotzdem nötig, um den senkrechten Greifvorgang zu realisieren. 

Vergröÿerung des Arbeitsbereichs 

Im Folgenden werden die Auswirkungen einer Verlängerung der Verbindungsstücke 

des aktuellen Roboterarms ermittelt. Die Simulation liefert die unten stehenden 

Ergebnisse: 

Als neue Längen wurden l 1 und l 2 auf den dreifachen Wert verlängert. 

Damit erhöht sich entsprechend auch die Masse der Segmente. Für l 1 = 

31, 5cm und l 1 = 36cm sowie für die entsprechenden Massen m 1 = 72gr 

und m 2 = 78gr ergeben sich die Drehmomente je Gelenk wie folgt: 

M aG4 = 0.193Nm 

M aG3 = 1.366Nm 

M aG2 = 2.578Nm 

Damit muss das Gelenk G 2 mit einem Servo angetrieben werden, der mindestens 

ein Drehmoment von 26.29kg/cm aufbringen kann. Zusätzlich sollte 

immer ein gewisser Puffer mit eingeplant werden. 

Aus den ermittelten Werten wird ersichtlich, dass in einem solchen Fall 

das Beibehalten der aktuellen Roboterplattform keine Vorteile bringt, da 

Verbindungsstücke sowie Servos neu dimensioniert werden müssten. 

Ansatz 3: Roboterarm auf Basis des SCARA mit 3 Freiheitsgraden 

(DOF) 

Der dritte Ansatz schlägt eine Gelenkkonfiguration in Anlehnung an den 

in 2.10.4.2 beschriebenen Roboterarms vor. Diese Konfiguration ist jedoch 

explizit auf eine Pick & Place Anwendung ausgelegt, sodass der Demonstrator 

zur Nachahmung des menschlichen Arms mit diesem Roboterarm 

nicht praktikabel umsetzbar ist. Abbildung 2.150 zeigt die Standard Gelenkkonfiguration 

eines solchen Roboterarms. 

Für die Wahl dieser Konfiguration sprechen eine einfache Umsetzbarkeit 

sowie weniger Rechenaufwand, da die Belastung der Servos durch den 

Aufbau gering gehalten wird. 

332


Abbildung 2.150: Kinematische Konfiguration Scara 

2.10.5 Erweiterung des Servo-IP-Cores 

Ziel dieses Arbeitspaketes ist es den Servo-IP-Core, siehe Abb. 2.152, zu erweitern, 

sodass ruckartige Bewegungen vermieden werden. Der Servo-IP- 

Core steuerte bisher die Servos direkt über das Pulspositionsmodulation- 

Protokoll an. Dabei wurde unmittelbar die Zielposition angefahren. Dieses 

Vorgehen verursachte ruckartige Bewegungen, da der Servo bei größeren 

Differenzen zwischen Aktueller und Zielposition mit voller Leistung agiert. 

Entsprechend traten hier hohe Ströme und Belastungen für den Roboterarm 

auf. 

Um diese ruckartigen Bewegungen und übermäßigen Belastungen zu vermeiden 

wurde der Servo-IP-Core um eine Rampenfunktion, siehe Abb. 

2.151, erweitert. Die Rampen bewirken, dass der Servo die Zielpostion 

schrittweise anfährt, anstatt direkt mit voller Leistung die Zielpositionn 

anzufahren. Dieses schrittweise Erreichen der Zielposition bewirkt eine weichere 

Bewegung sowie geringere Belastungen. 

333


Servowinkel 

in ms 

Zielposition 

stepsize 

Startposition 

20 ms Interval des PWM- 

Signals des Servo 

t in ms 

Abbildung 2.151: Funktion der Rampen im Servo-IP-Core 

2.10.5.1 VHDL-Code 

Um die weiche Ansteuerung der Servos zu erreichen, wird das Signal reg 

aufgeteilt. Dieses Signal liefert nun nicht nur die anzufahrende Zielposition, 

sondern auch die Schrittweite. Es wird im Treiber gesetzt und in ein 

Register geschrieben. Die ersten 16 Bit enthalten die Zielposition und die 

zweiten 16 Bit die Schrittweite. 

Die Rampe ist im st1_high Zustand implementiert, für den Automaten 

(siehe Abschnitt 2.80). Sie erhöht oder verringert den Zielwinkel des Servos 

um die Stepsize. Der Wert ist dabei in Millisekunden angegeben. Ist der 

Unterschied zwischen Ziel und aktuellem Wert kleiner als die Differenz 

zwischen Ziel und aktuellem Wert, wird dieser direkt auf den Zielwert 

gesetzt, sodass ein Springen um die Zielposition verhindert wird. 

334


clk 

reset 

reg[0:31] 

servo_v1_00_a 

output 

Abbildung 2.152: Blockschaltbild Servo-IP-Core 

2.10.5.2 Treiber 

Im folgenden Unterabschnitt werden die Änderungen am Servo-Treiber 

aufgeführt. 

unsigned short stepsize ; 

Um die stepsize an den IP-Core zu übergeben, muss ein Register gesetzt 

werden. Zu diesem Zweck wurde der bestehende Treiber um den Wert 

stepsize erweitert. 

Servo ( unsigned int base_address , unsigned short minimum , 

unsigned short maximum , unsigned short stepsize ); 

Zudem wurde ein neuer Konstruktor eingeführt bei dem die stepsize übergeben 

wird. 

void set_stepsize ( unsigned short stepsize ); 

Des Weiteren wurde eine Methode set_stepsize dem Treiber hinzugefügt. 

Mit dieser kann die stepsize neu gesetzt werden. 

void set_angle_over_time ( short degree , short ms ); 

Die Methode set_angle_over_time erlaubt es den Zielwinkel und die Zeit 

in Millisekunden anzugeben, in der der Winkel erreicht werden soll. Intern 

berechnet die Methode die benötigte stepsize. Gibt der Benutzer eine 

Zeit ein, welche nicht erreicht werden kann so wird die maximal mögliche 

Zeit eingestellt. Dies geschieht nicht im Treiber sondern automatisch im 

IP-Core. 

unsigned short get_angle () ; 

Mit get_angle kann der aktuell eingestellte Winkel in Grad abgerufen werden. 

unsigned_short get_stepsize () ; 

Die Methode get_stepsize liefert die derzeit eingestellte stepsize zurück. 

335


Dateistruktur 

• ip-cores/drivers/servo_v1_00_a/data/servo_v2_1_0.mdd: Generiert von 

Xilinx 

• ip-cores/drivers/servo_v1_00_a/data/servo_2_1_0.tcl: Generiert von Xilinx 

• ip-cores/drivers/servo_v1_00_a/data/src/servo.cpp: Cpp-Datei mit Implementierung 

• ip-cores/drivers/servo_v1_00_a/data/src/servo.h: Cpp-Datei mit Prototypendefinition 

• ip-cores/pcores/servo_v1_00_a/hdl/vhdl/servoctrl.vhd: Servo-IP-Core 

inklusive der Rampen. 

• ip-cores/pcores/servo_v1_00_a/hdl/vhdl/user_logic.vhd: Anbindung 

an den PLB 

• ip-cores/pcores/servo_v1_00_a/hdl/vhdl/simulation/servoctlr_tb.vhd: 

Testbench für den veränderten IP-Core. 

336


2.10.6 Entwicklung einer Trajektorienführung 


zur Trajektorienführung auf einer Ebene, welche in erster Linie im 

Anwendungsfall „Skizze zeichnen“ eingesetzt werden soll. Dies ist nötig, 

da die entwickelte Rückwärtskinematik alleine zur Ansteuerung eines eingegebenen 

Punktes dient. Damit wird zu diesem Zeitpunkt jedoch noch nicht das 

Abfahren einer vorgegebenen Strecke, also einer Trajektorie, realisiert. 

Durch Eingabe einer Punktliste können somit auf einer Ebene geometrische 

Formen wie z. B. Geraden mit dem Roboterarm abgefahren werden. Dafür 

soll in diesem Arbeitspaket die in Sprint 2 Abschnitt 2.2.3.3 erarbeitete 

Rückwärtskinematik genutzt und falls nötig angepasst werden, sodass das 

Abfahren der Trajektorien keine unerwünschten Sprünge beinhaltet. 

Das Ergebnis dieses Arbeitspakets ist ein zusätzliches Plugin für die OFFIS- 

Automation-Toolbox, welches aus einer Menge von Punkten als Eingabe 

eine Trajektorie interpoliert. Als Demonstrator wird ein Python-Skript implementiert, 

welches Trajektorienführung und Rückwärtskinematik kombiniert, 

sodass die errechneten Steuerwinkel über die USB-Schnittstelle und 

den FPGA an die Servos des realen Roboterarms weitergeleitet werden 

können. 







Lieferumfang 

• Plugin zur Trajektorienberechnung für die OFFIS-Automation-Toolbox 

• Python-Skript zur Verbindung von Trajektorienführung und Rückwärtskinematik 

– Vollständiger Aufbau zum Zeichnen planarer geometrischer Formen: 

Rechteck, Dreieck, Kreis 

337


2.10.6.1 Algorithmus 

Bei der Entwicklung einer Trajektorienführung spielt die Wahl des Algorithmus 

eine entscheidende Rolle. Daher erfolgen im Weiteren die Auswahl 

sowie Beschreibung der gewählten Methode. 

Auswahl 

Zur Planung einer Trajektorie zwischen zwei Punkten können je nach Bedarf 

unterschiedliche Interpolationsverfahren gewählt werden 53 . Dazu zählen 

unter Anderem lineare-, Kreis- oder auch Splineinterpolation. 

Der aufgrund seiner Einfachheit gewählte Algorithmus basiert auf einer 

linearen Interpolation der Punkte. Diese Methode reicht für die angestrebten 

Anwendungen aus und bereitet darüber hinaus weniger mathematischen 

Aufwand. 

v 

v 

Abbildung 2.153: Lineare Interpolation eines Vektors 

Im ersten Schritt wird die Länge der Strecke zwischen den eingegebenen 

Punkten ermittelt. Anschließend wird eine Menge der Punkte entlang des 

Vektors mit dem vorgegebenen Abstand zwischen diesen Punkten oder in 

der vorgegebenen Zahl dieser Punkte geliefert. Das Prinzip wird in Abbildung 

2.153veranschaulicht. 

Beschreibung 

Als Eingabe werden zwei Punkte P S sowie P E erwartet, die jeweils als Startund 

Endpunkt bezeichnet werden. Der minimale Abstand zwischen den 

Punkten der Interpolation A Int wird durch die Auflösung des Roboterarms 

festgelegt. Anschließend wird die Anzahl der benötigten Interpolationspunkte 

berechnet. Die Berechnung beginnt mit dem Verhältnis der 

53 http://edoc.sub.uni-hamburg.de/haw/volltexte/2011/1331/pdf/Trajektorienplanung.pdf 

338


Länge der Trajektorie L T zum Abstand A Int . Damit ergibt sich zunächst 

die grobe Anzahl der benötigten Punkte n grob . 

n grob = 

L T 

A Int 

(2.34) 

Da das Verhältnis nicht immer ganzzahlig ausfällt, entsteht ein gewisses 

Fehlermaß M F . Dies verhindert eine gleichmäßige Verteilung der Punkte 

über die Trajektorie. In einem solchen Fall würde bei bloßer Interpolation 

mit festgelegter Schrittweite der gewünschte Endpunkt nicht zwangsläufig 

erreicht werden. 

M F = L T mod A Int (2.35) 

Aus den Gleichungen 2.34 sowie 2.35 lässt sich daher ein Korrekturfaktor 

F K bestimmen. 

F K = M F 

n grob 

(2.36) 

Mit Hilfe des Korrekturfaktors wird nun die genaue Anzahl der benötigten 

Punkte der Interpolation n genau berechnet und somit der gewünschte Endpunkt 

erreicht. 

L 

n genau = T 

(2.37) 

A Int + F K 

Der Wert n genau bestimmt die Faktoren der Interpolation F I für die einzelnen 

Koordinaten (x, y) jedes Punktes auf der Trajektorie. 

Zunächst werden nun die Differenzen zwischen Start- und Endpunkten 

paarweise gebildet: 

x di f f = B.x − A.x 

y di f f = B.y − A.y 

(2.38) 

Anschließend erfolgt die Bestimmung der Faktoren der Interpolation F Ix 

und F Iy : 

F Ix = x di f f /n genau 

F Iy = y di f f /n genau 

(2.39) 

Jeder Punkt der Interpolation P Inti (x, y) ist wie folgt definiert: 

∀x i ∈ P Inti : P Inti .x = P Int0 .x + F Ix · i, 

∀y i ∈ P Inti : P Inti .y = P Int0 .y + F Iy · i, 

mit P Inti ∈ {P Int0 ..P Inti } 

(2.40) 

339


2.10.6.2 Ermittlung der theoretischen Schrittweite 

Um eine Annäherung an die kleinstmögliche Schrittweite des Roboterarms 

zu ermitteln, wird die folgende Berechnung durchgeführt. 

Für die Winkelgenauigkeit der Servos wird 1 Grad pro / Schritt angenommen. 

Dabei handelt es sich ebenfalls um die minimal einstellbare Schrittweite 

seitens des Servo IP-Cores. 

⍺ 

β 

l 1 

1° 

l 1 

1° 

l 2 

γ 

l 2 

l 1 + l 2 

a 

n 

Abbildung 2.154: Berechnung der minimalen Schrittweite 

Unter Einbezug der Längen des zweiten und dritten Verbindungsstücks 

kann die theoretisch mögliche Schrittweite eines Teilarms ermittelt werden. 

Hierzu wird der Kosinus-Satz angewendet. Die Längen der letzten 

beiden Verbindungsstücke des Roboterarms sind jeweils l 1 = 78, 5mm und 

l 2 = 70mm lang. Unter dem Winkel α = 180 ◦ , wie in Abbildung 2.154 

dargestellt ist, bilden beide Segmente die maximale gestreckte Länge von 

l 1 + l 2 . Falls die Gelenke (Winkel α und β) in Richtung der schwarzen 

Pfeilen sich um einen Grad drehen, verkürzt sich diese Strecke um n. 

Dabei ist das n die minimale Schrittweite, die der Roboterarm durch die 

Änderung der Gelenkwinkel um einen Grad erzielen kann. Die verkürzte 

Strecke wird zu einer Seite des Dreiecks und kann durch den Kosinus-Satz 

bestimmt werden. Das n ist die Differenz dieser Strecken. 

√ 

n = l 1 + l 2 − l1 2 + l2 2 − 2 · l 1 · l 2 · cos(α) (2.41) 

Daraus ergibt sich eine theoretische Schrittweite von 0, 0225432mm. Da 

diese Schrittweite mit dem gegebenen System der Servos nicht realistisch 

umsetzbar ist, wurde als Voreinstellung eine höhere Auflösung von 1mm 

340


angenommen. Es kann jedoch weiterhin eine genauere Schrittweite bei der 

Trajektorienberechnung gewählt werden. 

2.10.6.3 Anpassung der Kinematik auf 2D Ebene 

Um auf einer Ebene zeichnen zu können, wird der Roboterarm seitlich 

zur Ebene platziert. Das untere Gelenk des Roboters sollte ohne Winkeländerungen 

stehen bleiben, wobei lediglich die restlichen Gelenke bewegt 

werden. Der Stift wird, wie in Abbildung 2.155 dargestellt, am Tool-Center- 

Point senkrecht zur x-Achse und parallel zur y-Achse befestigt. 

Zur Umsetzung sollte die Rückwärtskinematik genutzt und wenn nötig 

entsprechend angepasst werden. Im ersten Schritt wird zu diesem Zweck 

der Punkt auf der y-Achse fest gesetzt. Dies reicht jedoch nicht aus, um die 

Rückwärtskinematik auf den gewünschten Arbeitsbereich einzuschränken, 

da zwei Probleme entstehen. Diese führen zwangsweise zu ungewollten 

Zwischenzeichnungen, bzw. Ausbrüchen des Roboterarms während des 

Ablaufs einer Trajektorie. 

Die Problematiken werden im Folgenden kurz erläutert: 

Z-Achsen Problem 

Da die Rückwärtskinematik mit dem Ziel entworfen wurde, einen beliebigen 

Punkt im Raum zu erreichen, sodass der Winkel des untersten Drehgelenks 

von der Position des Punktes im Arbeitsraum abhängt, lässt sich 

diese nicht ohne Drehung des unteren Gelenks auf das später erdachte 

Konzept des seitlichen Zeichnens anwenden. Bei einer Trajektorie, die Punkte 

auf beiden Seiten der z-Achse beinhaltet, kann unter Umständen eine 

Drehung des Arms um 180 Grad erfolgen. Diese kann aufgrund der geometrischen 

Lösung der Rückwärtskinematik nicht durch ein einfaches Invertieren 

der Winkel gelöst werden. 

Strategiewechsel Problem 

Bei der aktuellen Rückwärtskinematik werden zwei Strategien zur Punktermittlung 

genutzt (siehe Abschnitt 2.2.3.3). Die erste Strategie dient dazu, 

Punkte zu erreichen, die weit vom Ursprung entfernt liegen. Die zweite 

Strategie sorgt dafür, dass Punkte erreicht werden können, die nah zum 

Ursprung liegen. Bei einem Wechsel zwischen diesen Strategien erfolgen 

wiederum ungewollte Zwischenbewegungen. Da jede Strategie für das Erreichen 

eines Punktes die Winkel der Gelenke anders berechnet, kommt 

eine sprunghafte Winkeländerung bei einem Strategiewechsel zustande. 

341


Auch diese können daher nicht ohne starke Anpassungen bzw. Entwicklung 

einer neuen Rückwärtskinematik ausgeschlossen werden. 

Lösungsansätze 

Um die aufgezählten Probleme zu umgehen bzw. zu lösen werden im Folgenden 

einige mögliche Ansätze dargestellt. 

Problemumgehung 

Um dem Z-Achsen Problem aus dem Weg zu gehen, 

wird die Methode zur Trajektorienverfolgung der Python Implementierung 

angepasst, so dass bei einer berechneten Drehung seitens der Rückwärtskinematik 

der Stift ebenfalls um 180 Grad gedreht wird. Im Falle des 

Strategiewechsel Problems wird die Methode zur Trajektorienverfolgung 

der Python Implementierung dahingehend erweitert, dass der Stift vor jedem 

Strategiewechsel von der Zeichenebene abgewendet und nach erfolgtem 

Wechsel wieder auf die Ausgangslage gedreht wird. Diese Möglichkeit 

hat den Vorteil, dass keine Änderungen an der Kinematik vorgenommen 

werden müssen. Jedoch handelt es sich dabei um unerwünschtes Verhalten, 

welches zusätzlich auf Kosten der Wiederholgenauigkeit umgesetzt wird. 

Neue Kinematik 

Für den speziellen Fall des seitlichen Zeichnens soll eine 

neue Kinematik entwickelt werden, welche möglichst lange ohne Strategiewechsel 

auskommt und somit den Größtmöglichen Arbeitsbereich zulässt. 

Eingeschränkter Arbeitsbereich 

Um einer Drehung sowie einem möglichen 

Strategiewechsel vollständig aus dem Weg zu gehen, kann der Zeichenvorgang 

in einem stark eingeschränkten Arbeitsbereich erfolgen. 


Der folgende Abschnitt beschreibt die Implementierung des Plugins zur 

Trajektorienplanung sowie der zugehörigen Python Programmlogik. 

OFFIS-Toolbox Plugin: Trajektorienplanung 

Zur Berechnung einer Trajektorie zwischen zwei Punkten wurde ein neues 

Plugin für die OFFIS-Automation-Toolbox erstellt. Dieses bietet eine Schnittstelle 

zur Python Umgebung, sodass eine Kombination mit der Rückwärtskinematik 

ermöglicht wird. 

342


void setStepFactor ( float factor ); 

Diese Methode setzt die übergebene mindeste Schrittweite zwischen den 

Interpolationspunkten. 

float getStepFactor () ; 

Diese Methode liefert die aktuell gesetzte Schrittweite zurück. 

QList < float > getInterpolationPoints ( float x1 , float y1 , 

float x2 , float y2 ); 

Diese Methode berechnet eine Trajektorie auf Basis von Start- und Endpunkt. 

Zurückgeliefert wird eine Punktliste in Form von X- und Y-Koordinaten. 

void interpolate () ; 

Diese Methode sorgt für die eigentliche Interpolation und füllt eine Liste 

mit den berechneten Punkten auf der Trajektorie. Die weitere Logik sorgt 

dafür, dass trotz gesetzter Schrittweite der genaue Start- sowie der Endpunkt 

erreicht wird. 

OFFIS-Toolbox Automation: Python Skript 

Zur Umsetzung des Demonstrators wird eine Automatisierung in der OFFIS- 

Automation-Toolbox implementiert. Diese nutzt die Plugins zur Trajektorienplanung 

sowie zur Berechnung der Rückwärtskinematik. Ziel ist es, 

mit dem Aufbau simple geometrische Figuren auf einer senkrechten Ebene 

zu zeichnen. 

def traceTrajectory (x1 , y1 , x2 , y2 ) 

Diese Methode kombiniert die Trajektorienplanung mit der Rückwärtskinematik. 

Zu gegebenem Start- und Endpunkt wird zuerst eine Trajektorie 

ermittelt. Die Rückwärtskinematik wird nun genutzt, um die zugehörigen 

Winkel zu berechnen. Diese werden daraufhin zum Microblaze übertragen 

und dort weiterverarbeitet. Sie berücksichtigt jedoch nicht die in Abschnitt 

2.10.6.3 aufgezeigten Probleme der Rückwärtskinematik. 

def traceTrajectoryWithoutChaos (x1 , y1 , x2 , y2 ) 

343


Diese Methode besitzt die Funktionen der obigen Methode, ist jedoch weiter 

darauf ausgelegt, die Probleme zwischen Trajektorienführung und Rückwärtskinematik 

zu erkennen und abzufangen. Anmerkung: Diese Methode 

wurde als erster Test implementiert, um zu analysieren, ob es sich um eine 

mögliche Lösung der Probleme handelt. Daher sind zu diesem Zeitpunkt 

nicht sämtliche Testfälle berücksichtigt. 

def getSortedTrajectory (x1 , y1 , x2 , y2 ) 

Bei dieser Methode handelt es sich um eine Hilsmethode, welche die Rückgabewerte 

des Trajektorien-Plugins in eine separate x- und y-Liste einsortiert. 

def rectangle () 

Diese Funktion dient der Evaluation und zeichnet ein Rechteck ohne Strategiewechsel. 

def triangle () 

Diese Funktion dient der Evaluation und zeichnet ein Dreieck ohne Strategiewechsel. 

def circle () 

Diese Funktion dient der Evaluation und zeichnet einen Kreis ohne Strategiewechsel. 

def house () 

Diese Funktion dient der Evaluation und zeichnet das Haus vom Nikolaus 

ohne Strategiewechsel. 

344


2.10.6.5 Aufbau 

Als Ziel des Arbeitspakets wurde ein Demonstrator festgelegt, der in der 

Lage ist, geometrische Formen auf einer Ebene zu zeichnen. Zu diesem 

Zweck wurde der in Abbildung 2.155 gezeigte Aufbau gewählt. Der Roboterarm 

steht dabei mit seiner x-Achse parallel zur Zeichenfläche. 

Abbildung 2.155: Aufbau des vorläufigen Demonstrators 

Einige der getesteten geometrischen Formen sind in Abbildung 2.156 dargestellt. 

345


Abbildung 2.156: erste Zeichnungen 

Das Zeichnen mit Auflösung A Int = 3mm sowie Verzögerungszeit von 1 

ms zwischen Versenden der Nachrichten erfolgte für den Kreis sowie das 

Rechteck in 5 und für das Dreieck in 3,75 Sekunden. Das Zeichnen erfolgt 

zitternd, das heißt, dass die interpolierte Trajektorie durch den Roboterarm 

nicht präzise verfolgt werden konnte. In Abbildung 2.156 sind Figuren 

dargestellt, die durch die Vorgabe der geradlinigen Trajektorien gezeichnet 

wurden. Der Wiederholungsfehler des Roboterarms ist dagegen maximal 

4 mm. 

Die Höhe des „Hauses vom Nikolaus“ beträgt 6 und die Breite 4 cm. Das 

Zeichenbereich ist durch das Konzept der Strategiewechsel stark begrenzt. 

Die Natur des „Zittern“ entlang des Zeichnens der Linien wird untersucht. 

Hierzu wurde ein neues Arbeitspaket erstellt, in dem das Zeichenbereich 

verbessert sowie der genaue Grund des Zig-Zag artigen Verhaltens (des 

Zitterns) beim Zeichnen herausgefunden und ggf. beseitigt werden soll. 

346


Da es zwischenzeitlich zu Unklarheiten bezüglich der Anbindung der Servoversorgungsplatine 

kam, wird in den Tabellen 2.11 die genaue Portbelegung 

für das Genesys-Projekt dieses Teilarbeitspakets beschrieben. Anmerkung: 

Stecker mit der weißen Markierung nach oben. 

Port oben links 

GND AK8 AM11 AN12 AP14 

PORT oben rechts 

AN14 AN13 AP12 AL10 GND 

Pmod D Pins 

VCC GND AL10 AP12 AN13 AN14 

VCC GND AK8 AM11 AN12 AP14 

Tabelle 2.11: Konnektor zwischen FPGA-Board und Servoplatine 

Dateistruktur 

• genesys/system.xmp : Genesys-Board Projektdatei. 

• genesys/system.ucf : Verbindung logischer Netze mit physikalischen 

Pins. 

• genesys/system.mhs : Hardwarespezifikationsdatei. 

• offis-toolbox/projects/TrajectoryDemo/TrajectoryDemo.oap und ogr: 

Dateien für das OFFIS-Automation-Toolbox-Projekt 

• offis-toolbox/projects/TrajectoryTest/main.py : Hauptdatei des Automatisierungsprojekts 

• offis-toolbox/projects/TrajectoryTest/trajectory.py : Kombination von 

Trajektorienplanung und Rückwärtskinematik. 

• offis-toolbox/projects/TrajectoryTest/testForms.py : Datei mit vordefinierten 

geometrischen Formen und Testfällen. 

• offis-toolbox/projects/TrajectoryTest/rangeTests.py : Datei mit vordefinierten 

Strategiewechsel Testfällen. 

• offis-toolbox/plugins/automation/Trajectory/trajectory.pro : QT-Projektdatei. 

347


• offis-toolbox/plugins/automation/Trajectory/src/trajectory.cpp : Implementierungen 

der trajectory Klasse. 

• offis-toolbox/plugins/automation/Trajectory/src/trajectory.h : Header 

der trajectory Klasse. 

• offis-toolbox/plugins/automation/Trajectory/src/trajectoryInterface.cpp 

: Schnittstellenfunktionen zur Python-Umgebung. 

348



des Zig-Zag Verhaltens 

Im Abschnitt 2.10.6 wurden die Probleme mit dem Zeichenbereich sowie 

mit dem Zig-Zag mäßigen (zitternden) Verhalten festgestellt. Das Ziel dieses 

Arbeitspaketes ist das Programm der Rückwärtskinematik insofern nachzubessern, 

dass der Wechsel der Strategie so spät wie möglich erfolgt. Die Idee dabei 

ist, für die Punkte im Arbeitsbereich, die von beiden Strategien erreichbar 

sind, weiterhin mit der ersten Strategie die Winkelstellungen zu berechnen. 

Außerdem muss in diesem Arbeitspaket festgestellt werden, woher 

das oben beschriebene Verhalten beim Abfahren der geradlinigen Trajektorien 

stammt. Zusätzlich soll das Verhalten des Roboterarms beim Abfahren 

der Trajektorie „Von Punkt zum Punkt“ ohne Interpolation getestet 

werden. 




• Trajektorienführungsplugin inkl. Python-Schnittstellen 




Lieferumfang 

• Ein Demonstrator des verbesserten Arbeitsbereiches 

• Bericht über Grund des Zig-Zag mäßigen Verhalten des Roboterarms 

2.10.7.1 Strategiewechsel 

Das Wechsel der Strategie erst bei einem Punkt, der ausschließlich mit der 

zweiten Strategie erreichbar ist, wurde realisiert. Das Plugin der Rückwärtskinematik 

wurde hierzu umgebaut. Es konnten Punkte, die mit beiden 

Strategien erreichbar sind, für die erste Strategie priorisiert werden. 

349


Abbildung 2.157: Arbeitsbereich nach neuen Strategiewechsel 

Als Ergebnis kam ein Arbeitsbereich wie in Abbildung 2.157 darstellt, heraus. 

Abbildung 2.158: Quadrat ohne Strategiewechsel 

So konnte ein Quadrat 2.158 mit der Seitenlänge von 10 cm ohne Strategiewechsel 

gezeichnet werden. Der komplette Verzicht auf Strategiewech- 

350


sel ist konzeptuell nicht möglich. Es muss eine einfachere oder komplett 

neue Rückwärtskinematik erstellt werden. 

2.10.7.2 Tests und Erkenntnisse/Bericht 

Die Bewegung der Servos über einer vorgegebene geradlinigen Trajektorie 

ohne ihren Interpolation ergibt keine geradlinigen Trajektorien. 

Abbildung 2.159: Quadrat über Eckpunkte ohne Interpolation der Trajektorie 

In Abbildung 2.159 ist das gleiche Ergebnisquadrat links ohne und rechts 

mit Interpolation der Trajektorie dargestellt. 

Um auf das Zig-Zag mäßige Verhalten einzugehen wurde aus der Vermutung 

des Zeit versetzten Setzen der Pulspositionsmodulation-Signale über 

Microblaze der Code optimiert. Die Datei servo.cpp wurde entfernt und 

sämtliche Prozeduren wurden zu inline-Prozeduren in der Datei servo.h. 

Die Tests zeigten erneut das Zig-Zag mäßige Verhalten. 

Des Weiteren wurde zum Untersuchen der Richtigkeit der Winkelstellungen 

eine neue USB-Message vom Typ [USB_TYPE_SERVO_ANGLES_FINE] 

für das genauere Setzen der Winkel über Pulspositionsmodulation-Signale 

erstellt. 

Die Tests zeigten erneut das Zig-Zag mäßige Verhalten, obwohl das Pulspositionsmodulation-Signal 

bis zum Zehntel eines Winkelgrades gesteuert 

werden konnte. 

Das Zeichnen wurde mit unterschiedlichen Schrittweiten A Int und Geschwindigkeiten 

getestet. Hierbei wurde die Geschwindigkeit durch das Variieren der 

Zeitabstände zwischen den Sendevorgänge der USB-Nachrichten realisiert. 

Die Anwendung der Rampenfunktion glättet die Ecken geringfügig, die 

Amplitude des Zig-Zag Verhaltens bleibt dabei gleich. 

351


Es wurde herausgefunden, dass das Zittern des Roboterarms an der Fähigkeit 

des Servos die Stellung nach dem PPM Signal anzunehmen liegt. Die Beschaffenheit 

der Servos ist so, dass diese nicht in der Lage sind jede Winkelstellung 

anzunehmen. Eine tatsächliche Winkeländerung beim Servo erfolgt 

erst dann, wenn der Servo eine Stellung annehmen kann. So ignorieren 

einige Servos ihre Winkelstellung aus dem Winkelvektor, der durch die 

Rückwärtskinematik vorgegeben wird. Während dessen kann für einen anderen 

Servo zugleich eine annehmbare Winkelstellung aus dem Winkelvektor 

kommen. Dadurch erfolgt die Winkeländerung nicht bei allen Servos 

zu jedem Zeitpunkt der neuen Winkelstellung durch die Vorgabe des Pulspositionsmodulation-Signals. 

Damit entsteht ein Zeit verzögertes Bewegen 

der Servos, was die Zig-Zag artigen Mustern (das „Zittern“) verursachen. 

2.10.7.3 Ermittelter Arbeitsbereich für Skizze Zeichnen 

Der ermittelte Arbeitsbereich für den Anwendungsfall Skizze zeichnen ist 

wie folgt angegeben: 

In Anbetracht der Roboterstellung in Tests, wie in Abbildung 2.155 kann 

ein Rechteck, wie in Abbildung 2.158 gezeichnet werden. 

Dabei liegt der Zeichenbereich in der X-Z Ebene. Das heißt, dass Die Y- 

Dimension unverändert bleiben muss. Der Bereich zum Zeichnen eines 

Rechtecks (X, Z) liegt zwischen 

200.0, 25.0 (unten links) sowie 90.0, 120.0 (oben rechts) 

der in Python setzbaren Angaben. 

Dies entspricht einem durch ein Lineal auf dem Flipchart gemessenen 

Rechteck von 10x10 cm, wie in Abbildung 2.158 dargestellt ist. 

352


Der gesamte Zeichenbereich, wie er in Abbildung 2.160 zu sehen ist, wird 

im Folgenden angegeben: 

Abbildung 2.160: Koordinaten des Arbeitsbereichs 

Der Arbeitsbereich ohne Strategiewechslung wird durch die gelben Grenzen 

sowie durch folgenden Koordinaten {A, B, C, D} im Format (X, Z) 

aufgefasst: 

A: 226.5, 25.0; B: 90.0, 25.0 

C: 25.0, 240.0; D: 25.0, 120.0 

353


2.10.8 Drehgelenk 

Zielsetzung dieses Arbeitspaketes ist die Ermittlung des Drehwinkels des 

Roboterarms anhand gewonnener Informationen aus der Bildverarbeitung 

über die Position des menschlichen Arms. 

Dieser Winkel wurde bisher noch nicht berechnet. Hierzu muss eine gänzlich 

andere Strategie erdacht werden, als bei der Erkennung der Winkelstellungen 

des restlichen Arms. Dies hat zwei Gründe. Zum Einen ist das 

Armgelenk ein Kugelgelenk mit mehr Freiheitsgraden als der Roboterarm 

und zum Anderen wird dieses Kugelgelenk durch zwei unabhängig 

voneinander ansteuerbare Servos am Roboteram repräsentiert. Dabei ist 

zu beachten, dass Bewegungen, welche diese zusätzlichen Freiheitsgerade 

nutzen, nicht vollständig vom Roboterarm nachgeahmt werden können. 

Zur Ermittlung des Drehwinkels des Schultergelenks werden die Bildinformationen 

und berechneten Schwerpunkte aus der für den Arm vorhandenen 

Bildverarbeitung, zur Erkennung der Armgelenkwinkel, verwendet. 

Erstellt wird das entwickelte Verfahren mit Hilfe der OFFIS-Automation- 

Toolbox und wird entsprechend in der Programmiersprache Python geschrieben. 

Im Folgenden wird zunächst die Implementierung inklusive entsprechender 

Lösungsstrategie erläutert. Danach werden die durchgeführten Testfälle 

aufgelistet gefolgt von den aufgetretenen Problemen. Zum Schluss 

wird die Dateistruktur der mit diesem Arbeitspaket erzeugten Dateien 

aufgeführt. 

2.10.8.1 Algorithmus 

Dieser Abschnitt erläutert die Strategie zur Berechnung des Drehwinkels 

des Schultergelenks, sodass dieser auf den Roboterarm abgebildet werden 

kann. Die zugehörigen Gleichungen und Annahmen werden ebenfalls 

aufgeführt und erklärt. 

Zunächst wird aus drei Punkten ein Dreieck gebildet, sodass eine Ebene 

aufgespannt werden kann, welche parallel zur Szene liegt. Dabei ist der 

Stützvektor gleich dem Schwerpunkt des Schultergelenks. Die fehlenden 

beiden Punkte werden durch virtuelle Punkte erzeugt, da davon ausgegangen 

wir, dass der Benutzer parallel zur Szene steht. Der erste virtuelle 

Punkt liegt unterhalb des Schultergelenks und der zweite in Richtung des 

Schlüsselbeins des Benutzers. Der erste ist somit in y-Richtung verschoben 

und der zweite in x-Richtung, siehe Abb. 2.161. 

354


Abbildung 2.161: Runde Punkte stehen für die virtuellen Punkte in der 

Szene. Diese werden relativ zum Schwerpunkt des Schultergelenks 

gesetzt. 

Mit Hilfe dieser Punkte und der vorhandenen Funktionen zur Erstellung 

einer Ebene aus einem Dreieck wird die orthogonal zur Szene stehende 

Ebene erzeugt. Dabei ist die Reihenfolge der Punkte wichtig, damit die 

Ebene durch das Schultergelenk und den ersten virtuellen Punkt geht, 


Abbildung 2.162: Zeigt das Dreieck welches auf die Ebene projiziert wird, 

damit der Winkel α mit Hilfe des Kosinissatzes berechnet 

werden kann. 

Da der menschliche Arm verschiedene Stellungen einnehmen kann, muss 

355


je nach Stellung entschieden werden, welches Gelenk im Weiteren betrachtet 

wird. Ziwschen dem entsprechenden Gelenk und der Ebene wird 

nun der kürzeste Abstand, siehe Gleichung 2.42, die orthogonal zur Ebene, 

berechnet. 

d =⃗r ·⃗n −⃗a ·⃗n (2.42) 

Dieser Abstand ist wichtig, um den Durchstoßpunkt durch die Ebene zu 

bestimmen. Um den Durchstoßpunkt auf der Ebene zu erhalten, reicht es 

in diesem Fall aus, den Abstand auf den Schwerpunkt des entsprechenden 

Gelenks zu addieren. Dies begründet sich in der Annahme, dass sich der 

Benutzer parallel zur Szene befindet und mit Hilfe der virtuellen Punkte 

eine korrekte Ebene erzeugt wurde. Das bedeutet, dass sich der Abstand 

von Punkt zu Ebene auf die x-Richtung abbilden lässt. Mit Hilfe dieses 

Punktes, des Schwerpunktes des Schultergelenks und des ersten virtuellen 

Punktes, lässt sich nun ein auf die Ebene projiziertes Dreieck erzeugen. Da 

alle Punkte bekannt sind, können die Längen der Seiten bestimmt werden. 

Mit Hilfe dieser Seitenlängen und des Kosinussatzes, siehe Gleichung 2.43, 

lässt sich nun der Winkel alpha bestimmen. 

a 2 = b 2 + c 2 − 2 · b · c cos α ⇒ α = cos −1 ( b2 + c 2 − a 2 

) (2.43) 

2 · b · c 

Um zu entscheiden welches Gelenk für die Berechnungen verwendet wird, 

wurden folgende Fallunterscheidungen ausgearbeitet. 

1. Arm ist an einem beliebigen Gelenk gekrümmt 

a) Schulter gedreht (z.B. Abb. 2.164) 

b) Ellenbogen gedreht (z.B. Abb. 2.163) 

c) Handgelenk gedreht 

2. Arm ist gerade (z.B. Abb. 2.161) 

Das Gelenk zum Drehen des Roboterarms entspricht der Drehung des 

menschlichen ausgestreckten Arms um seine eigene Achse. Dabei wird 

ein Winkel von 180 Grad abgedeckt. Ein nach oben ausgestreckter Arm 

entspricht einer Drehung von 180 Grad und ein nach unten ausgestreckter 

Arm einer Drehung von 0 Grad, siehe Abb. 2.163 sowie Abb. 2.164. 

356


Abbildung 2.163: Angewinkelter Arm. Resultierende Drehung des 

Roboterarms 180 Grad. 

Abbildung 2.164: Gestreckter Arm. Resultierende Drehung des Roboterarms 

180 Grad. 

357



Dieser Abschnitt beschreibt die verwendeten bzw. implementierten Funktionen 

zur Umsetzung des oben beschriebenen Algorithmus. 

Folgende Funktionen waren bereits existent und wurden extra verwendet 

und nicht abgeändert, da diese schon auf dem Microblaze portiert wurden. 

def calcAngleFromTriangle ( self , side ): 

Diese Funktion berechnet einen Winkel anhand eines Dreiecks, mit Hilfe 

des Cosinussatzes. 

def scalarProduct ( self , v1 , v2 ): 

Diese Funktion berechnet das Skalarprodukt zweier Vektoren. 

def crossProduct ( self , v1 , v2 ): 

Diese Funktion berechnet das Kreuzprodukt zweier Vektoren. 

def deriveHyperPlaneNormalForm ( self , linkPosition , a , b): 

Diese Funktion berechnet eine Ebene im Raum und gibt diese in der Normalform 

zurück. 

Bei der Implementierung des oben erläuterten Algorithmus sind folgende 

neue Funktionen enstanden: 

def __init__ ( self ) 

In dieser Funktion werden die vorausgesetzen Winkel und Punkte global 

definiert. 

def shortestDistance ( self , point , plane ) 

Diese Funktion berechnet den kürzesten Abstand von einem Punkt zu einer 

Ebene. 

def deriveIntersectionPointPlane ( self , point , plane ) 

358


Diese Funktion liefert den Durchstoßpunkt zwischen einem beliebigen Punkt 

und einer Ebene. Dabei wird der Normalenvektor der Ebene als Richtungsvektor 

auf den Punkt gelegt und anschließend der Schnittpunkt zwischen 

Vektor und Ebene berechnet. 

def calculateTriangleLengths ( self , intersection ) 

Diese Funktion berechnet anhand eines Schnittpunktes und globaler Hilfspunkte 

ein Dreieck in Form der drei Seitenlängen. 

def radianToDegree ( self , angle ) 

Diese Funktion wandelt einen Winkel in Radiant zu einem Winkel in Grad 

um. 

def length3dVector ( self , vector ) 

Diese Funktion berechnet die Länge eines Vektors in Form des Betrags 

eines Vektors. 

def vectorSubstraction ( self , vectorOne , vectorTwo ) 

Diese zentrale Funktion berechnet aus den globalen Punkten und Winkeln 

(Voraussetzungen) den Drehwinkel, auch Alphawinkel genannt. Dies geschieht 

anhand der Krümmungsrichtung der verschiedenen Armgelenke, welche 

durch eine Fallunterscheiung berücksichtigt werden. 

2.10.8.3 Testfälle 

Zur Überprüfung der korrekten Funktionsweise des Algorithmus, wurden 

unter anderem folgende Testfälle durchgeführt: 

Test 1 (Arm komplett gerade) 

gamma = 180.0 

delta = 180.0 

betaCog = [100.0, 100.0, 100.0] 

gammaCog = [200.0, 100.0, 100.0] 

deltaCog = [500.0, 100.0, 100.0] 

tcp = [1250.0, 100.0, 100.0] 

Ergebnis: 

359


Arm streight, no change in Alpha 

Alpha = 0.0 

Test 2 (Nur Schultergelenk nach unten gedreht) 

gamma = 180.0 

delta = 180.0 

betaCog = [100.0, 100.0, 100.0] 

gammaCog = [200.0, 200.0, 100.0] 

deltaCog = [400.0, 400.0, 100.0] 

tcp = [500.0, 500.0, 100.0] 

Ergebnis: 

Arm not streight, checking subcases.. 

Shoulder-joint is bent 

Alpha = 0.0 

Test 3 (Nur Ellenbogengelenk ist nach unten gebeugt) 

gamma = 270.0 

delta = 180.0 

betaCog = [100.0, 100.0, 100.0] 

gammaCog = [200.0, 100.0, 100.0] 

deltaCog = [400.0, 200.0, 100.0] 

tcp = [800.0, 400.0, 100.0] 

Ergebnis: 


Elbow-joint is bent 

Alpha = 0.0 

Test 4 (Nur Handgelenk ist nach unten gebeugt) 

gamma = 180.0 

delta = 270.0 

betaCog = [100.0, 100.0, 100.0] 

gammaCog = [200.0, 100.0, 100.0] 

deltaCog = [400.0, 100.0, 100.0] 

tcp = [800.0, 200.0, 100.0] 

Ergebnis: 


Hand-joint is bent 

360


Alpha = 0.0 

Test 5 (Kombination, schräg vorne) 

gamma = 180.0 

delta = 180.0 

betaCog = [50.0, 50.0, 50.0] 

gammaCog = [75.0, 75.0, 25.0] 

deltaCog = [100.0, 100.0, 0.0] 

tcp = [125.0, 135.0, 0.0] 

Ergebnis: 



Alpha = 45.00000000000026 

Test 6 (Kombination) 

gamma = 270.0 

delta = 180.0 

betaCog = [50.0, 50.0, 50.0] 

gammaCog = [75.0, 50.0, 50.0] 

deltaCog = [75.0, 25.0, 25.0] 

tcp = [75.0, 12.0, 12.0] 

Ergebnis: 


Elbow-joint is bent 

Alpha = 134.99999999999974 

Test 7 (Arm frontal nach vorne) 

gamma = 270.0 

delta = 180.0 

betaCog = [50.0, 50.0, -50.0] 

gammaCog = [75.0, 50.0, 0.0] 

deltaCog = [75.0, 25.0, 0.0] 

tcp = [75.0, 12.0, 0.0] 

Ergebnis: 



Alpha = 89.99999999999974 

361


Test 8 (Handgelenk geknickt) 

gamma = 180.0 

delta = 90.0 

betaCog = [50.0, -50.0, 0.0] 

gammaCog = [50.0, -60.0, 0.0] 

deltaCog = [50.0, -70.0, 0.0] 

tcp = [100.0, -70.0, 0.0] 

Ergebnis: 



Alpha = 180.0 

Test 9 (wie Test 8, nur mit geändertem TCP) 

tcp = [100.0, -70.0, 10.0] 

Ergebnis: 



Alpha = 153.43494882292217 

Test 10 (wie Test 8, nur mit geändertem TCP) 

tcp = [100.0, -70.0, 25.0] 

Ergebnis: 



Alpha = 128.65980825409036 


Dieser Abschnitt erläutert die aufgetretenen Probleme welche während der 

Ermittlung der Strategie sowie während der Implementierung aufgetretene 

sind. Bei der Strategie war zu beachten, dass der Roboterarm weniger Freiheitsgrade 

als der menschliche Arm hat. Somit lassen sich nicht alle Armstellungen 

auf den Roboterarm abbilden. 

Desweiteren konnte mit den vorhandenen Punkten keine Ebene konstruiert 

werden, welche orthogonal zur Szene steht. Damit dies möglich ist, 

musste ein zusätzlicher virtueller Punkt zur Szene hinzugefügt werden. 

Dieser befindet sich in Richtung des Schlüsselbeins des Benutzers. Dies 

362


ist notwendig, damit drei Punkte zur Verfügung stehen. Ohne diese drei 

Punkte ist es nicht möglich eine eindeutige Ebene aufzuspannen. 

Bei der Verwendung des Systems durch den Benutzer muss darauf geachtet 

werden, dass dieser orthogonal zur Szene stehen muss. Sollte dieser nicht 

orthogonal zur Szene stehen, so müssen die virtuellen Hilfspunkte entsprechend 

angepasst werden. Alternativ könnte das System erweitert werden. Hierzu 

wären zusätzlichen Markierung an den entsprechenden Stellen am 

Benutzer notwendig. 


Dieser Abschnitt beschreibt die in diesem Teilpaket entstandenen Dateien. 

• offis-toolbox/projects/shoulderAngleDetection/ShoulderJoint.opa und 

ogr: Allen relevanten Dateien für das entsprechende OFFIS-Automation- 

Toolbox-Projekt. 

• offis-toolbox/projects/shoulderAngleDetection/main.py: Hauptdatei 

in der die Klasse ShoulderJoint definiert ist und entsprechend verschiedene 

Testfälle getestet werden können. 

• offis-toolbox/projects/shoulderAngleDetection/ShoulderJoint.py: Klasse 

in der die Realisierung der Ermittelung des Winkels des Schultergelenks 

(Drehwinkel) implementiert ist. 

• offis-toolbox/projects/shoulderAngleDetection/tests.txt: Datei mit den 

durchgeführten Testfällen und den entsprechenden Ergebnissen. 

363


2.10.9 Referenztakt für den cam_bootloader 

In diesem Arbeitspaket soll der bestehende cam_bootloader IP-Core derart 

geändert werden, dass ein fest bestimmter Referenztakt angelegt werden 

muss. Dieser Takt soll ermöglichen, dass die Parameter N und M des 

Treibers camcfg fest gewählt werden können. 

2.10.9.1 Modizierter cam_bootloader 

Der cam_bootloader IP-Core bekommt von uns ein zusätzlichen Eingangspin, 

welcher Boardunabhängig die gleiche Taktrate angelegt bekommen 

soll. Der IP-Core benutzt im folgenden diesen Pin als Taktgeber für die 

Kameras. Zusätzlich wurde ein TCL-Skript geschrieben, welches überprüft, 

ob an diesen Pin die korrekte Taktrate von 50MHz angelegt wurde. 


PLB Bus 

pclk (50MHz) 


vdd_en 

mclk1 

mclk2 

reset1 

reset2 

pwdn1 

pwdn2 

PLB Bus 

Abbildung 2.165: Blockschaltbild des geänderten cam_bootloader 

Treiber API 

Die API des “camcfg” Treiber wurde wie folgt verändert: 

1 enum CAM_SPEED { 

2 CAM_SPEED_75_MHZ = (1


Dieser Enum stellt korrekte Werte für N und M dar. N und M sind Werte 

dafür, wie schnell die Kameras getaktet werden. 

void reset ( CAM_SPEED speed = CAM_SPEED_75_MHZ ); 

Die Arbeitsweise dieser Methode hat sich im Vergleich zur ursprünglich 

Version nicht geändert. Hinzugekommen ist jedoch, das N und M nicht 

mehr direkt angegeben werden müssen, sondern ein enum bereitgestellt 

ist. Weiterhin kann diese Methode auch ohne Parameter aufgerufen werden, 

so dass automatisch ein Standardwert gesetzt wird. 

Probleme 

• Der “clock_generator” IP-Core des ATLYS kann die am besten geeigneten 

Taktraten nicht herausgeben, wenn gleichzeitig ein 75MHz Takt benötigt 

wird. 

Dateistruktur 

Die Dateistruktur von Treiber und IP-Core blieb mit Außnahme des TCL- 

Skripts unverändert: 

• pcores/cam_bootloader_v1_00_a/data/cam_bootloader_v2_1_0.tcl - TCL- 

Skript für die MPD-Datei 


Fast alle gesetzten Ziele des Sprint Ziele wurden erfolgreich erreicht. Die 

3D Armerkennung wurde portiert, jedoch weichte das Verhalten auf dem 

Microblaze von dem in Python programmierten Algorithmus ab. Der Softwareprototyp 

für die Trajektorienführung wurde für die zweidimensionale 

Ebene umgesetzt. Da die Trajektorienführung vor allem für den Anwendungsfall 

Sizze zeichnen erstellt wurde, reichte es den Softwareprototyp für 

die zweidimensionale Anwendung zu erstellen. Dieser ist auf dreidimensionale 

Anwendungen erweiterbar. Die übrigen geplanten Arbeitspakete 

wurden erfolgreich und vollständig umgesetzt. Die Untersuchung des Zig- 

Zag Verhaltens beim Zeichnen ergab, dass die sehr kleine und ungenaue 

Auflösung der Servos sowie der instabile Aufbau des Roboterarms der 

365


Grund für solches Verhalten ist. Eine bessere Roboterarm-Hardware würde 

diesem Problem entgegen wirken. Das Zeichenbereich wurde durch Verbesserung 

der Kinematik auf 10 · 10 cm verbessert. Des Weiteren wird ein neuer Sprint 

geplant, in dem die Integration der vorhandenen, Entwicklung der neuen 

Komponenten, sowie der Bau des neuen Roboterarms erfolgen soll. 

366



In diesem Sprint wird der Akzent auf die Integration der Komponenten 

für Steuerung sowie die Entwicklung der neuen Komponenten für den 

Anwendungsfall Skizze Zeichnen gesetzt. Außerdem wird in diesem Sprint 

der neue Roboterarm schrittweise designet und gebaut. Hierzu werden die 

Teile des Roboters in CAD designet und mit Hilfe einer Erodier-Maschine 

erstellt. 

Die Integration umfasst die Portierung der vorhandenen OFFIS-Automation- 

Toolbox-Plugins für die Kinematik und die alternative Gestensteuerung auf 

den Microblaze. Damit sollen die Kinematik sowie die alternative Gestensteuerung 

ohne Computer laufen. 

Die Entwicklung der Komponenten für den Anwendungsfall Skizze zeichnen 

umfasst die Vektorisierung einer durch die Kamera aufgenommenen 

Person sowie die Entwicklung der neuen Kinematik. Dabei wird die Kinematik 

für den neuen Roboterarm entwickelt, sodass sie bei der Fertigstellung 

des neuen Roboterarms bereits eingesetzt werden kann. Die Vektorisierung 

soll als OFFIS-Automation-Toolbox-Plugin realisiert werden, 

damit sie später mit der direkten Ansteuerung des Roboterarms integriert 

wird. 

2.11.1 Portierung der Kinematik 


• Kinematik Code 


Ziel dieses Arbeitspaketes ist die Portierung der Kinematik. Dabei soll die 

momentan in der OFFIS-Automation-Toolbox laufende Programmlogik derart 

geändert werden, dass sie auf dem Microblaze ausführbar ist. Um dies 

zu erreichen wird in einem ersten Schritt die Programmlogik in der OFFIS- 

Automation-Toolbox behalten, jedoch nicht auf dem Microblaze ausführbaren 

Programmteile ersetzt. Zu den nicht ausführbaren Programmteilen gehören 

zum Einen verwendete Bibliotheken wie Qt und zum Anderen Datenformate 

welche der Microblaze nicht verwenden kann wie doubles. 

Aufwand 

• 8 PT Portierung 

367



Lieferumfang 

• Portierter C++ Quelltext für den Microblaze 

• Testprojekt zur Verifizierung 

368


2.11.2 Portierung der alternativen Gestensteuerung 


• Programmquelltext der Alternativen Gestensteuerung 

• BlobDetection Treiber 

• portierte Kinematik 


Ziel dieses Arbeitspaketes ist die Portierung der alternativen Gestensteuerung. 

Dabei soll die momentan in der OFFIS-Automation-Toolbox laufende Programmlogik 

derart geändert werden, dass sie auf dem Microblaze ausführbar 

ist. Dabei müssen die Python-Skripte in C++ Dateien übersetzt 

werden. 

Aufwand 

• 2 PT Portierung 


Lieferumfang 

• Portierter C++ Code für den Microblaze 

• Testprojekt zur Verifizierung 

369


2.11.3 Integration der Komponenten zum Demonstrator 

Armhaltung nachahmen 


• Einzelkomponenten in Form von IP-Core für Hardware 

• Treiber der IP-Core für den Microblaze 


Ziel dieses Arbeitespaketes ist es die Integration aller nötigen Komponenten 

vorzunehmen für den Anwendungsfall Ärmhaltung nachahmen". 

Dazu wird die bereits erstellte doppelte Bildverarbeitungskette und die 

Ansteuerung der Servomotoren in einem Projekt integriert, sowie die Ausgabe 

der Aufnahmen über ein HDMI fähiges Display. Dazu werden die 

benötigten Hardwarekomponenten in einem Aufbau auf dem Atlys-Entwicklungsboard 

untergebracht. 

Die Ansteuerung der Komponenten erfolgt über Software die auf dem Microblaze 

laufen wird. Dazu werden bestehende Treiber und Algorithmen 

zu einem Programm vereint. Anschließend wird ermittelt ob die Laufzeiten 

der Software den Anforderungen entsprechen. 

Aufwand 

• 1W (4 PT) Integration der Hardware Komponenten 

• 1W (4 PT) Integration der nötigen Treiber, sowie weiterer Software 

Algorithmen 

• 1W (4 PT) Dokumentation sowie Geschwindigkeitsanalyse 

Lieferumfang 

• ATLYS-Projekt das den Anwendungsfall Ärmhaltung nachahmenërfüllt 

und die gestzten Anforderungen erfüllt. 

370


2.11.4 Kinematik für neuen Roboterarm 



• OFFIS-Automation-Toolboxplugin für Trajektorienführung mit Python- 

Schnittstellen 


Ziel dieses Arbeitspakets ist die Vor- sowie Rückwärtskinematik für den 

neuen Roboterarm zu entwickeln. Die Vorwärtskinematik soll die Position 

des Tool-Center-Point bezüglich des Weltkoordinatensystems des Roboters 

je nach Stellung der Gelenkwinkeln liefern. Die Rückwärtskinematik soll 

als Eingabe die Pose (Position und Ausrichtung) bekommen und eine Lösungsmenge 

im Sinne von Winkelvektoren liefern. Als Demonstrator wird 

ein Pythonscript erstellt, das die Schnittstellen der neuen Kinematik über 

OFFIS-Automation-Toolbox bereitstellt. 

Personen 


Aufwand 

• 4PT - Kinematische Beschreibung der Roboterkonfiguration und Entwicklung 

der Vorwärtskinematik 

• 4PT - Implementierung der Vorwärtskinematik 

• 12PT - Spezifikation und Implementierung der Rückwärtskinematik 

Lieferumfang 

• OFFIS-Automation-Toolboxplugin mit Pythonschnittstellen 

• OFFIS-Automation-Toolboxprojekt (Pythonscript) als Demonstrator 

Deadlines 

• 24.07.2013 12:00 Implementierung der Vorwärtskinematik 

• 07.08.2013 12:00 Implementierung der Rückwärtskinematik 

371


2.11.5 Anbindung des Grauwertlters an den PLB 


• RGB2Grey IP-Core 


Ziel dieses Arbeitspaketes ist den gewichteten Grauwertfilter an den PLB 

anzubinden. Dies soll es ermöglichen zur Laufzeit die gewichtetet Farbe 

auf dem Microblaze einzustellen. Dadurch kann die selbe Hardwarekonfiguration 

für mehrere Anwendungsfälle verwendet werden. 

Aufwand 

• 1W (4 PT) Anbindung des RGB2Grey IP-Core an den PLB 

Lieferumfang 

• ATLYS-Projekt, das den Anwendungsfall „Armhaltung nachahmen“ 

sowie die gesetzten Anforderungen erfüllt. 

372


2.11.6 Vektorisieren eines Portraits 



• Windows 7 Plattform 


Ziel dieses Arbeitespaketes ist die Vektorisierung eines mit der OFFIS- 

Automation-Toolbox aufgenommen Bildes einer Person. Dieses Bild soll 

mit Hilfe von Software, welche auf einem Windows 7 PC läuft, automatisiert 

in ein Vektorgrafikformat konvertiert werden. Das Quellbild ist ein 

Farbbild, das von einer Webcam aufgezeichnet wird sowie in ein schwarz 

weiß Vektorgrafikformat übertragen werden soll. Dabei ist zwischen den 

vorhanden Formaten abzuwegen. 

Aufwand 

• 1W (2 PT) Recherche und Evaluierung vorhandener Lösungen 

• 1W (2 PT) Erstellen eines Bildvektorisierungsprozesses 

Lieferumfang 

• Eine OFFIS-Automation-Toolbox Plugin für das erstellen einer Vektorgrafik 

373


2.12 Sprint 7 

Im Folgenden werden die Ergebnisse der Planung sowie der Umsetzung 

der einzelnen Arbeitspakete ausführlich vorgestellt. 

2.12.1 Portierung der Kinematik 

Ziel dieses Arbeitspaketes ist die Portierung der Kinematik. Dabei soll die 

momentan in der OFFIS-Automation-Toolbox laufende Programmlogik derart 

geändert werden, dass sie auf dem Microblaze ausführbar ist. Um dies 

zu erreichen wird in einem ersten Schritt die Programmlogik in der OFFIS- 

Automation-Toolbox behalten, jedoch nicht auf dem Microblaze ausführbaren 

Programmteile ersetzt. Zu den nicht ausführbaren Programmteilen gehören 

zum Einen verwendete Bibliotheken wie Qt und zum Anderen Datenformate, 

welche der Microblaze nicht verwenden kann, wie doubles. 

2.12.1.1 Durchgeführte Änderungen 

1. Includes Aufräumen 

2. Alle Vorkommen von QMatrix4x4 durch Matrix4x4 ersetzten 

3. Alle Vorkommen von QVector[234]D durch Vector[234]D ersetzten 

4. Alle Vorkommen von QVector und QList durch std::vector ersetzten 

5. Matrix4x4 und Vector[234]D implementieren (Programmquelltext aus 

Qt übernehmen) 

6. QSettings Verwendung durch struct mit Konstanten ersetzten 

7. Alle Vorkommen von double durch float ersetzten 

8. Alle double verwendeten-Funktionen (sqrt, sin, cos, ...) durch float Varianten 

ersetzten 

9. Alle Vorkommen von printf durch pg_printf ersetzten, welches per 

Präprozessor gesetzt werden kann 

10. Testen des Programmquelltextes in der Toolbox und auf dem Microblaze 

374



Die folgenden Dateien wurden für die Portierung angelegt oder Verändert. 

Das Basisverzeichnis ist offis-toolbox.git/plugins/automation/RoboArm/. 

Diese Dateien können desweiteren direkt in ein Microblaze-Projekt kopiert 

und verwendet werden. 

• Link.h 

Meta-Informationen zur Link-Klasse 

• Link.cpp 

Klasse welche Informationen über ein Verbindungselement des Roboterarms 

liefert 

• InverseKinematic.h 

Meta-Informationen für die Rückwärtskinematik 

• InverseKinematic.cpp 

Implementierung der Rückwärtskinematik 

• KinematicChain.h 

Meta-Informationen für die Vorwärtskinematik 

• KinematicChain.cpp 

Implementierung der Vorwärtskinematik 

• config.h 

Enthält die Meta-Informationen für die Konfiguration 

• config.cpp 

Enthält die Link-Konfiguration des Roboterarms 

• vector.h 

Enthält die Definition und Implementierung von Vector[234]D 

• matrix.h 

Enthält die Definition und Implementierung von Matrix4x4 

• xilinx_foo.h 

Enthält Präprozessor-Definitionen für pg_printf 

375


2.12.2 Portierung der alternativen Gestensteuerung 

Ziel dieses Arbeitspaketes ist die Portierung der alternativen Gestensteuerung. 

Dabei soll die momentan in der OFFIS-Automation-Toolbox laufende Programmlogik 

derart geändert werden, dass sie auf dem Microblaze ausführbar 

ist. Dabei müssen die Python-Skripte in C++ Dateien übersetzt 

werden. Weiterhin soll ein Demonstrator aufgebaut werden, welcher die 

alternative Gestensteuerung umsetzt. Dies bedeutet, dass eine komplette 

Kette von der Kamera bis zur Kinematik zusammenspielt. 

2.12.2.1 Umstellung des Graustufenlters auf mehrere Farben 

In seiner bisherigen Form hat der gewichtete Graustufenfilter immer den 

roten Kanal als größtes Gewicht genommen. Da die alternative Gestensteuerung 

aber auch auf einen gewichteten Grünkanal angewiesen ist, wurde 

dieser IP-Core angepasst, so dass durch einen Generic die Farbe der Gewichtung 

einstellbar ist. Am Quelltext wurde dabei nichts geändert, es wurden 

lediglich einige Variablen hinzugefügt um auf den Generic reagieren zu 

können. 


Die portierte Version der alternativen Gestensteuerung muss die BLOB- 

Detection wesentlich anders ansprechen, als es der Pythonquelltext kann. 

Dies führte zu Problemen im zeitlichen Ablauf, was korrigiert werden konnte. 

Die Integration der benötigten Komponenten hat sehr viel Zeit benötigt, 

da das XPS viele Probleme bereitete. Hierzu gehörte unter Anderem eine 

Anpassung des Speed Grade von -2 auf -3, damit das Timing stimmte. Der 

Graustufenfilter musste auf mehrere Farben angepasst werden. 


Die folgenden Dateien wurden für die Portierung angelegt. Das Basisverzeichnis 

ist microblazecode.git/alternative_gestensteuerung/. Das in diesem 

Verzeichnis enthaltene Projekt kann als Demonstrator verwendet werden. 

Das zugehörige XPS-Projekt befindet sich im Branch alternative_gestensteuerung 

des gits atlys.git/. 

• magic.h 

Meta-Informationen zur alternativen Gestensteuerungs-Klasse 

376


• magic.cpp 

Klasse, welche die komplette Alternative Gestensteuerung enthält. 

Die Methode main beinhaltet die Logik. 

• main.cc 

Enthält ein Beispiel zur Verwendung der alternativen Gestensteuerung 

377


2.12.3 Kinematik für neuen Roboterarm 

Ziel dieses Arbeitspakets ist die Vor- sowie Rückwärtskinematik für den 

neuen Roboterarm zu entwickeln. Die Vorwärtskinematik soll die Position 

des Tool-Center-Point bezüglich des Weltkoordinatensystems des Roboters 

je nach Stellung der Gelenkwinkeln liefern. Die Rückwärtskinematik soll 

als Eingabe die Pose (Position und Ausrichtung) bekommen und eine Lösungsmenge 

im Sinne von Winkelvektoren liefern. Als Demonstrator wird 

ein Pythonscript erstellt, das die Schnittstellen der neuen Kinematik über 

OFFIS-Automation-Toolbox bereitstellt. 



• OFFIS-Automation-Toolboxplugin für Trajektorienführung mit Pythonschnittstellen 

Lieferumfang 

• OFFIS-Automation-Toolboxplugin mit Pythonschnittstellen 

• Pythonscript als Demonstrator 

378


2.12.3.1 Umstellung der Entwicklungsstrategie 

Die Spezifikation des neuen Roboterarms beruht auf dem Modell des Puma- 

Roboters (Siehe Kapitel 2.10.4.2). Nach dem die ersten Analyseschritte der 

herkömmlichen Entwicklung der Kinematik gemacht wurden (Festlegung 

der Koordinatensysteme für jedes Segment sowie Aufstellung der Denavit 

Hartenberg-Tabelle) war die Gruppe auf die quelloffene Software Open- 

RAVE gestoßen. Da sich im Sprint 2 die Entwicklung der Kinematik als 

ein sehr zeitaufwändiger Prozess erwiesen hat, wurde durch die Gruppe 

beschlossen dieses Werkzeug zu benutzen, da es eine vollständige Berechnung 

der Vor- und Rückwärtskinenmatik übernehmen kann. Außerdem ist 

das Werkzeug in der Lage, eine komplett eigenständig lauffähige Anwendung 

in Form eines C++ Quelltextes zu generieren. 

Im Team wurde beschlossen statt eines kompletten Entwurfs der Kinematik 

die Zeit in die Einarbeitung in das Werkzeug OpenRAVE zu investieren. 

Damit wurden die konkreten Ziele (Teilaufgaben) dieses Arbeitspakets 

entsprechen geändert: 

• Einarbeitung in das Werkzeug OpenRAVE (Einrichtung, Nutzung, 

Codegenerierung) 

• Einarbeitung in das OpenRAVE konforme XML-Format für Modellierung 

der Roboter 

• Modellieren des neuen Roboterarms im OpenRAVE 

• Erstellung des neuen Kinematik-Plugins (Implementierung der Schnittstellen 

für die Benutzung der Kinematik) 

• Integration der generierten Programm in das eigene Projekt (Einarbeitung 

in die Schnittstellen des generierten Quelltextes) 

• Validierung des integrierten Programms 

Da bei der Einarbeitung nicht absehbare Probleme entstehen können, wurde 

eine Zeit von vier Wochen plus zwei Wochen Puffer für das Arbeitspaket 

geplant. 

2.12.3.2 Vorwärtskinematik 

Zur Beschreibung der Kinematik werden zunächst die Winkel der Gelenke 

definiert. Die Zuordnung der Winkelnamen zu Gelenken ist in Abbildung 

2.166 dargestellt. 

379


180° 

0° 

γ 

180° 

ζ 

0° 

ε 

180° 

0° 

180° 

δ 

0° 

β 

0° 

0° 

⍺ 

180° 

180° 

Abbildung 2.166: Kinematische Konfiguration des neuen Roboarms 

Die schwarzen Pfeile in Abbildung 2.166 stellen die Arbeitsbereiche und 

damit auch die Einschränkungen jedes einzelnen Gelenks dar. 

Da nach der Entscheidung der Gruppe die Vor- sowie Rückwärtskinematik 

aus dem OpenRAVE-Modell generiert werden soll, wurde zunächst das 

spezifizierte Modell aus Abbildung 2.166 im XML-Format umgesetzt. 

In Abbildung 2.167 ist das Ergebnis der Modellierung des neuen Roboterarm 

im OpenRAVE konformen XML-Format dargestellt. 

Die generierte C++ Datei für Kinematik ergibt ein eigenständiges Programm, 

das auch ohne ihre main-Methode als Programmbibliothek nutzbar 

ist. Diese bekommt einen validen Winkelvektor als Eingabe und liefert die 

Position und die Orientierungsmatrix des Tool-Center-Point zurück. Die 

Schnittstellen werden im Abschnitt 2.12.3.4 ausführlicher erklärt. 

2.12.3.3 Rückwärtskinematik 

Die Rückwärtsberechnung aus Position und Ausrichtung des Endeffektors 

(Tool-Center-Point) auf mögliche Winkelvektoren wurde ebenso aus dem in 

Abbildung 2.167 dargestellten Modell generiert. Das ist dieselbe C++ Datei, 

welche auch für die Rückwärtskinematik eine Schnittstelle bereitstellt. Als 

Eingabe bekommt diese Position des Tool-Center-Point und seine Orientierungsmatrix 

als Ausrichtung. Zurückgeliefert werden entweder mehrere 

Lösungen als Winkelvektoren oder keine Lösung, falls die eingegebene 

380


Abbildung 2.167: Modell des neuen Roboarm in OpenRAVE 

Kombination aus Position und Ausrichtung außerhalb des theoretisch erreichbaren 

Bereich des Roboters liegt. Anmerkung: diese Lösungen beachten 

nicht die gegebenen Winkeleinschränkungen. 

2.12.3.4 OFFIS-Automation-Toolboxplugin für neue Kinematik 

Da das generierte C++ Programm nicht die in dem Projekt RoboArm definierten 

Schnittstellen für die Kinematik bereitstellt, wurde das OFFIS-Automation- 

Toolboxplugin als Wrapper um das generierten Programm erstellt. Damit 

konnte die Kinematik getestet und in das Projekt eingebunden werden. 

Die generierte Rückwärtskinematik benötigt als Eingabe Rotationsmatrix 

und Ortsvektor der zu erreichenden Ausrichtung und Position. Da diese 

vom Benutzer nicht leicht auszurechnen sind, wird im Wrapper eine Umrechnung 

von Ausrichtung und Position in diese Parameter vorgenommen. 

Dabei beinhaltet die Rotationsmatrix die Drehungen um alle Koordinatenachsen. 

Schnittstelle Plugin 

Folgende Schnittstellen stellt das OFFIS-Automation- 

Toolboxplugin für die Nutzung im Projekt RoboArm bereit: 

381


1 QList < double > getTCP_ByModelAngleValues ( RcRepeatable < double 

, 1, 6> angles ); 

Diese Methode liefert die Position des Tool-Center-Point als Werteliste (x, 

y, z) zurück. Der Eingabeparameter ist ein sechsstelliger Winkelvektor in 

Radianten für die sechs Gelenke des Roboterarms (α, β, γ, δ, ɛ, λ) im Sinne 

von den durch OpenRAVE verwendeten Winkel. 

1 QList < double > getTCP_ByServoHardwareAngleValues ( 

RcRepeatable < double , 1, 6> angles ); 

Diese Methode liefert die Position des Tool-Center-Point als Werteliste (x, 

y, z) zurück. Der Eingabeparameter ist ein sechsstelliger Winkelvektor in 

Radianten für die sechs Gelenke des Roboterarms (α, β, γ, δ, ɛ, λ)im Sinne 

von Winkelwerten der Servos. 

1 QList < double > getAngleVectorModelValues ( double xP , double 

yP , double zP , double xO , double yO , double zO ); 

Diese Methode gibt eine Liste der Winkelvektoren im OpenRAVE konformen 

Format zurück. Die Winkelvektoren sind die berechneten Lösungen, 

die als aneinander gehängte Listen (immer genau sechs Werte) zusammengefasst 

sind. Beispiel: gibt es nur eine Lösung, dann ist die Länge der 

Rückgabeliste genau sechs. Bei zwei Lösungen ist die Länge 12 und bei n 

Lösungen ist die Rückgabeliste von der Länge 6 · n. Wenn keine Lösung 

gefunden werden kann, wird eine leere Liste zurückgegeben. 

Die ersten drei Eingabeparameter stehen für die Position des Tool-Center- 

Point im dreidimensionalen Raum und die anderen drei Parameter stehen 

für die Orientierung im Raum im Sinne von separaten Drehungen um die 

jeweiligen Koordinatenachsen (X, Y, Z) des Weltkoordinatensystems. Die 

Drehwinkel werden in Radiant im Bereich von −π bis π angenommen. 

1 QList < double > getAngleVectorMappedToHardware ( double xP , 

double yP , double zP , double xO , double yO , double zO ); 

Diese Methode setzt die gleiche Funktionalität um, wie die getAngleVector- 

ModelValues. Jedoch liefert diese Methode die auf die Hardware abgebildeten 

Winkelwerte. 

1 QList < double > getOptimalSolution ( RcRepeatable < double , 1, 6> 

currentAngleVector , RcRepeatable < double ,0 ,48 > 

solutionsAngleVector ); 

Diese Methode implementiert die Kostenfunktion. Die Ausgabe dieser Methode 

ist ein Winkelvektor. Die Eingabe der Methode sind zum Einen der 

Winkelvektor der aktuellen Stellung und zum Anderen eine Lösungsmenge 

von Winkelvektoren. Die Methode wählt aus den Eingabewinkelvektoren 

382


denjenigen, welcher am Wenigsten vom aktuellen Winkelvektor im Sinne 

der Kostenfunktion unterscheidet. 

Schnittstelle OpenRave 

Das OpenRAVE Plugin, das die Kinematiken 

berechnet und das Programm generiert, heisst IKfast. 

Folgende Schnittstellen stellt das von OpenRAVE generierte C++ Programm 

bereit (IKFAST_API 54 ): 

1 bool ComputeIk ( const IkReal * eetrans , const IkReal * eerot , 

const IkReal * pfree , ikfast :: IkSolutionListBase < IkReal >& 

solutions ); 

Diese Methode berechnet die Rückwärtskinematik. Sie gibt true zurück, 

wenn mindestens eine Lösung gefunden werden konnte. Das eetrans ist ein 

Array, welches den Translationsanteil des Tool-Center-Point (x, y, z) darstellt. 

Das eerot ist ein Array, welches die Orientierungsmatrix (Rotationsanteil) 

3x3 darstellt. Diese ist zeilenweise im Array abgelegt. Der Parameter pfree 

steht für freie Parameter(Gelenke), die aber von der im Projekt RoboArm 

benutzten Kinematik nicht verwendet werden und daher leer bleiben muss. 

Der letzte Parameter solutions ist der Zeiger auf die Lösungen, wenn sie gefunden 

werden konnten. 

1 void ComputeFk ( const IkReal * joints , IkReal * eetrans , IkReal * 

eerot ); 

Diese Methode berechnet die Vorwärtskinematik. Der Zeiger joints zeigt 

auf den Winkelvektor. Die berechnete Position des Tool-Center-Point wird 

im Parameter eetrans, welches ein Zeiger auf einen Array ist, abgelegt. 

Die Orientierung wird in der Drehmatrix kodiert zurückgegeben, die im 

Array über den Zeiger eerot erreichbar ist. Diese Drehmatrix müsste erst 

umgerechnet werden, so dass die Ausrichtung zurückgegeben werden kann. 

Dies wird nicht vorgenommen, da die Ausrichtung für das Projekt RoboArm 

keine praktische Bedeutung hat. 

2.12.3.5 Generierung des Quelltextes der Kinematik 

Hier wird ein kurzer Arbeitsfluss erläutert, wie die Kinematik mit IKfast 

erstellt werden kann. 

In Abbildung 2.168 ist der Arbeitsfluss für Generierung der Kinematik 

dargestellt. 

54 Quelle dieses Begriffes ist: openrave-users-list.185357.n3.nabble.com/ 

IK-generated-rotation-problem-td4026671.html 

383


XML-Modell des 

Roboters bearbeiten 

Roboterbestandteile 

(Segmente und Gelenke) 

untersuchen 

Kinematik generieren 

Abbildung 2.168: Arbeitsfluss für IKfast-Generierung 

Zunächst wird ein OpenRAVE konformes XML-Modell des Roboters erstellt 

55 . Danach muss der Roboter auf die Anzahl der Segmente, Gelenke 

sowie das erste (Base) und das Letzte Segment (meistens der Greifer) untersucht 

werden. 

Mit dem Befehl 

openrave-robot.py ROBOTERNAME.xml –info links 

werden die Segmente (Links) des Roboters aufgelistet. Anschließend wird 

durch den Befehl 

python ‘openrave-config 

–python-dir‘/openravepy/_openravepy_/ikfast.py 

–robot=ROBOTERNAME.xml –iktype=transform6d 

–baselink=ERSTES_SEGMENT –eelink=LETZTES_SEGMENT 

–savefile=DATEINAME.cpp 

die Kinematik für den angegebenen Roboter berechnet und eine C++ Datei 

mit dem Namen DATEINAME.cpp generiert. Dies erfolgt, falls der Roboter 

OpenRAVE konform in XML modelliert ist und eine richtige Anzahl an 

Gelenke für den Verwendenden Kinematiktyp (ggf. iktype=transform6d) 

besitzt 56 . 

55 http://openrave.programmingvision.com/wiki/index.php/Format:XML 

56 http://openrave.org/docs/latest_stable/openravepy/ikfast/ 

384



Einrichtung von OpenRAVE 

Auf der Webpage von OpenRAVE 57 sind 

die Installationspakete sowohl für Windows als auch für Ubuntu Linux 

Plattformen angeboten. In dem Projekt RoboArm werden die meisten Entwicklungswerkzeuge, 

abgesehen von Verwaltungs- sowie Versionierungssoftware, 

unter Windows verwendet. Aus diesem Grund wurde versucht die 

vollständige OpenRAVE Software unter Windows aufzusetzen. Dies scheiterte 

allerdings aufgrund der mangelhafte Unterstützung für Windows seitens 

Entwicklerteams von OpenRAVE. Es fehlten mehrere Bibliotheken sowie 

lies sich die OpenSource Software nicht mit den beschriebenen Mitteln 

kompilieren. Unter Windows wurde lediglich die Testumgebung für XML- 

Modelle installiert. Dies hat bereits eine Woche Zeit gekostet. 

Danach wurde zu Ubuntu Linux gewechselt, wo die OpenRAVE Software 

installiert und verwendet werden konnte. 

XML-Modell 

Ein OpenRAVE konformes XML-Modell besitzt eine Besonderheit: 

Die Maße der starren Körper, also der Segmente der Roboter, 

sind stets relativ zum Zentrum, dem sog. Gewichtsmittelpunkt angegeben. 

Auch die weiteren Segmente, die relativ zu den vorherigen Segmenten 

in der kinematischen Kette platziert sind, können mit ihren Gewichtsmittelpunkte 

relativ zum Gewichtsmittelpunk des vorherigen Segments lokalisiert 

werden. Dies erschwert den Aufwand der Anpassung der Längen der Segmente 

eines Roboters, wenn ein Robotermodell der gleichen Gelenkkonfiguration 

verschiedene Längen der Segmente besitzen soll. Die Kinematik 

muss stets entsprechend neu generiert werden, sobald etwas an Gelenkoder 

Längenkonfiguration geändert wurde. Das ist ein Nachteil gegenüber 

der herkömmlichen Art und Weise der Kinematikengineerings. Bei der 

herkömmlichen Kinematikengineering werden lediglich die Denavit Hartenberg-Parameter 

verändert und erst bei der Änderung der Gelenkkonfiguration 

eine neuen Kinematik entwickelt. 

Einbindung des generierten C++ Programms 

Die Einbindung des generierten 

Programms ins eigene Projekt besitzt gewissen Eigenheiten, welche 

beachtet werden müssen. Hier müssen die Definitionen der spezifischen 

Konstanten sowie die Reihenfolge dieser Definitionen beachtet werden. 

Außerdem müssen bestimmte Konstanten gesetzt werden, so dass das Programm 

selbständig lauffähig ist oder als gemeinsam genutzte Bibliothek 

verwendet werden kann. 

57 http://openrave.org/docs/latest_stable/install/ 

385


Diese Eigenheiten der Einbindung des C++ Programms in das eigene Projekt 

ist nicht auf der OpenRAVE Webpage oder in der Dokumentation 

angegeben. 

Schnittstelle der Rückwärtskinematik 

Die meisten Probleme ergab die 

Benutzung der Schnittstellen der Rückwärtskinematik und die Validierung 

über die Vorwärtskinematik. Die ersten Tests der Anwendung des generierten 

Programms wurden mit Hilfe des Robot Operation System (ROS) 

IKfast Testmoduls (ikfastdemo.cpp) 58 durchgeführt. Das generierte C++ 

Programm verwendet in der main-Methode lediglich die Schnittstelle für 

die Rückwärtskinematik. Dies führte daher zu dem Irrtum, dass IKfast 

lediglich die Rückwärtskinematik berechen kann. 

Mit dem ROS IKfast Testmodul wurde dann ersichtlich, dass auch die Vorwärtskinematik 

nutzbar ist. Die Vorwärtskinematik ist im Gegensatz zur 

Rückwärtskinematik einfacher zu verwenden. 

Das Hauptproblem der Rückwärtskinematik stellt die Transformationsmatrix 

für den Rotationsanteil dar. Es gibt keine Dokumentation für die Verwendung 

der Schnittstelle und in welcher Form die Drehwinkel in der Matrix 

kodiert sind (z.B. Euler-Notation oder Yaw-Pitch-Roll-Notation). Nach 

dem Feststellen der richtigen Matrix sind einige Tests gescheitert, welche 

zu der Vermutung geführt haben, dass die Matrix falsch verwendet wurde 

oder die Matrix selbst falsch ist. Nach dem Hinzufügen einer weiteren Person 

zur Bearbeitung der Aufgabe, wurden die Tests erneut durchgeführt 

und die korrekte Matrix herausgefunden. Die Interpretation der Winkel 

für die Rotation um die jeweiligen Achse war fehlerhaft. 


Folgende Dateien wurden für die Umsetzung des OFFIS-Automation-Toolboxplugins 

der neuen Kinematik angelegt: 

• ForwardKinematics.h 

Meta-Informationen zum Wrapper um die IKfast Vorwärtskinematik. 

• ForwardKinematics.cpp 

Wrapper um die IKfast Vorwärtskinematik. 

• InverseKinematics.h 

Meta-Informationen zum Wrapper um die IKfast Rückwärtskinematik. 

58 tutorial: http://wiki.ros.org/Industrial/Tutorials/Create_a_Fast_IK_Solution 

386


• InverseKinematics.cpp 

Wrapper um die IKfast Rückwärtskinematik. Beinhaltet die Logik 

der Umrechnung(Kodierung) der Winkel in die Enddrehmatrix (Rotationsanteil). 

• New_Kinematics.h 

Meta-Informationen zum Einstiegspunkt des Wrappers um die IKfast 

Vorwärtskinematik. Stellt die C++ Schnittstellen für die Benutzung 

der Kinematik im für das Projekt RoboArm definierten Format bereit. 

• New_Kinematics.cpp 

Einstiegspunkt des Wrappers für IKfast Vorwärtskinematik. Ruft die 

Funktionalität der Klassen ForwardKinematics und InverseKinematics 

auf. 

• New_KinematicsInterface.h 

Meta-Informationen zur Schnittstellen für Python 

• New_KinematicsInterface.cpp 

Stellt die C++ Schnittstellen als Python Schnittstellen bereit. 

• ikfast.h 

Meta-Informationen zur IKfast. 

• or_ikfast_generated_roboarm2.cpp 

IKfast generierte Datei, die Kinematiken berechnet. 

Die XML-Dateien, aus denen die Kinematik generiert wurde: 

• roboarm.kinbody.xml 

Definiert den kinematischen Aufbau des Roboters 

• roboarm.hand.xml 

Definiert den Greifer des Roboters 

• roboarm.robot.xml 

Definiert den kompletten Roboter 


Die Rückwärtskinematik wurde auf Zeitverhalten untersucht und mit der 

selbst entwickelten Rückwärtskinematik verglichen. Die Testfälle wurden 

387


mit Hilfe der QElapsedTimer-Programmbibliothek auf dem PC durchgeführt. 

Der Testablauf bestand aus der Messung der Ausführungszeiten beider 

OFFIS-Automation-Toolbox-Kinematik-Plugins (alten und der neuen). 

Jede Testvariante wurde mindestens 10000 Mal (mehrfach) aufgerufen und 

die mittlere Ausführungszeit wurde festgehalten. Als Testergebnisse wurden 

folgende Testwerte festgestellt: 

• Inverse Kinematik aus OpenRAVE mit Qt im Wrapper: 204.1 µs 

• Inverse Kinematik aus OpenRAVE ohne Qt im Wrapper: 109.8 µs 

• Alte inverse Kinematik ohne Qt im Wrapper: 10.8 µs 

Aus den Tests ist es ersichtlich, dass durch die Verwendung von Qt-Bibliothek 

die Ausführungszeiten um den Faktor 2 verlängert werden. Die aus dem 

OpenRAVE XML-Modell generierte Rückwärtskinematik arbeitet zusätzlich 

auf Double-Werten. Dies verlängert die Ausführungszeit gegenüber der 

mit Float-Werten implementierten Rückwärtskinematik der vorherigen Version. 

Ein weiteres Arbeitspaket wäre, zum Beispiel, die Optimierung des generierten 

Quelltext und anschließende Portierung auf den Microblaze. Nach 

der Fertigstellung des Roboters muss das XML-Modell bezüglich der Segmentlängen 

ggf. dem Roboter adoptiert werden. 

388


2.12.4 Integration der Komponenten zum Demonstrator 

Armhaltung nachahmen 

Ziel dieses Arbeitspaketes ist die Integration aller Komponenten für den 

Anwendungsfall Armhaltung nachahmen durchzuführen. Dabei liegt der Schwerpunkt 

auf der funktionalen Fertigstellung des Systems. Dazu gehört ebenfalls 

eine Analyse der Performanz und die Identifikation zeitintensiver Programmzeilen. 

Die Integration umfasst dabei das Erstellen das Hardwaredesigns. Darauf 

aufbauend werden die bereits fertigen Softwarekomponenten zu einem 

Gesamtsystem zusammengefügt. Eine weitere Aufgabe ist die Migration 

der in Python geschriebenen Funktionalität zur Erkennung des α -Winkels, 

des Drehwinkels des Schultergelenks, in die Programmiersprache C++. 

Dies ist notwendig, damit dieser auf dem Microblaze ausgeführt werden 

kann. 

2.12.4.1 Integration der Hardware Komponenten 

Dieser Unterabschnitt beinhaltet die Beschreibung der Integration der Hardwarekomponenten. 

Um dies zu erreichen, müssen die entsprechenden IP- 

Cores miteinander verknüpft werden. Hieraus lässt sich dann der entsprechende 

Bitstream für den FPGA erstellen. Als Ausgangspunkt für das Layout wurde 

das bereits erstellte Design aus dem Arbeitspaket 2.10.3 verwendet. Dieses 

besitzt bereits einen Großteil der benötigten Komponenten und wurde 

bereits ausführlich getestet. 

Als erstes wurde die Steuerung der Servos hinzugefügt, die in Abschnitt 

2.10.5 erstellt wurde. Diese IP-Cores generieren die nötigen Pulspositionsmodulations-Signale 

für die Servomotoren. Die Ansteuerung beziehungsweise 

das Setzen der Winkel für die IP-Cores wird durch die Software auf dem 

Microblaze übernommen. 

Des Weiteren wurde die Bildausgabe über die HDMI-Schnittstelle in das 

Hardwaredesign aufgenommen, welche im Abschnitt 2.6.3 dokumentiert 

ist. Diese Bildausgabe ermöglicht während der Entwicklung eine unmittelbare 

und autonome Fehleranalyse. Hiermit ist es möglich Daten über die 

aktuelle Szene, Winkel und Informationen über die aktuelle Tiefe, zu visualisieren. 

Somit bekommt der Benutzer eine Rückmeldung über die richtige 

Positionierung seines Armes gegenüber der Kamera. 

Um während der Entwicklung Informationen auf dem Bildschirm, zusätzlich 

zum Kamerabild, einblenden zu können, wurde der Overlay-IP-Core 

hinzugefügt, der in Abschnitt 2.10.1 beschrieben ist. In Rahmen dieses Ar- 

389


beitspaketes wurden zugehörige Zeitgebersignale aufgrund des HDMI-IP- 

Cores auf 75 MHz umgestellt. 

Die bereits vor diesem Arbeitspaket vorhandene Möglichkeit, Bilder an 

den PC zu übertragen, wurde nicht aus dem Hardwaredesign entfernt. 

Diese Funktionalität ist nicht für den in diesem Arbeitspaket beschriebenen 

Demonstrator wichtig, die USB-Kommunikation wird jedoch für einen 

weiteren Anwendungsfall benötigt. Hierbei geht es um den Anwendungsfall 

„Skizze zeichnen“, welcher in Abschnitt Skizze zeichnen 1.2.3.4 aufgeführt 

ist. Zu Gunsten eines verminderten Wartungsaufwandes, wurde das 

Hardwaredesign so gewählt, das alle Demonstratoren mit ihr realisiert werden 

können. 

Die Fläche des FPGAs ist mit dem erstellten Hardwarelayout zu ca. 90 % 

ausgelastet, sodass noch wenig Platz für weitere Hardwarekomponenten 

zur Verfügung stehen. Eine Übersicht über die verwendeten Hardwarekomponenten 

findet sich in Abbildung 2.169. 

simple_i2c 


simple_i2c 

VmodCamA 

VmodCamB 

cam_data 

cam_data 




image_ bus_ overlay 

pixel_Skipping 



hdmi_out 

usb_driver 

rgb2grey 

rgb2grey 

HDMI Display 

cam_usb 



PC 



servo_1 



servo_2 

servo_3 


servo_4 


servo_5 

servo_6 

Abbildung 2.169: Aufbau der Verwendeten Hardwarekomponenten 

390


2.12.4.2 Integration der Software 

Dieses Unterabschnitt beschreibt die integrierten Softwarekomponenten. 

Diese werden den vorhergegangenen Arbeitspaketen entnommen. Die auf 

dem Microblaze ausgeführte Software ist für verschiedene Aufgaben zuständig. 

Initial werden die notwendigen Einstellungen zur Konfiguration der einzelnen 

IP-Cores durchgeführt. Ein Beispiel für eine solche Einstellung ist das 

Setzen des Schwellwertes für den Schwellenwertfilter. 

In der Hauptmethode, des auf dem Microblaze ausgeführten Programms, 

werden aus Bildregionen und ihren Schwerpunkten Winkel berechnet. Diese 

Winkel werden benutzt, um die Winkel der Servomotoren einzustellen. 

Der eingesetzte Algorithmus ist in Abschnitt 2.6.2 beschrieben und dessen 

Übersetzung in die Programmiersprache C++ in Abschnitt 2.10.2. 

Die erkannten Schwerpunkte der Bildregionen werden durch einen Interrupt 

aktualisiert. Dies geschieht im BLOB-Treiber. Dieser wird Ausgelöst, 

wenn die Hardwarekomponenten die Verarbeitung eines Bildes abgeschlossen 

haben. Die Bildregionen werden zwischen den einzelnen Bilder verfolgt, 

sodass eine Zuordnung möglich ist. Dieser Vorgang wird im Folgenden als 

Tracking bezeichnet. 

Während der Tests dieser Umsetzung hat sich herausgestellt, dass mit dem 

bestehenden Algorithmus die Zuordnung von Bildpunkten untereinander 

nicht zuverlässig erfolgt. Zur Lösung dieses Problems wird eine Matrix 

aufgestellt, welche alle Abstände zwischen alten und neuen Schwerpunkten 

beinhaltet. 

Daraufhin wurde eine weitere Matrix, mit den möglichen Kombination 

zwischen neuer Schwerpunktliste und alter Schwerpunktliste, erstellt. Danach 

wurde mit Hilfe der beiden erstellten Matrizen der kürzeste Pfad zwischen 

alten und neuen Schwerpunkten ermittelt. 

Des Weiteren wurden der Algorithmus aus dem Abschnitt 2.10.8 von der 

Programmiersprache Python in C++ übersetzt. Dieser ermöglicht die Bewegungen 

des menschlichen Schultergelenkes genauer auf die Freiheitsgrade 

des Roboterarms abzubilden. 


Dieses Arbeitspaket wurde in der angesetzten Zeit nicht vollständig umgesetzt, 

da an verschiedenen Stellen der Umsetzung Problemen auftraten, die 

vorher nicht abgeschätzt werden konnten. 

391


Fehler im IP-Core-Image-Overlay 

Ein Problem, das aufgetreten ist, resultierte 

aus der Umstellung der Zeitgeber auf ein 75 MHz Signal. Dies führte 

dazu, dass der Overlay-IP-Core nicht mehr in der Lage war ein Zeilenende 

im Bildstrom zu generieren. Dies führte dazu, dass die Ausgabe auf dem 

HDMI-Bildschirm nicht wie vorgesehen funktionierte. 

Fehler bei der Verfolgung der Schwerpunkte über die Zeit 

Dieser Absatz 

erläutert die aufgetretene Zuordnungsproblematik der Schwerpunkte 

über die Zeit, beziehungsweise über mehrere Frames. Wie bereits angeführt, 

verursachte das Verfolgen von Bildregionen und die Zuordnung 

dieser in der aktuellen Implementierung das Verlieren von Bildregionen. 

Die Lösung zu diesem Problem ist komplexer als zuvor, ermöglicht jedoch 

eine stabilere Verfolgung der Regionen und wurde umfangreich mit den 

Kameradatenströmen getestet. Die Komplexität der Lösung ergibt sich aus 

dem Problem selbst, welches als „Problem des Handlungsreisenden“(Englisch: 

Traveling Salesperson Problem) bezeichnet wird und für das es keine allgemeine 

Lösung gibt. 

Dieser Algorithmus wurde jedoch zu einem späteren Zeitpunkt ebenfalls 

zu einem Problem, da dieser zu einem Speicherproblem auf dem FPGA 

führte. Zur Lösung dieses Problems wurden die möglichen Kombinationen 

der vier Markierungen direkt im Programm aufgeführt. Durch entsprechende 

Tests stelle sich heraus, dass diese Lösung sowohl funktional korrekt als 

auch performanter als die vorherige Lösung ist. 

Diese Lösung ist jedoch nicht kompatibel mit mehreren Markierungen. 

Die Anzahl der möglichen Kombinationen ergibt sich durch die Fakultät 

der Anzahl der Markierungen. Aus diesem Grund müsste für eine abweichende 

Anzahl von Markierungen eine neue Menge an möglichen Kombinationen 

eingegeben werden. 

Fehler bei der Berechnung der Tiefenwerte 

Zusätzlich stellte sich heraus, 

dass die Berechnung der Tiefenwerte von Bildregionen nicht zu den 

gemachten Bewegungen passten. Dies war sowohl mit dem in der OFFIS- 

Automation-Toolbox entwickelten Algorithmus in Python als auch mit der 

in C++ übersetzten Version der Fall. Da jedoch die Tiefen zum Testen und 

Analysieren der Bewegungen des Schultergelenks, Schwerpunkt mäßig der 

Drehwinkel nötig sind, konnte dies nicht abgedeckt werden. 

Das Problem konnte als Berechnungsfehler innerhalb der Berechnungen 

für die Tiefe identifiziert werden. Die stereoskopische Aufnahme einer Bildszene 

durch zwei Kameras führt dazu, dass sich die Position der selben 

Markierung im Raum auf den beiden Bildsensoren unterscheidet. Dieser 

392


Abstand wurde in der ersten Implementation nicht korrekt berechnet. Die 

alte Berechnung addierte jeweils die Längen der beiden Vektoren, im Bezug 

auf den Abstand zum Mittelpunkt des Bildsensors. Korrekt ist jedoch der 

direkte Abstand der beiden Punkte auf den entsprechenden Bildsensoren. 

Die vorher durchgeführten Testfälle ergaben dennoch korrekte Tiefen, da 

der direkte Abstand beider Punkte durch das Zentrum des Bildsensors verlief. 

Nach oben genannten Änderung und entsprechenden Testfällen funktioniert 

die Berechnung der Tiefen. Die Genauigkeit schwangt jedoch, wie 

auch schon zuvor, je nach Belichtungsverhältnis. 

2.12.4.4 Testfälle 

Dieser Unterabschnitt beschäftigt sich mit dem Testen des Systems. Dabei 

wird zunächst das portierte System mit statischen Testfällen getestet. Danach 

wird das System mit Hilfe von verschiedenen Testpersonen getestet. Als 

Testpersonen standen Tobias Schüürhuis, Vitaliy Beguchiy, Peter Gewald 

und Patrick Elfert zur Verfügung. 

Statische Testfälle 

Zur Validierung der am Ende des integrierten Algorithmus 

berechneten Winkel wurden folgende statische Testfälle verwendet. 

Die Eingabewerte entsprechen den Schwerpunkten bzw. den 3D- 

Koordinaten der Gelenke eines Arms und sind im Folgenden in der Reihenfolge 

Schulter (β-Schwerpunkt), Ellenbogen (γ-Schwerpunkt), Handgelenk 

(δ-Schwerpunkt) und Finger (ɛ- Tool-Center-Point) aufgelistet. Das 

Ergebnis entspricht den Gelenkwinkeln in gleicher Reihenfolge, wobei der 

erste Winkel (α) dem Drehwinkel des Roboterarms entspricht. 

Handgelenk geknickt (nach oben): 

⎡⎛ 

⎣⎝ 

90 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

120 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

150 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

180 

60 

90 

⎞⎤ 

⎠⎦ ⇒ 

⎛ 

⎜ 

⎝ 

α = 180° 

β = 90° 

γ = 180° 

δ = 90° 

⎞ 

⎟ 

⎠ 

̌ 

Handgelenk geknickt (nach oben, gebeugt): 

⎡⎛ 

⎣⎝ 

90 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

120 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

150 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

180 

60 

60 

⎞⎤ 

⎠⎦ ⇒ 

⎛ 

⎜ 

⎝ 

α = 90° 

β = 90° 

γ = 180° 

δ = 90° 

⎞ 

⎟ 

⎠ 

X 

393


Der obige Testfall zeigt einen Fehler bei der Berechnung des Drehgelenks. 

Die schräge Ausrichtung hätte eine Drehung von 135° ergeben müssen. 

Die Ausrichtung der Hyperebene, welche zur Berechnung des Drehwinkels 

verwendet wird, wurde im Folgenden statisch gesetzt. Die Ausrichtung 

dieser Ebene ist immer orthogonal zur Szene, sodass eine explizite Berechung 

nicht erforderlich ist. Lediglich der Stützvektor, also die Position der Ebene 

bleibt dynamisch. Nach Behebung dieses Fehlers, wurden sämtliche Winkel 

nochmals mit verschiedenen Gelenkpositionen wie folgt getestet. 

Gestreckter Arm (waagerecht): 

⎡⎛ 

⎣⎝ 

90 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

120 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

150 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

180 

90 

90 

⎞⎤ 

⎠⎦ ⇒ 

⎛ 

⎜ 

⎝ 

α = 0° 

β = 90° 

γ = 180° 

δ = 180° 

⎞ 

⎟ 

⎠ 

̌ 

Gestreckter Arm (diagonal nach oben): 

⎡⎛ 

⎣⎝ 

90 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

120 

60 

90 

⎞ 

⎛ 

⎠ , ⎝ 

150 

30 

90 

⎞ 

⎛ 

⎠ , ⎝ 

180 

0 

90 

⎞⎤ 

⎠⎦ ⇒ 

Gestreckter Arm (diagonal nach oben, gebeugt): 

⎡⎛ 

⎣⎝ 

90 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

120 

60 

60 

⎞ 

⎛ 

⎠ , ⎝ 

150 

30 

30 

⎞ 

⎛ 

⎠ , ⎝ 

Gestreckter Arm (diagonal nach unten): 

⎡⎛ 

⎣⎝ 

90 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

120 

120 

90 

⎞ 

⎛ 

⎠ , ⎝ 

150 

150 

90 

⎞ 

⎛ 

⎠ , ⎝ 

180 

0 

0 

180 

180 

90 

⎞⎤ 

⎠⎦ ⇒ 

⎞⎤ 

⎠⎦ ⇒ 

⎛ 

⎜ 

⎝ 

⎛ 

⎜ 

⎝ 

⎛ 

⎜ 

⎝ 

α = 180° 

β = 135° 

γ = 180° 

δ = 180° 

α = 135° 

β = 125° 

γ = 180° 

δ = 180° 

α = 0° 

β = 45° 

γ = 180° 

δ = 180° 

⎞ 

⎟ 

⎠ 

⎞ 

⎟ 

⎠ 

⎞ 

⎟ 

⎠ 

̌ 

̌ 

̌ 

Gestreckter Arm (diagonal nach unten, gebeugt): 

394


⎡⎛ 

⎣⎝ 

90 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

120 

120 

60 

⎞ 

⎛ 

⎠ , ⎝ 

150 

150 

30 

⎞ 

⎛ 

⎠ , ⎝ 

180 

180 

0 

Ellenbogen geknickt (senkrecht nach oben): 

⎡⎛ 

⎣⎝ 

90 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

120 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

120 

60 

90 

⎞ 

⎛ 

⎠ , ⎝ 

120 

30 

90 

⎞⎤ 

⎠⎦ ⇒ 

⎞⎤ 

⎠⎦ ⇒ 

Ellenbogen geknickt (sekrecht nach oben, gebeugt): 

⎡⎛ 

⎣⎝ 

90 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

120 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

120 

60 

60 

⎞ 

⎛ 

⎠ , ⎝ 

120 

30 

30 

⎞⎤ 

Ellenbogen geknickt (senkrecht nach unten): 

⎡⎛ 

⎣⎝ 

90 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

120 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

120 

120 

90 

⎞ 

⎛ 

⎠ , ⎝ 

120 

150 

90 

⎠⎦ ⇒ 

⎞⎤ 

⎠⎦ ⇒ 

Ellenbogen geknickt (sekrecht nach unten, gebeugt): 

⎡⎛ 

⎣⎝ 

90 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

120 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

120 

120 

60 

⎞ 

⎛ 

⎠ , ⎝ 

120 

150 

30 

⎞⎤ 

⎠⎦ ⇒ 

⎛ 

⎜ 

⎝ 

⎛ 

⎜ 

⎝ 

⎛ 

⎜ 

⎝ 

⎛ 

⎜ 

⎝ 

⎛ 

⎜ 

⎝ 

α = 45° 

β = 55° 

γ = 180° 

δ = 180° 

α = 180° 

β = 90° 

γ = 90° 

δ = 180° 

α = 135° 

β = 90° 

γ = 90° 

δ = 180° 

α = 0° 

β = 90° 

γ = 90° 

δ = 180° 

α = 45° 

β = 90° 

γ = 90° 

δ = 180° 

⎞ 

⎟ 

⎠ 

⎞ 

⎟ 

⎠ 

⎞ 

⎟ 

⎠ 

⎞ 

⎟ 

⎠ 

⎞ 

⎟ 

⎠ 

̌ 

̌ 

̌ 

̌ 

̌ 

Handgelenk geknickt (nach oben): 

⎡⎛ 

⎣⎝ 

90 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

120 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

150 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

150 

60 

90 

⎞⎤ 

⎠⎦ ⇒ 

⎛ 

⎜ 

⎝ 

α = 180° 

β = 90° 

γ = 180° 

δ = 90° 

⎞ 

⎟ 

⎠ 

̌ 

395


Handgelenk geknickt (nach oben, gebeugt): 

⎡⎛ 

⎣⎝ 

90 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

120 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

150 

90 

90 

⎞ 

Handgelenk geknickt (nach unten): 

⎡⎛ 

⎣⎝ 

90 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

120 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

150 

90 

90 

⎛ 

⎠ , ⎝ 

⎞ 

⎛ 

⎠ , ⎝ 

150 

60 

60 

150 

130 

90 

Handgelenk geknickt (nach unten, gebeugt): 

⎡⎛ 

⎣⎝ 

90 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

120 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

150 

90 

90 

⎞ 

⎛ 

⎠ , ⎝ 

150 

130 

60 

⎞⎤ 

⎠⎦ ⇒ 

⎞⎤ 

⎠⎦ ⇒ 

⎞⎤ 

⎠⎦ ⇒ 

⎛ 

⎜ 

⎝ 

⎛ 

⎜ 

⎝ 

⎛ 

⎜ 

⎝ 

α = 135° 

β = 90° 

γ = 180° 

δ = 90° 

α = 0° 

β = 90° 

γ = 180° 

δ = 90° 

α = 35° 

β = 90° 

γ = 180° 

δ = 90° 

⎞ 

⎟ 

⎠ 

⎞ 

⎟ 

⎠ 

⎞ 

⎟ 

⎠ 

̌ 

̌ 

̌ 

Die verwendeten statischen Testfälle zeigen somit, dass die gewünschte 

Funktionalität, die Berechnung von Winkeln anhand der Schwerpunkte im 

Raum, realisiert wurde und von den Berechnungen auf Seite des Microblaze 

entsprechend den Erwartungen funktioniert. 

Dynamische Testfälle 

Dieser Abschnitt führt die dynamischen Testfälle 

auf. Diese zeigen die Berechnungen von Winkeln und Tiefen mit Hilfe verschiedener 

Testpersonen zeigen. 

Im Rahmen der Testfälle hat sich herausgestellt, dass das verwendete Modell 

zur Berechnung der Armwinkel, exklusive Drehwinkel, nicht kompatibel 

mit der Berechnung des Drehwinkels ist. Bei der Entwicklung der 

Armwinkelberechnung wurde der Ellenbogenwinkel und Handgelenkwinkel 

als 180° abdeckendes Gelenk modelliert, siehe Abbildung 2.170. Der menschliche 

Arm erreicht die Abdeckung dieser 180° jedoch durch ein 90° Gelenk 

und die Drehung der Schulter, siehe Abbildung 2.171. 

396


α=180° 

α‘=0° 

x 

x 

γ=270° 

γ‘=90° 

Abbildung 2.170: Falsche Berechnung des Ellenbogenwinkels 

Daraus resultiert, dass bei der Berechnung der Winkel des Arms die Hyperebene 

zur Berechnung des entsprechenden Winkels nicht benötigt werden. 

Dies bedeutet, dass eine Umrechnung des Ellenbogen- oder Handgelenkwinkels 

von 90° auf 270° durch eine 180° Drehung ersetzt wird. Die 

oben aufgelisteten Testwerte sind also aufgrund des Drehwinkels als korrekt 

anzusehen. 

397


γ=90° 

α=180° 

α‘=0° 

x 

x 

γ‘=90° 

Abbildung 2.171: Korrekte Berechnung des Ellenbogenwinkels 

Systemtests 

Dieser Abschnitt führt die durchgeführten Systemtests auf. 

Dabei wird das gesamte System verwendet, sodass das Zusammenspiel 

aller Komponenten miteinander validiert werden kann. 

Als Testpersonen wurden Peter Gewald, Vitaliy Beguchiy und Patrick Elfert 

eingesetzt. Die Tests lieferten dabei immer die selben Ergebnisse. Die Winkel 

waren tendenziell wie beobachtet, unterlagen jedoch Schwankungen. Gerade 

im Bereich des α -Winkels waren diese sehr stark und führten teilweise 

zu einer fehlerhaften Auswertung. 

Die Analyse des Problems ergab, dass leichte Schwankungen in den Tiefenwerten 

der Schwerpunkte ausreichten, um einen vermeindlich geraden 

Arm als schief zu interpretieren. Somit berechnet der Algorithmus den 

α -Winkel in Bezug auf den Ellenbogen, obwohl sich die Berechnung des 

α -Winkels auf das Handgelenk beziehen sollte. 

2.12.4.5 Geschwindigkeitsanalyse 

Dieser Abschnitt beschreibt die getätigten Geschwindigkeitsmessungen (Profiling) 

an dem gesamten Algorithmus des Demonstrators Armerkennung. 

398


Im Fokus der Analyse stehen neben den verwendeten Treibern, BLOB- 

Treiber und Servotreiber, insbesondere die Funktionen aus den in Abschnitt 2.12.4.7 

genannten Dateien. 

Zunächst wurde die interne Funktion zum Profiling des Microblaze auf 

Basis des XPS-Timers verwendet, siehe 2.12.4.5. Da diese jedoch bereits zu 

detailierte Informationen liefert, z.B. zur Laufzeit von elementaren Rechenoperationen, 

wurde anschließend eine weitere Geschwindigkeitsmessung 

durchgeführt. Diese operiert auf einem höheren Abstraktionsgrad und misst 

die verschiedenen Laufzeiten der im Rahmen dieses Demonstrators entstandenen 

Methoden. 

Low level Microblaze Proling 

Dieser Abschnitt enthält die low level 

Geschwindigkeitsanalyse. Wie auch im folgenden Abschnitt über das 

high level Profiling, siehe Abschnitt 2.12.4.5, werden hier die verschiedenen 

Methoden, welche im Zuge der Realisierung des Demonstrators implementiert 

wurden, auf ihre Laufzeit untersucht. Hierzu wurde das von Xilinx zur 

Verfügung gestellte Profilingswerkzeug angepasst und verwendet. Dokumentiert 

ist die Vorgehensweise, mit kleineren Abweichungen, in einem 

von Xilinx zur Verfügung gestellten Dokument [19]. Dieses liefert eine 

Beschreibung zur Durchführung des Profilings auf dem Microblaze über 

die Xilinx Microprocessor Debugger-Console enthält. Um die getätigten 

Schritte zu diesem Profilingverfahren nachvollziehen zu können, sind diese 

im Folgenden aufgelistet. 

• Zunächst muss das Profiling in dem Xilinx Software Development Kit 

bei dem Kontextmenüpunkt Board Support Package Settings aktiviert 

und ein Timer zugewisen werden, siehe Abbildung 2.172 

– enable_sw_intrusive_profiling bei Overview→ Standalone auf 

true setzen 

– Timer xps_timer_0 dem profile_timer zuweisen. 

399


Abbildung 2.172: Profiling im Board Support Package Settings aktivieren 

• Der Compiler muss wissen, dass Profiling betrieben werden soll. Daher 

wird in dem Software Development Kit unter dem Kontextmenüpunkt 

des Projektes Properties → C/C + + − Build → Settings → Pro f iling → 

Enable Pro f iling (−pg) die Compileroption -pg gesetzt, siehe Abbildung 

2.173. 

Abbildung 2.173: Compileroption für Profiling setzen 

• Im Linkerskript lscript.ld muss eine freie Adresse reserviert werden 

(z.B. 0x91000000) mit einer festen Größe (z.B. 0x01000000). 

• Das Profiling kann in dem Software Development Kit unter dem 

Menüpunkt Run → Run Con f igurations → Pro f ile Options konfiguriert 

werden, siehe Abbdildung 2.174. 

400


Abbildung 2.174: Konfiguration des Profilings 

Alternativ können diese Optionen auch über die Xilinx Microprocessor 

Debugger-Console gesetzt werden. Zu einen ist die Frequenz 

einzugeben, welche die Messabstände definiert (sampling_frq_hz). 

Des Weiteren muss die Größe der Datenwörter (binsize) angegeben 

werden und abschließend die Speicheradresse, in welcher die Ergebnisse 

abgelegt werden sollen. 

XMD% profile -config sampling_freq_hz 10000 binsize 4 \ 

profile_mem 0x91000000 

• Anschließend muss das Programm (Binärdatei) auf den FPGA geladen 

werden. 

XMD% dow camera.elf 

• Danach wird der Breakpoint automatisch gesetzt. 

XMD% bps exit 

Setting breakpoint at 0x8c001dd8 

• Mit dem Befehl con wird der Microblaze mit dem Programm gestartet. 

XMD% con 

Info:Processor started. Type stop to stop processor 

• Terminiert das Programm, wird an dem gesetzten Breakpoint angehalten. 

401


RUNNING> XMD% Info:Software Breakpoint 0 Hit, Processor \ 

Stopped at 0x8c001dd8 

Alternativ muss das Programm manuell gestoppt werden: 

XMD% stop 

• Mit dem Befehl profile werden die gemessenen Daten im hexadezimalen 

Format abgespeichert. 

XMD% profile 

Profile data written to gmon.out 

• Schließlich müssen die codierten Ergebnisse noch unter Angabe der 

verwendeten Programmdatei in ein lesbares Format übersetzt werden. 

XMD% mb-gprof camera.elf gmon.out > profile.txt 

Alternativ kann die Datei gmon.out mit der Software Development 

Kit geöffnet werden, welche eine lesbarere Ausgabe der Ergebnisse 

liefert. 

Bei dem Wechsel zwischen Debug und Release Modus innerhalb der Entwicklungsumgebung 

ist darauf zu achten, dass diese Einstellungen erneut 

kontrolliert werden. Durch den Wechsel ist es möglich, dass diese Einstellungen 

zurückgesetzt werden. Ebenfalls können Problem mit der Option 

-PG auftreten. Es ist möglich, dass diese Option in der Entwicklungsumgebung 

als aktiviert angezeigt wird, sie aber deaktiviert ist. Nun ist 

es notwendig diese Option zu deaktivieren, zu bestätigen und erneut zu 

aktivieren und zu bestätigen. 

Im Folgenden ist ein Auszug aus der Textdatei zu sehen, welcher sich auf 

die am meisten genutzten elementaren Funktionen des Microblaze bezieht. 

% Ergebnisse 

Each sample counts as 0.0001 seconds. 

% cumulative self self total 

time seconds seconds calls us/call us/call name 

49.63 0.00 0.00 __divdf3 

8.82 0.00 0.00 _malloc_r 

6.62 0.00 0.00 __pack_d 

5.88 0.00 0.00 __udivsi3 

5.15 0.01 0.00 __unpack_d 

2.94 0.01 0.00 12 16.67 16.67 Servo::set_range( 

unsigned short, 

unsigned short) 

2.94 0.01 0.00 6 33.33 50.00 Servo::Servo() 

402


2.94 0.01 0.00 1 200.00 500.00 __static_initializa 

tion_and_destruction 

_0(int, int) 

2.94 0.01 0.00 __gedf2 

1.47 0.01 0.00 std::vector< 

BlobRegion, 

std::allocator< 

BlobRegion>>:: 

operator=(std:: 

vector const&) 

1.47 0.01 0.00 __fixdfsi 

1.47 0.01 0.00 __floatsidf 

1.47 0.01 0.00 __fpcmp_parts_d 

1.47 0.01 0.00 __malloc_lock 

1.47 0.01 0.00 _free_r 

1.47 0.01 0.00 malloc 

0.74 0.01 0.00 __malloc_unlock 

0.74 0.01 0.00 memset 

0.37 0.01 0.00 __muldf3 

0.00 0.01 0.00 17640 0.00 0.00 std::vector


Pfade analysiert, welche einen entsprechend großen Anteil an der Laufzeit 

der Hauptmethode haben. Diese Vorgehensweise setzt sich nun bis in die 

Spitze des Baumes fort, bis entsprechende Methoden gefunden werden, 

welche den größten Anteil an der Laufzeit haben. Diese Vorgehensweise 

wurde gewählt, damit nicht jede Methode bezüglich ihrer Laufzeit getestet 

werden muss. Die zusammengefassten Ergebnisse dieser Tests werden im 

Folgenden aufgeführt. Die vollständigen generierten Berichte sind ebenfalls 

vorhanden und könnten mit Hilfe der Dateistruktur 2.12.4.7 gefunden 

werden. 

Für die Laufzeitmessungen wurde ein Timer von Claas Diederichs verwendet. 

Dieser Timer wurde über den PLB-Bus an den Microblaze angebunden. 

Hauptfunktion: 

Ein Durchlauf, von Erkennung der BLOBs bis zur Ansteuerung 

der Servos benötigt eine gewisse Zeit, welche in Millisekunden 

angegeben wird. Diese Zeit teilt sich im Durchschnitt wie folgt auf, siehe 

Tabelle 2.12. 

Codeabschnitt Timer Zeit in [ms] 

Tracking (2x) 0x000000000004FFA8 327,600 

Tiefenberechnung 0x0000000000001E51 7,761 

Winkelberechnung 0x000000000000A5B8 42,420 

Overlay 0x000000000008A1B7 565,700 

Mapping 0x0000000000000C87 3,207 

Servoansteuerung 0x00000000000000F6 0,246 

Gesamtzeit 946,93 

Tabelle 2.12: Laufzeitmessung Übersicht 

Die Zeit für das Tracking gilt sowohl für die rechte als auch für die linke 

Kamera, siehe Abschnitt Optimierung 2.12.4.6. Im Folgenden sollen die 

oben am meisten Zeit beanspruchenden Teilfunktionen gemessen werden. 

Zu diesem Zweck wird das Tracking, die Winkelberechnung und das Overlay 

näher betrachtet. 

Initiale Sortierung der Schwerpunkte: 

Bevor die Werte verfolgt werden 

können, das Tracking durchgeführt werden kann, müssen diese initial sortiert 

werden. Die Laufzeit der Sortierung ist im Folgenden angegeben, siehe 

Tabelle 2.13. 

404



Sort 0x000000000000052D 1,325 

Rest of Tracking 0x0000000000000345 0,837 

Sort 0x00000000000008EE 2,286 

Rest of Tracking 0x0000000000000421 1,057 

Verfolgung der Schwerpunkte: 

Tabelle 2.13: Laufzeitmessung Sortieren 

Das Verfolgen der Schwerpunkte gliedert 

sich in folgende Zeitabschnitte. Dabei werden zunächst die Zeitwerte bei 

Stillstand des Armes und anschließend bei Bewegung des Armes aufgelistet, 

siehe Tabelle 2.14 und Tabelle 2.15. 


Erstellen der Distansmatrix 0x0000000000002B2A 11,05 

Erstellen der Kombinationsmatrix 0x000000000000305D 12,38 

Restliches Tracking 0x0000000000002A7D 10,88 

Tabelle 2.14: Laufzeitmessung Tracking ohne Armbewegung 


Erstellen der Distansmatrix 0x0000000000002C3F 11,33 

Erstellen der Kombinationsmatrix 0x0000000000002D11 11,54 

Restliches Tracking 0x0000000000002D78 11,64 

Tabelle 2.15: Laufzeitmessung Tracking mit Armbewegung 

Wie aus den beiden Tabelle zu entnehmen ist, unterscheidet sich die Laufzeit 

für den bewegten bzw. nicht bewegten Arm nicht signifikant. Da die Programmzeilen 

für das Tracking ca. 35 ms benötigen, jedoch für den gesamten 

Aufruf ca. 160 ms (327/2) benötigt werden, wird die restliche Zeit für den 

Aufruf der Methode, also für die Übergabe der Variablen verwendet. An 

dieser Stelle ist das Kopieren der Werte jedoch einmal notwendig, da sich 

der Speicher mit den entsprechenden Stellen durch den IP-Core jederzeit 

ändern kann. 

BLOB-Treiber: 

Als weitere für das System relevante Komponente wurde 

der BLOB-Treiber gemessen. Die Ergebnisse dieser Messung sind folgender 

Tabelle zu entnehmen. 

405



BLOB-Treiber 0x0000000000000077 0,119 

BLOB-Treiber (ohne Rechnung) 0x0000000000000044 0,068 

Image-Overlay: 

Tabelle 2.16: BLOB-Treiber 

Die letzte gemessene und für das System relevante Komponente 

ist das Image-Overlay. Es setzt sich aus folgenden Zeitabschnitten 

zusammen, siehe Tabelle 2.17. 


Overlay-Text 0x00000000000716EA 464,600 

Overlay-Kreuze 0x0000000000000556 1,366 

Overlay-Pageflip 0x0000000000006386 25,480 

Tabelle 2.17: Laufzeit des Image-Overlays 

Hier ist klar zu erkennen, dass das Zeichnen des Textes einen Großteil der 

Laufzeit in Anspruch nimmt. In diesem Fall beträgt der Anteil rund 50 % 

der Gesamtlaufzeit. Angezeigt werden im getesteten System die Winkel des 

Arms sowie die zu jedem Schwerpunkte gehörenden Tiefen. Aktuell werden 

diese jedoch als Fließkommazahl dargestellt und haben dementsprechend 

viele Stellen. Hier ist es anzuraten diese in einer kompakteren Art und 

Weise darzustellen, dass hier entsprechend viel Laufzeit eingespart werden 

kann. 

Winkelberechnung 

Die Winkelberechnung bildet die zentrale Komponente 

des Systems. Die oben gemessenen 42 ms setzen sich wie folgt zusammen, 

siehe Tabelle 2.18. 


3D-Vektoren generieren 0x0000000000002338 9.016 

3D-Vektoren vorbereiten 0x0000000000001F08 7.944 

Dreiecke berechnen 0x0000000000002253 8.787 

Winkel aus Dreiecken berechnen 0x0000000000001AEB 6.891 

Drehwinkel berechnen 0x0000000000001C1A 7.194 

Tabelle 2.18: Laufzeit der Winkelberechnung 

406


2.12.4.6 Optimierung 

Dieser Abschnitt enthält Vorschläge, welche umgesetzt werden sollten, um 

den Demonstrator in Funktion und Performanz zu verbessern. Dies ist 

notwendig, um die geforderte minimale Latenz von 500 ms einzuhalten, 

siehe Abschnitt 1.2.6. Die aktuelle Gesamtlaufzeit für die Berechnung einer 

Bewegung, Änderung der Schwerpunkt Positionen liegt bei fast einer 

Sekunde. Somit ist die Anforderung an die Performanz des Gesamtsystems 

nur zu ca. 50% erfüllt. Um die maximal mögliche Geschwindigkeit 

der Kamera zu nutzen, 15 fps, ist eine Laufzeit von unter 66, 66 ms zu erreichen. 

Möglichkeiten zur Steigerung der Performanz ergaben sich durch die Analyse 

der Ergebnisse der low level und der high level Geschwindigkeitsanalyse. 

Optimierungsmöglichkeiten zur Verbesserung der Funktionalität des 

Demonstrators ergaben sich aus der Analyse der Funktionalität der Programmzeilen, 

sowie durch Systemtests. 

Die Geschwindigkeit der Nachahmung des menschlichen Arms durch den 

Roboterarm erfolgt bis jetzt nicht in der geforderten Geschwindigkeit. Ebenfalls 

ist die Stabilität der Nachahmung nicht gegeben. Versucht der Benutzer 

zum Beispiel seinen Arm parallel zur Kamera zu halten, müssten 

vom System stabile Werte für die Winkel berechnet werden können. Diese 

sollten eine Schwankung von zehn Grad in der Regel nicht überschreiten. 

Schwankungen von bis zu 40 Grad treten jedoch in der aktuellen 

Version der Ansteuerung regelmäßig auf. Ebenfalls Schwankungen der 

berechneten Tiefenwerte sind ein Problem. Hier sind im Bereich von zwei 

Metern Kameraabstand, Schwankungen von über einem halben Meter regelmäßig 

aufgetreten. Das Systemspiel dieser Instabilitäten führt zu einem 

ruckartigen und nur entfernt menschenähnlichen Nachahmung des menschlichen 

Arms durch den Roboterarm. 

Bevor Maßnahmen zur Verbesserung der Performanz des Demonstrators 

durchgeführt werden, sollten die Änderungen zur Verbesserung der Funktionalität 

durchgeführt werden. Unter diesen Maßnahmen befindet sich die 

Möglichkeit der Bildung eines Mittelwertes über die Position der entsprechenden 

Schwerpunkte. Ebenfalls wäre es alternativ möglich einen Mittelwert 

über die berechneten Winkel zu bilden. Hierdurch würde jedoch die 

Performanz des Systems verschlechtert werden. Darüber hinaus gibt es 

mehr Schwerpunkte als berechnete Winkel, da das berechnen der Winkel 

mehr Zeit in Anspruch nimmt, als das Lesen der Schwerpunkte, weshalb 

ein Mittelwert über die Schwerpunkte sinnvoller sein kann. 

Zur Steigerung der Performanz ist es möglich Prozesse, die auf dem Mi- 

407


croblaze ausgeführt werden, auf die Hardware auszulagern. Hier ist es 

möglich Operationen durch Parallelität und Streaming zu beschleunigen. 

Beispielsweise können bei der Funktion zum Tracking der Schwerpunkte 

parallelisiert werden. 

Im Rahmen der Laufzeitmessungen, siehe Abschnitt 2.12.4.5 und 2.12.4.5, 

sind folgende Optimierungsschritte zu empfehlen. 

• Der angezeigte Text (Tiefenwerte und Winkel) im Overlay sollte gekürzt 

werden, z.B. ohne Nachkommastellen, um Laufzeit im Overlay zu 

sparen. 

• Der Speicherbereich für den Text im Overlay sollte nur einmal reserviert 

werden, um Speicherzugriffe zu sparen. 

• Die Schwerpunkte werden sowohl für die linke als auch für die rechte 

Kamera verfolgt. Es sollte nur eine Kameraseite verfolgt, und die 

Sortierung anschließend auf die andere Seite übertragen werden. 

• Das Tracking sollte die Variablen über Referenzen statt als Kopie erhalten. 

Damit könnte ein Großteil der Laufzeit dieser Methode eingespart 

werden. 

• Es sollten mehr, insbesondere kleine, Methoden als inline deklariert 

werden, um unnötige Funktionsaufrufe zu vermeiden. 

• Die Matrix, welche innerhalb der Tracking Funktion die möglichen 

Kombinationen für die Verfolgung der Punkte angibt ist statisch und 

konstant. Daher sollte diese nur einmal deklariert bzw. gefüllt werden, 

statt bei jedem Durchlauf. 

• Die Berechnung der unterschiedlichen Abstände der alten und neuen 

Schwerpunkte könnte optional auf Hardware ausgelagert werden. 

• Arrays und Vektoren sollten immer, mit fester Länge angelegt werden. 

• Arrays und Vektoren sollten immer direkt statt mit der Methode 

push_back beschrieben werden. 

• Fließkommazahlen sollten immer mit einem f deklariert werden, z.B.: 

180.0f statt 180.0, da damit Rechenoperationen performater durchgeführt 


408



Während der Integration wurden folgende Dateien erweitert oder funktional 

angepasst. Alle geänderten oder auch neu erstellten Dateien sind in 

dem Repository atlys und microblazecode vorhanden. 

• lib/MyProcessorIPlib/drivers/blob_detection_v2_10a/src/blob_detection.h 

C++ Header der BLOB Erkennung. 

• lib/MyProcessorIPlib/drivers/blob_detection_v2_10a/src/blob_detection.cpp 

C++ Datei der Implementation der BLOB Erkennung. 

• microblazecode/camera/src/AngleCalculation.h: C++ Header Datei 

der Winkelberechnung. 

• microblazecode/camera/src/AngleCalculation.cpp: C++ Datei mit der 


• microblazecode/camera/src/Stereoscopy.h: C++ Header Datei der 3D- 

Berechnung. 

• microblazecode/camera/src/Stereoscopy.cpp: C++ Datei mit der Implementation 

der 3D-Berechnung. 

• microblazecode/camera/src/main.cc: Programmquelltext, der die erstellten/geänderten 

Klassen benutzt, um das Hauptprogramm auszuführen. 

• roboarm/arbeitspakete/sprint7/Integration_Komponenten/profile_low.txt 

Textdatei, welche die Ergebnisse des low level Profilings enthält. 

• roboarm/arbeitspakete/sprint7/Integration_Komponenten/profile_high.txt 

Textdatei, welche die Ergebnisse des high level Profilings enthält. 

409


2.12.5 Anbindung des Grauwertlters an den PLB 

Ziel dieses Arbeitspaketes ist es den gewichteten Grauwertfilter an den PLB 

anzubinden. Dies soll es ermöglichen zur Laufzeit die gewichtete Farbe auf 

dem Microblaze einzustellen. Dadurch kann die selbe Hardwarekonfiguration 

für mehrere Anwendungsfälle verwendet werden. 

2.12.5.1 Herangehensweise 

Um den RGB2Grey IP-Core an den PLB anzubinden wurde in einem ersten 

Schritt ein neuer IP-Core selben Names durch das XPS generiert. Dies 

hat den Vorteil, dass die Anbindung an den PLB automatisch geschieht. 

Danach wurden in den generierten Dateien die für den RGB2Grey IP- 

Core benötigten Signal hinzugefügt. In der user_logic wurde nun eine Entität 

des vorherigen rgb2grey_v2_00_a eingebaut. Diese wurde geändert, 

so dass weiterhin ein 32-Bit Register als Eingabe erwartet wird. In der user_logic 

wurde dann das generierte Register slv_reg0 angebunden und die 

plb-clk an die pixel_clk gelegt. Im Weiteren mussten die .mpd und die .pao 

Dateien angepasst werden. 

Zu dieser PLB-Anbindung gehört auch ein Treiber, durch welchen das Register 

gesetzt werden kann. Der hier geschriebene Treiber hat die Dateien 

vom Schwellwertfilter übernommen, lediglich die Namen und die Art, wie 

das Register gesetzt wird sind anders. 


Die folgenden Dateien wurden für die Anbindung angelegt oder verändert. 

Das Basisverzeichnis ist ipcores.git/. 

• pcores/rgb2grey_v2_00_a/hdl/vhdl/rgb2grey_toplevel.vhd 

Toplevel Entität des IP-Core. Verarbeitet die PLB Logik. 

• pcores/rgb2grey_v2_00_a/hdl/vhdl/user_logic.vhd 

Mittlere Entität des IP-Core. Ordnet die Signale dem eigentlichen Filter 

zu. 

• pcores/rgb2grey_v2_00_a/hdl/vhdl/rgb2grey.vhd 

Lowlevel Entität des IP-Core. Implementiert die eigentliche Filterlogik 

• pcores/rgb2grey_v2_00_a/data/rgb2grey_v2_1_0.mpd 

Beinhaltet die Definition der Ein- und Ausgangssignale. 

410


• pcores/rgb2grey_v2_00_a/data/rgb2grey_v2_1_0.pao 

Definiert Dateiabhängigkeiten des IP-Core 

• drivers/rgb2grey_v2_00_a/data/rgb2grey_v2_1_0.mdd 

Definition des Treibers. 

• drivers/rgb2grey_v2_00_a/data/rgb2grey_v2_1_0.tcl 

TCL-Skript des Treibers. 

• drivers/rgb2grey_v2_00_a/src/rgb2grey.h 

Die Metaklasse des Treibers, beinhaltet nur den Konstruktor und einen 

Getter/Setter. 

• drivers/rgb2grey_v2_00_a/src/rgb2grey.cpp 

Implementierung des Treibers. 

• drivers/rgb2grey_v2_00_a/src/Makefile 

Makefile zum kompilieren des Treibers 

411


2.12.6 Vektorisierung von Portraitaufnahme 

Aufgabe ist es, ein mittels Kamera aufgezeichnetes Portraitbild mittels Software 

in eine Skizze zu verarbeiten, welche dann als Vektorgrafik vorliegen 

soll. Die erstellte Vektorgrafik soll im weiteren Projektverlauf genutzt werden, 

um Steuerinformationen für den Roboterarm generieren zu können. 

Ziel ist es, eine schematische Darstellung eines Gesichts zu erreichen, wie 

es in der Aufgabenstellung Kapitel 1.2.3.4 beschrieben wurde. In Abbildung 

2.175 ist ein mögliches Bild und dessen zu erstellende Vektorgrafik 

visualisiert. 

Abbildung 2.175: Farbbild und resultierende schematische Darstellung, als 

Anforderung an die Vektorisierung 

Das Bild einer Person wird mit einer handelsüblichen Webkamera aufgezeichnet, 

wobei für die Ansteuerung und das Aufzeichnen des Bildes die 

OFFIS-Automation-Toolbox verwendet wird. Mit dieser Software wird das 

Bild ebenfalls weiterverarbeitet. 

2.12.6.1 Bildvorverarbeitung 

Bevor die Pixelgrafik in die gewünschte Form überführt werden kann, wird 

das Bild vorverarbeitet. Dazu wurde eine Bildverarbeitungskette in der 

OFFIS-Automation-Toolbox erstellt. Die Bildverarbeitungskette reduziert 

412


die Informationen des aufgenommenden Bildes stark. Dies geschieht unter 

anderem über ein erstellten Filter, welcher die Helligkeit erhöht, gleichzeitig 

ebenfalls den Kontrast erhöht, wodurch Details reduziert werden, jedoch 

gleichzeitig die Konturen des Gesichts erhalten bleiben. Anschließend 

werden weitere Farbfilter eingesetzt um das Gesicht des Benutzers hervorzuheben. 

Das erzeugte Bild nach diesen Schritten ist als Zwischenergebnis 

in Abbildung 2.176 dargestellt. 

Abbildung 2.176: Zwischenergebnis der Bildverarbeitungskette 

Für die Manipulation von Helligkeit und Konstrast des Bildes wurde ein 

OFFIS-Automation-Toolbox Plugin entwickelt welches diese Funktionalität 

auf Basis der OpenCV Bibliothek bereitstellt. Die gesammte Bildverarbeitungskette 

ist in Abbildung 2.177 zu sehen. 

413


Abbildung 2.177: die gesammte Bildverarbeitungskette 

Das Endresultat der Bildverarbeitungskette wird an das letzte Plugin übergeben. 

In den Abbildungen 2.178 und 2.179 sind verschiedene Personen mit dem 

Bildverarbeitungsalgorithmus getestet worden. Dabei lieferte dieser Prozess 

eine ausreichende Detailstufe in den Bildern um die Person auf dem Bild 

noch ausmachen zu können. Das Resultat wird dann als Pixelgrafik an das 

letzte Glied in der Verarbeitungskette zur Vektorisierung gereicht. 

414


Abbildung 2.178: Farbbild und resultierende schematische Darstellung von 

einer Testperson 

Abbildung 2.179: Farbbild und resultierende schematische Darstellung von 

einer weiteren Testperson 

2.12.6.2 Vektorisierung 

Um eine Vektorisierung des vorbereiteten Bildes vornehmen zu können, 

wurden sich verschiedene existierende Lösungen angeschaut. Dabei wurde 

versucht die Vektorisierung mit dem Vekorgrafikprogramm Inkscape zu 

realisieren, da sich diese über die Windows Eingabeaufforderung aufrufen 

und in Teilen steuern lässt. Dies ließ sich jedoch nicht ohne Weiteres für 

die gewünschten Zwecke voll nutzen. Als eine weitere mögliche Lösung 

für unser Problem stellte sich die Freie Software Potrace 1 heraus, welche 

intern von Inkscape benutzt wird. Dieses Programm wurde in ein ebenfalls 

1 Dokumentation und Quellcode der Software Potrace http://potrace.sourceforge.net 

(Besucht am 3.9.2013) 

415


von uns erstelltes Plugin gekapselt und mit entsprechenden Parametern 

aufgerufen. Ein Ergebnis des Vektorisierungsvorgangs ist in Abbildung 

2.180 dem Eingangbildern und der schematischen Pixelgrafik gegenüber 

gestellt. 

Abbildung 2.180: Farbbild, Zwischenschritt und resultierende schematische 

vektorisierte Darstellung 

2.12.6.3 Ausblick auf anstehende Aufgaben 

Die erstellte Vektorgrafik muss noch interpretiert werden, sodass es möglich 

wird den Roboterarm zu steuern. Für Inkskape existiert ein Plugin, welches 

Vektorgrafiken aus dem SVG Format in ein Format überführt, welches 

für Computer gesteuerten Fräsen genutzt wird, auch Gcode genannt. Diese 

Erweiterung ließ sich jedoch noch nicht vollständig in den automatisierten 

Ablauf integrieren, konnte jedoch bereits ein Resultat erzeugen, welches in 

der Abbildung 2.181 abgebildet ist. Die grünen Linien ist das Absetzen der 

Fräse und die roten Linien sind die Linien, an denen entlang gefräst wird. 

Abbildung 2.181: Darstellung des generierten Gcodes 

416


Die Erzeugung dieses Datenformats muss im Weiteren automatisiert werden, 

sodass nachfolgend daraus Steuerbefehle für den Roboterarm generiert 

werden können. Ebenfalls sollte die erzeugen Pfade in der Vektorgrafik 

vereinfacht werden, da sonst sehr komplexe und lange Wege für 

den Roboterarm entstehen können, wie es aktuell noch der Fall ist. In Abbildung 

2.182 lässt sich der Umfang an Bewegungen allein für das Auge 

bereits deutlich anhand der vielen Kanten erkennen. 

Abbildung 2.182: Bildausschnitt und die Komplexität der Pfade aus der 

generierten Vektorgrafik 


• projects/offis-toolbox/plugins/vision/brightness.pro : 

OFFIS Automation Framework Projektdatei 

• projects/offis-toolbox/plugins/vision/brightness/src/brightness.h : 

Header Datei des Brightness Quellcodes 

• projects/offis-toolbox/plugins/vision/brightness/src/brightness.cpp : 

C++ Programm des brightness Plugin 

• projects/offis-toolbox/projects/Vectorizer.oap : 

Bildverarbeitungskette für die Bildvorverarbeitung und Vektorisierung. 

417


2.12.7 Design und Bau des Roboterarms 

Ziel dieses Arbeitspakets ist die Planung und Erstellung von CAD Modellen 

der benötigten Bauteile. Im Anschluss werden diese gefertigt und 

montiert. Das Ergebnis ist dabei ein Roboterarm mit der in Abschnitt 2.9.4 

festgelegten Gelenkkonfiguration. 

Im Folgenden Unterabschnitt werden zuerst die wichtigsten Designentscheidungen 

hervorgehoben. 

2.12.7.1 Designentscheidungen 

Die geplante Konfiguration des Roboterarms erfordert ein entsprechendes 

Design der Links und Gelenke. Abbildung 2.193 zeigt die erste Version des 

zusammengebauten Roboterarms. Zur Erstellung der Zeichnungen wurden 

die freien Programme FreeCAD 59 sowie LibreCAD 60 genutzt. 

Als Material wird einheitlich Aluminiumblech der Dicke 1,5mm ausgewählt. 

Um die Knickgelenke zu realisieren werden Öffnungen für Kugellager und 

Servos in das Material eingelassen. Durch eine Gewindestange, die zusammen 

mit den Lagern als Achse dient, kann somit die Verbindung zum nächsten 

Link hergestellt werden. 

Ein Axialgelenk besteht aus drei einzelnen Bauteilen. Diese werden mit 

Winkeln an den Links befestigt und bieten Halterung für den Servo, Kugellager 

sowie die Verbindung zum nächsten Link. 

Die letzten beiden Gelenke werden zusammengefasst und durch ein Differential 

realisiert. 

Um höheren Belastungen stand zu halten oder den Arbeitsbereich zu erhöhen, 

werden an einigen Stellen Zahnräder zwischen Servos und Achse 

mit einer 1:2 sowie 2:1 Übersetzung eingesetzt. Weiter sind Anbringungsmöglichkeiten 

für ein Gegengewicht am zweiten Link eingeplant. Um eine Gewichtsreduzierung 

zu erlangen, wurden bei den Links Aussparungen ins Design 

eingefügt. 

Im nächsten Unterabschnitt werden die CAD-Zeichnungen der einzelnen 

Bauteilgruppen kurz dargestellt und beschrieben. 

2.12.7.2 CAD-Zeichnungen 

Um die Abstände der erstellten Zeichnungen im voraus zu verifizieren 

wurden für jedes Bauteil Protoypen aus Pappelholz gefertigt. Im Folgenden 

werden die einzelnen Bauteile kurz vorgestellt. 

59 http://www.freecadweb.org/ 

60 http://librecad.org/ 

418


Basis 

Die Basis, die gleichzeitig auch den ersten Link des Arms darstellt, 

besteht aus zwei Elementen. Abbildung 2.183 zeigt die Seiten aus denen 

die Box für die in Abbildung 2.184 dargestellte Axialverbindung besteht. 

Die Axialverbindung verbindet dabei die Basis mit dem zweiten Link. 

(a) Seite A 

(b) Seite B 

Abbildung 2.183: Base Seiten 

419


(a) Servohalterung (b) Kugellagerhalterung (c) Achshalterung 

Abbildung 2.184: Base Axialverbindung zum zweiten Link 

Zweiter Link 

Der zweite Link besteht aus in Abbildung 2.185 dargestellten 

Bauteilen. In die in Abbildung 2.185(b) gezeigte Seite B kann der entsprechende 

Servo eingelassen werden, mit dem über die Zahnradkonstruktion die Achse 

zwischen zweitem und drittem Link bewegt werden kann. Beide Seiten besitzen 

zu diesem Zweck Bohrungen zur Befestigung der Kugellager. 

420


(a) Seite A 

(b) Seite B 

Abbildung 2.185: Zweiter Link 

Dritter Link 

Wie der zweite besitzt auch der dritte Link in Abbildung 

2.186 die Bohrungen zur Befestigung der Kugellager sowie eine Ausfräsung 

für den Servo. Da dieser nur auf einer Seite der Konstruktion benötigt 

wird, existieren die Seiten A und B des Links. Weiterhin ist ca. in der Mitte 

des Bauteils ein Loch zur Anbringung einer Stabilisierungsstange geplant. 

Link drei und Link vier werden dabei wiederum durch die Achsenkonstruktion 

verbunden. 

421


(a) Seite A 

(b) Seite B 

Abbildung 2.186: Dritter Link 

422


Vierter Link 

Der in Abbildung 2.187 gezeigte Link vier besitzt am oberen 

Ende Bohrungen zur Befestigung der im Folgenden beschriebenen Axialverbindnug. 

Abbildung 2.187: Vierter Link 

Axialgelenk 

Abbildung 2.188 zeigt die zur Realisierung eines Axialgelenks 

benötigten Bauteile. Die Servo- sowie Kugellagerhalterung in Abbildungen 

2.188(a) und 2.188(b) werden dabei an Link vier, die Achshalterung 

in Abbildung 2.188(c) am Folgelink angebracht. 

423


(a) Servohalterung (b) Kugellagerhalterung (c) Achshalterung 

Abbildung 2.188: Axialverbindung 

Fünfter Link 

Das Ende des in Abbildung 2.189 dargestellten Links fünf 

bildet die Basis für das im folgenden beschriebene Differential. Zu diesem 

Zweck werden auf beiden Seiten des Links Servos eingesetzt. 

424


Abbildung 2.189: Fünfter Links 

Dierential 

Zur Realisierung des Differentials werden vier der in Abbildung 

2.190 gezeigten Seiten zu einer Box verbunden. Diese bietet Platz für 

die benötigten Kegelzahnräder. 

Abbildung 2.190: Differential 

Kugellager-Halterung 

Um sämtliche Kugellager der Links, Gelenke und 

des Differentials beidseitig zu fixieren, werden je Lager zwei der in Abbil- 

425


dung 2.191 gezeigten Kugellager-Halterungen eingesetzt. 

Abbildung 2.191: Kugellager-Halterung 

Greifer 

Bei dem Greifer aus Abbildung 2.192 handelt es sich um ein Design 

aus der Sammlung der Thingiverse 61 3D-Modelle. 

Abbildung 2.192: Gripper for Micro Robot Arm 

61 http://www.thingiverse.com/thing:71797 

426


2.12.7.3 Zusammenbau 

Abbildung 2.193 zeigt den aktuell zusammengebauten Roboterarm. Die 

weiteren Abbildungen 2.194 zeigen einzelne Abschnitte des Arms. 

Abbildung 2.193: Gesamter Arm 

(a) Basis (b) Axialverbindung (c) Differential 

Abbildung 2.194: einzelne Abschnitte des Roboterarms 


Um ein Umkippen des Arms zu verhinden müssen an der Basis noch 

Ausleger angeschraubt werden. Diese sollten möglichst schwer sein. 

Bei ersten Tests des neuen Roboterarms wurde festgestellt, dass das erste 

Knickgelenk dem Gewicht des Arms nicht standhält. Der Servo scheint das 

Gewicht jedoch zu verkraften. Da in der Planungsphase dieses mögliche 

Szenario bereits betrachtet wurde, existiert für das Problem bereits eine 

Lösung: 

• Die Kunststoffzahnräder am Knickgelenk werden durch Zahnräder 

aus Stahl ausgetauscht. 

427


• Diese benötigen eine größere Achse, welche ebenfalls mehr Stabilität 

bietet. 

• Zur weiteren Steigerung der Stabilität werden die Zahnräder mittig 

auf der Achse (also zwischen den Links) angebracht. Dazu wird der 

Servo so in die Servohalterung eingeschraubt, dass die Achse nach 

innen zeigt. 

• Es wird eine weitere Achse von dem Servo in die gegenüberliegende 

Linkseite gezogen, um die Konstruktion zu entlasten/stabilisieren. 

• An Link 3 befinden sich Löcher zum befestigen eines Gegengewichtes. 

An diesem sollte ein weiterer Link außenliegend hinter die Achse 

geführt werden. Dort sollte nach ersten Berechnungen als Gegengewicht 

ungefähr das halbe Gewicht des Armes montiert werden. 

Der Bau eines neuen Greifers wurde bereits begonnen, jedoch nicht abgeschlossen. 

Für diesen muss noch eine Servohalterung entworfen und gebaut werden, 

siehe Abbildung 2.192. 


Für die erstellten CAD-Zeichnungen wurde ein eigenes CAD Repository 

erstellt. In diesem befinden sich die folgenden Dateien: 

• cad/freecad_parts/*.fcstd FreeCAD-Zeichnungen der Bauteile. 

• cad/export_base/*.dxf DXF-Export der Basis. 

• cad/export_links/*.dxf DXF-Export der Links. 

• cad/export_differential/*.dxf DXF-Export des Differentials. 

• cad/export_lagerhalterung/*.dxf DXF-Export der Lagerhalterung. 

• cad/export_axial/*.dxf DXF-Export des Axialgelenks. 

428



In dem Sprint 7 wurden als Ziele die Portierung von Kinematik und alternativer 

Gestensteuerung, die Kinematik für den neuen Roboterarm, die 

Anbindung des Grauwertfilters an den PLB und die Entwicklung der Vektorisierung 

gesetzt. Außerdem musste der neue Roboterarm gebaut werden. 

Fast alle Ziele wurden erfolgreich umgesetzt. Der Bau des neuen Roboterarms 

konnte nicht im geplanten Umfang umgesetzt werden. Aufgrund 

der Qualität der Zahnräder, die für Gelenkbau eingesetzt wurden, konnte 

der Roboterarm den Widerstand der Räder überwinden. Aus Zeitgründen 

wurde der Prototyp des neuen Roboterarms mit den vorhandenen 

Zahnräder fertiggestellt, die jedoch keinen Betrieb des Roboterarmes ermöglichen. 

Des Weiteren wird ein neuer Sprint geplant, welcher die bisher erarbeiteten 

Ergebnisse zusammenführen und integrieren soll, sowie Demonstratoren 

vorbereiten soll. 

429



Der Sprint 8 ist der abschließende Sprint der Projektgruppe RoboArm. 

Die Ziele des Sprints sind die Fertigstellung der Demonstratoren sowie 

deren Optimierung. Außerdem wird die gesamte Dokumentation überarbeitet, 

um die Einheitlichkeit der festgelegten Struktur des Dokumentes 

zu validieren, sowie die Endpräsentation wird erstellt. Folgende Demonstratoren 

werden fertiggestellt: Armhaltung nachahmen, Gestensteuerung 

sowie Skizze zeichnen. 

2.13.1 Fertigstellung und Optimierung des 

Demonstrators Armhaltung nachahmen 


• Einzelkomponenten in Form von IP-Core für Hardware 

• Treiber der IP-Core für den Microblaze 

• Quellcode aus dem Arbeitspaket „Integration der Komponenten“ 

• Vollständig und funktional einsatzfähiges Gesamtsystem 


Ziel dieses Arbeitespaketes ist die Stabilisierung und Optimierung der 

im vorherigen Arbeitspaket integrierten Komponenten. Resultat des Arbeitspakets 

ist der vollständige Demonstrator für den Anwendungsfall „Armhaltung 

nachahmen“, d.h. ein ohne Rechner lauffähiges System, welches den 

Anwendungsfall erfüllt. Dieser muss stabil die funktionalen sowie nichtfunktionalen 

Anforderungen des Anwendungsfalles erfüllen. Dabei darf 

die maximale Laufzeit von 500 ms nicht überschritten werden. Ebenfalls 

müssen die Bewegungen des Benutzers korrekt nachgeahmt werden. Auch 

hierbei sind die Anforderungen an den Anwendungsfall einzuhalten. Verantwortlich 

für die Durchführung dieses Arbeitspakets sind Peter Gewald 

und Patrick Elfert. 

Aufwand 

• 1W (4 PT) Stabilisierung der Roboterarmbewegung 

430


• 1W (4 PT) Optimierung gemäß der Vorschläge aus dem vorherigen 

Arbeitspaket (Integration) 

• 1W (4 PT) Dokumentation, inkl. Userguide 

Lieferumfang 

• ATLYS-Projekt das den Anwendungsfall „Armhaltung nachahmen“erfüllt 

und die gestzten Anforderungen erfüllt. 

• Ausführbare Programmdatei (.elf) für den Microblaze. 

• Userguide zur Bedienung der Armverfolgung. 

431


2.13.2 Semi-Demonstrator Gestensteuerung 


• OFFIS-Toolbox Projekt zur Greiferansteuerung 


In diesem Abschnitt soll die Ansteuerung für den Greifer durch eine Geste 

der Hand umgesetzt werden, sowie das Verfolgen der Handposition zur 

Steuerung des TCP des Roboterarms. Die Ansteuerung des Greifers basiert 

auf einem OFFIS-Toolbox Projekt aus einem vorherigen Sprint. Für die Ansteuerung 

des TCP soll ein Konzept erarbeitet und umgesetzt werden. Ziel 

ist es, dass der Demonstrator Objekt bewegen, mit dem neuen Roboterarm, 

umsetzbar ist. 

Aufwand 

• 1W (2 PT) Konzeptionierung und Hardwarekette zu Bildverarbeitung 

• 1W (2 PT) C-Code und Integration 

• 1W (2 PT) Dokumentation, und Test 

Lieferumfang 

• C-Code für Gestensteuerung incl. Ansteuerung des Greifers 

• Hardwarekette für Gestensteuerung 

432


2.14 Sprint 8 

In diesem Sprint werden die Ergebnisse der Fertigstellung der Demonstratoren 

sowie der Überarbeitung der Dokumentation vorgestellt. 

2.14.1 Fertigstellung und Optimierung des 

Demonstrators Armhaltung nachahmen 

Ziel dieses Arbeitspaktes ist die Fertigstellung eines stabilen und zeitlich 

optimierten Demonstrators der Armverfolgung. Zu diesem Zweck werden 

zunächst die getätigten Schritte zur Verbesserung der Performanz erläutert. 

Anschließend folgen Maßnahmen zur Stabilisierung des Roboterarms. 

Nach einem Ausblick, welcher weitere mögliche Verbesserungen vorschlägt, 

ist schließlich die finale Datenstruktur kurz beschrieben. 

2.14.1.1 Verbesserung der Performanz 

Im Folgenden sind die Laufzeitverbesserungen beschrieben, welche auf 

den Optimierungsvorschlägen des vorherigen Sprints basieren. Dabei wurden 

die Zeitgewinne in grüner Farbe markiert. Die angegebenen Werte 

entsprechen der möglichst schlechtesten Laufzeit innerhalb einer Zeitmessung, 

die Resultate dieser Laufzeitverbesserungen sind dem folgenden Diagramm 

2.195 zu entnehmen. 

433


Abbildung 2.195: Optimierungsdiagramm 

1. Als erster Schritt wurde die Optimierung der Treiber vorgenommen. 

Insbesondere der BLOB -Treiber und der Image-Overlay Treiber wurden 

überarbeitet. Des Weiteren wurde für das Overlay nur einmal 

Speicher alloziert, anstatt dieses bei jedem Durchlauf erneut durchzuführen, 

siehe Tabelle 2.19. 

Programmteil Alte Zeit in [ms] Zeit in [ms] 

Tracking (2x) 327,600 260,500 

Tiefenberechnung 7,761 6,140 

Winkelberechnung 42,420 41,110 

Overlay 565,700 545,300 

Mapping 3,207 3,308 

Servoansteuerung 0,246 0,248 

Gesamtzeit 946,934 856,606 

Tabelle 2.19: Laufzeitmessung nach Treiberoptimierung 

2. Der angezeigte Text, Tiefenwerte und Winkel, im Overlay wird gekürzt, 

434


die Werte haben künftig keine Nachkommastellen, um Laufzeit im 

Overlay zu sparen, siehe Tabelle 2.20. 


Tracking (2x) 260,500 260,500 



Overlay 545,300 204,606 

Mapping 3,308 3,220 


Gesamtzeit 856,606 515,990 

Tabelle 2.20: Laufzeitmessung nach erster Overlayoptimierung 

3. Des Weiteren werden die Tiefenwerte statt in mm in cm angezeigt, 

was ebenfalls Zeit beim Zeichnen des Overlays einspart, siehe Tabelle 

2.21. 


Tracking (2x) 260,500 260,500 



Overlay 204,606 169.091 

Mapping 3,220 3,211 


Gesamtzeit 515,990 480,816 

Tabelle 2.21: Laufzeitmessung nach zweiter Overlayoptimierung 

4. Die Matrix, welche innerhalb der Funktion für das Tracking die möglichen 

Kombinationen für die Verfolgung der Punkte angibt, ist statisch und 

konstant. Daher wird diese nun nur noch einmal deklariert und mit 

Werten gefüllt, statt dies bei jedem Durchlauf durchzuführen. Folglich 

fällt das Erstellen der Matrix bei jeden Durchlauf weg, was ca. 

10 ms einspart, siehe Tabelle 2.22. 

435



Erstellen der Distanzmatrix 11,05 11,55 

Erstellen der Kombinationsmatrix 12,38 0,00 

Restliches Tracking 10,88 7,74 

Tabelle 2.22: Laufzeitmessung Tracking ohne Armbewegungg 

Dem Tracking werden die Schwerpunkte über Referenzen statt als 

Kopie übergeben. Damit wird ein Großteil der Laufzeit dieser Methode 

bzw. des Gesamtsystems eingespart, siehe Tabelle 2.23. 


Tracking (2x) 260,500 39,367 



Overlay 169,091 183,362 

Mapping 3,211 3,246 


Gesamtzeit 480,816 268,606 

Tabelle 2.23: Laufzeitmessung nach Trackingoptimierung 

5. Der folgende Optimierungsschritt berücksichtigt drei kleinere Aspekte. 

Zum einen werden Arrays und Vektoren künftig immer mit fester 

Länge angelegt. Darüber hinaus werden Arrays Vektoren immer 

direkt statt mit der Methode push_back() beschrieben. Schließlich 

sind Fließkommazahlen ab sofort immer mit einem „f“deklariert werden, 

z.B.: 180.0 f statt 180.0, damit Rechenoperationen performanter 

durchgeführt werden. Insgesamt konnte hier nur eine geringe Zeit 

von 8 ms eingespart werden, siehe Tabelle 2.24. 

436



Tracking (2x) 39,367 38,871 



Overlay 183,362 182,887 

Mapping 3,246 1,161 


Gesamtzeit 268,606 260,456 

Tabelle 2.24: Laufzeitmessung nach Array und Vektor Optimierung 

6. Es werden mehr, insbesondere kleine, Methoden der Winkelberechnung 

als inline deklariert, um unnötige Funktionsaufrufe zu vermeiden. 

Diese Optimierungsmaßnahme bewirkt lediglich eine sehr geringe 

Performanzverbesserung, siehe Tabelle 2.25. 


Tracking (2x) 38,871 39,046 



Overlay 182,887 181,976 

Mapping 1,161 1,166 


Gesamtzeit 260,456 258,830 

Tabelle 2.25: Laufzeitmessung nach inline-Optimierung 

7. Im Folgenden wird die Zeitmesseung im Releasemode durchgeführt, 

was die Laufzeit nochmals optimiert, siehe Tabelle 2.26. 

437



Tracking (2x) 39,046 26,189 



Overlay 181,976 146,114 

Mapping 1,166 0,490 


Gesamtzeit 258,830 198,324 

Tabelle 2.26: Laufzeitmessung im Releasemodus 

Der Text des Overlays, welcher die Winkel- und Tiefenwerte angibt 

hat eine Laufzeit von 143, 090 ms und ist damit der größte Bestandteil 

des Overlays. 

8. Ohne diesen Text, der nicht zwangsläufig im Endprodukt angezeit 

werden muss, würde eine Laufzeit von 55, 234 ms erreicht. Dieser 

Wert liegt unter der Grenze von 66 ms, welcher der maximale Ausnutzung 

der 15 fps der Kamera entspricht. 

2.14.1.2 Gesamtzeit 

Nachdem die Zeiten des Algorithmus gemessen wurden, soll im Folgenden 

die von außen beobachtbare Zeit von einer Bewegungsänderung des 

menschlichen Arms bis zur sichtbaren Reaktion des Roboterarms gemessen 

werden. Zu diesem Zweck wird anhand einer Videoaufnahme mit 30 fps 

Frameweise analysiert. Um einen möglichst genauen Wert zu erhalten, werden 

zehn Messwerte gemittelt, siehe Tabelle 2.27. 

Nr. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 

Zeit in [ms]: 453 708 590 435 195 284 380 541 433 681 

Tabelle 2.27: Beobachtete Reaktionszeit 

Aus den obigen Werten ergibt sich eine durchschnittliche Zeit von 470 ms. 

Damit liegt der Demonstrator Armhaltung nachahmen unter den im Lastenheft 

geforderten Zeitgrenze von 500 ms. 

438


2.14.1.3 Stabilisierung 

Das Abfahren von vorgegeben Punkten bzw. einer Trajektorie verläuft problemlos, 

jedoch sind die Armbewegunden mit Erkennung der Schwerpunkte 

nicht stabil. Aufgrund von suboptimalen Lichtverhältnissen und der 

BLOB-Erkennnug ergeben sich zum Teil sprunghafte Tiefeninformationen, 

welche sich in fehlerhaften Bewegungen des Roboterarms äußern. Um diesem 

Verhalten entgegen zu wirken, wird der Mittelwert aus den letzten acht 

Tiefenwerten berechnet. Da bei der Berechnung durch diese Anzahl dividiert 

wird, sollte es sich aus Effizienzgründen um eine Zweierpotenz 

handeln. Dieser Wert ist unter dem Bezeichner DEPTHSTORE in der Datei 

main.cc definiert. Diese Optimierung benötigt einen zeitlichen Mehrverbrauch 

von 6 ms. Abgesehen vom Overlay ist die zeitliche Grenze von 66 ms 

insgesamt mit ca. 61 ms nicht überschritten. 

Der wichtigste Faktor für die Stabilität des System bleibt jedoch eine möglische 

statische Beleuchung, welche aus Kamerarichtung auf die Armbinden 

trifft. 


Im Folgenden sind weitere Möglichkeiten der Optimierung und Stabilisierung 

genannt: 

• Die Schwerpunkte werden sowohl für die linke als auch für die rechte 

Kamera verfolgt. Es könnte nur eine Kameraseite verfolgt und die 

Sortierung anschließend auf die andere Seite übertragen werden. 

• Die Berechnung der unterschiedlichen Abstände der alten und neuen 

Schwerpunkte könnte zu Gunsten einer parallelen Berechnung auf 

der Hardware ausgelagert werden. 

• Die Armbinden könnten durch rote LEDs ersetzt werden, um die Stabilität 

der Erkennung der Schwerpunkte zu verbessern. 

• Eine weitere Möglichkeit das System zu optimieren, wäre die Verwendung 

von Infrarotlicht. Dies ist im aktuellen Setup des System jedoch 

nicht ohne Weiteres möglich, da die VModCam einen entsprechenden 

Filter hat, welcher das infrarote Licht herausfiltert. 

439




angepasst. Alle geänderten oder auch neu erstellten Dateien liegen 

in dem Repository microblazecode vor. 

• microblazecode/camera/src/AngleCalculation.h: C++Header Datei der 

Winkelberechnung. 

• microblazecode/camera/src/AngleCalculation.cpp: C++Datei mit der 


• microblazecode/camera/src/Stereoscopy.h: C++Header Datei der 3D- 

Berechnung. 

• microblazecode/camera/src/Stereoscopy.cpp: C++Datei mit der Implementation 

der 3D-Berechnung. 

• microblazecode/camera/src/main.cc: Programmcode, der die erstellten/geänderten 


2.14.1.6 Finale Methoden 

Abschließend sind die finalen Schnittstellen der Methoden dieses Demonstrators 

aufgelistet und kurz beschrieben, da sich diese zum Teil im Rahmen 

der Optimierung geändert haben. 

Öffentliche Methoden der Stereoskopie: 

Stereoscopy () ; 

Konstruktur für die Erstellung einer Stereoskopieinstanz. 

float calcDepthPoint ( Vector2d left , Vector2d right ); 

Berechnet die Tiefe anhand von 2D-BLOBs und Kamerakonstanten 

DepthList getAllDepths ( const CenterOfGravityList & 

cogListLeft , const CenterOfGravityList & cogListRight ); 

Berechnet die Tiefe für alle Schwerpunkte, indem die Funktion calcDepthPoint 

jeden Schwerpunkt aufruft. 

für 

440


CenterOfGravityList calcCogVectors ( const 

CenterOfGravityList & coglist , const DepthList & 

depthlist ); 

Berechnet 3D-Vektoren für alle Schwerpunkte in [mm]. 

Öffentliche Methoden der AngleCalculation: 

AngleCalculation () ; 

Konstruktor zur Erstellung einer Winkelberechnungsinstanz. 

CenterOfGravityList getSortedPose2DList ( 

CenterOfGravityList cogList , SIDE side ); 

Tracking Algorithmus, welcher die Schwerpunkte über die Zeit verfolgt. 

Beim ersten Durchlauf werden die Schwerpunkte zunächst sortiert. 

AngleSet calcAngles ( Stereoscopy stereo , const DepthList & 

depthlist ); 

Berechnet die Winkel anhand von 3D-Vektoren. 

ArmAngleSet mapAngles ( const ArmAngleSet & aaSet ); 

Stellt sicher, dass die eingehenden Winkel in einem gültigen Wertebereich 

liegen und bildet diese auf die Servohardware ab. 

Private Methoden der AngleCalculation: 

Vector3d vectorSubstraction ( Vector3d vectorOne , Vector3d 

vectorTwo ); 

Subtrahiert zwei 3D-Vektoren voneinander. 

Vector3d deriveIntersectionPointPlane ( Vector3d point , 

Plane plane ); 

Berechnet Schnittpunkt zwischen einem 3D-Punkt und einer Ebende im 

3D-Raum. 

Vector3d calculateTriangleLengths ( Vector3d 

intersection , Vector3d betaCog , Vector3d 

betaBottom ); 

441


Berechnet aus drei Punkten ein Dreieck in Form von drei Seitenlängen. 

VectorListContainer prepareVectors ( Stereoscopy stereo , 

const DepthList & depthlist ); 

Erstellt und füllt Datenstruktur für die Winkelberechnung. 

std :: vector < Vector3d > calcTriangleList ( const std :: vector < 

Vector3d >& linkVectors ); 

Gibt eine Liste von Dreiecken in Form von drei Seitenlängen für jeden zu 

berechnenden Winkel zurück. 

float calcAngleFromTriangle ( Vector3d side ); 

Gibt einen Winkel in Radiant anhand eines Dreiecks (drei Seitenlängen) 

zurück. 

Vector3d crossProduct ( Vector3d v1 , Vector3d v2 ); 

Gibt das Kreuzprodukt zweier 3D-Vektoren zurück. Ein Vertauschen der 

Parameter hat einen Vorzeichenwechsel zur Folge. 

float calcAlphaAngle ( std :: vector < Vector3d > oldCogList , 

float gamma , float delta ); 

Berechnet den Drehwinkel des Roboterarms, anhand der Schwerpunkte 

und der bereits berechneten Winkel. 

442


2.14.2 Semi-Demonstrator Gestensteuerung 

Das Ziel dieses Arbeitspakets ist es, die Ansteuerung des Greifers entsprechend 

des OFFIS-Automation-Toolbox Projekts aus einem vorherigen Sprint umzusetzten. 

Zudem soll die Steuerung der Position des Tool-Center-Point der 

Roboterarm konzeptioniert und implementiert werden. Die Umsetzung 

des Pakekts erfordert eine, für diesem Anwendungsfall angepasste Hardware, 

für die Bildverarbeitung, welche in Abschnitt 2.14.2.3 beschrieben 

wird. In Abschnitt 2.14.2.1 wird das Konzept der Ansteuerung des Greifers 

und in Abschnitt 2.14.2.2 das Konzept zur Ansteuerung des Tool-Center- 

Point erläutert. 

2.14.2.1 Greiferansteuerung 

Die Ansteuerung des Greifers erfolgt über eine Geste der Hand. Diese 

Geste wird mit dem Daumen und Zeigefinger der Hand ausgeführt. Um 

die Geste zu erkennen werden grüne Markierungen an Daumen und Zeigefinger 

verwendet. Die Gesten für Öffnen und Schließen sind in den Abbildungen 

2.196 dargestellt. Rechts ist die Geste zum schließen und links die Geste 

zum öffnen des Greifers zu sehen. 

Abbildung 2.196: Handgesten zur Ansteuerung des Greifers. Rechts: Geste 

für das Schließen des Greifers; Links: Geste für das Öffnen 

des Greifer. 

Die grünen Markierungen werden durch eine für die Farbe angepasste 

Bildverarbeitungskette in Hardware gefiltert. Die Gesten werden durch den 

dafür entwickelten Quellcode erkannt. Im Quellcode werden dabei zwei 

443


Zustände unterschieden. Wenn nur eine grüne Markierung erkannt wird, 

wird dies als Geste für eine geschlossene Greiferstellung interpretiert. Sollten 

zwei grüne Markierungen erkannt werden, wird der Abstand der Center 

of Gravity der grünen Markierungen berechnet. Solange der Abstand 

einen bestimmten Schwellwert nicht überschreitet, wird die Geste als eine 

geschlossene Greiferstellung interpretiert. Überschreitet der Abstand den 

Schwellwert, so wird die Geste als offene Greierstellung interpretiert. Die 

Auswertung der Geste für die Greiferstellung ist in der Methode gestensteuerung::getHandStatus() 

gekapselt. Bei der Ausführung liefert die Methode 

das enum hand_status zurück. Dieses enum kann die Werte OPEN und 

CLOSED annehmen. 

2.14.2.2 Tool-Center-Point-Ansteuerung 

Um die Ansteuerung des Tool-Center-Point auszuführen wird eine rote 

Binde an der Hand verwendet. Die Position des Tool-Center-Point wird 

relativ zur Position des Binde zum Start der Ansteuerung berechnet. Das 

bedeutet, die Position zum Start stellt den Ursprung da. In diesem Punkt 

hält der Roboterarm seine Position. Sobald die Position der Binde relativ 

zum Ursprung einen bestimmten Abstand überschreitet, wird eine Bewegung 

des Roboterarm ausgeführt. Die Abbildung 2.197 verdeutlicht das 

vorgehen anhand einer Beispielbewegung. 

y-Achse 

z-Achse 

rote Binde 

TCP 

x-Achse 

x-Achse 

z-Achse 

y-Achse 

Abbildung 2.197: Steuerung der Tool-Center-Point-Position durch Position 

der Hand 

444


Der Roboterarm kann dabei in allen drei Dimensionen gleichzeitig angesteuert 

werden. Hierzu wird auch die Tiefeninformation der Binde ausgewertet. 

Um die Tiefe zu berechnen wird die Stereoskopie verwendet, 

welche auch bei der Nachahmung der Armhaltung zum Einsatz kommt. 

Die Auswertung der Postition und Tiefeninformation der Binde, sowie die 

Berechnung der Ansteuerung des Roboterarms, erfolgen in der Methode 

getHandPosition(). Die Methode schreibt die Ergebnisse in ein Array, welches 

aus der Main-Methode ausgelesen und an die Kinematik weitergereicht 

wird. 

2.14.2.3 Hardware der Bildverarbeitungskette 

Die entwickelten Algorithmen für die Ansteuerung des Greifers und des 

Roboterarms erfordern eine angepasste Bildverarbeitungskette. Die Greifersteuerung 

benötigt eine Filterkette die den grünen Farbkanal aus dem Bild 

extrahiert und eine BLOB-Detektion, die die grünen Objekte im Bild erkennt. 

Diese Filterkette wird lediglich auf einer der zwei Kameras des Kameramoduls 

benötigt. Um die rote Binde zu erkennen wird eine Filterkette 

eingesetzt die den roten Farbkanal aus dem Bild extrahiert und eine BLOB- 

Detektion, die die roten Objekte im Bild erkennt. Da bei der Ansteuerung 

des Roboterarms auch die Tiefeninformation ausgewertet wird, muss diese 

Bildverarbeitungskette auf beiden Kameras des Kameramoduls angewendet 

werden. Das vollständige Hardwaredesign ist in Abbildung 2.198 zu 

sehen. 

445


simple_i2c 


simple_i2c 

Legende: 

Filterkette für den roten Farbkanal 

VmodCamA 

VmodCamB 

Filterkette für den grünen Farbkanal 

cam_data 

cam_data 





rgb2grey 

rgb2grey 

rgb2grey 







servo_1 




servo_2 

servo_3 


servo_4 


servo_5 

servo_6 

Abbildung 2.198: Bildverarbeitungskette für die Gestensteuerung 

Als Grundlage für das Hardwaredesign wurde das ATLYS-Projekt der alternativen 

Gestensteuerung verwendet. Dieses wurde um eine zweite Bildverarbeitungkette 

für den roten Farbkanal erweiter. Das Design verwendete 

94% der zur Verfügung stehenden Fläche des FPGA. Dies hatte zu Folge, 

dass das Design nicht mehr synthetisiert werden konnte. Grund hierfür 

ist, dass das Zeitmodell des Designs nicht mehr alle Bedingungen erfüllen 

konnte. Um das Design synthetisieren zu können, mussten IP-Core aus 

dem Design entfernt werden. Bei den IP-Core die entfernt wurden, handelt 

es sich um die HDMI-Ausgabe und das Overlay, sowie den Image-Bus- 

Switch. 


In diesem Arbeitspaket wurde die Ansteuerung des Greifers durch Gesten 

der Hand, sowie die Steuerung der Position des Roboterarms, realisiert. 

Diese Funktionen wurde zur Umsetzung des Demonstrators Objekt be- 

446


wegen 1.2.3.2 entwickelt. Da der Demonstrator auf dem neuentwickelten 

Roboterarm, welcher in Sprint 6 spezifiziert wurde, ausgeführt werden soll, 

konnte die Funktion zur Steuerung der Position der Roboterarm bisher 

nicht auf dem Zielsystem getestet werden. Ausführliche Tests der Funktionen 

müssen nach Fertigstellung des neuen Roboterarm noch durchgeführt 

werden. Alle bisherigen Tests wurden auf dem alten Roboterarm durchgeführt. 

Die Steuerung des Tool-Center-Point kann durch eine alternative Ansteuerung 

ergänzt werden. Dieser Ansatz umfasst eine Kalibrierung des Arbeitsbereichs 

des Roboterarms auf den Bewegungsraum des Arms des Benutzers. 

Dies könnte eine intuitivere Steuerung ermöglichen. 

Im Abschnitt 2.14.2.3 wurden die HDMI-Bildausgabe und das Overlay aus 

dem Hardwaredesign entfernt. Dies war erforderlich um das Hardwaredesign 

zu synthetisieren. Da die Bildausgabe als Rückmeldung für den 

Benutzer nichtmehr zur Verfügung steht, kann es passieren, dass der Benutzter 

sich aus dem Sichtfeld der Kamera entfernt. Dadurch würde der 

Roboterarm nicht mehr auf Eingaben des Benutzers reagieren. Um die Bedienbarkeit 

zu verbessern kann das Hardwaredesign überarbeitet werden, 

um die HDMI-Bildausgabe und das Overlay wieder in das Design zu integrieren. 

Hierzu kann eine Neukonfiguration des Microblaze durchgeführt 

werden. 



angepasst. Alle geänderten oder auch neu erstellten Dateien liegen 

in dem Repository microblazecode vor. 

• microblazecode/gestensteuerung/src/gestensteuerung/gestensteuerung.h: 

C++Header Datei der Gestensteuerung. 

• microblazecode/gestensteuerung/src/gestensteuerung/gestensteuerung.cpp: 

C++Datei mit der Implementation der Gestensteuerung. 

• microblazecode/gestensteuerung/main.cc: Programmcode, der die erstellten/geänderten 


• ATLYS (Branch gestensteuerung): Xilinx EDK Projekt mit Hardwaredesign. 

447


2.14.3 Fertigstellung und Optimierung Skizze Zeichen 

In diesem Arbeitsschritt sollen die bereits im Kapitel 2.12.6 erstellen Prozesse 

optimiert werden, welche für das Erstellen einer Skizze nötig sind. Dabei 

sollen die einzelnen Schritte dahingehend optimiert werden, dass von dem 

Benutzer ein Bild mit einer Webcam aufgenommen und so vorbereitet wird, 

das Steuerinformation an den FPGA gesendet werden können und dieser 

den Roboterarm benutzt, um eine Skizze des Benutzer automatisiert zu zeichnen, 

so wie es in den Anforderungen im Abschnitt 1.2.3.4 beschrieben ist 

Die einzelnen Prozesse müssen aufeinander weiter abgestimmt werden, 

um die formulierten Anforderungen erfüllen zu können. Dazu zählt zum 

Beispiel die Bildverarbeitungskette, welche das Bild vereinfacht und aus 

dem Bild eine Vektorgrafik erstellt, da dies noch nicht optimal erfolgt. 

Ebenfalls ist es nötig dem Benutzer eine auf die Anforderung zugeschnittene 

Benutzeroberfläche bereitzustellen. Der Ablauf soll für den Benutzer 

darauf reduziert werden, das sein Gesicht von ihm vor eine Webcam platziert 

wird und durch das auslösen einer Aktion der gesamte Prozess gestartet 

wird, ohne weiteres zutun des Benutzers. 

2.14.3.1 Umsetzung der Anforderungen 

Für den Anwendungsfall Skizze zeichnen wurde die Anforderung gestellt, 

dass das System vor dem Beginn des Zeichnens sich selbständig initialisiert 

und eine Kalibrierung druchgeführt. Die Initialisierung erfolgt durch 

die erstellen Servomotoren-IPCore und durch die entwickelten Treiber. Die 

Aufnahme und die Verarbeitung des Portraits des Benutzer erfolgt durch 

die Verwendung eines PCs und entsprechender Software, die bereits im 

Abschnitt 2.12.6 vorgestellt wurde. 

2.14.3.2 Optimierungen für die Anforderungen 

Bisher wurde die Bildverarbeitungskette mit statischen Bildern getestet 

und entwickelt. Diese Bilder haben bereits verwendbare Ergebnisse geliefert, 

jedoch waren die resultierenden Konturen welche in ein Vektorgrafik übersetzt 

werden sollten noch zu komplex. Folglich musste der Bildverarbeitungsprozess 

optimiert werden und eine Möglichkeit für den Benutzer geschaffen werden, 

ein Bild von sich aufzunehmen. 

448


(a) Anbindung einer Webcam in den 

Verarbeitungsprozess 

(b) Bildvorverarbeitung einschließlich 

der Vektorisierung 

Abbildung 2.199: Bildverarbeitungsketten die verwendet wurden 

Im Ersten Schritt wurde die Integration der Webcam vorgenommen. Dafür 

wurde ein zusätzlicher Bildverarbeitungsprozessor erstellt, welcher eine 

Webcam ansteuert. In unserem Szenario wurde eine Webcam der Firma 

Logitech vom Typ HD C270 verwendet. Die Bildverarbeitungskette, in Abbildung 

2.199(a) dargestellt, ist ausschließlich für das Aufzeichnen, Zuschneiden 

und Spiegeln des Bildes zuständig. 

Das resultierende Bild wird anschließend mit einer weiteren Bildverarbeitungskette 

verarbeitet. Diese Kette, dargestellt in der Abbildung 2.199(b), 

ist eine Weiterentwicklung der Kette aus dem Abschnitt 2.12.6.1. Sie wurde 

um eine öffnende und schließende morphologische Operation erweitert, 

449


welche kleine Flächen auf dem Bild entfernt. 

Darüber hinaus wurden die Parameter der einzelnen Filter optimiert, so 

dass die Konturen einfacher werden konnten. Nachstehend ist in Abbildung 

2.200 ein Vergleich der jeweiligen Ergebnisse aus den verschiedenen 

Bildverarbeitungsketten dargestellt. Dabei ist deutlich zu sehen, das rechts 

weniger und einfachere Linien enthalten sind. 

Abbildung 2.200: Links vor und rechts nach der Optimierung der Bildverarbeitungskette 

2.14.3.3 Optimierungen der Bildaufnahme 

Der letzte Filter in der Bildverarbeitungskette beinhaltet die Vektorisierung, 

als auch das Umwandeln in die CNC-Fräsmaschinen kompatiblen Anweisungen. 

Dieser Filter wird jedoch erst durch das Auslösen vom Benutzer 

aktiv, welches mittels einer Schaltfläche erfolgt. Dadurch bekommt 

der Benutzer die Möglichkeit eine Vorschau von den Konturen zu erhalten. 

Die Koordination der Prozesse wurde mittels der in die OFFIS-Automation- 

Toolbox integrierten Skriptumgebung und Erweiterungen für diese realisiert. 

Das Aufnehmen des Bildes erfolgt nun mit einer Webcam und durch den 

Benutzer ausgelöst. Die Aufnahme wird mittels eines Buttons in der OFFIS- 

450


Automation-Toolbox ausgelöst, wenn der Benutzer eine gewünschte Einstellung 

verwenden möchte. Der Aufbau der Benutzeroberfläche ist in Abbildung 

2.201 veranschaulicht. 

Abbildung 2.201: Aufbau der Benutzeroberläche für den Benutzer 

Zu der Möglichkeit die Aufnahme auszulösen, wurde ebenfalls die Optionen 

Helligkeits- und Kontrastwerte dynamisch anzupassen hinzugefügt, 

damit der Benutzer auf variierende Lichtverhältnisse und damit auf die 

erzeugte Skizze Einfluss nehmen kann. 

2.14.3.4 Verwendete Komponenten 

Für die Umsetzung wurde die OFFIS-Automation-Toolbox verwendet in 

Zusammenarbeit mit der frei erhältlichen Software Inkscape, wobei die 

Komunikation zwischen den Programmen über eigens entwickelte Plugins 

realisiert wurde. 

Ebenfalls wurde das Kinematik Projekt aus dem Sprint 2.10.6 verwendet, 

welches Erweiterungen für die OFFIS-Automation-Toolbox bereitstellt und 

451


ein Programm enthält, das auf dem Microblaze ausgeführt werden kann. 

Der FPGA wurde zur Ansteuerung der Servomotoren des Roboterarms 

verwendet. Der sich ergebende gesamte Aufbau ist in Abbildung 2.202 

vereinfacht dargestellt. 

FPGA 

Abbildung 2.202: Aufbau des Demonstrator Skizze zeichnen 

Das eingesetzte Hardwarelayout wurde aus dem Projekt 2.14.2 übernommen, 

da dieses alle benötigen Komponenten enthält. Auch hier waren keine 

weiteren Anpassungen mehr nötig. 

2.14.3.5 Prozess Steuerung 

Die Zusammenarbeit der einzelnen Komponenten ist mit einem Interpreterprogramm 

in der Programmiersprache Python umgesetzt worden. Der Ablauf 

ist in Abbildung 2.203 veranschaulicht und die einzelnen Funktionen der 

Klasse im weiteren erläutert. 

452


Start 

Verbindung mit Roboter 

Initialisieren 

Benutzeroberfläche 

Initialisieren 

Bildvorverarbeitung 

Benutzer 

löst 

Aufnahme 

aus 

nein 

ja 

Vektorisierung aktivieren 

Steuerbefehle generieren 

lassen 

einlesen der 

Steuerbefehlen 

Steuerbefehlen an den 

FPGA übertragen 

Stop 

Abbildung 2.203: Programmablauf der Hauptfuntion 

Funktionen 

Die für den Ablauf zuständige Klasse besitzt eine Hauptfunktion 

welche den Aufruf der restlichen Funktionen koordiniert. 

main () 

In der Hauptfunktion werden Initialisierungen vorgenommen, als auch die 

koordination des Programmablaufs. 

handleNGC () 

Mit Hilfe dieser Funktion werden die Maschienensteuerbefehle eingelesen 

und interpretiert. 

453


parse_g_cmd ( g_cmd_type , line ) 

Diese Funktion bekommt eine Zeile mit Maschienensteuerbefehlen übergeben 

und extrahiert die nötigen Informationen. 

parse_g_cmd_value ( line , val ) 

Um einen bestimmten Wert für einen Befehl zu erhalten wird diese Funktion 

benutzt, welche zum Beispiel den Wert für die X-Achsen Koordinate 

ermittelt. 

move ( oldPoint , point ) 

Die Bewegungssteuerung wird mittels der Funktion move realisiert. Diese 

Funktion bewegt die Zeicheneinheit des Roboterarms entweder zeichnend 

oder nicht zeichnend und berechnet die benötigten Winkel. 

armPosition ( angles ) 

Die Position, welche der Roboterarm mit Hilfe der Servomotoren einnehmen 

soll, wird mit dieser Funktion und vorher berechneter Winkel umgesetzt. 

2.14.3.6 Ergebnis und Ausblick 

Das erzielte Ergebnis ist in Abbildung 2.204 dargestellt und zeigt das Ursprungsbild 

vor und nach der Bildverarbeitung. Das rechte der drei Bilder, 

ist dann das von dem Roboterarm auf Papier umgesetzte Bild. Die Konturen 

lassen sich zum Teil erkennen, jedoch lässt diese Umsetzung noch 

spiel für Verbesserungen. 

454


Abbildung 2.204: Links ist das Ausgangsbild gezeigt, und in der Mitte und 

Rechts die Roboterumsetzung mit verschiedenen Stiften 

Das Resultat könnte sich noch verbessern lassen, in dem man auf eine überarbeitete 

Kinematik setzt, welche die Eigenheiten des Roboters besser abbildet. 

Das bezieht sich vor allem auf einen Strategiewechsel, auf welchen 

man nicht reagieren kann. Der Strategiewechsel sorgt in diesem Fall für 

unkontrollierbare Striche im Bild, die sich Aufgrund unserer aktuellen Umsetzung 

der Kinematik nicht vermeiden lassen. 

Ebenso wäre mit einer verbesserten Roboterarm-Hardware, das heißt genaueren 

Servomotoren und stabileren Konstruktion des Arms selber, auch eine detailreichere 

Zeichnung möglich gewesen. Es war aus Zeitgründen nicht 

mehr möglich den Aufbau mit dem neu geplanten und zum Teil bereits 

umgesetzten Roboterarm zu testen. 


In dem abschließenden Sprint wurden die geplanten Demonstratoren fertiggestellt. 

Allerdings wurden die Demonstratoren Alternative Gestensteuerung 

sowie Skizze zeichnen als Semi-Demonstratoren fertiggestellt. Beide Demonstratoren 

würden mit der neuen Kinematik und mit der neuen Roboter- 

Hardware genauer funktionieren. Aufgrund des Zeitmangels und des noch 

nicht komplett gebauten neuen Roboterarms war es nicht möglich, diese 

Demonstratoren mit dem neuen Roboterarm zu testen. Der vorhandene 

Roboterarm würde mit der verbesserten Kinematik einen größeren Arbeitsbereich 

aufweisen. Es war aus zeitlichen Gründen nicht mehr möglich 

455


dies zu testen. Die zwei Demonstratoren werden als Semi-Demonstratoren 

angesehen, da diese auf dem kleineren Arbeitsbereich die Zwecke der 

entsprechenden Anwendungsfälle erfüllen. 

Der Demonstrator Armhaltung nachahmen wurde vollständig fertiggestellt. 

Die Struktur der Dokumentation wurde validiert. 

456

3 Fazit 

Heutzutage werden in der Industrie immer häufiger Kamerasysteme verwendet, 

um die automatisierten Anlagen oder Roboter sowie die Bearbeitung 

und Manipulation der Werkstoffe zu beobachten. Die Daten der 

Kameras werden dabei als Eingabe für die entsprechenden Steuerungssysteme 

genutzt. Die Projektgruppe RoboArm stellte sich der Aufgabe, ein 

Kamerasystem zu entwickeln, welches ohne PC und auf Basis eines FP- 

GAs funktioniert. 

Das Hauptaugenmerk lag dabei auf der Bildverarbeitung sowie dem Steuerungssystem 

eines Roboterarms. Die Bildverarbeitung umfasste die Erkennung 

der Bewegungen eines menschlichen Arms sowie alternativer Gesten, 

wie zum Beispiel Bewegungen des Kopfs oder der Augen. Die Hauptanforderungen, 

welche die Projektgruppe umgesetzt hat, waren die Nachahmung 

der Bewegungen des menschlichen Armes, sowie die gezielte Ansteuerung 

des elektromechanischen Roboterarmes. Eine weitere Anforderung 

war, die Echtzeitfähigkeit des Systems zu gewährleisten. Das von der Projektgruppe 

realisierte System bestand aus einem FPGA, einer Kamera sowie 

einem vormontierten Roboterarm. Die Projektgruppe hat folgende Anwendungsfälle 

umgesetzt, die die Hauptanforderungen demonstrieren sollen: 

Anhand des Demonstrators Armhaltung nachahmen werden die Bewegungen 

des menschlichen Arms erkannt und diese durch den Roboterarm 

nachgeahmt. Der Demonstrator Roboter steuern durch alternative Gesten setzt 

die erkannten alternativen Gesten in Form von Kopfbewegungen in die 

vordefinierten Bewegungen des Roboterarms um. Der Demonstrator Skizze 

zeichnen nimmt durch die Kamera das Gesicht einer Person auf und zeichnet 

dessen Skizze auf einer Zeichenfläche. 

Die Projektgruppe näherte sich schrittweise den gestellten Ziele an. Zunächst 

befasste sich die Gruppe mit der Fertigstellung der grundlegenden Steuerungseinheiten 

der Systemkomponenten. Parallel wurde die Machbarkeitsstudie 

für das Eye-Tracking durchgeführt und ein Softwareprototyp für die Objektverfolgung 

erstellt. Nach dem Ergebnis dieser Studie fiel die Entscheidung 

auf die Erkennung von Kopf- statt Augenbewegungen als Eingabe der al- 

457

Kapitel 3. Fazit 10. Oktober 2013 

ternativen Gestensteuerung. Im nächsten Schritt folgte die Umsetzung der 

Module zur Bildvorverarbeitung auf dem FPGA sowie die Analyse der 

HDMI-Ausgaben in Echtzeit. Basierend auf diesen Ergebnissen wurden 

Softwareprototypen zur Erkennung der alternativen Gesten durch Kopfbewegungen, 

sowie für die Ermittlung der Tiefeninformation erstellt. Außerdem 

wurden die HDMI-Ausgabe sowie die Bewegungserkennung in Hardware 

umgesetzt. Weiterhin erfolgte die Umsetzung des Softwareprototyps 

zur Handsteuerung. Die weiteren Schritte in der Erstellung der Bildverarbeitungkette 

erfolgten mit der Realisierung der ImageBus-Overlay Hardware- 

Komponente sowie der Umsetzung des Softwareprototyps zur Vektorisierung 

eines Portraits. Danach wurden die Prototypen der Bildverarbeitung für die 

alternative Gestensteuerung und die Armnachahmung auf Hardware und 

den Microblaze portiert. Die Vektorisierung läuft dabei, konform mit der 

Spezifikation, auf einem Rechner ab. 

Für die Robotersteuerung wurden die Routinen für Ansteuerung der Servos 

sowie die Kinematik umgesetzt. Im späteren Verlauf wurde ein neuer 

Roboterarm entwickelt und gebaut, da der zur Verfügung gestellte Roboterarm 

viele Schwächen aufweist. Dennoch wurden die Demonstratoren mit 

dem alten Roboterarm realisiert, da der neue Roboterarm erst zum Schluss 

des Projektes fertiggestellt wurde. Die letzten Wochen dienten zur Optimierung 

der Demonstratoren. 

Im Laufe des Projekts hat sich die Entwicklung von Hardware als besonders 

zeitaufwändig herausgestellt. Es fiel auf, dass die Hardwareentwicklung 

im Gegensatz zur Software eine gründliche Planung der Komponenten 

sowie ein tiefes Verständnis von Echtzeit und Parallelität benötigt. 

Aus diesem Grund gehört die Entwurfsphase zu den wichtigsten Entwicklungsprozessen, 

da insbesondere bei der Planung vorausschauendes Denken 

erforderlich ist. Für eine Validierung des in VHDL beschriebenen Verhaltens 

ist daher das lange und kontinuierliche Simulieren und Testen jeder 

Hardware-Komponente notwendig. Durch die steigende Anzahl der Hardware- 

Komponenten sowie die sich dadurch verlängernden Synthesezeiten wurde 

die Bedeutsamkeit einer ausführlichen Planung stark verdeutlicht. 

Auf dem Weg zu den gestellten Zielen hat die Projektgruppe viele Probleme 

und Herausforderungen überwunden. Die automatische Regelung 

der Lichtverhältnisse der zur Verfügung gestellten Kameras stellten eine 

weitere Herausforderung dar: Erst durch die Anwendung mehrerer Filter 

konnte ein Bereich der Lichtintensität festgestellt werden, bei dem der 

Systemprototyp definitionsgemäß funktioniert. Jedoch bereitet eine wenig 

458


oder ungleichmäßig ausgeleuchtete Umgebung Probleme bei der Erkennung 

von eindeutig gefärbten Markierungen. Eine durch definierte Lichtverhältnisse 

festgelegte Umgebung erleichtert die Erkennung von Markierungen 

daher deutlich. 

Sowohl die mechanische Beschaffenheit der Metall- und Plastik-Komponenten 

als auch die grobe Auflösung der Servos stellten ein Hindernis bei der Umsetzung 

der Anwendungsfälle Skizze zeichnen und Objekt bewegen dar. Für 

den Anwendungsfall Objekt bewegen resultierte aus diesen Hindernissen 

eine starke Begrenzung der (Wiederhol-)Genauigkeit. Durch die Entwicklung 

und den Bau des neuen Roboterarms verzögerte sich die Umsetzung 

der Anwendungsfälle Objekt bewegen, Skizze zeichnen sowie Roboter 

steuern durch alternative Gesten. Eine weitere Herausforderung stellte das 

nur begrenzt vorhandene Ingenieurwissen in der Robotik dar, welches sich 

die Gruppe daher im nötigen Umfang aneignen musste. Die manuelle 

Entwicklung der Kinematik stellte sich als eine sehr rechenlastige und 

zeitaufwändige Aufgabe heraus. Nach dem Versuch die Kinematik algebraisch 

zu entwickeln wurde auf eine geometrische Lösung ausgewichen. 

Im Folgearbeitspaket stieß die Gruppe weiter auf die frei verfügbare Software 

OpenRAVE. Diese ermöglichte die automatisierte Entwicklung der 

Kinematik, erforderte jedoch eine gründliche Einarbeitung. Da die Entdeckung 

sowie Einarbeitung in diese Software erst relativ spät erfolgte, 

mussten die Anwendungsfälle Objekt bewegen und Skizze zeichnen weiterhin 

auf der manuell entwickelten Kinematik aufsetzen. Diese ermöglichte 

jedoch nicht die Nutzung des gesamten Arbeitsbereichs des Roboterarms. 

Außerdem ist in dieser Kinematik die Ansteuerung der Orientierung des 

Tool-Center-Point nicht enthalten. 

Durch die hohe Komplexität und Einarbeitung in viele neue Themengebiete 

wurde festgestellt, dass zur Realisierung der einzelnen Demonstratoren 

in den meisten Fällen mehr Zeit benötigt wurde, als zunächst erwartet. 

Dies hatte zur Folge, dass die verbleibende Arbeitszeit nicht mehr für die 

Integration und Tests mit der verbesserten Kinematik ausreichte. Daher 

wurde der Demonstrator Objekt bewegen nicht umgesetzt. Dennoch konnte 

die Gruppe die geforderten Grundlagen des Systems realisieren, um somit 

eine Basis für darauf aufbauende Arbeiten zu schaffen. Der Anwendungsfall 

Armhaltung nachahmen ist vollständig umgesetzt worden. Die weiteren 

Anwendungsfälle Roboter steuern durch alternative Gesten und Skizze zeichnen 

wurden ebenso fertiggestellt. Weiterhin wurde der Softwareprototyp 

zur Erkennung und Vektorisierung des Gesichts einer Person fertiggestellt. 

459


Das Zeichnen der Skizze funktioniert dabei auf einem Zeichenbereich von 

5 x 5 cm. Die Steuerung durch alternative Gesten erkennt die definierten 

Geste und ermöglicht das Senden der vordefinierten Steuersignale an den 

Roboterarm. Insgesamt hat die Projektgruppe ein System fertiggestellt, das 

die gesetzten Hauptanforderungen erfüllt. Die nicht eingebundenen Systemkomponenten 

funktionieren im einzelnen und sind lediglich aus Zeitgründen 

nicht integriert worden. 

Zur Unterstützung der Gruppe im Zeitmanagement wurde ein Mitglied 

der Gruppe zum Projektmanager ernannt. Diese hatte einen Überblick über 

alle laufenden Arbeitspakete und konnte somit wirkungsvoll Gruppenentscheidungen 

bei der Verteilung der Aufgaben koordinieren. Einzelne Sprints 

wurden zu diesem Zweck durch ein zusätzlich angefertigtes Gantt-Diagramm 

begleitet. 

Durch die Projektgruppe konnten viele Erfahrungen gesammelt werden, 

die zum Teil nicht Gegenstand des übrigen Studiums sind: 

Dazu zählt an erster Stelle das Zeitmanagement welches insbesondere für 

die Arbeit in einem richtigen Unternehmen unerlässlich ist. Durch das Erlernen 

der Hardwareentwicklung auf FPGAs hat die Gruppe einen vertieften 

Einblick in die eingebetteten Systeme und Hardware-Engineering 

bekommen. Jedes Teammitglied setzte sich dabei mit mehrere Entwicklungswerkzeuge 

auseinander. Weiterhin eignete sich die Gruppe Kenntnisse 

aus den Bereiche des Ingenieurwissens wie der Robotik, Kamerasensorik, 

Kinematik oder auch der CAD-Modellierung an. Durch das Erkennen 

der persönlichen Stärken und Neigungen konnten nach kurzer Einarbeitung 

einzelne Aufgaben gezielter verteilt werden. Insgesamt wurde der 

Erfolg der Projektgruppe durch enge Zusammenarbeit, kompetente Unterstützung 

der Betreuer sowie gegenseitige Hilfsbereitschaft geprägt. 

460

4 Ausblick 

Dieses Kapitel beschreibt mögliche Verbesserungen und Erweiterungen des 

Projekts. Grundsätzlich können die umgesetzten Demonstratoren als Prototypen 

angesehen werden, welche für den Einsatz im Bereich der Medizin, 

der Sicherheitstechnik oder der Geriatrie weiterentwickelt werden müssten. 

Zur Verbesserung der Unabhängig von Lichtverhältnissen und der damit 

verbundenen Präzisierung der Armbindenerkennung, können rote LEDs 

an Stelle der Armbinden verwendet werden. Es könnte darüber hinaus eine 

Kamera ohne Infrarotfilter zum Einsatz kommen. Dies ermöglicht andere, 

leichter erkennbare, Markierungen zu verwenden, um damit die Stabilität 

des System zu verbessern. Anstatt der farbigen Markierungen, welche dem 

Hintergrund sehr ähnlich sein können, würden Markierungen verwendet, 

welche nur in einer bestimmten Entfernung zur Infrarotlichtquelle erkannt 

werden. 

Eine weitere mögliche Erweiterung des Systems wäre die Steuerung des 

Roboterarms mit Hilfe der Verfolgung von Augenbewegungen. Das menschliche 

Auge könnte als Joystick fungieren und somit eine zusätzliche alternative 

Gestensteuerung umsetzen. 

Der Demonstrator Objekt bewegen wurde im Projekt Roboarm nicht umgesetzt. 

Abgesehen von der fehlenden Portierung sind alle Voraussetzungen 

für diesen Demonstrator geschaffen. Der Roboterarm ist gebaut, die zugehörige 

Kinematik erstellt, die Algorithmik ist fertig. Der neue Roboterarm 

könnte mit Hilfe der Ausgaben eines Schachcomputers Schachfiguren an 

die korrekte Position bewegen. Zu diesem Zweck bedürfte es entweder einer 

definierten Umgebung oder weitere Bilderkennungsverfahren zur Identifikation 

von Schachfiguren. 

Weiterhin können mit Hilfe des neuen Roboterarms schon umgesetzte Anwendungsfälle 

verbessert werden hinsichtlich des Arbeitsbereiches und der 

Präzision. Der Anwendungsfall Skizze zeichnen erhält dadurch die Möglichkeit 

größere Bilder zu skizzieren und die Linienführung würde verbessert. Der 

Arbeitsbereich des Anwendungsfalls alternative Gestensteuerung wird vergrößert 

und die Genauigkeit einen bestimmten Punkt anzufahren erhöht 

sich. Dies könnte der Erstellung von Portraits oder Landschaftszeichnungen 

mit künstlerischem Wert dienen. 

461

Kapitel 4. Ausblick 10. Oktober 2013 

Die Kapazität des verwendeten Boards (ATLYS) ist durch das Projekt erschöpft. 

Bei Erweiterung des Systems muss ein größeres Board verwendet 

werden (z.B. ein GENESYS). Dabei ergibt sich das Problem, dass die 

HDMI-Anbindung ATLYS spezifische Details verwendet und nicht auf anderen 

Boards funktioniert. Wenn bei Verwendung eines neuen Boards weiterhin 

die HDMI-Ausgabe verwendet werden soll, muss diese entsprechend 

an das neue Board angepasst werden. Beim GENESYS-Board ist beispielsweise 

ein eigener Chip für die HDMI-Codierung verbaut, welcher explizit 

angesprochen werden müsste. 

462

Literaturverzeichnis 

[1] V. Paletta A. Freimann, E. Topcagic, Eyetracking, 2011. 

[2] Aptina, Mt9d112 data sheet, URL http://www.aptina.com/assets/ 

downloadDocument.do?id=801. 

[3] Donald G. Bailey, Design for Embedded Image Processing on FPGAs, 1 ed., 

Wiley-IEEE Press, Massey University, New Zealand, August 2011. 

[4] Andry Black, Fontbuilder, URL https://github.com/andryblack/ 

fontbuilder/. 

[5] J. E. Bresenham, Algorithm for computer control of a digital plotter, IBM 

Syst. J. 4 (1965), no. 1, 25–30, URL http://dx.doi.org/10.1147/sj. 

41.0025. 

[6] John J. Craig, Introduction to robotics mechanics and control, Pearson Education, 

Inc., New Jersey, 2005. 

[7] Linux Kernel Developers, Linux/drivers/staging/dream/camera/mt9d112.c, 

URL http://lxr.free-electrons.com/source/drivers/ 

staging/dream/camera/mt9d112.c?v=2.6.36. 

[8] Digilent, Vmodcam reference manual, URL http://www.digilentinc. 

com/Data/Products/VMOD-CAM/VmodCAM_rm.pdf. 

[9] Patrick Elfert, Architekturbegründete Vor- und Nachteile FPGA basierender 

Bildverarbeitung sowie grundelegende Transformationsstrategien, 2012. 

[10] Jesse S. Jin John G. Allen, Richard Y. D. Xu, Object Tracking Using 

CamShift Algorithm and Multiple Quantized Feature Spaces, 2006. 

[11] Micron, Mt9d112 data sheet, URL http://www.zhopper.narod.ru/ 

mobile/mt9d112_misoc-2020_full.pdf. 

463

Literaturverzeichnis 10. Oktober 2013 

[12] I. Oikonomidis, N. Kyriazis, and A.A. Argyros, Full DOF tracking 

of a hand interacting with an object by modeling occlusions and physical 

constraints, Proceedings of the 13th IEEE International Conference 

on Computer Vision, IEEE, November 2011, pp. 2088–2095 (english), 

URL http://www.ics.forth.gr/~argyros/mypapers/2011_11_ 

iccv_hope.pdf. 

[13] Werner Roddeck, Einführung in die mechatronik, Teubner GmbH, Wiesbaden, 

2003. 

[14] R. Männer S. Hezel, A. Kugel, FPGA-based Template Matching using 

Distance Transforms, 2012. 

[15] Tobias Schüürhuis, FPGA Architektur und verfügbare Entwicklungsplattformen, 

2012. 

[16] Matthias Stasch, Objekterkennung, 2012. 

[17] Robert Y. Wang and Jovan Popović, Real-time hand-tracking with a 

color glove, ACM Transactions on Graphics 28 (2009), no. 3 (english), 

URL http://people.csail.mit.edu/rywang/handtracking/ 

s09-hand-tracking.pdf. 

[18] xilinx, Logicore ip multi-port memory controller (v6.06.a), URL http: 

//www.xilinx.com/support/documentation/ip_documentation/ 

mpmc/v6_06_a/mpmc.pdf. 

[19] xilinx (Richard Griffith and Felix Pang), Microblaze system performance 

tuning, URL http://www.xilinx.com/support/documentation/ 

white_papers/wp348.pdf. 

[20] Projektgruppe yaDAS, Fpga-basiertes echtzeit-kamerasystem für fahrassistenz, 

IEEE, September 2011, pp. 2088–2095 (german), URL 

http://www-is.informatik.uni-oldenburg.de/~dibo/pg_fb10/ 

endberichte/2011/yaDAS.pdf. 

464

Glossar 

3D-Kamera Kamera, welche Bilder mit Tiefeninformationen erstellt. 20 

Agilen Softwareentwicklung Oberbegriff für den Einsatz von Agilität (Dynamik) 

in der Softwareentwicklung. 63 

Algorithmus Aus endlichen, ausführbaren Schritten bestehende Handlungsvorschrift. 

155, 232, 234, 235, 279, 283, 337, 338, 391–393, 398, 441 

AMiR Abteilung Mikrorobotik und Regelungstechnik. 25, 158 

AREXX Firma, welche den von der Projektgruppe benutzten Roboterarm 

anbietet. 28 

Array Ein Array ist eine Datenstruktur, in der jedes Datum einen eindeutigen, 

fortlaufenden Index besitzt. 18, 408, 436, 437 

ATLYS Entwicklerplatine mit FPGA von Digilent. Siehe auch Digilent und 

FPGA. 28, 177, 181, 182, 190, 194, 203, 260, 285, 288, 289, 365, 446, 447, 

462 

Auösung Anzahl der gesamten Bildpunkte einer Rastergrafik, welche meistens 

als Bildpunkte pro Zeile multipliziert mit den Bildpunkten pro 

Spalte angegeben wird. 216, 227, 228, 236, 338 

Base Der festgeschraubte, im Raum unbewegliche Fußpunkt des Roboters 

wird Base genannt. 15, 323–326 

BGR888 BGR steht für blau, grün und rot. Den drei Kanälen stehen dabei 

jeweils acht Bit zur Verfügung. 173 

Bildwiederholungsrate Anzahl der Einzelbilder bzw. Bewegungsphasen, 

die in einem bestimmten Zeitabschnitt aufgenommen werden. 111, 

216 

Bitstream Ein Bitstream ist eine Bitfolge, welche aus IP-Cores generiert 

wird. Mit diesem Bitstream wird FPGA mit der entsprechenden Funktionalität 

programmiert. 389, siehe IP-Core 

465

Glossar 10. Oktober 2013 

BLOB Binary Large Object, Die Binary Large Objects sind Strukturen in 

binären Bildern. 13, 18, 184, 189, 198, 199, 214, 219, 227, 229, 234, 235, 

259, 266, 267, 269, 271, 272, 274, 285, 376, 391, 399, 404–406, 409, 434, 

439, 440, 445 

Breakpoint Ein Breakpoint wird in der Softwareentwicklung verwendet, 

um ein Programm an einer vorher festgelegten Stelle zu unterbrechen 

bzw. zu pausieren. Dies geschieht z.B. zum Debuggen von Programmzeilen 

see. 401 

Bulkdaten Übertragung großer Datenmengen über USB. 109 

Bus Binary Unit System, System zur Datenübertragung zwischen mehreren 

Teilnehmern. 109 

C++ Eine objektorientierte Programmiersprache, Erweiterung von C. 235, 

297, 368, 369, 376, 379–381, 383–387, 389, 391, 392, 409, 417, 440, 447 

Compiler Ein Compiler übersetzt geschriebenen (z.B. C++)-Quellcode in 

die Maschinensprache. 400, siehe C++ 

Datenstrom kontinuierliche Abfolge von Datensätzen ohne absehbares Ende. 

27, 63 

Denavit Hartenberg DH-Transformation: Überführung von Ortskoordinatensystemen 

innerhalb von kinematischen Ketten. 116, 117, 120, 121, 123, 

212, 379, 385 

Digilent Firma, welche elektronische Bauteile, insbesondere FPGAs verkauft. 

28, 103, 106, 109, 110, 159, 177, 182, 465, 467, siehe FPGA 

Dilatation Beschreibt eine morphologische Bildoperation, welche mit Hilfe 

eines Filterkerns Strukturen vergrößert. 158, 171, 175, 223, 224, 231, 

232 

Disparitätskarte Karte aus zwei Kameras, welche den Versatz der erkannten 

Objekte angibt. 61 

Echtzeit Zwischen definierten Zeitgrenzen arbeiten. 24, 194, siehe Echtzeitsystem 

Echtzeitsystem System, welches zwischen definierten Zeitgrenzen arbeitet. 

23 

466


Ein-/Ausgabe Pin Pin, welcher für beliebige Ein/Ausgabe benutzt werden 

kann. 110 

eingebettetes System elektronisches System, welches in einen technischen 

Kontext eingebunden ist. 22 

Equalizer-Histogramm Equalizer-Histogramme werden verwendet um die 

Helligkeit eines Bildes anzugleichen. 198 

Erosion Beschreibt eine morphologische Bildoperation, welche mit Hilfe 

eines Filterkerns Strukturen verkleinert. 158, 171, 175, 223, 224, 231 

Euler-Notation Die Euler-Notation gibt ein Format an, in welchem Winkel 

angegeben werden. Dabei werden Rotation um X,Y,Z konsekutive 

ausgeführt. 386 

Eye-Tracking Tracking von Augen. 36, 66, 155, 158, 457, siehe Tracking 

FIFO Besondere Form der Queue, welche als Puffer dient. 14, 179, 207, 209, 

240, 241, 243–246, 285–289, siehe Queue 

Filter Eine mathematische Funktion, welche aus einem Eingangsbild ein 

reduziertes Ausgangsbild erzeugt. 23 

Flieÿkommazahl Eine Fließkommazahl ist eine angenährte Darstellung einer 

reellen Zahl. 436 

FPGA Field Programmable Gate Array, Integrierter Schaltkreis in den logische 

Schaltungen programmiert werden. 27, 28, 61, 66, 103, 106, 109, 

110, 156–158, 175, 177, 189, 192, 196, 200, 214, 216, 232, 279, 281, 289, 

297, 303, 337, 349, 389, 390, 392, 401, 446, 448, 452, 457, 458, 460, 465, 

467, 473, siehe Integrierter Schaltkreis 

fps Bilder pro Sekunde (Frames per Second). 216, 407, 438 

Frame Ein Frame ist ein Bild innerhalb eines Videostreams. 392 

Generic Ein Generic ist ein konfigurierbare Konstante. 171, 175, 178, 206, 

285, 303, 376 

GENESYS Entwicklerplatine mit FPGA von Digilent. Siehe auch Digilent 

und FPGA. 177, 181, 203, 279, 281, 285, 289, 337, 349, 462 

467


HDMI High Definition Multimedia Interface, Schnittstelle zur digitalen 

Übertragung von Audio- und Video-Daten. 111, 157, 159, 177, 180, 

181, 187, 189, 194, 239, 259, 389, 390, 392, 446, 447, 458 

HIL IP-Core, welcher Bilddaten vom PC entgegen nimmt, diese an eine 

Bildverarbeitungskette auf dem FPGA weiterreicht und am Ende wieder 

an den PC zurückschickt. 272 

I 2 C Inter-Integrated Circuit, serieller Datenbus, auch TWI (Two-Wire-Interface) 

genannt. 27, 104, 105 

IKfast Ein Modul des OpenRAVE, welches zur Generierung von Vor- und 

Rückwärtskinematik verwendet werden kann. 15, 383, 384, 386, 387 

Image-HIL Image Hardware in the Loop. Projekt welches ein Bildsignal 

vom PC annimmt und nach dem durchlaufen einer Bildkette an diesen 

zurückschickt. Es wird zum testen von Bildfilter IP-Cores verwendet. 

173, 289 

ImageBus der ImageBus ist ein Bus, über den die Bilddaten pixelweise 

seriell übertragen werden. 12, 14, 108, 110, 162, 163, 177, 180, 181, 209, 

272, 285–291, 293, 458 

ImageBusSwitch IP-Core, welcher einen Umschalter zwischen zwei ImageBus 

Eingängen auf einen ImageBus Ausgang implementiert. 157, 

169 

ImageCache IP-Core, welcher ein Bild zwischenspeichert. 111, 177, 181, 

232 

Infrarot-Cutter Kamerafilter, welcher infrarote Strahlung eliminiert. 200 

inline Eine Anweisung für eine Methode innerhalb der Programmiertsprace 

C++, welche einen größeren Programmcode zu Gunsten eines effizienteren 

Programms zur Folge hat. 18, 437 

Interpolation hier: Dicheinterpolation. Berechnung von Pixeln zur Gewinnung 

von Bildgenauigkeit, z.B. beim nachträglichen erhöhen der Auflösung. 

61, 281, 338, 339, 343, 349, 351 

Interrupt Unterbrechung der normalen Programmausführung, zur Ausführung 

eines Interrupthandlers. 164, 165, 169, 189, 207, 255, 259, 391 

468


IP-Core Intellectual property core, Widerverwendbarer Teil eines Chipsdesigns. 

5, 6, 12–15, 27, 28, 61, 103–106, 108–111, 157–160, 162–165, 

169–183, 187, 189, 194–197, 203, 204, 206, 207, 209, 216, 239, 241–249, 

251–254, 258, 259, 272, 274, 275, 278, 284–291, 302–304, 315, 333–336, 

340, 364, 365, 370, 372, 376, 389–392, 405, 410, 411, 430, 446, siehe FPGA 

Iteration Wiederholung. 224, 226, 232 

Jenga Ein Geschicklichkeitsspiel, welches mit mehreren Holzklötzchen gespielt 

wird. 21, 24 

KB Größeneinheit von digital gespeicherten Objekten (z.B. Dateien). Entspricht 

1000 Bytes. 232 

Kinematik Kinematik ist die Wissenschaft über die physikalische Bewegung 

der Gegenstände im Raum. In der Robotik befasst sich die Kinematik 

mit der Abbildung der Position und Stellung des Endeffektors 

im Weltkoordinatensystem auf die Stellungen der einzelnen Robotersegmente 

und umgekehrt. Man unterscheidet die Vor- und Rückwärtskinematiken. 

Die Vorwärtskinematik bildet die Winkelstellungen 

der Gelenke eines Roboters auf die Position und Ausrichtung des 

Endeffektors (Tool-Center-Point) im Weltkoordinatensystem ab. Die 

Rückwärtswärtskinematik befasst sich mit der Abbildung der Position 

und Ausrichtung des Tool-Center-Point auf die Winkelstellungen 

der Gelenke. Damit wird jedes einzelne Segment eines Roboterarms 

oder Roboters in eine gewisse Stellung versetzt, um die gewünschte 

Position und Ausrichtung des Endeffektors zu erreichen. 7, 66, 198, 

203, 210–213, 278, 366, 367, 371, 374, 376, 378–381, 383–388, 429, 445, 

455, 458, 459, 472, 475 

KISS Keep It Small and Simple, Handhabe es möglichst einfach. 63 

Kreuzprodukt Mathematische Verknüpfung zweier Vektoren zu einem Vektor, 

welcher orthogonal auf den beiden Eingabevektoren steht. 237, 

300, 358 

Language Templates Durch die Entwicklungsumgebung vorgegebene Konstrukte, 

welche erkannt und ideal auf in Hardware übersetzt werden 

können. 176 

Latenz Verzögerungszeit zwischen Eingabe des Benutzers und Reaktion 

des Systems. 58 

469


Mapping Mapping, Abbildung oder Kartierung von Elementen (z.B. Funktionen, 

Eigenschaften ...). 198, 434–438 

Methode Eine Methode ist eine Programmfunktion, welche eine algorithmische 

Teilaufgabe löst. 436, 444, 445 

Microblaze in FPGAs von Xilinx verwendeter 32 Bit RISC Mikrocontroller. 

103, 104, 109, 164, 177, 178, 189, 193–195, 204, 207, 259, 272, 274, 275, 

283, 285, 286, 288–290, 297, 303, 343, 351, 358, 365, 367–369, 372, 374, 

376, 388, 389, 391, 396, 399, 401–404, 407, 410, 431, 447, 452, 458 

Mikado Ein Geschicklichkeitsspiel, welches mit mehreren bunten Holzstäbchen 

gespielt wird. 21, 24 

Morphologie Verarbeitung von binären Bildern bezüglich Teilmengen eines 

Bildes. 13, 158, 218–221, 223–227, 231 

MPMC IP-Core, welcher mehrere abstrahierte Schnittstellen auf Arbeitssspeicher 

anbietet. 177–179, 181, 239, 241, 244–246 

Normalform Hier: Spezielle Darstellung für eine Ebene zur leichteren Abstandsberechnung. 

238, 300, 358 

OFFIS-Automation-Toolbox grafisches Programm zum erstellen und testen 

von Filterketten. 7, 14, 28, 66, 103, 109, 155, 157, 158, 168, 170, 172, 182, 

184, 189–193, 214, 218, 235, 248–250, 257, 260, 279–281, 283, 289, 337, 

342, 343, 349, 354, 363, 367, 369, 371, 373, 374, 376, 378, 381, 386, 388, 

392, 412, 413, 443, 450, 451 

OpenCV Programmbibliothek zur Bildverarbeitung. 109, 215, 232, 413 

OpenRAVE Ein Werkzeug zum Modellieren und Berechnen Robotischer 

Umgebungen http://openrave.org. 15, 379–386, 388, 459 

Overlay Bild, welches über ein anderes Bild gelegt wird. 14, 18, 272, 285– 

293, 389, 392, 404, 406, 408, 434–439, 446, 447, 458 

Parameter Spezielle Variablen bzw. Kenngrößen. 224 

PC Personal Computer. 25, 27, 58, 108, 110, 163, 194, 241, 257, 258, 390, 457 

PIM Abtrahierte Schnittstelle, welche Zugriff auf den Arbeitsspeicehr ermöglicht. 

178, 179 

470


Pixel Digitaler Bildpunkt. 216, 222, 228, 236, 299 

PLB High-Speed Datenbus zur Kommunikation zwischen IP-Cores und 

Prozessorkernen. 110, 163, 164, 169, 171, 178, 179, 181, 204, 207, 243, 

245, 251, 272, 285, 286, 288, 336, 372, 404, 410, 429 

Plugin Ein Plugin ist Erweiterung oder auch ein Softwaremodul für eine 

bestehende Software, welches bei Bedarf eingebunden werden kann 

und den Funktionsumfang einer Software erweitert. 367, 388, 413, 

414, 416, 417 

Plugin Ein Plugin ist Erweiterung oder auch ein Softwaremodul für eine 

bestehende Software, welches bei bedarf eingebunden werden kann 

und den Funktionsumfang einer Software erweitert. 155, 189, 451 

Polygon Geometrisches Vieleck. 222 

Proling Profiling bezeichnet eine Analyse des Laufzeitverhaltens von Software. 

16, 398, 399, 401, 403, 409 

Pull-up Widerstand Widerstand, der den Standardzustand einer Leitung 

auf aktiv zieht. 109 

Pulspositionsmodulation Modulationsverfahren zur Datenübertragung. 28, 

203, 333, 351, 352, 389 

Python Programmiersprache, welche den Ruf hat leicht lesbar zu sein 

(Pseudocode). 155, 190, 192, 274, 279–281, 283, 337, 342, 349, 352, 365, 

369, 371, 376, 378, 387, 389, 391, 392 

Qt Qt ist eine C++ Programmbibliothek, siehe www.qt-project.org. 367, 

374, 388 

Queue Eine Warteschlange für Daten. 179, 180 

RA1-PRO Lern- und Schulungsroboter der Firma Arexx. 23 

RAM Schneller Speicher welcher als Ablage für Daten dient. 175–178, 194, 

239, 242, 244–246, 272, 285, 287, 289, 290 

Referenz Eine Referenz ist ein Verweis auf einen Speicherbereich. 408, 436 

Repository Eine Repository ist ein (hier: dezentrales, versioniertes) Datenarchiv. 

409, 428, 440, 447 

471


RGB2Grey Bildverarbeitungsfilter, der eine ausgewählte Farbe (Rot, Grün 

oder Blau) filtert. 158, 172, 173, 196, 199, 201, 214, 223, 372, 410 

RGB565 RGB steht für rot, grün und blau. Dem roten und blauen Kanal 

stehen dabei fünf Bit zur Verfügung, dem grünen sechs Bit. 239, 287, 

288 

RGB888 RGB steht für rot, grün und blau. Den drei Kanälen stehen dabei 

jeweils acht Bit zur Verfügung. 12, 158, 171–174 

RGBA888 RGB steht für rot, grün und blau. Den drei Kanälen stehen 

dabei jeweils acht Bit zur Verfügung. Zusätzlich existiert ein acht Bit 

Alpha-Kanal für Transparenzinformationen. 287, 290, 291, 294, 295 

RoboArm Name der Projektgruppe. 20, 25, 156, 182, 271, 381, 383, 385, 387, 

430, 457 

ROI Region of interest, Eingrenzung des Bildbereichs auf einen Bereich 

der im Weiteren verwendete Daten beinhaltet. 198, 200 

ROS Ein Betriebsystem zur Steuerung von Robotern www.ros.org. 386 

Rückwärtskinematik Kinematik. 155, 278–281, 337, 341–344, 349, 351, 352, 

371, 378, 381, 383, 386–388 

Schwellwertlter Schwellwertfilter werden im Bereich der Bildsegmentierung 

eingesetzt. Sie ermöglichen es durch Eingabe eines Wertes, in der 

Regel 0-255, Regionen voneinander zu unterscheiden. Dies kann sowohl 

auf Graubildern als auch auf den Farbkanälen von Farbbildern geschehen. 

158, 214, 225, 234 

Schwerpunkt Geometrischer Schwerpunkt eines Objekts, der durch Mittelung 

aller Punkte innerhalb des Objekts berechnet wird. 189, 269, 

297, 393, 405, 407, 408, 436, 439–442 

Sensor Messfühler, welcher bestimmte physikalische oder chemische Eigenschaften 

erfasst und in elektrische Signale umwandelt. 13, 216, 235, 

236 

Servo Elektromotor mit PPM-Ansteuerungselektronik. 5, 6, 13, 28, 47, 48, 

59, 66, 203–207, 212, 278, 279, 283, 305, 311, 312, 314–319, 321–323, 

330–337, 340, 352, 354, 365, 382, 389, 399, 403, 404, 418, 420, 421, 423, 

424, 428, 434–438, 441, 458, 459, siehe Pulspositionsmodulation 

472


Skalarprodukt Mathematische Verknüpfung zweier Vektoren zu eine Zahl 

(Skalar). 237, 300, 358 

Software Development Kit Das Xilinx Software Development Kit ist eine 

Entwicklungsumgebung für die Programmierung von Hardware. 399, 

400, 402, siehe Xilinx 

Spartan-6 FPGA Series von Xilinx. Siehe auch Xilinx und FPGA. 28 

Sprint Ein, eine festegelegte Dauer andauernder, Iterationsschritt, Konzept 

aus der Agilen Softwareentwicklung. 10, 63, 65, 66, 155, 189, 259, 260, 

271, 272, 279, 337, 365, 429, 430, 455 

Stereobild Zwei 2D-Bilder, welche mit einer 3D-Kamera zeitglich aufgenommen 

wurden. 232 

Stereoskopie Zwei 2D-Bilder, die zusammen einen räumlichen Eindruck 

enstehen lassen. 27, 235, 445 

Streaming Streaming bezeichnet einen Fluss von Daten, z.B. Bilddaten von 

einer Kamera zu einem Monitor. 408 

Testbench Virtuelle Testumgebung für Verhaltenstest und Verifikation von 

Designs oder ModellDesigns oder Modellen. 278, 304, 336 

Threshold Threshold, Schwellwert bei dem Pixelwerte unterhalb des Threshold 

auf 0 und alle Pixelwerte über dem Threshold auf 1 gesetzt werden. 

198, 199 

Tiefenkarte Bild, welches Tiefeninformationen für verschiedene Punkte im 

Bild enthält. 110, 232 

Timer Ein Timer ist ein Taktzähler. 399, 404 

Tool-Center-Point Mitte des Werkzeugkoordinatensystems des Roboterarms. 

8, 16, 57, 61, 112, 116, 117, 119–121, 123, 125, 127, 132, 134–136, 

138, 212, 213, 341, 371, 378, 380, 382, 383, 393, 443, 444, 447, 459, 469 

Torso Rumpf des Körpers. 215 

Tracking Alle Bearbeitungsschritte, welche zum Verfolgen von Objekten 

notwendig sind. 18, 32, 34, 37, 57, 198, 391, 404, 405, 408, 434–438 

473


Trajektorie Eine Trajektorie bezeichnet eine Raumkurve entlang derer sich 

ein Punkt bewegt. 15, 272, 278–281, 337–339, 341–344, 349, 351, 365, 

371, 378, 439 

Treiber Ein Treiber ist eine Software, welche z.B. durch das Setzen von 

Registern direkt die Hardware ansteurt. 18, 369, 391, 399, 403, 405, 

406, 410, 411, 434 

UCF User Constraint File. Datei in welcher Netze mit IO Pins des FP- 

GAs verknüpft werden und zusätzliche Einschränkungen, wie z.B. 

das Taktverhalten, gemacht werden. 181 

Unterschneidung Auch “Kerning” genannt. Verringerung des horizontalen 

Abstands zweier Buchstaben, so dass sich deren Rahmen bereits 

überschneidet. 295 

USB Ein serielles Bussystem zur Verbindung elektronischer Geräte. 27, 

103, 108–111, 155, 157, 163, 181, 189, 194, 207, 239, 245, 255, 257, 258, 

279, 289, 337, 351, 390 

Variable Eine Variable reserviert Speicher und ist ein Platzhalter für dynamische 

Werte. 408 

Vektor Mathematisches Objekt, welches einen Punkt in einem Koordinatensystem 

bzw. die Gerade von dem Ursprung (Nullpunkt) zu einem 

Punkt beschreibt. 18, 230, 235–237, 298–300, 338, 408, 436, 437 

Verilog Sprache in der Hardware beschrieben werden kann. 178 

VFBC Diese spezielle Schnittstelle des MPMC dient der Speicherung von 

2D-Bilddaten in einem externen Speicher. 12, 177–181, 194, 239–241, 

243–246, 272, 285, 287–289, siehe MPMC 

VHDCI Very-High-Density Cable Interconnect. 27, 28 

VHDL Very High Speed Integrated Hardware Description Language, Sprache 

in der Hardware beschrieben werden kann. 14, 178, 194, 286, 289, 458 

VHDL-Modul wiederverwendbarer und gekapselter VHDL-Quellcode. 285, 

287 

VModCam Stereo-Kameramodul für das Atlys- und Genesys-Board, welches 

von der Projektgruppe verwendet wird. 172, 184, 185, 187, 302, 439, 

siehe 3D-Kamera 

474


Vorwärtskinematik Kinematik. 155, 371, 378, 383, 386, 387 

Wrapper Eine Schnittstelle, welche zwei Programme verbindet. 381, 386– 

388 

Xilinx Firma, welche FPGAs designed. 28, 164, 206, 279, 281, 285, 337, 349, 

399, 447, 473, siehe FPGA 

Xilinx Microprocessor Debugger Der Xilinx Microprocessor Debugger ist 

eine Konsole, welche eine manuelle Kommunikation mit dem Microblaze 

erlaubt. 399, 401, siehe Xilinx & 

Xilinx Peripheral Wizard Tool, welches IP-Core Templates erstellt. 169, 242, 

246, 247, 251, siehe Xilinx 

XML Extensible Markup Language, Format zur Darstellung hierarchisch 

strukturierter Daten. 235 

XPS Xilinx Platform Studio, Grafisches Tool zum Erstellen, Bauen und 

Konfigurieren von eingebetteten Systemen. 178, 182, 376, 399, 410, 

siehe Xilinx 

Yaw-Pitch-Roll-Notation Die Yaw-Pitch-Roll-Notation-Notation gibt ein 

Format an, in welchem Winkel angegeben werden. Dabei werden Rotation 

um X,Y,Z parallel ausgeführt. 386 

z-Modus Modus, in welchem auf der z-Achse, statt auf der xy-Ebene gearbeitet 

wird. 56, 57 

Zustandsautomat Modell eines Verhaltens, welches aus Zuständen, Zustandsübergängen 

und Aktionen besteht. 204 

475

Abschlussbericht - Universität Oldenburg

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?