Bachelor Bericht

Bachelorthesis

Anbindung des Kinect-Systems an die Animationssoftware BlenderConnecting the Kinect device to the Blender Software

Adrian Eissfeldt

2012

Bachelorthesis

Anbindung des Kinect-Systems an die Animationssoftware BlenderConnecting 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

i

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

ZusammenfassungUm 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


v

Abbildungsverzeichnis3.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

Tabellenverzeichnis1.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 AufgabenstellungDas 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

1

2. AnforderungenDas 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

F

Auswahl Krperbautypen

6 Modelle

- Krpergre entsprechend den Durchschnittswerten verschiedener Bevlkerungsgruppen - Aufnehmen und Speichern von

F

Funktion Aufnehmen

-

Bewegungen innerhalb einer flexiblen Zeitspanne

F F

Funktion Wiedergeben Rekonstruktion Krperhaltung

Extremitten, Rumpf -

- Gespeicherte Sequenz wiedergeben

W

Rekonstruktion Krperposition

- Position des Modells entsprechend der Positionsnderung des Users ndern - Das Modell wird nach jedem empfangenen Frame neu ausgerichtet

W

Verarbeitung in Echtzeit

-


2

3. Stand der TechnikZur 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. CUELACUELA (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).


3

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 MarkernBei 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)


4

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


5

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. KinectFr 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)


6

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.


7

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 LiveDieses 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 (sieheTU 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 SDKVor 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.


9

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 FrameworkDie 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. NitePrimeSense 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. BlenderBlender 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. MakeHumanMakeHuman 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 BlenderUm 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

b

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 MenschmodellIn 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 kgebildet, 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 q1TU Darmstadt IAD | Adrian Eissfeldt | 2012

(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. DemonstratorDer 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 EngineZum 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 DemonstratorDer 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 AuswahlBeschreibung 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 EinzelansichtBeschreibung 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 BlenderEin 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 CaptureBlender 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 besc

Documents

Bachelor Bericht