Bachelor Bericht

Bachelorthesis
Anbindung des Kinect-Systems an die Animationssoftware Blender

Connecting the Kinect device to the Blender Software
Adrian Eissfeldt
2012
Bachelorthesis
Anbindung des Kinect-Systems an die Animationssoftware Blender

Connecting the Kinect device to the Blender software
Adrian Eissfeldt
Tag der Abgabe: 30. April 2012 Betreuende Mitarbeiter: Dipl.-Ing. Torsten Wagner Dr. rer. nat. Peter Pott
Erklrung zur vorliegenden Arbeit gem 22/7 bzw. 23/7 APB
Hiermit versichere ich, die vorliegende Bachelor Thesis ohne Hilfe Dritter nur mit den angegebenen Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die aus den Quellen entnommen wurden, sind als solche kenntlich gemacht worden. Diese Arbeit hat in gleicher oder hnlicher Form noch keiner Prfungsbehrde vorgelegen.
Name:
................................................
Vorname:
................................................
Ort:
................................................
Datum:
................................................
Unterschrift:
................................................
TU Darmstadt IAD | Eissfeldt| 2012
Geheimhaltungserklrung / Rechte an der Arbeit
Hiermit verpflichte ich mich, bei Zusammenarbeit mit einem externen Auftraggeber, ber alle mir im Rahmen der Bearbeitung meiner Bachelor Thesis im Zusammenhang mit dem Auftraggeber zur Kenntnis gekommenen Informationen Verschwiegenheit gegenber jedermann zu bewahren. Die Verffentlichung oder Weitergabe meiner Studien- bzw. Diplomarbeit darf in diesem Falle nur in Absprache mit dem Leiter des Instituts fr Arbeitswissenschaft der TU Darmstadt erfolgen.
Name:
................................................
Vorname:
................................................
Ort:
................................................
Datum:
...............................................
Unterschrift:
................................................
ii
Zusammenfassung
Um ein automatisiertes Bewerten von Montagearbeitspltzen zu ermglichen, muss die Krperhaltung des Arbeiters digital erfasst und weiterverarbeitet werden. Eine mgliche Realisierung fr ein solches System, sieht eine Bewegungserfassung mit der 3D-Kamera Kinect vor. In dieser Arbeit wird ein Betriebssystemunabhngiges Gesamtsystem entwickelt, dass mit einer Kinect Skelettdaten erzeugt und diese in einer grafischen Demonstrator Anwendung auf ein digitales Menschmodell bertrgt. Die Anwendung wird in der Animationsumgebung Blender implementiert, deren Animationsfunktionen auerdem beschrieben werden. Fr die Skeletterkennung wird die API OpenNI in Verbindung mit der Middleware Nite benutzt. Die Skelettdaten werden als UDP Netzwerk-Nachricht im OSC-Format verschickt und von dem Demonstrator entgegengenommen, wo sie in Echtzeit mit einem digitalen Skelett verbunden werden, um ein digitales Menschmodell entsprechend der Bewegung des Benutzers auszurichten. Bewegungssequenzen lassen sich innerhalb des Demonstrators speichern und ffnen. In einem Konzept fr ein haltungsbasiertes ErgonomieBewertungsverfahren wird beschrieben, inwiefern sich die Skelettdaten eignen, um die fr ein Bewertungsverfahren ntigen Krperhaltungen zu identifizieren.
iii
Inhaltsverzeichnis
Erklrung zur vorliegenden Arbeit gem 22/7 bzw. 23/7 APB ............................................................................. i Geheimhaltungserklrung / Rechte an der Arbeit.............................................................................................................. ii Zusammenfassung....................................................................................................................................................................... iii Inhaltsverzeichnis ....................................................................................................................................................................... iv Abbildungsverzeichnis............................................................................................................................................................... vi Tabellenverzeichnis .................................................................................................................................................................. viii 1. 2. Motivation und Aufgabenstellung .................................................................................................................................. 1 Anforderungen ..................................................................................................................................................................... 2
3. Stand der Technik ............................................................................................................................................................... 3 3.1. CUELA .............................................................................................................................................................................. 3 3.2. Optisches Motion Capture mit Markern................................................................................................................... 4 3.3. Kinect ................................................................................................................................................................................. 6 3.4. Asus Xtion Pro Live....................................................................................................................................................... 8 3.5. Kinect SDK ....................................................................................................................................................................... 9 3.6. OpenNI Framework ..................................................................................................................................................... 10 3.7. Nite ................................................................................................................................................................................... 11 3.8. Blender............................................................................................................................................................................. 13 3.9. MakeHuman ................................................................................................................................................................... 14 4. Konzeption zur Verarbeitung der Kinect-Daten ....................................................................................................... 16 4.1. Schnittstelle Kinect Blender ................................................................................................................................... 16 4.1.1. Skelettdaten zur Verfgung stellen...................................................................................................................... 18 4.1.2. Datenaufbereitung .................................................................................................................................................... 23 4.2. bertragung der Skelettdaten auf ein digitales Menschmodell........................................................................ 26 5. Demonstrator ..................................................................................................................................................................... 34 5.1. Blender Game Engine.................................................................................................................................................. 34 5.2. Konzeption Demonstrator .......................................................................................................................................... 36 5.3. Szene Auswahl ............................................................................................................................................................... 37 5.4. Szene Einzelansicht ...................................................................................................................................................... 39 6. Animationsfunktionen in Blender ................................................................................................................................. 43 6.1. Motion Capture ............................................................................................................................................................. 43 6.2. Keyframe Animation .................................................................................................................................................... 45 6.3. Game Engine Animation ............................................................................................................................................ 48 7. 8. 9. Konzeption der Integration eines haltungsbasierten Ergonomie Bewertungsverfahren ................................ 49 Kritik und Ausblick ........................................................................................................................................................... 53 Literaturverzeichnis.......................................................................................................................................................... 55
Anhang ......................................................................................................................................................................................... 58 a. Anforderungsliste .............................................................................................................................................................. 58
iv
Abbildungsverzeichnis
3.1: Proband ausgestattet mit Sensoren und Datenspeichereinheit 3.2: Screenshot der Auswertesoftware (Quelle: Berufsgenossenschaftliches Institut fr Arbeitsschutz) 3.3: Optisches Motion Capture mit passiven Markern (Quelle: Aueragsakul) 3.4: Tiefenmessung mit optischer Triangulation 3.5: Kinect (verndert nach: amazon.de) 3.6: Strukturiertes Licht trifft auf ein Gesicht (Quelle: wikipedia.org) 3.7: IR Muster trifft auf eine Person (Quelle: Penven) 3.8: Pseudozufllige Struktur von Punkten (Quelle: creativeapplications.net) 3.9: Vergleich Kinect und Xtion Pro Live (Quelle: iheartrobotics.com) 3.10: Identifizierbare Gelenke mittels Microsoft SDK (Quelle: Taylor) 3.11: Konzept von OpenNI (Quelle: openni.org) 3.12: Mit Nite identifizierbare Gelenke 3.13: Blender Viewport 3.14: Blender Outliner 3.15: Blender Properties 3.16: MakeHuman Screenshot 4.1: Unterteilung Gesamtkonzept 4.2: OSCeleton Hilfe 4.3: Darstellung eines OSC-Bundles 4.4 : Importiertes Menschmodell aus MakeHuman 4.5: In Blender erstelltes Skelett 4.6: Blender Outliner Hierarchie 4.7: Rotation des Oberarms wirkt sich auf alle Child Bones aus 4.8: Vertex Groups 4.9: Bone Envelopes 4.10: Rotation eines Koordinatensystems 4.11: Transformation betrachtet im globalen Koordinatensystem 4.12: Transformation betrachtet im lokalen Koordinatensystem 4.13: Der rechte Oberarm mit inverser Rotation des Torsos 4.14: Gelenke, deren Ausrichtung von Nite berechnet wird 5.1: Blender Logic Editor 5.2: Ansicht Viewport (links), gerenderte Ansicht (rechts) 5.3: Implementierung Szene Auswahl 5.4: Ausschnitt Einzelansicht 5.5: Implementierung Szene Einzelansicht 5.6: Font Map ariblk.tga (Quelle: blender.freemovies.co.uk) 4 4 4 5 6 7 8 8 9 10 11 12 14 14 14 15 16 22 24 26 26 27 27 28 28 30 31 31 32 33 34 37 38 39 41 41
vi
6.1: BVH Datei Hierarchie Darstellung 6.2: BVH Datei Bewegungsdaten 6.3: Blender Viewport mit Keyframe Men 6.4: Blender Timeline Editor 6.5: Blender Graph Editor 6.6: Blender Dope Sheet Editor 6.7: Blender NLA Editor 7.1: Darstellung der Rumpfdrehung, -neigung und Reichweite (Quelle: IAD)
44 44 45 45 46 47 47 49
vii
Tabellenverzeichnis
1.1: Auszug aus der Anforderungsliste. F = Forderung, W = Wunsch 3.1: Technische Daten Kinect (Quelle: openkinect.org) 4.1: bersicht Production Nodes 4.2: Standard Typetags 5.1: Statistik Krpergren 7.1: Erkennung Krperstellung 2 8 17 20 36 50
viii
1. Motivation und Aufgabenstellung

Das Institut fr Arbeitswissenschaft (IAD) der Technischen Universitt Darmstadt ist im Rahmen des Kooperationsprogramm zu normativem Management von Belastungen und Risiken bei krperlicher Arbeit (KoBRA) zustndig fr die Durchfhrung der Ergonomiebewertung der Arbeitspltze. In der industriellen Fertigung kommt es hufig zu Fllen von Arbeitsunfhigkeit auf Grund von Muskel- oder Skeletterkrankung. Die Ursache hierfr ist in den meisten Fllen ein nicht ergonomisch gestalteter Arbeitsplatz. Um solche Arbeitsausflle zu vermeiden, muss schon bei der Planung von Fertigungslinien darauf geachtet werden, den Arbeiter nicht zu Krperhaltungen zu zwingen, die auf Dauer oder bei hufiger Ausfhrung Muskel-Skelett-Erkrankungen hervorrufen knnen. Am IAD wurde ein Bewertungsverfahren namens EAWS entwickelt, welches eine Kennzahl fr die Ergonomie des Montagearbeitsplatzes liefert. Hierfr sind Bewertungsbgen ntig auf denen typische Krperhaltungen aufgelistet sind, um deren Dauer und Auftreten zu vermerken. Des Weiteren spielen die zu bewegenden Lasten eine Rolle sowie die Stellungen einzelner Krperglieder. Das Ausfllen des Bewertungsbogens geschieht von speziell fr diese Aufgabe geschultem Personal. Die Tatsache, dass die Datenerhebung nach Augenma geschieht, sorgt fr eine Erhebungsunsicherheit, welche vor allem bei langzyklischen Ttigkeiten durch eine automatisierte Datenaufnahme erheblich vermindert werden knnte. Ein erster Ansatz fr ein preisgnstiges Verfahren sieht ein computergesttztes Erfassen der Bewegung mittels der 3D Kamera Kinect von Microsoft vor. Mit der Kinect erffnet sich fr private Entwickler und kleine Unternehmen der Zugang zu einer bisher sehr teuren Technologie, dem Erzeugen von Tiefenbildern. Dadurch bildete sich eine weltweite Interessengemeinschaft, welche Software entwickelt und verbreitet, mit der beispielsweise die Kinect-Daten benutzt werden, um eine Gestenerkennung zu realisieren. Ziel dieser Arbeit ist es, mit der Kinect Skelettdaten eines Benutzers zu erzeugen und diese mit der Animationssoftware Blender zu koppeln, um die Skelettdaten auf ein digitales Menschmodell zu bertragen. Das entwickelte Konzept soll in einem Demonstrator realisiert werden, welcher auf einer grafischen Oberflche die Bewegung des Benutzers anhand eines Menschmodells in Echtzeit darstellt. Die Lsung soll nicht auf ein bestimmtes Betriebssystem beschrnkt sein, sondern plattformunabhngig funktionieren. Im Rahmen der Arbeit sollen auerdem die Animationsfunktionen von Blender untersucht und ein Konzept erarbeitet werden, welches beschreibt, wie mit den digitalen Skelettdaten des Modells eine haltungsbasierte Ergonomie Bewertung realisiert werden kann. Somit soll eine Grundlage geschaffen werden, um in folgenden Arbeiten die Datenerhebung fr die Ergonomie Bewertung zu ermglichen und den Einstieg in die Thematik zu erleichtern.
TU Darmstadt IAD | Adrian Eissfeldt | 2012
2. Anforderungen
Das Ergebnis dieser Arbeit wird in der Demonstrator-Anwendung prsentiert, weswegen sich die Anforderungen an das zu entwickelnde Gesamtsystems auf die Details des Demonstrators konzentrieren. Im Demonstrator sollen sechs verschiedene Menschmodelle zur Auswahl stehen (drei mnnliche und drei weibliche), deren Krpergren den Durchschnittswerten verschiedener Bevlkerungsgruppen entsprechen. Wird das ausgewhlte Modell entsprechend der Userbewegung animiert, soll es mglich sein die Bewegung aufzuzeichnen, zu speichern und wieder abzuspielen. Fr die Rekonstruktion der Userbewegung wird gefordert, dass die Krperhaltung des Rumpfs und der Extremitten dargestellt wird. Bewegt sich der User im Raum, wird gewnscht, dass das Modell ebenfalls seine Position ndert. Das Darstellen der User-Bewegung anhand des Modells ist in Echtzeit gewnscht, jedoch nicht gefordert. Mit Echtzeit ist eine Datenverarbeitung gemeint, welche empfangene Skelettdaten direkt auf das Modell anwendet, bevor neue Daten empfangen werden. Die genannten Anforderungen sind in Tabelle 1.1 zusammengefasst, die vollstndige Anforderungsliste befindet sich in Anhang a.
Tabelle 1.1: Auszug aus der Anforderungsliste. F = Forderung, W = Wunsch
F/W Anforderung
Wert
Bemerkung - 3 mnnliche, 3 weibliche
Auswahl Krperbautypen
6 Modelle
- Krpergre entsprechend den Durchschnittswerten verschiedener Bevlkerungsgruppen - Aufnehmen und Speichern von
Funktion Aufnehmen
Bewegungen innerhalb einer flexiblen Zeitspanne
F F
Funktion Wiedergeben Rekonstruktion Krperhaltung
Extremitten, Rumpf -
- Gespeicherte Sequenz wiedergeben
Rekonstruktion Krperposition
- Position des Modells entsprechend der Positionsnderung des Users ndern - Das Modell wird nach jedem empfangenen Frame neu ausgerichtet
Verarbeitung in Echtzeit
3. Stand der Technik

Zur Gestaltung eines computergesttzten Ergonomie Bewertungsverfahrens und eines Demonstrators werden folgende Komponenten als Mindestvoraussetzung bentigt: Bewegungserfassung (Motion Capture): Erfasst die Krperhaltung/Bewegung eines Users und wandelt sie in digitale Daten, anhand derer dessen Bewegung rekonstruiert werden kann. Die Daten einer Motion Capture-Aufnahme beschreiben zu diskreten Zeitpunkten die Position und Identitt definierter Punkte eines Krpers. Zum Speichern und Austauschen von Motion Capture-Daten hat sich das Biovision Hierarchy Format etabliert, welches in Kapitel 6.1 nher beschrieben wird. Digitales Menschmodell: Modell um einen Menschen grafisch dreidimensional darzustellen und mit einem Skelett dessen Freiheitsgrade zu definieren. Fr die grafische Beschreibung wird ein Polygonnetz verwendet, welches die Form eines menschlichen Krpers hat. Da mit der Polygonanzahl die zum Rendern ntige Rechenleistung steigt, wird fr Echtzeit-Anwendungen meist ein Low PolyModell verwendet, bei dem mit mglichst wenigen Polygonen eine menschliche Form dargestellt wird. Um die Haltung des Modells zu ndern, muss nur die Haltung dessen Skeletts verndert werden, da die Bewegung der Knochen die zugeordneten Polygone mitbewegt. Animationsumgebung: Ntig, um die Daten des Motion Capturing mit dem digitalen Menschmodell zu verknpfen und diese fr eine grafische Ausgabe zu rendern. Im Folgenden werden die recherchierten Komponenten bzw. Systeme vorgestellt, die entweder zur Verwendung in dieser Arbeit infrage kommen oder Informationen bieten, die fr das Verstndnis der Thematik oder den Ausblick hilfreich sind.
3.1. CUELA
CUELA (Computer untersttze Erfassung und Langzeitanalyse von Belastungen des Muskel-SkelettSystems) ist ein Komplettsystem zur Belastungsanalyse von Arbeitspltzen. Es besteht aus Sensoren, einer batteriebetriebenen Datenspeichereinheit und einer Software zum Auswerten der Daten. Beschleunigungssensoren und Potentiometer werden am Probanden befestigt (siehe Abbildung 3.1), um die Bewegung von Rcken und Beinen zu erfassen. In den Schuhen des Probanden werden Einlagen platziert, welche mit 24 Drucksensoren ausgestattet sind, um die Bodenreaktionskrfte zu messen. Die Sensordaten knnen mit der Software des Systems sowohl zeitlich aktuell grafisch dargestellt werden als auch deren Verlauf ber die Zeit, anhand eines Graphen. Das Abspielen einer Videoaufzeichnung der Datenaufnahme lsst sich mit der Darstellung der Daten synchronisieren, was einen guten berblick ber die zugrunde liegende Situation gewhrleistet (siehe Abbildung 3.2).
Abbildung 3.1 (links): Proband ausgestattet mit Sensoren und Datenspeichereinheit Abbildung 3.2 (rechts): Screenshot der Auswertesoftware (Quelle: Berufsgenossenschaftliches Institut fr Arbeitsschutz)
3.2. Optisches Motion Capture mit Markern

Bei dem auf optischen Markern basierenden Verfahren wird die Bewegung einzelner Marker, welche an der zu erfassenden Person angebracht sind, mit mehreren Kameras gefilmt. Die Kamerasignale werden von einem Computer verarbeitet, um in jedem Bild der Videos die Marker zu identifizieren.
Abbildung 3.3: Optisches Motion Capture mit passiven Markern (Quelle: Aueragsakul)
Um saubere Daten zu erzeugen, mssen die Marker in jedem Frame der Videoaufnahme erkannt werden. Ist dies nicht der Fall, ist ein aufwendiges manuelles Nachbearbeiten erforderlich, da in jedem Frame die Position des Markers angegeben werden muss. Zur Auswahl stehen zum einen aktive Marker, die meist eine LED beinhalten, welche im Pulsbetrieb angesteuert wird, um den Marker anhand der Pulsfrequenz von anderen Lichtquellen und Markern zu unterscheiden. Zum anderen bieten sich passive Marker an. Diese haben eine reflektierende Oberflche und werden mit infrarotem (IR) Licht von den Kameras ausgeleuchtet. Jedoch funktioniert dieses Verfahren nur, solange das Objekt selbst nicht stark reflektierend ist (vgl. Schwarze Anzge in Abbildung 3.3). Ein Marker muss von mindestens zwei Kameras gleichzeitig erfasst werden, damit seine Position im Raum mittels optischer Triangulation berechnet werden kann. Ist die Position im Raum bekannt, lsst sich in Verbindung mit der Information, an welcher Stelle des Krpers der Marker sitzt, die Bewegung der erfassten Person rekonstruieren. Abbildung 3.4 verdeutlicht das Prinzip der Tiefenmessung mit optischer Triangulation. Durch die berlagerung zweier Kamerabilder aus unterschiedlichen Perspektiven, lsst sich der Abstand eines Objekts zur Kamera berechnen, indem die unterschiedliche Position des Objekts in den Bildern gemessen wird.
Abbildung 3.4: Tiefenmessung mit optischer Triangulation
Da typischer Weise die Bewegung des kompletten Krpers erfasst werden soll, mssen auch gleichzeitig mehrere Marker erkannt werden. Bei der Verwendung von passiven Markern kann dabei das Problem auftreten, dass sich Marker aus einer bestimmten Perspektive berlagern und ab diesem Zeitpunkt die Software nicht mehr nachvollziehen kann, welchem Krperteil welcher Marker zugeordnet ist. Dies fhrt dazu, dass eine manuelle Nachbearbeitung der Daten notwendig ist. Mit aktiven Markern lsst sich dieses Problem jedoch umgehen, da die Marker anhand ihrer Pulsfrequenz erkannt und zugeordnet werden knnen (Metamotion.com).
3.3. Kinect
Fr ein optisches Motion Capturing ohne Marker stehen verschiedene Hard- und Softwarekomponenten zur Verfgung, die zu einem System kombiniert werden knnen. Die bekannteste Hardware hierfr liefert Microsoft mit der 3D-Kamera Kinect (in vielen Artikeln als Project Natal bezeichnet, dem Namen zur Entwicklungszeit). Entwickelt wurde die Kinect zum Einsatz als Controller fr die Spielkonsole Xbox360. Die Kamera erzeugt ein Farbbild und eine Tiefen Map (jedem Pixel ist ein Tiefenwert zugeordnet). Diese Daten schickt sie der Konsole ber die USB-Schnittstelle. Da das RGB-Bild und das Tiefenbild aus leicht unterschiedlichen Perspektiven aufgenommen werden, sind die zugrunde liegenden Positionen der Pixel der beiden Maps nicht zwangslufig identisch. Entgegen vielen falschen Darstellungen in Blogs und Artikeln findet die weitere Informationsverarbeitung, die es ermglicht Personen und deren Krperhaltung zu identifizieren, in der Konsole statt und nicht bereits in der Kinect (Elliott, 2010). Auf Grund des vergleichbar geringen Preises fr einen Tiefensensor (Einfhrungspreis der Kinect circa 150 Euro) fand das Gert sehr groen Anklang unter Wissenschaftlern, Knstlern und Hobbyentwicklern. Als Folge davon brachte Microsoft eine Kinect-Entwicklungsumgebung (vgl. Kapitel 3.5) sowie eine neue Version der Kamera unter dem Namen Kinect fr Windows heraus. Der wesentliche Unterschied liegt hier in dem Mindestabstand zur Tiefenbilderzeugung von 40 cm im Near Mode, whrend beim Vorgngermodell ca. 1,2 m Abstand eingehalten werden musste.
Abbildung 3.5: Kinect (verndert nach: amazon.de)
Zur Erzeugung des Tiefenbilds wird in der Kinect eine von der Firma PrimeSense entwickelte und patentierte Technologie verbaut (vgl. Freedman et al., 2010), die nach dem Prinzip des Structured Light arbeitet. Auch hier kursieren viele falsche Darstellungen in Artikeln, welche behaupten das Gerte messe die Zeit bis ausgesendetes Licht wieder empfangen werde. Zur Oberflchenvermessung mittels Structured Light wird ein definiertes Lichtmuster ausgesendet und anhand der Verformung, die eintritt, wenn das Muster auf ein unebenes Objekt trifft (siehe Abbildung 3.6), die rumliche Geometrie rekonstruiert.
Abbildung 3.6: Strukturiertes Licht trifft auf ein Gesicht (Quelle: wikipedia.org)
Bei der von PrimeSense entwickelten Verwendung dieses Verfahrens sendet ein 60mW starker 830nmInfrarotlaser eine Struktur von Punkten in den Raum. Ein CMOS-Bildsensor mit Infrarotfilter nimmt die abgebildete Struktur auf und vergleicht sie mit der bekannten ausgesendeten Struktur. Da der IR-Projektor und die IR-Kamera leicht versetzt angeordnet sind (siehe Abbildung 3.5) ergeben sich zwei Perspektiven auf das Muster (Perspektive 1 muss nicht gemessen werden, da das ausgesendete Muster bekannt ist, Perspektive 2 wird mit der IR-Kamera gemessen). Anhand der Verschiebung zwischen gesendeter und empfangener Position eines Punktes lsst sich mit optischer Triangulation der Tiefenwert berechnen. Zur Lsung des Korrespondenzproblems (welchem gesendeten Punkt entspricht der gemessene Punkt) wird eine pseudozufllige Struktur der Punkte erzeugt, wodurch sich ein Punkt durch Betrachtung der benachbarten Punkte identifizieren lsst (siehe Abbildung 3.7 und 3.8). Zur Erzeugung eines Farbbilds befindet sich ein RGB-Bild-Sensor in dem Gert.
Abbildung 1.7 (links): IR Muster trifft auf eine Person (Quelle: Penven) Abbildung 3.8 (rechts): Pseudozufllige Struktur von Punkten (Quelle: creativeapplications.net)
Des Weiteren beherbergt die Kinect ein Mikrofonarray, bestehend aus vier Mikrofonen, zum Empfangen und Orten von Audiosignalen und zum Filtern der Umgebungsgerusche. Ein Motor im Standfu kann die vertikale Ausrichtung des Gerts ndern und ein Beschleunigungssensor die Ausrichtung messen. Da der Motor ber die USB-Schnittstelle nicht ausreichend mit Strom versorgt werden kann, ist ein Netzteil notwendig. Die wichtigsten technischen Daten sind in Tabelle 3.1 aufgefhrt.
Tabelle 3.1: Technische Daten Kinect (Quelle: openkinect.org)
Tiefenbild Messbereich
11 Bit-Tiefenauflsung, 320 x 240 Pixel 30 fps 1,2 m bis 3,5m Je nach Konfiguration
Farbbild
640 x 480 Pixel bei 30 fps oder 1280 x 1024 Pixel bei 15 fps
Audio
16 Bit 16 kHz
Um
Motion-Capture-Daten
zu
erzeugen,
mssen
die
Daten
der
Kinect
von
einer
externen
Informationsverarbeitung jedoch noch richtig interpretiert werden.
3.4. Asus Xtion Pro Live

Dieses Gert hnelt sehr stark der Kinect, da es ebenfalls die Technologie von PrimeSense beherbergt. Mit dem simpel gestalteten Design lsst es sich leichter an spezielle Aufbauten montieren, als die Kinect (siehe
TU Darmstadt IAD | Adrian Eissfeldt | 2012 8
Abbildung 3.9). Es beinhaltet ebenfalls einen Infrarot-Tiefensensor, einen Farbbildsensor und ein Mikrofonarray, jedoch keinen Motor zur Ausrichtung, wodurch eine zustzliche Stromversorgung zur USBVerbindung entfllt. Die wesentlichen Unterschiede betreffen neben den kleineren Abmessungen die Auflsung. So werden beim Tiefenbild wahlweise entweder bei 30 fps 640x480 Pixel oder bei 60 fps 320x240 Pixel aufgelst. Die Auflsung des RGB-Bilds betrgt 1280x1024 Pixel und die Tiefe wird von 0,8m bis 3,5m Abstand gemessen. Der Preis betrgt circa 200 Euro (Stand Frhjahr 2012).
Abbildung 3.9: Vergleich Kinect und Xtion Pro Live (Quelle: iheartrobotics.com)
3.5. Kinect SDK

Vor Verkaufsstart (November 2010) der Kinect rief das Unternehmen Adafruit einen Wettbewerb aus, in dem es ein Preisgeld von 3000 US-Dollar demjenigen versprach, dem es gelingt als erstes einen Open-SourceTreiber zu programmieren, der die Daten der Kinect fr den PC zugnglich macht (Schindler, 2010). Nach knapp einer Woche wurde der erste Treiber fr Linux auf der Social-Coding-Seite Github verffentlich (heise.de, 2010). Microsoft wehrte sich anfangs zwar gegen das Modifizieren der Kinect und drohte mit Konsequenzen, nderte dann jedoch seinen Standpunkt und kndigte an, ein eigenes kostenloses Software Development Kit (SDK) zu verffentlichen, um Entwicklungen mit der Kinect unter Windows zu untersttzen. Im Juni 2011 erschien dieses SDK als Beta-Version zum freien Download, Anfang 2012 als Release-Version, mit der auch die kommerzielle Verwendung mglich ist. Es bietet Audio-ProcessingFunktionen zur Rausch- und Echounterdrckung sowie zur Lokalisierung von Audiosignalen, SkelettTracking von bis zu zwei Personen gleichzeitig anhand von 20 Gelenkpunkten (siehe Abbildung 3.10) und Rohdaten-Zugriff. Zur Programmierung stehen die Sprachen C++, C# und Visual Basic zur Auswahl. Gleichzeitig knnen die Daten von vier Kinect-Gerten verarbeitet werden.
Abbildung 3.10: Identifizierbare Gelenke mittels Microsoft SDK (Quelle: Taylor)
Um Algorithmen zu schaffen, die aus rohen Pixeldaten in Echtzeit Koordinaten von Gelenken bestimmen, benutzt Microsoft maschinelles Lernen (Duffy, 2010). Dafr wurden in vielen Lndern die Bewegungen von Menschen aufgezeichnet und nachbearbeitet, um die verschiedenen Krperregionen in jedem Frame zu markieren. Beim maschinellen Lernen werden diese Daten von Grorechnern analysiert und Statistiken erstellt, die beschreiben, mit welcher Wahrscheinlichkeit ein Bild einer bestimmten Krperhaltung entspricht. Diese Statistiken sind in den Algorithmen implementiert, die auf einer Xbox360 ausgefhrt werden, um Skelettdaten des Benutzers zu erzeugen. Da die Qualitt der Skeletterkennung des SDKs gleichwertig zu der Erkennung auf der Konsole ist (microsoft.com, o. J.), lsst sich annehmen, dass das SDK dieselben Algorithmen verwendet. Da dieses SDK an das Betriebssystem Windows gebunden ist und somit nicht die Voraussetzung erfllt Plattform-unabhngig zu sein, findet es in dieser Arbeit keine Verwendung.
3.6. OpenNI Framework

Die Firma PrimeSense grndete im November 2010 zusammen mit den Firmen Willow Garage (Robotik), Side Kick (Entwicklung bewegungsbasierter Spiele) und Asus (Computer-Hardware) die Nonprofit Organisation Open Natural Interaction (OpenNI). Ziel der Organisation ist es, die Entwicklung auf dem Gebiet der natrlichen Interaktion zwischen Mensch und Maschine zu beschleunigen. Mit natrlicher Interaktion bezieht sich PrimeSense auf technische Eingabemglichkeiten, die den Sinnen des Menschen entsprechen, Hauptfokus ist die Sprach- und Gestensteuerung (openni.org, o. J.). OpenNI verffentlichte die ersten offiziellen Treiber fr die Kinect und unter dem gleichen Namen der Organisation ein Framework, das Funktionen zur natrlichen Interaktion bereitstellt. Das Framework ist kostenlos verfgbar und der Sourcecode ist ffentlich. Es werden die Betriebsysteme Windows, Mac und
10
Ubuntu untersttzt. Es stellt Programmierschnittstellen (APIs - Application Programming Interface) zwischen Anwendungen zur Verfgung, die mittels natrlicher Interaktion bedient werden sollen, und Sensoren, wie Kameras und Mikrofonen, welche die notwendigen Rohdaten zur Verfgung stellen (siehe Abbildung 3.11). Zustzlich lsst sich Middleware einbinden, wodurch fremde Software den Funktionsumfang erweitert ohne dabei die Komplexitt stark zu steigern. Somit lassen sich Softwaremodule verwenden, die Daten einer niedrigen Ebene (z.B. Rohdaten einer Kamera) entgegennehmen, High-level Dienste ausfhren (z.B. Gestenerkenung) und neue Daten (z.B. Geste x erkannt) einer hheren Ebene zur Verfgung stellen.
Abbildung 3.11: Konzept von OpenNI (Quelle: openni.org)
Die API bedient sich der Sprache C, stellt aber verschiedene Wrapper (bersetzer in eine andere Programmiersprache) zur Verfgung, sodass sie auch mit den Sprachen C++, C# und Java verwendbar ist.
3.7. Nite
PrimeSense stellt die Middleware Nite zur Verfgung. Nite ist ebenfalls kostenlos verfgbar, jedoch ist der Sourcecode nicht ffentlich. Die Middleware bietet Funktionen zur Handgestenerkennung, Handverfolgung, Benutzerunterscheidung und Skeletterkennung. Handgesten und Handverfolgung Damit die Software eine Hand als solche erkennt, mssen die Finger gespreizt sein und die Handflche zum Sensor zeigen. Wird eine Hand identifiziert, so lsst sich auf bestimmte Handgesten reagieren und kontinuierlich die Position abfragen.
11
Vordefinierte Handgesten sind: Click: Eine Bewegung, bei der sich die Hand mindestens 20 cm auf den Sensor zu und wieder weg bewegt Wave: Eine Wink Bewegung bestehend aus mindestens 5 horizontalen Bewegungen Swipe left und Swipe right: Eine Wischbewegung in entsprechende Richtung Raise hand candidate: Registriert das Heben einer Hand Hand candidate moved: Registriert das Bewegen einer Hand
Mithilfe der vordefinierten Gesten lsst sich der Fokus auf eine bestimmte Hand legen, um dann gegebenenfalls nur deren Position fr eine Steuerung zu verwenden. Jedoch werden lediglich die Gesten Click und Wave hierfr empfohlen, da die Erkennung der anderen Gesten eine hohe Fehlerrate aufweist (PrimeSense, 2011). Benutzersegmentierung Bei der Benutzersegmentierung werden Benutzer im Sichtfeld einer 3D-Kamera identifiziert. Jedem Benutzer wird eine Zahl zur Beschreibung dessen Identitt (ID) zugeteilt. In einer Label Map ist jedem Pixel eine der zuvor verteilten IDs zugewiesen. Diese Label Map ist notwendig fr die Skelett-Tracking Algorithmen. Skeletterkennung Das von Nite beschriebene Skelett einer Person besitzt 15 Gelenke (siehe Abbildung 3.12). Seit Version 1.5 ist keine Kalibrierungspose mehr ntig, whrend bei frheren Versionen der Benutzer die Psi-Pose (aufrechte Haltung, die Arme bilden ein U) fr wenige Sekunden einnehmen musste, bevor der Trackingvorgang starten konnte. Die Koordinaten der Gelenkposition sowie deren Rotationsmatrizen beziehen sich auf den globalen Raum. Da der Erkennungsalgorithmus eine Rotation der Hand und Fugelenke nicht erfasst, wird sie gleich der Rotation des zugehrigen Ellbogens bzw. Knies gesetzt. Das Skelett, welches von der Software errechnet wird ist nicht fix, sondern kann in den Abmessungen, also den Abstnden zwischen den Gelenken, whrend eines Trackingprozesses variieren. ber die Methode, mit der die Algorithmen arbeiten um eine Skeletterkennung zu ermglichen, lsst sich keine Aussage treffen, da PrimeSense hierzu keine Informationen verffentlicht.
12
Abbildung 3.12: Mit Nite identifizierbare Gelenke
Zu jeder Angabe eines Gelenkpunktes wird auch ein Confidence Wert geliefert. Dieser nimmt einen Wert zwischen 1 und 0 an, wobei bei 1 das Ergebnis verlsslich ist, und bei 0 der Trackingvorgang nicht erfolgreich war und die Koordinaten wahrscheinlich falsch sind. Um nicht aufgrund einer schlechten Erkennung (Confidence Wert = 0) flschlich ein Umherspringen der Gelenke zu beschreiben, verwendet Nite seit Version 1.4 fr diesen Fall heuristische Methoden um Koordinaten zu liefern. Der Confidence Wert ist in dem Fall 0.5 und die Extremitten werden in Richtung des Bodens ausgerichtet. Die heuristische Methode wird nur ausgefhrt, wenn die Berechnung beider Gelenke einer Extremitt (z.B. Hand und Ellbogen) fehlschlug und lsst sich auch abschalten (PrimeSense, 2011).
3.8. Blender
Blender ist ein kostenloses 3D-Grafikprogramm. Der Quellcode ist frei verfgbar und es wird kontinuierlich weiter entwickelt. Ursprnglich entwickelte es das niederlndische Animationsstudio NeoGeo. Da vergleichbare Software damals mehrere Tausend US-Dollar kostete, kam der Chefentwickler von NeoGeo Ton Roosendaal auf die Idee, Blender kostenlos zur Verfgung zu stellen, um normale Computernutzer und Knstler zu erreichen. Diesen sollten Dienstleistungen und kommerzielle Produkte rund um Blender angeboten werden. Hierfr grndete er 1998 eigens die Firma Not a Number (NaN), die jedoch drei Jahre spter Insolvenz meldete. Um Blender weiter am Leben zu erhalten, grndete Roosendaal die Blender Foundation und sammelte Spenden, da die Investoren von NaN sich bereit erklrten, die Lizenzen an Blender fr 100.000 Euro frei zu geben. Dies gelang innerhalb kurzer Zeit und so wurde Blender 2002 als Open Source Projekt verffentlicht (Blendercommunity, 2009). Blender umfasst vielfltige Funktionen zum Modellieren und Texturieren von Objekten, sowie zum Animieren und Rendern. Mit der integrierten Game-Engine lassen sich Spiele entwickeln und Echtzeitanimationen erstellen. Die Skriptsprache Python ermglicht dem Benutzer die Funktionspalette zu erweitern.
13
Die Oberflche wird in einem einzigen Fenster dargestellt, welches sich in beliebig viele weitere Fenster unterteilen lsst. Dadurch ist es nicht mglich, dass Fenster sich gegenseitig verdecken. In jedem Fenster lsst sich auswhlen, welcher Editor angezeigt wird. So lsst sich beispielsweise ein Objekt gleichzeitig aus verschiedenen Perspektiven anzeigen, um eine einfache Bearbeitung zu ermglichen. Abbildung 3.13 zeigt den Viewport, in dem Objekte grafisch angezeigt und bearbeitet werden. Der Outliner (siehe Abbildung 3.14) zeigt eine bersicht ber alle Objekte eines Projekts und deren Hierarchie.
Abbildung 3.13 (links): Blender Viewport Abbildung 3.14 (rechts): Blender Outliner
Im Properties-Fenster lassen sich alle Eigenschaften eines Objekts ndern. Die Registerkarten nehmen eine Einteilung in Kategorien wie Render-Einstellungen, Material, Textur und physikalische Parameter vor (siehe Abbildung 3.15).
Abbildung 3.15: Blender Properties
Es stehen weitere Editoren zur Auswahl, die jedoch sehr anwendungsspezifisch sind. Im Laufe des Berichts werden die relevanten Funktionen nher erlutert. Verwendet wird dabei die Version 2.62.
3.9. MakeHuman
MakeHuman ist eine Open Source Software zur Erstellung digitaler Menschmodelle, um diese auerhalb von MakeHuman in einer 3D-Animationsumgebung zu verwenden. Die Software existiert bisher nur als AlphaVersion, es ist also noch nicht der volle Funktionsumfang enthalten und es knnen Fehler auftreten. Jede
14
Nacht wird eine Version kompiliert, welche die aktuellsten Entwicklungen beinhaltet und als Nightly Build ebenfalls zum kostenlosen Download angeboten. Verwendbar ist MakeHuman unter den gngigen Betriebssystemen. Das fertige Modell lsst sich in verschiedene Dateiformate exportieren: Wavefront obj Blender exchange mhx Collada dae Doom 3 md5
Der Fokus der Software liegt bei einem intuitiven Umgang zum schnellen Kreieren eines eigenen Modells. Ein komplettes Modell umfasst: Krper in Form eines Polygonnetzes (ausschlielich Vierecke) Skelett: Lsst den Krper anhand der Ausrichtung des Skeletts verformen. Textur Kleidung Haare
Abbildung 3.16: MakeHuman Screenshot
Es existiert ein einziges geschlechtsneutrales Grundmodell, welches durch die zahlreichen Funktionen verformt wird (siehe Abbildung 3.16). Um das Grundmodell grob den eigenen Wnschen anzupassen, lassen sich ber Regler Eigenschaften wie Geschlecht, Ethnie, Alter, Muskeldefinition, Hhe und Gewicht einstellen. Detailliertere Wnsche wie Abmessungen einzelner Gliedmae und die Proportionen des Gesichts knnen ebenfalls eingestellt werden. Damit der erzeugte Mensch nicht zu knstlich aussieht, lassen sich auch Asymmetrien fr Krper und Gesicht erzeugen. Fr beispielsweise Spiel-Anwendungen stehen verschiedene Low Poly Proxies zur Verfgung, also Modelle, die eine geringere Polygonanzahl als das Original aufweisen.
15
4. Konzeption zur Verarbeitung der Kinect-Daten
Abbildung 4.1: Unterteilung Gesamtkonzept
Abbildung 4.1 veranschaulicht die drei wesentlichen Teile des zu erarbeitenden Gesamtkonzepts: 1. Schnittstelle Kinect Blender Die Kinect erzeugt ein dreidimensionales Bild, welches analysiert werden muss, um die Krperhaltung eines Benutzers zu identifizieren. Die erzeugten Daten mssen anschlieend an die Animationsumgebung Blender bergeben werden.
2. bertragung der Skelettdaten auf ein digitales Menschmodell Die Skelettdaten des Benutzers mssen mit einem digitalen Menschmodell verknpft werden, damit dieses Modell die Krperhaltung des Benutzers widerspiegelt.
3. Demonstrator Der Demonstrator ist eine Anwendung mit grafischer Oberflche, in der die Lsungen der beiden vorherigen Punkte implementiert sind. Die Bewegung eines Benutzers wird mit einem digitalen Menschmodell wiedergeben. Es lassen sich verschiedene Modelle dafr auswhlen und deren Bewegungen aufzeichnen und wiedergeben.
4.1. Schnittstelle Kinect Blender

Um Blender Skelettdaten zur Verfgung zu stellen, mssen diese im ersten Schritt anhand der Kinect Daten berechnet werden. Hierfr wird die API OpenNI verwendet werden, da diese API als einzige plattformunabhngig die notwendigen Funktionen bereitstellt.
16
OpenNI benutzt ein Softwarekonzept, welches Production Nodes definiert und diese zu einem Production Graph verknpft. Jeder Production Node hat spezielle Aufgaben (siehe Tabelle 4.1) um Daten zu verarbeiten bzw. zu erstellen, die er dem nchsten Production Node zur Verfgung stellt. Der letzte Production Node eines Production Graphs ist die Schnittstelle zur Anwendung, da hier Callback Funktionen bergeben werden, um auf Ereignisse zu reagieren oder Daten direkt ausgelesen werden. Production Nodes die in Abhngigkeit eines anderen Production Nodes stehen, da sie dessen Ausgangsdaten als Eingabe brauchen, bilden mit diesen eine Production Chain. Dieses Konzept gewhrt groe Flexibilitt, whrend es leicht zu verwenden ist. So lsst sich problemlos stets neue Middleware einbinden, ohne dabei einen Einfluss auf das bestehende Programmierkonzept einer mit der API erstellten Anwendung zu haben. Dies funktioniert natrlich nur solange die Middleware die Funktionen eines entsprechenden Production Nodes beinhaltet. Um ein Skelett-Tracking zu realisieren, wird ein User Generator verwendet. Dieser bietet alle Daten der aktuellen User, wie Skelettdaten, und die zu jedem User zugehrigen Pixel. Als Grundlage fr seine Berechnungen bentigt der User Generator ein 3D-Bild, welches der Depth Generator bereitstellt. Der Depth Generator muss bevor er Daten von einer 3D-Kamera ausliest diese erst konfigurieren, wofr der Production Node Device zustndig ist. Soll ein solches System implementiert werden, muss dafr nicht jeder Knoten einzeln explizit erstellt werden, sondern nur der letzte in der Hierarchie. Zur Laufzeit werden alle angeschlossenen Gerte und installierte Middleware gescannt, um die ntigen Production Nodes zu erstellen. Falls es mehrere Implementierungen eines Nodes gibt, so ergeben sich mehrere mgliche Production Graphs, aus denen einer ausgewhlt werden muss. Sobald die Nodes aufgefordert werden Daten zu generieren, kann die eigentliche Anwendung starten. Die aktuell definierten Production Nodes sind in Tabelle 4.1 dargestellt:
Tabelle 4.1: bersicht Production Nodes
Production Node Sensor bezogen Device Depth Generator Image Generator IR Generator Audio Generator Middleware bezogen Gestures Alert
Beschreibung
Konfiguriert ein physisches Element Liefert Tiefenbild Liefert Farbbild Liefert Infrarot-Bild Liefert Audio-Stream
Erkennt spezifische Gesten
17
Generator Scene Analyzer Hand Point Generator User Generator Recording Funktionen Recorder Player Codec Ermglicht das Aufzeichnen von Daten Spielt aufgezeichnete Daten ab Komprimiert und dekomprimiert aufgezeichnete Daten Liefert eine Labeled DepthMap: Jedem Pixel ist ein Label zugeordnet, das beschreibt, ob es zur Bodenebene oder zu einer Person gehrt Ermglicht es eine Hand zu verfolgen und Handgesten zu erkennen. Reprsentiert die Daten die zu einem User gehren (z.B. Pixel, ID, Center of Mass)
4.1.1.
Skelettdaten zur Verfgung stellen
Zur Erzeugung der Skelettdaten soll wie zuvor beschrieben OpenNI benutzt werden. Die Funktionen lassen sich mit den Sprachen C, C++, Java und C# direkt verwenden. Die weitere Verarbeitung, welche in Blender stattfindet, lsst sich dort jedoch nur mit der Skriptsprache Python programmieren. Um ber die Skelettdaten in Blender zu verfgen sind zwei Anstze mglich: Verwendung der API OpenNI in Blender mittels eines Wrappers, der die Funktionen der API in Python bersetzt, um diese in einem Python Skript auszufhren Nebenlufiger Prozess, der die API in einer der untersttzten Sprache nutzt und die Daten durch Interprozesskommunikation Blender zur Verfgung stellt
Interprozesskommunikation ist ein berbegriff fr verschiedene Verfahren, die das Austauschen von Daten unterschiedlicher Prozesse ermglicht. Diese Verfahren sind notwendig, da jeder Prozess fr seinen Kontext einen eigenen Speicherbereich hat und vom Kernel aus Sicherheitsgrnden daran gehindert wird, Zugriffe auf Speicherbereiche auerhalb des eigenen zu ttigen. Gngige Verfahren der Interprozesskommunikation sind: Anonyme Pipes: Daten werden von einem Prozess in einen Puffer geschrieben, der von einem anderen Prozess ausgelesen werden kann. Zugriff haben nur verwandte Prozesse, also Prozesse selben Ursprungs. Benannte Pipes: Der Datenstrom kann unter allen Prozessen in einem Netzwerk stattfinden, die den Namen der Pipe kennen und autorisiert sind. Netzwerk Protokoll TCP (Transmission Control Protocol): Dieses Protokoll baut eine Verbindung zwischen einem Server und Client auf. Es garantiert ein zuverlssiges Senden und
18
Empfangen von Daten, da falls welche verloren gehen, sie erneut angefordert werden und auch die richtige Reihenfolge vom Protokoll sichergestellt wird. Dieser Mechanismus kann allerdings zu vergleichsweise hohen Latenzzeiten fhren (Kaiser, 2008). Netzwerk Protokoll UDP (User Datagram Protocol): Charakteristisch fr dieses Protokoll ist, dass keine Verbindung zwischen Server und Client explizit hergestellt wird. Es werden lediglich einzelne Datagramme an eine Netzwerkadresse geschickt oder verbindungslos empfangen. Zur Sicherstellung, dass Daten richtig empfangen werden, existiert kein Mechanismus, wodurch aber die Latenzzeiten konstant gering bleiben. Das Protokoll wird vor allem fr Multimedia-Anwendungen genutzt, da bei Audio- oder Videostreams geringe Latenzzeiten erwnscht sind und geringe bertragungsfehler toleriert werden knnen (Kaiser, 2008).
Die Recherche ergab, dass es bereits eine Open Source Software namens OSCeleton gibt, welche OpenNI verwendet, um mit einer Kinect Skelettdaten zu erzeugen und diese als UDP Nachricht ber ein Netzwerk verschickt. Das Format der UDP Nachrichten entspricht dem OSC (Open Sound Control) Protokoll, welches vor allem fr Echtzeitanwendungen im Multimediabereich verwendet wird. Dieses Programm soll in dieser Arbeit Verwendung finden. Die Grnde der Entscheidung dafr sind: Die Verwendung der Netzwerkkommunikation bietet eine groe Flexibilitt des zu entwickelnden Gesamstsystems. So kann beispielsweise die Kinect in einem anderen Raum platziert werden als der Demonstrator. Die Rechenleistung fr das Rendern des Demonstrators in Echtzeit und fr die Berechnung der Skelettdaten kann somit auf zwei Rechner aufgeteilt werden, wodurch Ressourcen fr sptere rechenintensive Optimierungen freigehalten werden. Die Tatsache, dass es durch die Verwendung von UDP keine Garantie zur erfolgreichen bermittlung der Daten gibt, fllt nicht stark ins Gewicht, da in einem Local Area Network (LAN) die Wahrscheinlichkeit fr bertragungsfehler sehr gering ist. Des Weiteren ist bei einer Echtzeitanwendung das erneute Verschicken eines nicht erhaltenen Datagramms nicht ntig, da nur ein zeitlich aktuelles Datagramm von Interesse ist. Da das Auftreten eines Fehlers sehr selten zu erwarten ist, lsst sich auch der zu erwartende Fehler fr eine Aufzeichnung und sptere Analyse von Bewegungsdaten als gering und tolerierbar einschtzen. Voraussetzung dafr ist jedoch ein Empfngersystem, das schnell genug die verschickten Daten verarbeitet, um einen synchronen Betrieb zu gewhrleisten. Es entfllt das unter Umstnden zeitaufwendige Programmieren einer eigenen Lsung, wodurch in dem zeitlich engen Rahmen dieser Arbeit ein grerer Fokus auf die folgenden Schritte mit spezifischeren Anforderungen gelegt werden kann.
19
Open Sound Control Protokoll Das Open Sound Control (OSC) Protokoll ist ein sehr flexibles nachrichtenbasiertes Protokoll, das hauptschlich zur Steuerung von Audiotechnik ber ein Netzwerk entwickelt wurde. Es ist unabhngig vom Transportprotokoll und beschreibt lediglich, wie die zu verschickenden Daten zu formatieren sind (vgl. UC Berkeley, o. J.). OSC-Message Das Grundelement einer OSC-bertragung ist eine OSC-Message, bestehend aus einer Zahl, welche die Anzahl der Bytes des Inhalts angibt, und dem eigentlichen Inhalt. Die Lnge des Inhalts ist immer ein Vielfaches von vier. Der Inhalt besteht aus: Adresse: Die Adresse ist ein String und hnelt der Beschreibung einer Ordnerstruktur. Ein Schrgstrich (/) kennzeichnet den Anfang und es knnen beliebig viele Knoten einer Adresse angegeben werden, jeweils getrennt durch einen Schrgstrich (Beispiel /Kanal1/Filter/Tiefpass). Typetag: Um den Datentyp der folgenden Bytes zu beschreiben, wird ein String mit Typetags verwendet. Er beginnt mit einem Komma gefolgt von jeweils einem Buchstaben, dem Typetag, fr jeden einzelnen Datentyp (Beispiel ,ifff fr einen Integer gefolgt von 3 Floats). Tabelle 4.2 zeigt eine bersicht ber die Standard Typetags. Sollte einer der Datentypen OSC-String oder OSC-Blob aufgrund des Inhalts nicht so viel Platz bentigen, dass die Lnge in Bytes ein Vielfaches von vier ist, so wird dies erzwungen in dem ein bis drei Null-Bytes hinzugefgt werden.
Tabelle 4.2: Standard Typetags
Typetag i f s
Datentyp Integer (Ganzzahl) 32 Bit (Zweierkomplement, Big-Endian) Float (Gleitkommazahl) 32 Bit (IEEE 754, Big-Endian) OSC-String: Ein Null-terminierter String (Zeichenkette), die Anzahl der Bytes ist ein Vielfaches von 4. OSC-Blob: Ein Blob (Binary Large Object) fr z.B. Bild- oder
Audiodateien besteht aus einem 32 Bit Integer und so vielen Bytes wie diese Zahl angibt.
Argumente: Eine Sequenz von Bytes die entsprechend den Typetags zu interpretieren sind.
OSC-Bundle Um mehrere OSC-Messages in einem Datagramm zu verschicken, mssen diese Teil eines OSC-Bundles sein. Ein Bundle beginnt mit dem String #bundle gefolgt von einem Timetag und einer variablen Anzahl von
20
OSC-Messages oder ebenfalls Bundles. Das Timetag ist eine 64 Bit Festkommazahl, welche dem Empfnger mitteilt, wann der gesendete Steuerbefehl ausgefhrt werden soll.
OSCeleton Wie zuvor kurz beschrieben handelt es sich bei OSCeleton um eine Open Source Software zur Berechnung von Skelettdaten, mittels der OpenNI API die als UDP Netzwerknachricht im OSC Format verschickt werden (vgl. Gonalves, o. J.). Der Sourcecode ist im Internet verffentlicht, ebenso wie kompilierte Versionen fr die Betriebsysteme Windows und Mac OS X. Die Konsolenanwendung stellt in Verbindung mit einer Kinect die Skelettdaten erkannter User zur Verfgung, in Form von Punktkoordinaten und Rotationsmatrizen bestimmter Gelenke im kartesischen Raum. Damit OSCeleton ausgefhrt werden kann, mssen Kinect Treiber, OpenNI und Nite zuvor installiert sein. Fr die Installation dieser Komponenten unter Windows wurde ein Installer des Unternehmens zigfu verwendet (zigfu.com , o. J.). Dieser installiert die Versionen OpenNI 1.5.2.7, Nite 1.5.2.7, Treiber 3.1.2.0 fr Kinect-Audio, Kamera und Motor. Wird das Programm normal gestartet (ohne Konsolenaufruf mit bergabe von Argumenten), werden nur Koordinaten (keine Rotationsmatrizen) an Port 7110 des Local Host geschickt. Es stehen verschiedene Parameter bei einem Konsolenaufruf zur Verfgung, um beispielsweise IP-Adresse und Port zu ndern Handtracking zu aktivieren Ausgabe der Rotationsmatrizen zu aktivieren Multiplikatoren und Offset-Werte fr die Koordinaten zu setzen.
Ruft man die Hilfe ber die Konsole auf, so werden alle Parameter angezeigt (siehe Abbildung 4.2). Um OSCeleton mit den fr diese Arbeit ntigen Parametern nicht von einer Konsole starten zu mssen, kann der Aufruf durch das Ausfhren einer cmd-Datei (unter Windows) erfolgen. Diese lsst sich mit einem Texteditor erstellen und beherbergt nur den Befehl zum Starten des Programms, zusammen mit dem Parameter -a, gefolgt von der IP-Adresse. an welche die Daten gesendet werden sollen, und -xt, um die Ausgabe von Rotationsmatrizen zu aktivieren. Beispiel: Die cmd-Datei befindet sich im selben Ordner wie OSCeleton und es soll an die Adresse 192.168.112 geschickt werden .\OSCeleton -a 192.168.178.112 xt. Das Programm ist in C++ geschrieben. Fr das Skelett-Tracking wird der Production Node User Generator verwendet. Wird ein User erkannt, ruft OSCeleton eine Funktion auf, um nach der Kalibrierungspose des Users zu suchen. Diese Kalibrierungspose ist seit der Nite Version 1.5 nicht mehr ntig, was aber kein Fehlverhalten verursacht, wenn diese Version verwendet wird. In diesem Fall ist die Aufforderung von der Konsole die Kalibrierungspose einzunehmen zu ignorieren.
21
Abbildung 4.2: OSCeleton Hilfe
Um die Daten in Blender zu empfangen, muss dort ein Python Skript ausgefhrt werden, welches einen UDP Server erstellt und die auf dem Server eingehenden Daten gem dem OSC Protokoll in eine leicht weiter zu verwendende Form bringt. Hierfr bot sich die Verwendung der C-Bibliothek liblo (vgl. Harris & Sinclair, o. J.), einer OSC Implementierung, in Verbindung mit dem Python Wrapper pyliblo (vgl. das.nasophon.de, o. J.) an. Fr die Verwendung der Bibliothek muss der Source Code selber kompiliert werden, was jedoch fehlschlug und auch mit der Email-Hilfe des Autors von pyliblo nicht erfolgversprechend war. Die ebenfalls potentielle Lsung python-osc (Python Implementierung von OSC in Form eines Moduls, vgl Coyner, o. J.) schien prinzipiell zu funktionieren, jedoch lieen sich damit nicht die Daten von OSCeleton erfolgreich empfangen. Aus diesen Grnden wird davon abgesehen eine Bibliothek zu verwenden, die dem OSC Standard entspricht, und stattdessen wird eine eigene Implementierung realisiert. Diese hat nicht den Anspruch den kompletten Umfang des OSC Protokolls zu beinhalten, sondern soll lediglich ausreichen um die Skelettdaten von OSCeleton verwenden zu knnen.
Das Skript mit den im Folgenden beschriebenen Inhalten befindet sich in der Blender Projektdatei Demonstrator unter dem Namen main.py. Empfangen der UDP Nachrichten Zum Erstellen eines UDP Servers in Python wird das Python Modul socket verwendet. Die Funktion recv() erstellt einen UDP Socket und gibt die empfangenen Daten zurck. import socket def recv():
22
Die eigene IP Adresse wird verwendet, wenn die Nachrichten von einem anderen Computer geschickt werden. Werden die Nachrichten vom selben Computer verschickt, nutzt man die Adresse des Local Host 127.0.0.1. UDP_IP = 192.168.178.112 UDP_PORT = 7110 Der Parameter SOCK_DGRAM gibt an, dass ein Datagram-Socket (UDP) erstellt werden soll. Mit AF_INET wird angeben, dass die IP Adresse entweder als Hostname oder IPv4 Adresse in Form eines Strings bergeben wird. sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.bind((UDP_IP,UDP_PORT)) Sobald der Socket mit recvfrom() aufgefordert wird, auf neuen Daten zu warten, wird erst dann der nachstehende Code ausgefhrt, wenn entweder ein Datagramm empfangen wurde oder die Timeout Zeit (in Sekunden) abgelaufen ist. Die Variable data beinhaltet das empfangene Datagramm in Form des Datentyps String. sock.settimeout(0.05) try: data, addr = sock.recvfrom(4096) sock.close() return data except socket.timeout: sock.close()
4.1.2.
Datenaufbereitung
Abbildung 4.3 zeigt den kompletten Inhalt eines empfangenen OSC Bundles. Zur einfachen Darstellung wird fr jedes Byte das entsprechende ASCII-Zeichen angezeigt. Ausnahmen sind der Byte Wert Null, hierfr wird das Zeichen 0 angezeigt, und Byte Werte im Bereich von 1 bis 32. Letztere werden durch das Zeichen x dargestellt, da die entsprechenden ASCII Werte keinem Zeichen entsprechen, sondern spezielle Funktionen haben. Das blaue Gitter verdeutlicht die OSC-Eigenschaft, dass die Lnge einzelner Elemente der Nachricht immer ein Vielfaches von vier ist, was gegebenenfalls durch das Hinzufgen von Null-Bytes erreicht wird. Diese Tatsache erleichtert die Implementierung eines Algorithmus zum Interpretieren der Daten, da immer nur Pakete vier Bytes analysiert werden mssen. Aus Grnden der Anschaulichkeit soll hier ein Pseudocode anhand Abbildung 4.3 grob beschreiben, wie der Algorithmus funktioniert, um die Daten aufzubereiten. Er entspricht der Funktion bundleToMsgList() in der Datei main.py. Im Folgenden bezieht sich der Begriff Paket auf eine Sequenz von vier Bytes. Die Koordinaten
23
(z.B. A1) dienen ebenfalls nur der anschaulichen Darstellung und finden sich nicht in der Implementierung wieder.
Abbildung 4.3: Darstellung eines OSC-Bundles
Zuerst werden alle Bytes eines empfangenen Datagramms jeweils in 4er Gruppen in eine Liste geschrieben und diese Listen bilden die einzelnen Elemente einer bergeordneten Liste. Somit lsst sich einfach auf ein einzelnes Paket zugreifen. OSC-Bundle Identitt Falls die ersten beiden Pakete (A1 und A2) den String #bundle beinhalten, wird fortgefahren: Timetag Die nchsten zwei Pakete (A3 und A4) stellen ein Timetag dar (dieser findet hier keine Verwendung). Identifikation OSC-Messages Das nchste Paket A5 gibt die Lnge des Inhalts der OSC-Message an. A5 hat den Wert 40 (ASCII Wert fr (), demnach bilden die nchsten 40 Bytes (10 Pakete, A6 bis B5) den Inhalt einer OSCMessage. Das darauf folgende Paket B6 gibt die Lnge der nchsten OSC-Message an. Der Wert des Paketes ist 72 (ASCII Wert von H), somit bilden die nchsten 18 Pakete (B7 bis D4) die nchste
24
OSC-Message. Auf dieser Grundlage wird eine Liste erstellt, in der jedes Element nur die Daten einer OSC-Message enthlt. OSC-Messages Es steht nun die Liste mit OSC-Messages zur Verfgung, von dieser wird jedes Element in einem Schleifendurchlauf genauer analysiert: Adresse Als erstes wird ein String mit der Adresse erwartet. Da das letzte Byte eines Strings den Wert Null hat (Null-terminierter String), werden bis zum ersten Vorkommen dieses Werts alle Pakete als Bestandteil des Address-Strings betrachtet. A6 bildet den Anfang und A7 enthlt bereits eine Null, somit ist die Adresse /joint. OSCeleton nutzt fr Koordinaten eines Gelenks die Adresse /joint und fr die Orientierung eines Gelenks die Adresse /orient. Typetags Nun folgt ein String mit Typetags. Um diesen zu identifizieren, wird wie bei dem Address-String verfahren. A8 und A9 bilden den Typetag-String ,sifff. Datentypen Nun wird jeder einzelne Character des Typetag-Strings (nach ,) betrachtet, um zu entscheiden, welchen Datentyp die folgenden Bytes haben. Typetag s Alle Pakete bis zum ersten Vorkommen eines Null-Bytes bilden einen String. OSCeleton schickt in einem String die Bezeichnung des Gelenks, dessen Daten folgen. A10 und B1 beinhalten den String head. Typetag i Das nchste Paket beinhaltet einen 32 Bit Integer. Diesen Datentyp verwendet OSCeleton fr die ID des getrackten Users. Typetag f Das nchste Paket beinhaltet eine 32 Bit Gleitkommazahl (Float). Diesen Datentyp verwendet OSCeleton fr die Werte von Koordinaten und Rotationsmatrizen. Grundstzlich werden Koordinaten in der Form ,sifff und Rotationen in der Form ,sifffffffff verschickt. Der String enthlt immer die Bezeichnung des Gelenks und der Integer immer die ID des Users. Bei Koordinaten enthalten die drei Floats den X-, Y- und Z-Wert des Gelenks. Bei einer Rotation enthalten die neun Floats die Ausrichtung der X-, Y- und Z-Achse des Gelenks, gemessen in dem Koordinatensystem des Raums (Rotationsmatrix).
25
Nach diesen Schritten stehen die Skelettdaten in Blender zur Verfgung und mssen nun mit einem digitalen Menschmodell verbunden werden.
4.2. bertragung der Skelettdaten auf ein digitales Menschmodell

In MakeHuman wird ein Modell erstellt und als mhx-Datei exportiert. Um diese Datei in Blender importieren zu knnen, muss im Men unter File > User Preferences unter dem Reiter Addons Import: MakeHuman (.mhx) aktiviert werden. Danach kann ber File -> Import -> MakeHuman die Datei geffnet werden. Es wird nur das von MakeHuman erzeugte Mesh (Polygonnetz des Krpers, siehe Abbildung 4.4) verwendet und ein eigenes Skelett (Abbildung 4.5) erzeugt, das dem Nite Skelett (vgl Abbildung 3.12) entspricht. Zwar wird von MakeHuman ebenfalls ein Skelett erstellt, hier wird aber ein mglichst simples bevorzugt, ohne Constraints oder andere Erweiterungen.
Abbildung 4.4 (links): Importiertes Menschmodell aus MakeHuman Abbildung 4.5 (rechts): In Blender erstelltes Skelett
In Blender ermglicht die Verwendung von Bones das Verformen eines Meshs, indem dafr nur die Ausrichtung der Bones gendert wird. Eine Armature ist die Gruppierung mehrere Bones in einer hierarchischen Anordnung. Ein Bone, der in der Hierarchie ber einem anderen steht, wird als dessen Parent bezeichnet, da jede Transformation (Verschiebung oder Rotation) sich auf seinen Child Bone auswirkt (siehe Abbildung 4.7). Der Root-Bone ist allen anderen Bones bergeordnet. Abbildung 4.6 zeigt wie diese Hierarchie in Blender im Outliner dargestellt wird, jedes Childobjekt wird im Vergleich zum Parent eingerckt.
26
Abbildung 4.6: Blender Outliner Hierarchie
Abbildung 4.7: Rotation des Oberarms wirkt sich auf alle Child Bones aus
Es stehen zwei Methoden zur Verfgung, um die Wirkung eines Bones auf ein Mesh zu definieren: Vertex Groups: Innerhalb des Polygonnetzes werden verschiedene Bereiche benannt. So kann angegeben werden, dass ein Bone nur einen bestimmten Bereich verformt. Hierfr muss der Name einer Vertex Group mit dem des entsprechenden Bones bereinstimmen. Abbildung 4.8 zeigt mit orangenen Vertices die Gruppe ArmLower.R an, die nur von dem gleichnamigen Bone bewegt wird.
27
Bone Envelopes: Wird diese Option gewhlt, werden alle Polygone verformt, die sich innerhalb eines bestimmten Abstands zum einem Bone befinden bzw. die von der Einhllenden des Bones umfasst werden. Abbildung 4.9 zeigt eine Darstellung von Bones anhand ihrer Envelopes, fr ein korrektes Verformen mssten die Envelopes teilweise grer skaliert werden, worauf aus Grnden einer anschaulichen Darstellung verzichtet wurde.
Abbildung 4.8: Vertex Groups
Abbildung 4.9: Bone Envelopes
Es knnen prinzipiell beide Optionen kombiniert werden, jedoch ist das nur fr sehr ausgefallene Anwendungen ntig. Fr diese Arbeit wird nur die Option Vertex Groups verwendet. Um die Haltung des Skeletts zu ndern, muss die Ausrichtung einzelner Bones gendert werden. Es lassen sich Constraints verwenden, um die Handhabung fr z.B. Animationen zu erleichtern. Beispielsweise stehen zur Verfgung: Inverse Kinematic (IK): Die Ausrichtung mehrerer Bones wird anhand der Position des End-Bones berechnet. So kann die Hand (innerhalb des Arm-Radius) frei bewegt werden, whrend Unterarm- und Oberarmknochen automatisch eine passende Ausrichtung annehmen. Track To: Ein Bone richtet sich in Richtung eines anderen Objekts aus. Stretch To: Ein Bone richtet sich in Richtung eines anderen Objekts aus und ndert gegebenenfalls dafr seine Lnge. Limit Rotation: Mit diesem Constraint lsst sich die Eigenschaft natrlicher Gelenke simulieren, nur eingeschrnkt rotieren zu knnen. Das Ausrichten des Skeletts anhand der gelieferten Daten von OpenNI lsst sich grundstzlich mit zwei Verfahren realisieren, die sich auch kombinieren lassen: Verwendung von Punktkoordinaten: Von jedem getrackten (von der Software erkannten und verfolgten) Gelenk stehen Koordinaten zur Verfgung, die dessen Position im Raum beschreiben. An jeden dieser Punkte wird ein Objekt platziert (z.B. ein Wrfel) und der entsprechende Bone mit einem Track To oder Stretch To Constraint zu diesem Objekt ausgerichtet. Voraussetzung fr ein sauberes
28
Ergebnis ist, dass die Abmessung des Users (Armlnge, Schulterbreite, etc.) mit den Abmessungen des digitalen Skeletts bereinstimmen. Verwendung von Rotationen: Von jedem getrackten Gelenk steht eine Rotationsmatrix zur Verfgung, mit welcher der entsprechende Bone ausgerichtet wird. Dieses Verfahren ist nicht darauf angewiesen, dass die Abmessungen des Users mit denen des Modells bereinstimmen. Auf Grund der Tatsache, dass Rotationen nur eine relative Beziehung zwischen zwei Bones beschreiben, lsst sich jedoch ohne zustzliche Einbeziehung von Punkkoordinaten keine vollstndige Beschreibung einer Pose rekonstruieren. Das System, das in dieser Arbeit erstellt wird, verwendet sechs Menschmodelle mit verschiedenen Abmessungen. Es ist jedoch nicht davon auszugehen, dass fr jeden mglichen User eines der Modelle dessen Abmessungen entspricht. Auch das von Nite berechnete Skelett des Users ist nicht fix, sondern kann whrend des Trackingprozesses in den Abmessungen variieren (PrimeSense, 2011). Aus diesen Grnden wird der Ansatz verfolgt, das Skelett mittels Gelenk-Rotationen zu bewegen. Rotation OSCeleton verschickt die Orientierung eines Gelenks als Rotationsmatrix. Eine Rotationsmatrix beschreibt die Rotation eines Objektes, indem die Ausrichtung dessen lokalen Koordinatensystems im globalen Koordinatensystem beschrieben wird. In Abbildung 4.10 stellt ein schwarzer Kasten die Kinect Kamera dar, mit Blickrichtung in Richtung der Z-Achse. Das Koordinatensystem XYZ stellt das globale und XYZ das lokale Koordinatensystem dar. Bei einem Gelenk in der Grundhaltung (vgl. Haltung in Abbildung 4.8) stimmen die Ausrichtungen beider Koordinatensysteme miteinander berein. Die Ausrichtung der Achsen X, Y und z in den Koordinaten x, y und z angegeben, wodurch sich die Rotationsmatrix R ergibt.
xx ' R = xy' x z'
yx' y y' yz'
zx' z y' zz'
(4.1)
Die Lnge der Achsen x, y und z betrgt 1, somit ist der Betrag jeder Zeile der Matrix ebenfalls 1. Um die Ausrichtung eines Bones in Blender zu ndern, muss die Ausrichtung in Form von einer Quaternion bergeben werden. Es ist zwar auch mglich Euler-Winkel zu bergeben, jedoch wird hier die QuaternionDarstellung vorgezogen, da diese einfacher zu verwenden ist. Fr das Berechnen einer Quaternion aus einer Rotationsmatrix und fr verschiedene Rechenoperationen mit Quaternionen stehen in Blender Python Funktionen zur Verfgung.
29
Abbildung 4.10: Rotation eines Koordinatensystems
Quaternionen hneln den komplexen Zahlen, sie bestehen aus einem Realteil und den drei Imaginrteilen i, j und k.
q = w + x i + y j + z k
w, x, y , z R
(4.2)
Mchte man zwei Rotationen nacheinander ausfhren, so werden dafr die beiden Quaternionen multipliziert. Hierbei spielt die Reihenfolge der Multiplikation eine Rolle. Soll zuerst die Rotation q1 und anschlieend q2 ausgefhrt werden so, erhlt man den Ausdruck
q = q 2 q1 .
(4.3)
Nite gibt die Orientierung der Gelenke in globalen Koordinaten des Raums an, in Blender jedoch wird die Ausrichtung nur in dem lokalen Koordinatensystem des jeweiligen Bones angeben. Abbildung 4.11 zeigt, dass eine Transformation keine Auswirkungen auf die Ausrichtung des globalen Koordinatensystems hat, whrend in Abbildung 4.12 zu erkennen ist, dass ein lokales Koordinatensystem abhngig von der Ausrichtung des Parent Bones ist. Um die globale Rotation verwenden zu knnen, muss jeder Bone so ausgerichtet werden, dass sein lokales Koordinatensystem dem globalen Koordinatensystem gleicht bzw. jede Achse durch nur eine Achse des anderen Systems beschrieben werden kann.
30
Abbildung 4.11: Transformation betrachtet im globalen Koordinatensystem
Abbildung 4.12: Transformation betrachtet im lokalen Koordinatensystem
Steht der User aufrecht mit seitlich ausgestreckten Armen vor der Kinect, so ist er in der Grundhaltung und jede Rotation beschreibt die Abweichung eines Bones von dieser Pose. Ein Vergleich von Abbildung 4.11 und Abbildung 4.12 lsst erkennen, dass sich jede Achse des globalen Koordinatensystems durch eine negative Achse des gezeigten lokalen Koordinatensystems beschreiben lsst, solange die Pose der Grundhaltung entspricht. Um diese Ausrichtung eines einzelnen Bones whrend des Trackingprozesses wieder herzustellen, muss die Ausrichtung des Parent-Bones kompensiert werden. Abbildung 4.13 zeigt, wie der rechte Oberarm wieder der Grundhaltung entspricht, nachdem die inverse Rotation des Torsos auf ihm ausgefhrt wird. Ist die Parent-Bone Rotation kompensiert, kann die Rotation des Child-Bones durchgefhrt werden.
31
Abbildung 4.13: Der rechte Oberarm mit inverser Rotation des Torsos
Beispiel Von OSCeleton wird die Ausrichtung des Torsos empfangen und in die Quaternion q0 umgerechnet. Die Torso Rotation wird durch keinen anderen Bone beeinflusst, demnach muss keine Rotation kompensiert werden und die Ausrichtung kann gleich q0 gesetzt werden. Nun folgt die Ausrichtung des rechten Oberarms. Wird der Torso mit der Quaternion
q0 = w0 + x0 i + y0 j + z 0 k
(4.4)
rotiert, bewegt sich u.a. der rechte Oberarm mit. Um diese Rotation des Oberarms auszugleichen, wird
q1 = w0 x0 i y0 j z 0 k
gebildet, indem die Argumente der Imaginrteile von q0 mit -1 multipliziert werden.
(4.5)
Wird die Rotation q1 auf dem rechten Oberarm ausgefhrt, kann sein lokales Koordinatensystem durch das globale Koordinatensystem beschrieben werden, indem die Vorzeichen aller Koordinaten gewechselt werden (siehe Abbildung 4.13 und 4.11). Die Rotationsmatrix des Oberarms wird in die Quaternion
q2 = w2 + x2 i + y2 j + z 2 k
(4.6)
umgerechnet. Damit das zugrundeliegende Koordinatensystem dieser Rotation mit dem lokalen des Oberarms bereinstimmt, mssen alle drei Achsen invertiert werden. Es entsteht somit
q3 = w2 x2 i y 2 j z 2 k .
(4.7)
Da sowohl die empfangene Rotation als auch die Kompensationsrotation ausgefhrt werden muss, werden beide miteinander multipliziert und
q final = q3 q1
(4.8)
32
beschreibt die Rotation, die der rechte Oberarm in Blender ausfhren muss, um die Orientierung dem User entsprechend einzunehmen. Entsprechend diesem Verfahren mssen fr Unterarm und Unterschenkel zwei Rotationen (Oberarm/schenkel und Torso) ausgeglichen werden. Die Betrachtung, in welcher Weise die Achsen des lokalen Koordinatensystems dem globalen Koordinatensystem entsprechen (nachdem die Parent Bone Rotation ausgeglichen wurde), muss fr jeden Bone einzeln erfolgen, da dies je nach Grundausrichtung variiert. Ausgerichtet werden die Gelenke Torso, Schulter links/rechts, Ellbogen links/rechts, Hfte links/rechts und Knie links/rechts (siehe Abbildung 4.14). Die Orientierungen der Fu- und Handgelenke sowie des Genicks und Kopfs werden von Nite nicht berechnet, dennoch werden Rotationsmatrizen fr diese Gelenke geliefert. Diese Rotationsmatrizen entsprechen jedoch genau der Orientierung eines anderen Gelenks (linkes Handgelenk gleich Ellbogen, Kopf und Genick gleich Torso), was einen konstanten Offset bei der Beschreibung in globalen Koordinaten bewirkt. In Blender haben Child Bones ohnehin einen Offset zum Parent Bone, somit bieten diese Rotationsmatrizen keine zustzlichen Informationen und werden nicht verwendet.
Abbildung 4.14: Gelenke, deren Ausrichtung von Nite berechnet wird
33
5. Demonstrator
Der Demonstrator ist eine Software mit grafischer Oberflche, auf der die Bewegung eines Users anhand eines digitalen Menschmodells dargestellt wird. Blender bietet mit seiner Game Engine die Mglichkeit, Modelle in Echtzeit zu animieren und sowohl mit externen Sensoren (z.B. Tastatureingabe) als auch internen Sensoren (z.B. Kollisionserkennung animierter Objekte) zu steuern. Ein weiteres mchtiges Feature ist die Einbindung von Python Skripts. Somit ist es mglich sehr spezifische Anwendungen zu erstellen, da zum einen die gesamte Blender Funktionspalette mittels Python Funktionen zur Verfgung steht und zum anderen die gngigen Python Module (z.B. das Modul socket fr Netzwerkkommunikation) bereits enthalten sind. Somit bietet sich die Verwendung der Blender Game Engine zum Entwickeln des Demonstrators an und es entfllt ein aufwendiges Einbinden von Blender Source Code in einer Entwicklungsumgebung.
5.1. Blender Game Engine

Zum Erstellen einer Anwendung in Blender kommt der Logic Editor zum Einsatz. Im Logic Editor werden die drei Komponenten (auch bezeichnet als Logic Bricks) Sensor, Controller und Actuator im Kontext eines Objekts miteinander verbunden (siehe Abbildung 5.1). Die so entstandene Beschreibung wird als Game Logic bezeichnet. Es lassen sich Game Properties anlegen, um Daten zu speichern und diese in den verschiedenen Komponenten zu verwenden. Als Game Properties lassen sich die Datentypen Integer, Float, Boolean und String speichern, whrend mit dem Game Property Timer ab Start der Anwendung die Zeit gemessen wird.
Abbildung 5.1: Blender Logic Editor
Abbildung 5.1 zeigt beispielhaft eine Game Logic im Kontext eines Objekts namens Cube1. Wird die rechte Pfeiltaste gedrckt, lst der Keyboard Sensor eine Rotation des Objekts um die Z-Achse aus. Ein Always Sensor ruft mit jedem Logic Tic das Skript move.py auf.
34
Im Folgenden werden nur die fr diese Arbeit relevanten Logic Bricks nher erlutert. Sensor Ein Sensor erzeugt entweder ein einfaches Trigger Signal oder Sensor spezifische Daten wie z.B. Taste x wurde gedrckt. Das Timing von Sensoren (z.B. Verzgerung) bezieht sich auf Logic Tics. Die Anzahl der Logic Tics pro Sekunde entspricht der Refresh Rate (nicht zu verwechseln mit der Frame Rate) und ist standardmig auf 60 Hz eingestellt. Always Sensor Dieser Sensor ist immer aktiviert und sendet je nach Einstellung entweder einmalig beim Starten der Anwendung oder kontinuierlich in einstellbaren zeitlichen Abstnden ein Trigger Signal. Keyboard Sensor Auf Tastendruck einer bestimmten Taste oder auf beliebigen Tastendruck wird ein Signal mit entsprechender Information generiert. Controller Ein Controller hat die Aufgabe, die Daten von einem oder mehreren Sensoren an einen oder mehrere Actuator weiterzugeben. Hierfr stehen logische Ausdrcke (AND, OR, XOR, etc.) zur Verfgung, um z.B. nur dann einen Actuator zu aktivieren, wenn die Trigger Signale der Sensoren einem bestimmten Muster entsprechen. Auerdem ermglicht der Python Controller das Ausfhren eines Skripts, wodurch ein Interface geschaffen wird, das beliebig komplexe Anwendungen ermglicht. Actuator Ein Actuator ermglicht das Ausfhren verschiedener Funktionen, z.B. Objekte bewegen, Szene wechseln, die Anwendung neustarten oder schlieen. Motion Actuator Dieser Actuator bewegt das Objekt, in dessen Kontext die Logic Bricks existieren. Das Objekt lsst sich verschieben, rotieren oder dessen Geschwindigkeit ndern. Scene Actuator Um in eine andere Szene zu wechseln wird dieser Actuator verwendet. Es kann die aktuelle Szene neugestartet, pausiert und fortgesetzt werden. Zustzlich zur aktuellen Szene kann auch der Inhalt einer weiteren Szene in den Vorder- oder Hintergrund gezeichnet werden.
35
5.2. Konzeption Demonstrator

Der Demonstrator soll die Mglichkeit geben eines von sechs verschiedenen Menschmodellen auszuwhlen und das ausgewhlte Modell in einer Einzelansicht mit der Bewegung eines Benutzers zu animieren. Hierfr bietet sich eine Aufteilung in mehrere Szenen an. Szene 1: Auswahl
Auswahl der sechs verschiedenen Modelle. Mit den Pfeiltasten links und rechts wird navigiert und mit der Taste Enter die Auswahl besttigt. Szene 2 7: Einzelansicht
Modell Nr.1 - 6 in der Einzelansicht. Das Modell wird entsprechend den von OSCeleton empfangenen Skelettdaten ausgerichtet. Es stehen Funktionen zum Aufzeichnen, Speichern und Wiedergeben von Bewegungen zur Verfgung. Als Vorlage fr die Krpergren der Modelle werden die statistischen Daten anthropometrischer Datenbanken genutzt (DIN, 2011). Diese beschreiben die durchschnittlichen Krpermae verschiedener Perzentile in verschiedenen Bevlkerungsgruppen. Betrachtet wurden die Perzentile P5, P50 und P95, um die kleinste und grte Krpergre zu finden (siehe Tabelle 5.1). Der Wert eines Perzentils beschreibt die obere Schranke, unter der die betrachtete Menge liegt (z.B. sind bei einem P5 Perzentil 5% der Gruppe kleiner als der zugehrige Wert und 95% sind grer). Da die Krpergre in MakeHuman ber einen Schieberegler eingestellt wird, lieen sich die Krpergren nicht exakt bis auf die letzte Ziffer bernehmen.
Tabelle 5.1: Statistik Krpergren
Nation
Geschlecht
Verwendetes Perzentil
Bemerkung
Krpergre in cm
Thailand Japan Kenia Deutschland Amerika Niederlande
w w m m w m
P5 P50 P5 P50 P95 P95
Kleinste P5 Grter P95
146,7 157,0 160,7 175,0 176,7 195,9
36
5.3. Szene Auswahl

Beschreibung Die sechs Menschmodelle sind kreisfrmig angeordnet (Abbildung 5.2). ber jedem Modell befindet sich eine Tafel, auf der dessen Daten (z.B. Krpergre) zu lesen sind. Mit den Pfeiltasten links und rechts lsst sich die Gesamtanordnung drehen. Der Tastendruck veranlasst eine Drehung soweit, bis das nchste Modell mittig im Fenster ausgerichtet ist. Damit die Drehung als solche zu erkennen ist, mssen Zwischenpositionen eingenommen werden und in einem gleichmigen zeitlichen Abstand gendert werden. Durch Drcken der Taste Enter wird die Auswahl besttigt und die Einzelansicht Szene des fokussierten Modells geladen.
Abbildung 5.2 :Ansicht Viewport (links), gerenderte Ansicht (rechts)
Implementierung In dieser Szene ist kein Skelett fr die Modelle notwendig, da diese nicht verformt werden, sondern lediglich im Raum bewegt werden. Es werden nur die Low Poly Proxies der in MakeHuman erstellten Modelle in Blender importiert. Um die kreisfrmige Bewegung zu ermglichen, ist im Mittelpunkt der Anordnung ein Wrfel als ParentObjekt jedes einzelnen Modells platziert (siehe Bild 5.2). Die Child-Parent-Beziehung bewirkt, dass die Modelle ihre relative Ausrichtung zu dem Wrfel immer beibehalten. Somit muss nur der Wrfel gedreht werden, um eine kreisfrmige Verschiebung der Modelle zu bewirken. Die Sichtbarkeit des Wrfels ist nur im Viewport aktiviert, whrend er in der gerenderten Darstellung nicht zu sehen ist. Abbildung 5.3 stellt die Implementierung der Game Logic dar. Das Skript main.py wird als Pseudo Code stark vereinfacht beschrieben. Im Logic Editor sind ein Keyboard-Sensor und ein Always-Sensor mit einem PythonController verbunden, welcher das Skript main.py aufruft. Wird eine der vertikalen Pfeiltasten gedrckt, weist das Skript der Game Property direction (Drehrichtung der Gesamtanordnung) einen Wert zu und speichert die aktuelle Position der Gesamtanordnung in der Game Property startPosition. Die Ausrichtung der Gesamtanordnung wird dafr in sieben Positionen eingeteilt. Sechs dieser Positionen entsprechen dem Fall,
37
dass eines der Modelle mittig im Fenster ausgerichtet ist und die siebte Position bezeichnet alle Zwischenpositionen, also den Fall, dass keines der Modelle genau mittig im Fenster steht. Der Always-Sensor ruft das Skript ebenfalls auf und dreht den Wrfel um wenige Grad, falls sich die Anordnung entweder in der Startposition befindet oder in der Zwischenposition. Ist die Anordnung soweit gedreht, dass ein anderes Modell als zuvor mittig im Fenster steht, wird keine Rotation mehr ausgefhrt. Da der Always Sensor in Millisekunden-Abstnden diese einzelnen Rotationen ausfhrt, ergibt sich eine flssige Rotation der gesamten Anordnung. Um auf Tastendruck der Taste Enter eine neue Szene zu starten, wird ebenfalls ber das Skript die dem Modell entsprechende Szene der Einzeldarstellung aufgerufen.
Abbildung 5.3: Implementierung Szene Auswahl
38
5.4. Szene Einzelansicht

Beschreibung In dieser Szene wird das zuvor ausgewhlte Modell in der Einzelansicht prsentiert. Es wird entsprechend der Pose des Benutzers in Echtzeit ausgerichtet, sofern die entsprechenden Daten extern zur Verfgung gestellt werden. ber die Tastatur lassen sich die Funktionen zum Aufzeichnen und Wiedergeben von Bewegungen aufrufen. Eine Men-Leiste oberhalb des Menschmodells zeigt mit einem kleinen Symbol den aktuellen Modus an und enthlt die Mglichkeit zur Textdarstellung (siehe Abbildung 5.4).
Aufzeichnen Die Taste R (fr Record) wechselt in den Modus, in dem die Eingabe eines Namens erwartet wird (Symbol (Symbol ).
Diese Eingabe wird durch Drcken der Taste Enter abgeschlossen. Nun beginnt die Aufzeichnung ), diese wird durch Drcken einer beliebigen Taste beendet. Die entsprechenden Daten werden als Text Datei (.txt) im Ordner der Anwendung gespeichert.
ffnen und Wiedergeben Um eine zuvor aufgezeichnete Bewegung zu ffnen, muss die Taste O (fr Open) gedrckt werden. Es stehen dann alle Text-Dateien zum ffnen zur Verfgung, die sich im selben Ordner wie die Anwendung befinden (Symbol ). Es wird immer nur ein Dateiname angezeigt und mit den Pfeiltasten links und rechts zu dem vorherigen bzw. nchsten Dateinamen gewechselt. Die Pfeilsymbole < und > zeigen an, ob in entsprechender Richtung weitere Dateien existieren (siehe Abbildung 5.4). Durch Drcken der Taste Enter wird die Auswahl besttigt und direkt wiedergegeben (Symbol ). Ist die Wiedergabe beendet, kehrt die Anwendung wieder in den Standard-Modus zurck (kein Symbol), in dem das Modell die Krperhaltung des Benutzers einnimmt.
Abbildung 5.4: Ausschnitt Einzelansicht
Implementierung Als Modell wird das Low Poly Proxy einer in MakeHuman erzeugten Datei verwendet. Das Modell wird mit einem Skelett gleicher Abmessungen verknpft, um das Modell verformen zu knnen.
39
Abbildung 5.5 stellt die Implementierung der Game Logic dar. Dafr werden die Skripte main.py und modus.py stark vereinfacht als Pseudo Code beschrieben. Im Kontext des Skeletts wird im Logic Editor ein Always Sensor (im Modus kontinuierlich zu triggern) mit einem Python Controller verbunden. Dieser Controller ruft das Skript main.py auf, das entsprechend der Beschreibung in Kapitel 4.1.1. einen UDP Socket erzeugt, um die Netzwerk Nachrichten von OSCeleton zu empfangen, die Daten aufbereitet und das Skelett entsprechend ausrichtet, falls die Game Property Variable status kein Abspielen einer zuvor erstellten Bewegungsdatei auslst.
Aufzeichnen und Wiedergeben Um eine Bewegung aufzuzeichnen, wird eine Text-Datei mit dem zuvor eingegebenen Namen fileName geffnet. Existiert die Datei bereits, wird sie erweitert, andernfalls wird sie neu erzeugt. Es wird dann jedes empfangene Datagramm in die Text-Datei geschrieben, gefolgt von einem Tupel aus vier Bytes, deren ASCIIReprsentation ende ist, um bei einem spteren Auslesen die verschiedenen Datagramme auseinanderhalten zu knnen. Es wre zwar denkbar, dass ein Datagramm bereits ein solches Tupel enthlt und somit flschlicher Weise das Ende eines Datagramms angezeigt wird, wodurch alle folgenden Datagramme falsch interpretiert wrden, jedoch ist dieser Fall auszuschlieen. Der Fehler knnte nur auftreten wenn ein String das Wort ende in Kleinschreibung beinhaltet ein Integer mit dem Wert 1701733477 enthalten ist oder ein Float mit dem Wert 7.0360948446709021022 enthalten ist.
Da alle Strings, die OSCeleton verschickt, statisch definiert sind, Integer nur fr die IDs der getrackten User verwendet werden (der erste erkannte User erhlt die ID 0) und Floats fr die Koordinaten (in der Einheit mm, maximal Wert ca. 3,5 m) und Rotationsmatrizen (alle Werte 1) verwendet werden, knnen diese Werte bei einer fehlerfreien bertragung nicht enthalten sein. Um eine Datei abzuspielen, erfolgt mit jedem Triggersignal des Always Sensors das Auslesen eines Datagramms und das Ausrichten des Skeletts, entsprechend den im Datagramm enthaltenen Informationen. Der Always Sensor wird mit einer Verzgerung von einem Logic Tic bei einer Refresh Rate von 60 Hz betrieben. Somit wird 30-mal pro Sekunde ein Datagramm ausgelesen, was der Frame Rate entspricht, mit der die Daten empfangen und gespeichert wurden.
40
Abbildung 5.5: Implementierung Szene Einzelansicht
Dynamischer Text Das Skript modus.py realisiert u.a. auch die Dialoge zum Speichern und ffnen von Bewegungsdateien. Dafr ist eine Funktionalitt zum dynamischen (zur Laufzeit der Anwendung) Erstellen eines Textes notwendig. Diese Funktion steht in Blender nicht direkt zur Verfgung, sondern muss mit Hilfe einer Font Map selber erstellt werden.
Abbildung 5.6: Font Map ariblk.tga (Quelle: blender.freemovies.co.uk)
41
Eine Font Map ist eine Bild-Datei, die zustzlich zu den Farbwerten der Pixel Metadaten enthlt, mit deren Hilfe Blender die einzelnen Zeichen voneinander unterscheiden kann. Verwendet wird die in Abbildung 5.6 abgebildete Font Map. In Blender wird eine Flche erzeugt, welche die Font Map als Textur verwendet. Nach Aktivierung bestimmter Optionen wird der Inhalt eines Game Property Strings als Text auf dieser Flche dargestellt. Diese Game Property muss im Kontext der Flche existieren und den Namen Text haben. Die Gre der Flche wird entsprechend dem bentigten Platz zur Darstellung des Textes automatisch vergrert. Fr eine genauere Beschreibung der vorzunehmenden Einstellungen sei auf blender.freemovies.co.uk (o. J.) verwiesen. Soll ein neuer Name eingegeben werden, werden nur die Buchstaben a bis z (in Kleinschreibung) und die Zahlen 0 bis 9 akzeptiert. Mit der Backspace-Taste lsst sich eine Eingabe korrigieren. Die Dateiendung .txt wird automatisch an den Namen angehngt.
42
6. Animationsfunktionen in Blender
Ein Objekt zu animieren bedeutet es in bewegten Bildern darzustellen. Dafr wird ihm eine Bewegung verliehen oder der zeitliche Verlauf dessen Eigenschaften (z.B. Farbe) definiert. Im Blender lassen sich prinzipiell alle Einstellungen eines Objekts animieren. Animationen werden entweder benutzt, um einen Film zu erstellen oder um fr eine grafische Anwendung (in der Regel Spiele) Ablufe zu definieren, welche dann in Abhngigkeit der Game Logic ausgefhrt werden (z.B. das Rennen eines Avatars als Reaktion auf einen Tastendruck). Um in Blender Animationen zu erstellen, knnen entweder extern erzeugte Daten genutzt werden (Motion Capturing) oder Daten intern manuell erzeugt werden unter Zuhilfenahme zahlreicher untersttzender Funktionalitten. Dieses Kapitel beschreibt Methoden und Funktionen von Blender, mit denen es mglich ist eine Animation zu erstellen. Es dient dazu einen berblick zu erhalten, wie ein Workflow zum Animieren aussehen kann. Zustzlich zu den hier beschrieben Funktionen lassen sich Objekte entsprechend den physikalischen Gesetzen animieren. Dafr werden lediglich die ntigen Parameter eingestellt und Optionen aktiviert (z.B. Parameter Gewicht fr die Berechnung des Impulses bei einer Kollision zweier Objekte).
6.1. Motion Capture

Blender ermglicht das Verwenden von Motion Capture Daten, wenn diese als Biovision Hierarchy (BVH) Datei zur Verfgung stehen (vgl. character-studio.net, o. J.). Dieses Format wurde von dem Unternehmen Biovision speziell dafr entwickelt, Motion Capture Daten an Kunden weitergeben zu knnen. Wie der Name andeutet, wird in einer solchen Datei nicht nur die Position und Ausrichtung der Gelenke beschrieben, sondern auch deren Hierarchie. Die Daten werden als deren ASCII Reprsentation gespeichert, wodurch die Darstellung einer Datei im Text-Editor mglich ist. Eine Datei gliedert sich in zwei Teile: 1. Beschreibung des Skeletts Dieser Teil beginnt mit dem Schlsselwort HIERARCHY (siehe Abbildung 6.1). Es folgt die Auflistung aller Gelenke entsprechend der Hierarchie des Skeletts (vgl. Abbildung 4.6). Zu jedem Gelenk wird die Offset Position in globalen Koordinaten angeben, woraus sich die Lnge der Knochen ableiten lsst. Des Weiteren wird nach dem Schlsselwort CHANNELS angegeben, wie viele der folgenden Daten pro Frame wie zu interpretieren sind. Vor allem fr die Beschreibung der Rotation mit Eulerwinkeln ist es ntig zu wissen, in welcher Reihenfolge um welche Achsen rotiert wird.
43
Abbildung 6.1: BVH Datei Hierarchie Darstellung
2. Beschreibung der Bewegung Dieser Teil beginnt mit dem Schlsselwort MOTION (siehe Abbildung 6.2). Es werden zuerst die Anzahl der enthalten Frames beschrieben sowie das Zeitintervall zwischen den einzelnen Frames in Sekunden. Darauf folgen fr jeden Frame die Daten in einer Zeile, deren Reihenfolge und Identitt der Beschreibung in HIERARCHY entspricht.
Abbildung 6.2: BVH Datei Bewegungsdaten
In Blender wird beim Importieren einer solchen Datei automatisch ein entsprechendes Skelett erzeugt und fr jeden Frame ein Keyframe gesetzt.
44
6.2. Keyframe Animation

Bei einer Keyframe-Animation werden die Parameterwerte eines Objekts manuell fr verschiedene Frames angegeben (Keyframes) und die Werte fr die Interframes (alle Frames, die zwischen den Keyframes liegen) interpoliert. Die zu ndernden Parameter werden auch als Kanle des Keyframes bezeichnet. Es wird z.B. zum Erzeugen einer Verschiebung eines Objekts dessen Startposition (Kanal X-Koordinate) in Frame 1 und die Endposition in Frame 100 gespeichert. Fr die 98 dazwischen liegenden Frames werden die Werte der X-Koordinate interpoliert. Blender bietet vier Editoren, um die Keyframes zu bearbeiten, die Interpolation zu bearbeiten, Keyframes zu Actions zusammenzufassen und um diese Actions zu bearbeiten. Diese vier Editoren werden im Folgenden beschrieben.
Timeline Dieser Editor ermglicht das Abspielen einer Animation und das Navigieren in deren Frames. Ein Bearbeiten einzelner Keyframes (bis auf Lschen) ist nicht mglich. Das Einstellen der Parameter, welche als Keyframe gesetzt werden sollen, erfolgt in einem anderen Editor (z.B. Viewport, siehe Abbildung 6.3). Die Position der Keyframes wird auf der Timeline als gelber Strich dargestellt (siehe Abbildung 6.4). Die Timeline bietet somit eine bersicht ber alle Keyframes des fokussierten Objekts und die aktuelle Frameposition, welche mit einem grnen Strich dargestellt wird.
Abbildung 6.3: Blender Viewport mit Keyframe Men
Abbildung 6.4: Blender Timeline Editor
45
Graph Editor Der Graph Editor stellt den Verlauf der Kanalwerte des fokussierten Objekts ber die Zeit (in Frames) als Graph dar (siehe Abbildung 6.5). Wie in allen Editoren, die mehrere Kanle anzeigen knnen, lsst sich die Sichtbarkeit der Kanle einstellen. Um die Form eines Graphen zu verndern, lassen sich die Tangenten verschieben und drehen. Ebenso knnen die Sttzstellen (Keyframes) frei verschoben werden. Des Weiteren lsst sich in diesem Editor der Einfluss von beliebigen Parametern eines beliebigen Objekts auf die Kanle des fokussierten Objekts beschreiben.
Abbildung 6.5: Blender Graph Editor
Dope Sheet Dieser Editor bietet verschiedene Modi, um die zeitliche Position der Keyframes aller Objekte zu bearbeiten, nur Keyframes bestimmter Daten zu bearbeiten oder um die Keyframes des fokussierten Objekts als Action zu speichern. Die Verwendung von Actions ermglicht ein schnelleres und flexibleres Erstellen einer komplexen Animation, als die Verwendung einzelner Keyframes. Es ist sinnvoll, sptestens beim Erstellen von Actions darauf zu achten, nur Kanle zu verwenden, deren Parameter auch verndert werden, um sptere Konflikte mit anderen Actions zu vermeiden. Abbildung 6.6 zeigt die Position von Schlsselwerten. Ein dunkelgrauer Balken zwischen zwei Markierungen zeigt, dass sich der Wert nicht ndert. Die Actions knnen anschlieend im NLA Editor weiterverwendet werden.
46
Abbildung 6.6: Blender Dope Sheet Editor
NLA Editor Der Non-Linear Animation (NLA) Editor wird verwendet, um Actions zu bearbeiten und zu kombinieren. Das Konzept dahinter ist, mit Actions jeden Verlauf und jede Bewegung als Einheit zu Verfgung zu haben, um aus diesen Bausteinen komplexe Animationen zu erstellen (siehe Abbildung 6.7). Dafr knnen mehrere Actions eines Objekts parallel angeordnet werden, solange diese unterschiedliche Kanle haben. Es knnen bergnge zwischen den Actions erstellt werden und Modifier auf einzelne Actions angewendet werden, um z.B. Rauschen in die Bewegung zu bringen. Fr eine Animation eines Menschen wrden hier beispielsweise Actions wie Laufen oder Springen nacheinander angeordnet werden, da diese die Beinbewegung beschreiben. Andere Actions, wie z.B. Lippenbewegungen, verwenden andere Kanle und knnen somit parallel zum Laufen ausgefhrt werden.
Abbildung 6.7: Blender NLA Editor
47
6.3. Game Engine Animation

Die Funktionalitt der Game Engine wurde in Kapitel 5 bereits beschrieben. Die dort beschriebene Umsetzung zeigt, wie eine Echtzeitanimation realisiert werden kann, indem die zu animierenden Parameter anhand von Echtzeitdaten berechnet werden. Diese Mglichkeit, mittels Python Skripts Animationsdaten zu erstellen, ist nahezu unbeschrnkt und orientiert sich an dem Talent eines Programmierers. Die andere Mglichkeit eine Echtzeitanimation zu realisieren, ist die Ausfhrung von zuvor definierten Actions in Abhngigkeit von Sensordaten. Hierfr bietet die Blender Game Engine den Action Actuator an. Dieser wird im Logic Editor mit Sensoren und Controllern verbunden und fhrt seine Action aus, sobald er ein Trigger Signal erhlt.
48
7. Konzeption der Integration eines haltungsbasierten Ergonomie Bewertungsverfahren

Das vom IAD entwickelte EAWS (European Assembly Worksheet) zur Ergonomie-Analyse zeigt u.a. typische Krperhaltungen eines Arbeiters an einem Montagearbeitsplatz. Die automatische Erkennung dieser Krperhaltungen soll auf Grundlage dieser Arbeit realisiert werden. Hierfr folgt eine Betrachtung einzelner Krperhaltungen, um zu diskutieren, in wie weit dies mglich ist und welche Problematiken auftreten knnen. Vorausgesetzt wird, dass die Skelettdaten mit der Nite Middlware erzeugt werden. Dauer Grundstzlich ist das Bestimmen der Dauer einer Haltung ohne groen Aufwand zu bewerkstelligen, vorausgesetzt die Haltung wird von dem System erkannt. Bei der Skeletterkennung mit Nite kommt es vor, dass zu manchen Zeitpunkten die Erkennung einzelner Gelenke fehlschlgt. Ein Confidence-Wert informiert jedoch darber, dass dies der Fall ist. Somit ist unter Einbeziehung dieser Zusatzinformation ein flschliches Beenden einer Zeitmessung vermeidbar. Krperhaltung Zu allen Krperhaltungen sollen die drei Parameter Rumpfdrehung, Rumpfneigung und Reichweite der Arme bestimmt werden (siehe Abbildung 7.1). Zur Bestimmung der Rumpfdrehung knnen die Positionsdaten der beiden Schultergelenke sowie die Orientierung des Torsos verwendet werden. Die Rumpfneigung lsst sich ebenfalls direkt mit Torso Orientierung angeben. Zur Bestimmung der Reichweite eignen sich die Positionsdaten der Schulter-, Ellbogen- und Handgelenke, da diese bereits in der Einheit mm erhalten werden (vgl. PrimeSense, 2011).
Abbildung 7.1: Darstellung der Rumpfdrehung, -neigung und Reichweite (Quelle: IAD)
49
Krperstellungen Die Nummerierung, Abbildungen und Beschreibungen der folgenden Krperstellungen ist dem EAWS (IAD, 2009) entnommen. In Tabelle 7.1 wird fr verschiedene Krperstellungen beschrieben, mit welchen Daten eine Implementierung der Erkennung realisiert werden knnte.
Tabelle 7.1: Erkennung Krperstellung
Nr. Darstellung
Beschreibung
Mgliche Implementierung Charakteristisches Merkmal ist eine (nicht zwangslufig vollstndige) Streckung der Beine. Hierber geben die Orientierung der Kniegelenke Auskunft, in Kombination mit einer Fallunterscheidung anhand der Position von beispielsweise Fu- und Hftgelenke, um ein Stehen von z.B. einem Liegen zu unterscheiden. Die Torso Orientierung beschreibt, ob die Haltung aufrecht ist bzw. welcher Winkel eingenommen wird. An den Skelettdaten lsst sich jedoch nicht direkt erkennen, ob eine Absttzung erfolgt. Hierfr liee sich beispielsweise wie beim CUELA System (vgl. Kapitel 3.1) eine Sensorik in die Schuhe des Arbeiters integrieren, um zu messen, ob dessen Gewicht komplett von den Fen getragen wird. Erfolgt eine Absttzung, knnte jedoch die Erkennung des Benutzers und somit jegliche Skelettdatenerzeugung scheitern. Diese Problematik kann immer auftauchen, wenn ein Benutzer sich zu nahe an einem anderen Objekt befindet (vgl. PrimeSense , 2011).
Stehen
Aufrecht Stehen und 1 Gehen, ggf. leicht nach vorne oder hinten geneigt
Stehen, keine Absttzung Nach vorn gebeugt (20- 60)
Vgl. Nr. 1
3 Mit geeigneter Absttzung Stark gebeugt > 60 4 Mit geeigneter
Vgl. Nr. 1
Vgl. Nr. 1
50
Absttzung Aufrecht, Arme 5 auf/ber Schulterhhe Zustzlich zu der in Nr.1 beschriebenen Erkennung bietet sich die Verwendung der Ellbogen- und Handgelenkspositionsdaten an, um die Armposition relativ zu den Schultern zu beschreiben.
Aufrecht, Arme ber Kopfhhe
Vgl. Nr.5
Das Erkennen der Sitzposition ist problematisch, da Nite Probleme hat, einen Benutzer zu erkennen, wenn dieser Sitzen in Berhrung mit einem anderen Objekt ist. Die zugehrigen Krperstellungen (Nr. 7 - 11) lassen sich vermutlich nicht zuverlssig erkennen. Knien oder Hocken Ein Knien oder Hocken lsst sich anhand der Orientierung von Knie und Hftgelenk erkennen.
12
Aufrecht
Auswertung der Torso Orientierung
13
Nach vorn gebeugt
Auswertung der Torso Orientierung
14
Arme auf/ber Schulterhhe
Identifizierung anhand der Handgelenk- und Ellbogenposition.
Ein Liegen impliziert, dass eine Person sich sehr nah am Boden befindet, wodurch Nite Probleme hat, die Person Liegen und Klettern als Benutzer zu identifizieren. Beim Klettern kann das ebenfalls der Fall sein, da der Krper zwangslufig in Kontakt mit einem anderen Objekt sein muss.
51
Liegen auf 15 Rcken, Brust oder Seite, Arme ber Kopf
Vorausgesetzt eine Skelleterkennung verluft erfolgreich, liee sich ein Liegen an der Torso Orientierung identifizieren.
Im Vergleich zu den anderen Stellungen muss hier eine 16 Klettern Bewegung erkannt werden. Das Klettern liee sich anhand der vertikalen nderung der Torso- bzw. der Center Of Mass-Position erkennen.
Fr das Bewertungsverfahren ist auerdem die Handgelenkstellung von Interesse. Das von Nite implementierte Hand-Tracking ermglicht jedoch keine Erkennung der Gelenkstellung. OpenNI bietet Funktionen zum Vermitteln von Hand- und Fingerausrichtungen, jedoch msste dies noch von einer entsprechenden Middleware implementiert werden.
52
8. Kritik und Ausblick

Im Rahmen dieser Bachelorarbeit ist ein Demonstrator entwickelt worden, der die Bewegung eines Benutzers auf ein digitales Menschmodell bertrgt und grafisch darstellt. Dafr wurden bestehende Softwarelsungen betrachtet, welche ein Erzeugen von Skelettdaten mittels der Kinect-Kamera ermglichen. Da die gesamte Lsung unabhngig von der Wahl des Betriebssystems funktionieren soll, wurde das OpenNI Framework in Verbindung mit der Middleware Nite ausgewhlt, da diese Komponenten als einzige die Anforderung erfllen. Die Implementierung der API zum Generieren der Skelettdaten musste nicht selbst vorgenommen werden, da mit der Software OSCeleton eine Open Source-Lsung bereits existiert, die eine geeignete Funktionalitt umsetzt. OSCeleton verschickt die Skelettdaten an einen Server, der mit einem Python Skript implementiert wird. Blender bietet mit seiner Game-Engine und der Verwendung von Python Skripts die ntigen Mglichkeiten, um den gewnschten Demonstrator zu realisieren. Dafr wurden sechs mit MakeHuman erzeugte Menschmodelle importiert und Python Skripte programmiert, um diese Modelle anhand der auf dem Server eingehenden Daten in Echtzeit zu bewegen. Programmiert wurden zustzlich Funktionen zum Speichern und Wiedergeben von empfangenen Bewegungsdaten. Es werden alle Forderungen der Anforderungsliste erfllt, jedoch konnten nicht alle Wnsche umgesetzt werden, da dies im zeitlich begrenzten Rahmen der Arbeit nicht mglich war. Nicht umgesetzt wurden die Wnsche Editieren von aufgezeichneten Bewegungen Optional jedes Modell mit Kleidung ausstatten, welche mitbewegt werden Beschrnkung auf Krperzonen Anzeige der Silhouette des Benutzers Translation des Modells
Teilweise kann jedoch eine Mglichkeit genannt werden, wie eine solche Funktion umzusetzen ist. Um eine Einschrnkung auf bestimmte Krperzonen zu implementieren, liee sich ein Dialog gestalten, um abzufragen, welche Krperzonen des Modells von einem Benutzer ausgerichtet werden und entsprechende Variablen setzen. Ein Anpassen des Algorithmus zur Ausrichtung des Skeletts in Abhngigkeit dieser Variablen knnte dann diesen Wunsch umsetzen. Zur Rekonstruktion der Userbewegung werden die Orientierungen der Benutzer-Gelenke auf das Modell bertragen. Die Position der Hfte des Modells wird nicht verndert, womit es sich nicht von der Stelle bewegen kann. Damit sich das Modell auch um die eigene Achse drehen kann, muss evaluiert werden, welche Daten sich am besten eignen, um die Rotation des ganzen Krpers zu beschreiben. Wird eine Rotation des kompletten Modells ausgefhrt, so muss das in den Algorithmus, welcher die Transformation einer Rotation vom globalen zum lokalen Koordinatensystem beschreibt, miteinbezogen werden. Da bei einer Drehung um die vertikale Achse und gleichbleibender Krperhaltung sich die global beschriebene Orientierung jedes Gelenks ndert, in Blender jedoch die lokal beschriebene Orientierung der Gelenke konstant bleiben muss, ist ein solcher Schritt ntig.
TU Darmstadt IAD | Adrian Eissfeldt | 2012 53
Gewnscht wurde eine Bild in Bild Funktion, mit der die Silhouette des Benutzers im Demonstrator klein eingeblendet wird, was nicht umgesetzt wurde. Hierfr msste der Quellcode von OSCeleton modifiziert werden. Dessen Implementierung der Skeletterkennung verwendet den Production Node User Generator, welcher eine Pixel-Map ausgeben kann, die beschreibt welche Pixel des Bilds zu welchem Benutzer gehren. Diese Pixel-Map liee sich mit Bildverarbeitungsalgorithmen den Wnschen anpassen und jedem OSCBundle anhngen. In Blender liee sich das empfangene Bild zu einer Textur einer Flche umwandeln, um die Darstellung der Silhouette zu ermglichen. Fr die Bilddaten bietet sich der Datentyp OSC-Blob an, da dieser Binrdaten flexibler Gre aufnimmt. Beachtet werden muss hierbei, dass zum Speichern von Bewegungen der komplette Inhalt eines OSC Bundles in eine Text-Datei geschrieben wird und das Ende des Bundles mit dem Character-Tupel ende gekennzeichnet wird. Ein solches Tupel knnte ebenfalls in einer Bilddatei vorhanden sein. Ist in den OSC-Bundles ein OSC-Blob enthalten, muss beim Auslesen der Text-Datei jedes vier-Byte-Paket direkt interpretiert werden, um zu entscheiden, ob die folgenden vier-Byte-Pakete einem Datenobjekt angehren oder ob es sich um die Endmarkierung handelt (vgl. Kapitel 5.2.). Des Weiteren knnte getestet werden, inwieweit sich die physikalischen Simulationen der Game-Engine eignen, damit das Modell in Abhngigkeit der Bein-Haltung seine vertikale Position ndert, die Fe also immer Kontakt zum Boden haben. Bei der Implementierung des Demonstrators wurde die ID des Benutzers nicht bercksichtigt. Somit ist kein Besttigen ntig, dass eine erkannte Person getrackt werden soll. Es muss jedoch sichergestellt werden, dass nur eine Person im Sichtbereich der Kamera ist, da ansonsten die Skelettdaten von mehreren Benutzern auf das Menschmodell bertragen werden. Schlielich wird mit der Konzeption eines haltungsbasierten Ergonomie-Bewertungsverfahren wird ein Ausblick gegeben, wie Ergebnisse dieser Arbeit verwendet werden knnen.
54
9. Literaturverzeichnis
amazon.de (o. J.). Retrieved April 18, 2012, from http://www.amazon.de/Xbox-360-Kinect-SensorAdventures/dp/B003H4QT7Y Aueragsakul, T. (o. J.). Retrieved April 18, 2012, from http://tigermyuou.deviantart.com/art/MotionCapture-Fighting-185797335 Berufsgenossenschaftliches Institut fr Arbeitsschutz (o. J.). Das Cuela-Messsystem. Retrieved April 18, 2012, from http://www.dguv.de/ifa/de/fac/ergonomie/pdf/text1a.pdf Blendercommunity (2009). Blender Dokumentation: Die Geschichte von Blender. Retrieved April 18, 2012, from http://de.wikibooks.org/wiki/Blender_Dokumentation:_Die_Geschichte_von_Blender blender.freemovies.co.uk (o. J.). Retrieved April 18, 2012, from http://blender.freemovies.co.uk character-studio.net (o. J.). BVH File Specification. Retrieved April 18, 2012, from http://www.characterstudio.net/bvh_file_specification.htm Coyner, R. (o. J.). Python-OSC Documentation. Retrieved April 18, 2012, from http://docs.ryancoyner.com/python-osc/ creativeapplications.net (2010). Retrieved April 18, 2012, from http://www.creativeapplications.net/maxmsp/kinect-one-week-later-processing-of-cinder-maxmsp/ das.nasophon.de (o. J.). pyliblo. Retrieved April 18, 2012, from http://das.nasophon.de/pyliblo/ DIN (2011). DIN CEN ISO/TR 7250-2. Wesentliche Mae des menschlichen Krpers fr die technische Gestaltung - Teil 2: Anthropometrische Datenbanken einzelner Bevlkerung von ISO-Mitgliedslndern (ISO/TR 7250-2:2010) ; Deutsche Fassung CEN ISO/TR 7250-2:2011 Duffy, J. (2010). Exclusive: Inside Project Natals Brain. The artificial intelligence behind Microsofts Xbox 360 motion-sensing game controller. Retrieved April 18, 2012, from http://www.popsci.com/gadgets/article/2010-01/exclusive-inside-microsofts-project-natal Elliott, P. (2010). Microsoft drops internal Natal chip. Retrieved April 28, 2012, from http://www.gamesindustry.biz/articles/microsoft-drops-internal-natal-chip_1 Freedman, B., Shpunt, A., Machline, M., & Ariele, Y. (2010). United States Patent Application Publication: DEPTH MAPPING USING PROJECTED PATTERNS. Retrieved April 28, 2012, from http://www.freepatentsonline.com/20100118123.pdf Harris, C., & Sinclair, S. (o. J.). liblo: Lightweight OSC implementation. Retrieved April 18, 2012, from http://liblo.sourceforge.net/
55
IAD (2009). European Assembly Worksheet (V 1.3.2c de)
iheartrobotics.com (2011). ASUS Xtion PRO LIVE Unboxing. Retrieved April 18, 2012, from http://www.iheartrobotics.com/2011/09/asus-xtion-pro-live-unboxing.html Gonalves, T. (o. J.). OSCeleton. Retrieved April 18, 2012, from https://github.com/Sensebloom/OSCeleton
heise.de (2010). Open-Source-Treiber fr Kinect verffentlicht. Retrieved April 28, 2012, from http://heise.de/-1135025 Kaiser, P. (2008). Netzwerkkommunikation. Retrieved April 18, 2012, from http://openbook.galileocomputing.de/python/python_kapitel_20_001.htm Makehuman.org (o. J.). Retrieved April 18, 2012, from www.makehuman.org Metamotion.com (o. J.). Optical Motion Capture Systems. Retrieved April 28, 2012, from http://www.metamotion.com/motion-capture/optical-motion-capture-1.htm
microsoft.com (o. J.). KINECT for Windows.faq. Retrieved April 18, 2012, from http://www.microsoft.com/en-us/kinectforwindows/news/faq.aspx openkinect.org (o. J.). Protocoll Documentation. Retrieved April 18, 2012, from http://openkinect.org/wiki/Protocol_Documentation openni.org (o. J.). Programmer Guide. Retrieved April 18, 2012, from http://openni.org/Documentation/ProgrammerGuide.html Penven, A. Retrieved April 18, 2012, from http://www.flickr.com/photos/audreypenven/5197391931/in/set-72157625454305998 PrimeSense (2011). NITE Algorithms.pdf Schindler, M. (2010). Erster Open-Source-Treiber fr Kinect. Retrieved April 28, 2012, from http://www.silicon.de/41540539/erster-open-source-treiber-fuer-kinect/ Taylor, T. (2011). Kinect for Robotics. Retrieved April 18, 2012, from http://blogs.msdn.com/b/msroboticsstudio/archive/2011/11/29/kinect-for-robotics.aspx UC Berkeley (o. J.). The Open Sound Control 1.0 Specification. Retrieved April 18, 2012, from http://opensoundcontrol.org/spec-1_0
56
wikipedia.org (o. J.). Retrieved April 18, 2012, from http://upload.wikimedia.org/wikipedia/commons/d/d1/9-facex3.jpg zigfu.com (o. J.). Retrieved April 18, 2012, from http://zigfu.com/
57
Anhang a. Anforderungsliste Bezeichnung Technische Daten

Frames per Second Frames per Second Auflsung Auflsung 25fps >25fps 800x600 beliebig gro, z.B. FullHD F W F W
Wert
Erluterung
F/W
Funktionen
Aufnehmen und Speichern von Aufnehmen Bewegungen innerhalb einer flexiblen Zeitspanne Abspielen Editieren Bewegungsmusterdatenbank Live Live mit Vorschau (PiP) Beschrnkung auf Krperzonen Kleidung mitbewegen -3 mnnliche und 3 weibliche Anzahl Krperbautypen Parameter Krperbau Parameter Gestaltung 6 - Verschiedene Krpergren 2 2 mnnlich, weiblich Standard, bekleidet F W F Bild-in-Bild-Funktion zur Anzeige der Silhouette des Benutzers F W W W W W W F
Rekonstruktion Krperhaltung
Krperhaltung Rumpf und Extremitten F
58
Translation Krperschwerpunkt
59

Bachelor Bericht

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Bachelor Bericht

Uploaded by

Copyright:

Available Formats

Bachelorthesis

Anbindung des Kinect-Systems an die Animationssoftware Blender

Anbindung des Kinect-Systems an die Animationssoftware Blender

Erklrung zur vorliegenden Arbeit gem 22/7 bzw. 23/7 APB

TU Darmstadt IAD | Eissfeldt| 2012

Geheimhaltungserklrung / Rechte an der Arbeit

TU Darmstadt IAD | Eissfeldt| 2012

TU Darmstadt IAD | Eissfeldt| 2012

TU Darmstadt IAD | Eissfeldt| 2012

TU Darmstadt IAD | Eissfeldt| 2012

TU Darmstadt IAD | Eissfeldt| 2012

TU Darmstadt IAD | Eissfeldt| 2012

TU Darmstadt IAD | Eissfeldt| 2012

1. Motivation und Aufgabenstellung

TU Darmstadt IAD | Adrian Eissfeldt | 2012

Bemerkung - 3 mnnliche, 3 weibliche

Bewegungen innerhalb einer flexiblen Zeitspanne

Funktion Wiedergeben Rekonstruktion Krperhaltung

- Gespeicherte Sequenz wiedergeben

TU Darmstadt IAD | Adrian Eissfeldt | 2012

3. Stand der Technik

TU Darmstadt IAD | Adrian Eissfeldt | 2012

3.2. Optisches Motion Capture mit Markern

TU Darmstadt IAD | Adrian Eissfeldt | 2012

Abbildung 3.4: Tiefenmessung mit optischer Triangulation

TU Darmstadt IAD | Adrian Eissfeldt | 2012

Abbildung 3.5: Kinect (verndert nach: amazon.de)

TU Darmstadt IAD | Adrian Eissfeldt | 2012

TU Darmstadt IAD | Adrian Eissfeldt | 2012

Informationsverarbeitung jedoch noch richtig interpretiert werden.

3.4. Asus Xtion Pro Live

3.5. Kinect SDK

TU Darmstadt IAD | Adrian Eissfeldt | 2012

Abbildung 3.10: Identifizierbare Gelenke mittels Microsoft SDK (Quelle: Taylor)

3.6. OpenNI Framework

TU Darmstadt IAD | Adrian Eissfeldt | 2012

Abbildung 3.11: Konzept von OpenNI (Quelle: openni.org)

TU Darmstadt IAD | Adrian Eissfeldt | 2012

TU Darmstadt IAD | Adrian Eissfeldt | 2012

Abbildung 3.12: Mit Nite identifizierbare Gelenke

TU Darmstadt IAD | Adrian Eissfeldt | 2012

Abbildung 3.15: Blender Properties

TU Darmstadt IAD | Adrian Eissfeldt | 2012

Abbildung 3.16: MakeHuman Screenshot

TU Darmstadt IAD | Adrian Eissfeldt | 2012

4. Konzeption zur Verarbeitung der Kinect-Daten

Abbildung 4.1: Unterteilung Gesamtkonzept

4.1. Schnittstelle Kinect Blender

TU Darmstadt IAD | Adrian Eissfeldt | 2012

Erkennt spezifische Gesten

TU Darmstadt IAD | Adrian Eissfeldt | 2012

Skelettdaten zur Verfgung stellen

TU Darmstadt IAD | Adrian Eissfeldt | 2012

TU Darmstadt IAD | Adrian Eissfeldt | 2012

TU Darmstadt IAD | Adrian Eissfeldt | 2012

TU Darmstadt IAD | Adrian Eissfeldt | 2012

Abbildung 4.2: OSCeleton Hilfe

TU Darmstadt IAD | Adrian Eissfeldt | 2012

TU Darmstadt IAD | Adrian Eissfeldt | 2012

Abbildung 4.3: Darstellung eines OSC-Bundles

TU Darmstadt IAD | Adrian Eissfeldt | 2012

TU Darmstadt IAD | Adrian Eissfeldt | 2012

4.2. bertragung der Skelettdaten auf ein digitales Menschmodell

TU Darmstadt IAD | Adrian Eissfeldt | 2012