Entwicklung eines Virtual Reality System aus einem Head-Mounted-Display und der Microsoft Kinect

Inhaltsverzeichnis

1. Einführung
1.1 Motivation
1.2 Aufbau der Arbeit
1.3 Voraussetzungen und Grundlagen zum Verständnis der Arbeit

2. Projektorganisation und Vorgehen
2.1 Gruppenarbeit und Aufgabenteilung
2.2 Vorgehensmodell und Zeitplanung

3. Anforderungsanalyse
3.1 Einführung
3.2 Zielbeschreibung
3.3 Anforderungen Middleware
3.3.1 Funktionale Anforderungen
3.3.2 Nichtfunktionale Anforderungen
3.4 Anforderungen Beispielanwendung
3.4.1 Funktionale Anforderungen
3.4.2 Nichtfunktionale Anforderungen
3.5 Vorhandene Systeme
3.6 Technische Umgebung
3.7 Anwendungsfallmodell
3.7.1 Akteure
3.7.2 Anwendungsfälle des Assistenten
3.7.2.1 Anwendung starten
3.7.3 Anwendungsfälle des Nutzers
3.7.3.1 Skeletterkennung kalibrieren
3.7.3.2 Kopflage kalibrieren
3.7.3.3 Kameraposition und -Rotation anpassen
3.7.3.4 Geste durchführen
3.7.3.5 Pose einnehmen
3.7.3.6 Gegenstand berühren
3.7.3.7 Skelett bewegen
3.7.4 Anwendungsfälle des Middleware-Nutzers
3.8 Dynamisches Modell
3.8.1 Sequenzdiagramme des Assistenten
3.8.1.1 Skeletterkennung kalibrieren
3.9 Objektmodell

4. Systementwurf
4.1 Entwurfsziele
4.2 Systemzerlegung
4.3 Globaler Kontrollfluss
4.4 Datenhaltung
4.5 Hard- und Softwareplattform
4.5.1 Wahl der Programmiersprache

5. Implementierung
5.1 Meilensteine der Implementierung
5.1.1 Erster Meilenstein (30.09.2011)
5.1.2 Zweiter Meilenstein (01.11.2011)
5.1.3 Dritter Meilenstein (06.12.2011)
5.2 Implementierung der einzelnen Systemkomponenten
5.2.1 Erster Meilenstein
5.2.1.1 Head-Mounted-Display
5.2.1.2 Darstellung der Kinect-Skelett-Daten durch eine Figur in der Engine
5.2.1.3 Build-Skript
5.2.2 Zweiter Meilenstein
5.2.2.1 Szenenverwaltung
5.2.2.2 Sound-Subsystem
5.2.2.3 Stereoskopische Ansicht (stereoPlugin)
5.2.2.4 Posen
5.2.3 Dritter Meilenstein
5.2.3.1 Exceptions
5.2.3.2 Gestenerkennung
5.2.3.3 Linuxtreiber der Vuzix-Brille
5.2.3.4 Bereitstellung des Zustandes der Middleware
5.2.3.5 Licht und Schatten
5.2.3.6 Spiegel und Fernseher
5.2.3.7 Modifizierter Oger
5.2.3.8 Scripting
5.2.3.9 Kollision

6. Testen
6.1 C++ Unittest-Frameworks
6.2 TestDog
6.3 Ziele und Vorgehensweise
6.4 Code-Review

7. Evaluation
7.1 Formulierung von Thesen
7.1.1 Erläuterung der Thesen
7.1.1.1 Die Bedienbarkeit des Systems (Hypothese 1)
7.1.1.2 Grad der Immersion bei Nutzung des gesamten Systems (Hypothese 2)
7.1.1.3 Vorteil durch Bewegungssteuerung (Hypothese 3)
7.1.1.4 Präsenzempfinden durch das HMD (Hypothese 4)
7.2 Vorbereitung der Evaluation
7.2.1 Der Fragebogen zum Messen der Immersion
7.3 Die virtuelle Umgebung
7.4 Durchführung der Evaluation
7.5 Ergebnisse der Evaluation
7.5.1 Qualitative Auswertung
7.5.2 Mathematische Auswertung
7.5.2.1 Immersionsgrad der Versuchsaufbauten
7.5.2.2 Bewegung in der virtuellen Welt
7.5.2.3 Präsenzempfinden
7.5.2.4 Geräusche in der virtuellen Welt
7.5.2.5 Vergleich zur realen Welt
7.6 Fazit

8. Fazit und Ausblick

9. Literaturverzeichnis

10. Anhang
10.1 Schnittstellenfunktionen
10.1.1 registerPose, registerGesture
10.2 Installation
10.2.1 Windows
10.2.2 Unix
10.3 Fragebogen
10.4 Erhobene Daten der Fragebögen
10.5 Probandeninformation

1. Einführung

Die Projektgruppe „Virtual Reality“ der Universität Oldenburg hatte die Aufgabe ein System zu entwickeln, welches Nutzern die Möglichkeit gibt, in virtuelle Welten einzutauchen. Das Projekt startete im April 2011 und endete im März 2012. Realisiert wurde das VR-System durch die Kombination von Bewegungserfassung über eine Microsoft Kinect mit einer Videobrille der Firma Vuzix. Zu diesem Zweck haben wir eine Middleware implementiert, die die Signale der genannten Hardware verarbeitet und als Schnittstelle zu einer grafischen Anwendung fungiert. Die virtuelle Szene haben wir mit Blender modelliert und verwenden die Grafik-Engine Ogre3D. Unser Hauptziel bei der Entwicklung war ein möglichst hoher Immersionsgrad des VR-System, der sich von klassischen Desktop-PC´s deutlich abhebt. Um unsere Zielerfüllung zu überprüfen, haben wir das System am Ende des Projekts umfangreich evaluiert.

1.1 Motivation

Virtuelle Realitäten haben in den letzten Jahrzehnten Einzug in viele verschiedene Branchen gehalten. Neben der Unterhaltungsindustrie zählen hierzu auch Medizin, Militär und Ingenieurswesen. Da die Preise der benötigten Hardwarekomponenten in den letzten Jahren deutlich gefallen sind, ist der Einsatz von VR auch bei Heimanwendern möglich. Unser Streben nach einer kostengünstigen Lösung für ein immersives VR-System und die Entwicklung einer Middleware, die als Grundlage anderer Projekte dient, sind unsere Motivation zur Durchführung des Projekts.

1.2 Aufbau der Arbeit

Kapitel 2 behandelt die Dokumentation der Projektorganisation. Kapitel 3 umfasst die Anforderungsanalyse für das zu entwickelnde System. Diese wurde in Kapitel 4 in ein Systementwurfsmodell überführt. Kapitel 5 dokumentiert die Implementierung des Systems. Die verwendeten Testverfahren sind Gegenstand des Kapitels 6. Kapitel 7 behandelt die Evaluation des entwickelten Systems. In Kapitel 8 wird abschließend das Gesamtfazit und ein Ausblick präsentiert.

1.3 Voraussetzungen und Grundlagen zum Verständnis der Arbeit

Grundlagenkenntnisse der Softwareentwicklung sind nötig um die in diesem Dokument beschriebenen Entwicklungsschritte nachvollziehen zu können.

2. Projektorganisation und Vorgehen

In diesem Kapitel wird die Planung des Projektes und das Vorgehensmodell beschrieben. Ziel der Veranstaltungsform „Projektgruppe“ ist die Umsetzung eines Projektes und Realisierung eines Produktes wie in einem Unternehmen. Im Gegensatz zu einem Unternehmen, das in der freien Wirtschaft agiert und angestellte Mitarbeiter hat, finden sich in einer universitären Projektgruppe Studierende zusammen, die gemeinsam mit einer Problemstellung konfrontiert werden und diese innerhalb eines Jahres lösen müssen.

Im Fall der Projektgruppe Virtual Reality haben sich sechs Studierende zusammengefunden, die mit unterschiedlichen Voraussetzungen, aber ähnlichen Motivationen ihre Zusammenarbeit selbstständig organisieren müssen. Im Folgenden werden die Vorgehensweise und die Erfahrungen im Verlauf der Projektgruppe beschrieben. Die Gruppenarbeit und die Aufgabenteilung werden in Abschnitt 2.1 dargestellt. Ebenso zählen hierzu die Mittel, die wir zur Kommunikation in der Gruppe eingesetzt haben und das Konfigurationsmanagement. Das Vorgehensmodell und die Zeitplanung werden in Abschnitt 2.2 vorgestellt.

2.1 Gruppenarbeit und Aufgabenteilung

Zur Organisation der Gruppenarbeit wurde im ersten Treffen ein Projektleiter bestimmt, der für die Organisation des Projektes verantwortlich war. Für die einzelnen Aufgaben bei der Entwicklung des Systems waren meist zwei Personen als Kleingruppe verantwortlich, sodass eine hohe Qualität und eine gleichmäßige Arbeitsteilung gewährleistet werden konnten.

Zur Kommunikation innerhalb der Gruppe wurde, wie für Projektgruppen typisch, ein Mailverteiler eingesetzt. Darüber hinaus kam das Projektmanagement-Tool

Redmine ^[1] zum Einsatz. Dieses bietet ein Ticket-Tracking-System, bei dem jedem Projektmitglied Aufgaben (Tickets) zugewiesen werden können. Mit dem TicketTracking-System kann für das gesamte Projekt oder für Unterprojekt der Fortschritt in einem Gantt-Diagramm angezeigt werden: So wird visualisiert, ob die gesetzten Fristen eingehalten werden. Darüber hinaus bietet Redmine ein Wiki an, das unkompliziert für organisatorische Aspekte wie Protokolle, Tagesordnungen und Notizen verwendet wurde.

Um eine komfortable Zusammenarbeit zu gewährleisten, wurde die Versionsverwaltung git ^[2] verwendet. Diese bietet eine dezentrale Versionskontrolle und erleichtert die Arbeit am Projekt von unterschiedlichen Rechnern und Orten.

2.2 Vorgehensmodell und Zeitplanung

Während der Seminarphase wurden die Projektziele detailliert ausgearbeitet. Das weitere Vorgehen, dargestellt in Abb. 2.1, wurde in den folgenden Phasen durchgeführt: In der Anforderungsanalyse (Kapitel 3), deren Datum zur Fertigstellung auf den 21.06.2011 festgelegt wurde, wurden die Zielsetzung und die genauen Anforderungen aufgestellt. Das dabei erstellte Modell wurde im Systementwurf (Kapitel 4) verfeinert und die konkrete Umsetzung des Systems geplant. Die Frist hierfür war der 19.07.2011. Anschließend wurde in vier Schritten das System implementiert (genauer beschrieben in Kapitel 5):

Meilenstein 1 (Frist: 30.09.2011) Grundgerüst und grundsätzliche Nutzung der Hardware

Meilenstein 2 (Frist: 01.11.2011) Verbesserung der Bedienung und vollständige Nutzung der Hardware

Meilenstein 3 (Frist: 06.12.2011) Vollständige Umsetzung der Anforderungen und Anwendungsfälle, komfortable Bedienung

Umfangreiche Beispielanwendung Erschaffen einer komplexen virtuellen Welt zur Demonstration der Features

(Anschließend soll das System in einer Evaluation mit Versuchspersonen getestet werden.)

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1.: Vorgehensmodell

3. Anforderungsanalyse

3.1 Einführung

Ziel der Anforderungsanalyse ist das Ermitteln der genauen Anforderungen an das System. Diese Analyse ist das Fundament für die Software-Entwicklung. Die Anforderungen sollten daher möglichst vollständig, widerspruchsfrei und realisierbar definiert werden. Fundamentale Fehler in der Anforderungsanalyse können auch im weit fortgeschrittenen Entwicklungsprozess noch zum Scheitern komplexer Softwareprojekte führen.

3.2 Zielbeschreibung

Im Folgenden wird auf die Zielsetzung des zu realisierenden Projekts eingegangen. Es soll ein Virtual Reality System (ab hier: VR-System) realisiert werden, das es einem Benutzer ermöglicht in virtuelle Umgebungen einzutauchen. Nach der Entwicklung einer Lösung zu dieser Problemstellung soll diese in Hinblick auf die Zielsetzung evaluiert werden. Dabei wird sowohl Handhabung, als auch das Präsenzgefühl, das bei einem Benutzer bei der Verwendung des VR-Systems vorherrscht, untersucht. Zusätzlich zu der Realisierung des VR-Systems soll eine quasi-experimentelle Studie ausgearbeitet werden, die das Präsenzempfinden in verschiedenen virtuellen Umgebungen untersucht.

Nachfolgend werden die Hauptkomponenten des Präsenzgefühls erwähnt und zu realisierende Ziele für die jeweiligen Einflussfaktoren angegeben. Danach wird auf den Aufbau der Eingabe- und Ausgabeschnittstellen und auf die Implementierung der benötigten Software eingegangen.

In der Seminararbeit “Präsenzempfinden in virtuellen Umgebungen“ wurden Modelle betrachtet, die das Präsenzgefühl als Produkt verschiedener Einflussfaktoren definieren. Dabei spielt sowohl die räumliche Präsenz, die durch geeignete Eingabe- und Ausgabeschnittstellen intensiviert werden kann, als auch die soziale Präsenz und die Eigenwahrnehmung eine entscheidende Rolle. Die Wahl der Eingabe- und Ausgabeschnittstellen mithilfe derer sich ein Benutzer in eine virtuelle Umgebung hineinversetzt ist demnach ein signifikanter Faktor für die Umsetzung eines immersiven VR-Systems.

Die soziale Präsenz beschreibt Einflussfaktoren, die durch das Phänomen der gesteigerten Involvierung in gesellschaftliche Zusammenhängen hervorgerufen wird. Die Einbindung von virtuellen Charakteren, die entweder einem einfachen Verhaltensmuster entsprechen oder durch ein Agentensystem komplex nachgebildet werden, vermittelt dem Benutzer das Gefühl in diesem sozialen Gefüge anwesend zu sein. In Bezug auf diesen Aspekt wird versucht die virtuelle Umgebung mit minimalistischen, aber entscheidenden Mitteln zur Förderung der sozialen Präsenz zu unterstützen.

Die Eigenwahrnehmung umfasst die innerliche Auseinandersetzung eines Benutzers mit seinem virtuellen Avatar. Der Benutzer identifiziert sich mit ihm selbst, sodass der Avatar eine virtuelle Schnittstelle zwischen dem Benutzer und der virtuellen Umgebung darstellt. Dieser Effekt soll in die virtuelle Umgebung durch Spiegel und dynamischen Schattenwurf des Körpers genutzt werden um den Einflussfaktor der Eigenwahrnehmung zu steigern.

In den Seminararbeiten, die im Rahmen der Projektgruppe ausgearbeitet wurden, sind verschiedene Arten von VR-Systemen angesprochen worden. Die Systeme bieten unterschiedlich reichhaltige Möglichkeiten zur Interaktion mit virtuellen Umgebungen und erfordern einen unterschiedlich komplexen Aufbau. Die Projektgruppe hat festgelegt, dass das zu realisierende VR-System möglichst einfach aufzubauen ist. Es soll die Benutzung durch einem für Heimanwender zu einem erschwinglichen Preis ermöglichen.

Die Eingabe- und Ausgabeschnittstellen, die dem Einflussfaktor der räumlichen Präsenz zuzuordnen sind, sollen folgende Interaktion und Wahrnehmung mit der virtuellen Umgebung ermöglichen: Ein Benutzer kann sich grobmotorisch frei in der virtuellen Umgebung bewegen. Diese Körperpose des Benutzers wird demnach auf die Körperpose seines digitalen Abbilds übertragen. Diese Funktion wird von der von uns verwendeten Microsoft Kinect bereitgestellt und wird als technische Komponente im VR-System vorausgesetzt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1.: Kinect (Quelle: Microsoft)

Eine weitere Vorrausetzung stellt ein Lagesensor für die Neigung des Kopfes in sechs Freiheitsgeraden dar. Bei der Neigung des Kopfes wird gegenüber dem restlichen Körper die Präzision als besonders wichtig erachtet, um Fehler in der Auslenkung des Sichtbereiches und damit gegebenenfalls Simulatorübelkeit zu vermeiden.

Nach der Festlegung der Eingabeschnittstellen folgt im Weiteren die Betrachtung der Ausgabeschnittstellen mit derer einem Benutzer künstliche Reize vermittelt werden. Das Head-Mounted-Display zählt zu den Standardwerkzeugen im Forschungsbereich Virtual Reality und soll auch in unserem VR-System als audiovisuelle Ausgabeschnittstelle verwendet werden.

Bei der Auswahl der Videobrille hatten wir zwei Alternativen: Das Modell Cinemizer von Carl Zeiss und das Modell Wrap 920 VR von Vuzix. Wir haben uns für das Modell von Vuzix entschieden, da sie im Gegensatz zur Cinemizer einen Lagesensor mit sechs Freiheitsgraden bereits integriert hat. Somit musste nicht zusätzlich ein Lagesensor beschafft werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.2.: Vuzix Wrap 920 VR (Quelle: Vuzix)

Der Benutzer nimmt den Sichtbereich seines Avatars über eingebaute Bildschirme wahr. Der Sichtbereich des Benutzers wird dabei auf die Bildschirme reduziert, sodass der Benutzer gegenüber externer Reizeinflüsse isoliert wird. Die eingebauten Stereokopfhörer ermöglichen ferner die Vermittlung akustischer Reize, die im Zusammenhang mit emuliertem Raumklang eine weitere Orientierungsmöglichkeit in der Umgebung anbieten.

Es soll nun der Aufbau der benötigten Software beleuchtet werden. Das zu entwickelnde Softwaresystem soll sich zwei Komponenten zusammensetzen: Einer Bibliothek, die die Ansteuerung der Microsoft Kinect und des HMD kapselt, und einer unabhängigen Anwendung, die als Modell und Laufzeitumgebung für die virtuelle Umgebung dient. Die Bibliothek kann dabei auch als Middleware zwischen der VR-Hardware und der virtuellen Umgebung angesehen werden. Durch die Trennung soll erreicht werden, dass verschiedene Anwendungen mit der nachhaltig entwickelten Bibliothek angesprochen werden können.

Zusätzlich zu der Kapselung der Treiber soll die Bibliothek die Funktion zur Speicherung von Gesten anbieten. Das Erkennen einer Geste soll dabei zu einem bestimmten vordefinierten Ereignis führen.

Die Anwendung soll mithilfe der Bibliothek die Körperpose und die Kopflage des Benutzers in einen entsprechenden Avatar überführen und die virtuelle Umgebung in Abhängigkeit der Körperpose, Kopflage und Position des Avatars visuell darstellen. Die erzeugten Bildinformationen der virtuellen Welt sollen zur visuellen Reizvermittlung über das HMD genutzt werden. Ferner soll die Anwendung in der Lage sein, eine vorgegebene Klangumgebung zu erzeugen. Die akustischen Reize werden dabei über den eingebauten Stereokopfhörer des HMD vermittelt. In Bezug auf Interaktion soll eine Kollisionserkennung des virtuellen Avatars mit der Umgebung stattfinden. Zum Laden verschiedener virtueller Umgebungen soll ein Dialogmenü angeboten werden.

Bei der Entwicklung der Anwendung wird die plattformunabhängige Spiele-Engine OGRE 3D verwendet, die neben grundlegenden grafischen Technologien wie Modellen, Animationen, Charakterskelette, Texturen, Reflexionen und Schatten auch 3D-Raumklang unterstützt.

Da sowohl der Treiber für die Microsoft Kinect, der Treiber Vuzix Wrap und die Spiele-Engine OGRE 3D für Microsoft Windows, Linux und Apple Mac OS X portiert sind, liegt eine wünschenswerte plattformunabhängige Realisierung des VR-Komplettsystems nahe. Das erarbeitete System wird ferner über eine quelloffene Lizenz der Öffentlichkeit zugänglich gemacht.

3.3 Anforderungen Middleware

Das Projekt besteht aus zwei Teilanwendungen: Es soll eine Middleware entwickelt werden und die Nutzung dieser in einer beispielhaften Anwendung (Frontend) umgesetzt werden.

3.3.1 Funktionale Anforderungen

Die zu entwickelnde Middleware soll Features anbieten, die Programmierern die Möglichkeit bietet, mit geringem Aufwand eine Anwendung zu schreiben, welche eine hohe Immersion liefert. Dabei soll eine Funktionalität zur Skeletterkennung eines Menschen im dreidimensionalen Raum angeboten werden. Als weitere zentrale Anforderung ist die Bereitstellung der Kopfdrehung zu nennen. Hier soll die Nutzung des Lagesensors gekapselt werden, sodass der Programmierer keine Kenntnisse über die verschiedenen Treiber für die Vuzix-Brille haben muss. Es ist darauf zu achten, dass die Nutzung der Middleware möglichst einfach und verständlich erfolgen kann und nur minimale Kenntnisse der eingesetzten Hardware notwendig sind. Zudem muss mithilfe der Middleware eine Anzahl von vordefinierten Gesten, welche von einem Menschen ausgeführt werden, algorithmisch erkannt werden. So soll zum Beispiel das Winken eines Nutzers als solches erkannt werden und eine Reihe von Listenern benachrichtigt werden, welche sich zuvor bei der jeweiligen Geste angemeldet haben.

3.3.2 Nichtfunktionale Anforderungen

Eine einfache Bedienbarkeit der Middleware setzt eine gute Dokumentation voraus. So sollen Entwickler sich möglichst ohne große Hürden sich in den Quellcode und die eigentliche Thematik einarbeiten können. Die Bedienungsanleitung muss Interaktionsmöglichkeiten, sowie Posen und Gesten, die zur Interaktion dienen, erklären.

Bezogen auf die Zuverlässigkeit sind die ausgehenden Daten (z.B. erkannte Geste) korrekt auszugeben oder bei fehlerhaften Daten entsprechende Fehlermeldungen. Der Durchsatz zur Verarbeitung aller von der Kinect ankommenden Daten ist zu gewährleisten. Des Weiteren soll die Antwortzeit möglichst kurz sein, so dass der Eindruck einer Verarbeitung der Daten in Echtzeit gewonnen wird. Eine Portabilität ist anzustreben, vor allem für Windows und Linux, wobei MacOS als optionale Anforderung in den Hintergrund tritt. Als Implementierungsanforderung wird sauberer C++-Quellcode verlangt, sowie die Erstellung mit CMake. Weitere Anforderungen an die Implementierung sind in Abschnitt 4.5.1 aufgeführt. Eine gute Dokumentation der Middleware und dessen Schnittstelle wird vorausgesetzt, wobei das Dokumentationstool „Doxygen“ zu verwenden ist.

3.4 Anforderungen Beispielanwendung

3.4.1 Funktionale Anforderungen

Als Beispiel für die Nutzung der Middleware soll eine grafische Anwendung erstellt werden, welche die entwickelte Middleware verwendet. Der von uns geplante virtuelle Raum soll eine Wohnung in Italien abbilden. Die Wohnung soll dabei voll begehbar sein und die Immersion unterstützen. Erreicht wird dies durch eine realitätsnahe Gestaltung des Raumes. Zudem wird durch die Verwendung von Sound der Realitätsgrad weiter erhöht.

3.4.2 Nichtfunktionale Anforderungen

Die Bedienung der Anwendung soll ohne besondere Kenntnisse des Anwenders erfolgen. Optional soll während der ersten Bedienung zusätzliche Informationen/Hilfen auf der Brille angezeigt werden. Fehleingaben sind entweder zu ignorieren oder zu korrigieren. Gegebenenfalls sind zusätzliche Informationen einzublenden, die eine Aufforderung zur Wiederholung der Eingabe beinhalten. Gesichtspunkte wie die Portabilität, Implementierungs- und Dokumentationsanforderungen sind wie bei der Middleware zu handhaben.

Das Gesamtsystem, bestehend aus Beispielanwendung und Middleware, soll unter Berücksichtigung der technischen Möglichkeiten (3D-Engine, Sound usw.) einen möglichst hohen Grad an Immersion erzeugen. Alle potentiellen Anwender sollen das System nutzen können. Unabhängig von Geschlecht und Alter, ohne technisches Vorwissen jeder Art, ohne zu wissen was einen erwartet und ohne vor der Nutzung vom Operator bezüglich des Gebrauchs instruiert zu werden. Das System soll sich dem Nutzer vollständig selbst erklären. Der Nutzer entdeckt von selbst, dass seine Bewegungen in der Realität eins zu eins in der virtuellen Realität umgesetzt werden. Gesten und andere realitätsferne Funktionen werden während der Nutzung vom System erläutert. Ausgenommen von der völligen Eigenständigkeit des Anwenders ist das Starten des Systems, das Aufsetzen der VR-Brille und das Laden von Levels sowie die Kalibrierung des Nutzers für die Kinect.

3.5 Vorhandene Systeme

Im Bereich der Low-Budget VR-Systeme (< 1000e) sind Lösungen für die oben beschriebenen Anforderungen nicht bekannt. Dennoch kommen für das Projekt bereits vorhandene Lösungen als Teilkomponente zum Einsatz: die Microsoft Kinect und die Vuzix Videobrille. Eine vergleichbare Middleware ist zurzeit weder frei, noch kommerziell verfügbar. Im Bereich der auf der Middleware aufbauenden Anwendungssoftware gibt es bereits einige ähnliche Entwicklungen. Zum Beispiel Videospiele mit immersiver Wirkung oder VR-Software die im medizinischen Sektor zur Entspannung des Patienten eingesetzt wird.

3.6 Technische Umgebung

Das zu entwickelnde System soll auf herkömmlichen PC verwendbar sein. Für die Lokalisation des Anwenders und Gestensteuerung wird die Microsoft Kinect verwendet. Die Kinect verwendet für die Ermittlung von Tiefeninformationen die Technik des “Structured Light“. Es findet die Aussendung eines Musters in Form von “Infrared Structured Light“ über einen Infrarot-Sensor auf eine zu scannende Oberfläche statt. Eine Kamera zeichnet von einem anderen Punkt das verzerrte Muster auf. Die Tiefeninformationen können anschließend mit Stereo-Triangulation über die Verzerrung des aufgenommenen Musters errechnet werden. Weitergehend stellt die Kinect eine CMOS-Kamera mit einer Auflösung von 640 x 480 Pixel zur Verfügung, mit der aufgrund des physischen Abstands von RGB-Kamera und IR-Sensor Tiefenwerte auf Farbwerte abgebildet werden können. Auch besitzt die Kinect einen Stellmotor für das Verändern der vertikalen Ausrichtung der Kinect und ein Mikrofon, mit dem es möglich ist, Personen im Raum zu lokalisieren.

Als Ausgabe der virtuellen Welt für den Anwender wird die Video-Brille “Vuzix Wrap 920 VR“ verwendet. Diese Video-Brille bietet zwei unabhängig ansteuerbare 640 x 480 LCD´s, sowie einen Lagesensor mit sechs Freiheitsgraden, der die Bestimmung der Position und Neigung des Anwenderkopfes ermöglicht. Zudem wird von dem Hersteller ein SDK (Software Development Kit) angeboten. Nähere Informationen zu der 3D-Brille können unter Vuzix-Corporation [2012a] eingeholt werden.

Für die Darstellung einer virtuellen Welt in der Anwendung wird die 3D-Engine “Ogre 3D“ (Streeting [2012]) genutzt. Sie bietet Skelettanimationen und ist komplett in C++ ansprechbar.

3.7 Anwendungsfallmodell

Im Folgenden wird das Anwendungsfallmodell des zu entwickelnden Systems dargestellt. Da es sich bei diesem System um eine multimediale Anwendung handelt, fällt es teilweise schwer, Anwendungsfälle als solches zu definieren: Oft löst nicht der Akteur selber eine Aktion aus, sondern das System fragt in regelmäßigen Abständen den Zustand des Benutzers, wie z.B. die Position, ab. Da wir dennoch gewisse Aspekte als Anwendungsfall sinnvoll modellieren können, sind bei Abweichungen entsprechende für den weiteren Entwurf nützliche Notizen angefügt.

3.7.1 Akteure

Als Akteure wurden identifiziert:

Nutzer Ein Nutzer, der eine stereoskopische Ansicht der Welt sieht und mit der Welt interagieren kann.

Assistent Der Assistent startet die Anwendung und legt die Parameter der Ausführung fest.

Middleware-Nutzer (Programmierer) Ein Programmierer, der die zu entwickelnde Middleware in einem eigenen Programm einsetzt.

3.7.2 Anwendungsfälle des Assistenten

3.7.2.1 Anwendung starten

Abbildung in dieser Leseprobe nicht enthalten

3.7.3 Anwendungsfälle des Nutzers

In Abb. 3.3 sind die Anwendungsfälle des Nutzers als Anwendungsfalldiagramm dargestellt. Diese werden im Folgenden beschrieben.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.3.: Anwendungsfalldiagramm des Nutzers

3.7.3.1 Skeletterkennung kalibrieren

Abbildung in dieser Leseprobe nicht enthalten

3.7.3.2 Kopflage kalibrieren

Abbildung in dieser Leseprobe nicht enthalten

3.7.3.3 Kameraposition und -Rotation anpassen

Abbildung in dieser Leseprobe nicht enthalten

3.7.3.4 Geste durchführen

Abbildung in dieser Leseprobe nicht enthalten

3.7.3.5 Pose einnehmen

Abbildung in dieser Leseprobe nicht enthalten

3.7.3.6 Gegenstand berühren

Abbildung in dieser Leseprobe nicht enthalten

3.7.4 Anwendungsfälle des Middleware-Nutzers

Für den Middleware-Nutzer werden keine tatsächlichen Anwendungsfälle beschrieben. Dieser kann die Middleware in sein eigenes Softwareprojekt einbauen und als Grundgerüst nutzen. Dabei kann er folgende Aktionen durchführen:

- Middleware in Programm einbinden
- Neue Instanz der Middleware erstellen
- Instanz der Middleware beenden
- Status-Informationen abfragen
- Skelett-Daten verwenden
- Kamera-Daten verwenden
- Neue Pose definieren
- Event-Handler implementieren
- Event-Handler an Posen und Gesten binden

3.8 Dynamisches Modell

Im Folgenden wird das dynamische Modell des zu entwickelnden Systems festgelegt. Zunächst wird in Abschnitt 3.8.1 das Verhalten des Systems in Sequenzdiagrammen dargestellt. Diese dienen im Wesentlichen dazu, die Anwendungsfälle aus dem vorherigen Kapitel mit Objekten zu verbinden und die benötigten Objekte zu identifizieren (vgl. Bernd Brügge [2004]).

3.8.1 Sequenzdiagramme des Assistenten

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.4.: Sequenzdiagramm Welt laden: Der Assistent wählt die Funktion Level laden und anschließend ein Level aus. Diese wird von der Anwendung geladen.

3.8.1.1 Skeletterkennung kalibrieren

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.5.: Sequenzdiagramm Skeletterkennung kalibrieren: Der Nutzer nimmt die Kalibrierungspose ein, damit die Skeletterkennung kalibriert werden kann.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.6.: Sequenzdiagramm Skelett bewegen: Die Daten von der Kinect lösen ein Event aus, welches bewirkt, dass sich die Anwendung die aktuellen Skelett-Daten holt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.7.: Sequenzdiagramm Pose einnehmen: Die Person vor der Kinect nimmt eine zur Compile-Zeit definierte Pose ein. Diese Pose wird von der Middleware erkannt und ein entsprechendes Event in der Anwendung wird ausgelöst. Verschiedene Posen lösen verschiedene Events aus.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.8.: Sequenzdiagramm Geste durchführen: Die Middleware erkennt eine vordefinierte Geste des Benutzers. Ist für diese Geste ein Event registriert, wird dieses ausgelöst.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.9.: Sequenzdiagramm Gegenstand berühren: Wenn das virtuelle Skelett des Nutzers mit einem Gegenstand der virtuellen Welt kollidiert, kann dies in der Anwendung eine Reaktion auslösen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.10.: Sequenzdiagramm Kameraposition und -rotation anpassen: Die Anwendung fragt bei Middleware die Blickrichtung des Kopfes des Benutzers ab. Die Middleware liefert daraufhin die aktuelle, permanent vorgehaltene, Blickrichtung zurück.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.11.: Sequenzdiagramm Kopflage kalibrieren: Die Erkennung der Kopflage wird auf plausible Werte eingestellt.

3.9 Objektmodell

Das in Abbildung 3.12 dargestellte Objektmodell besteht aus Klassen, die sich im Wesentlichen in drei Gruppen ordnen lassen: Die Anwendung mit Model- und View-Klassen ist grün dargestellt. Die Middleware-Klasse ist rot dargestellt. Diese greift über zwei Wrapper-Klassen (blau) auf die Hardware zu. Hier sei angemerkt, dass das Diagramm nur eine vorläufige Identifikation der Objekte darstellt und diese im Systementwurf verfeinert werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.12.: Klassendiagramm

4. Systementwurf

Im Folgenden wird das Analyse-Modell, welches im Kapitel 3 beschrieben wurde, in ein Systementwurfsmodell überführt und präzisiert. Dazu werden zunächst in Kapitel 4.1 die Entwurfsziele festgelegt sowie in Kapitel 4.2 das System in kleinere Subsysteme zerlegt, sodass die Komplexität beim Implementieren verringert wird. Kapitel 4.3 beschreibt kurz den globalen Kontrollfluss. Die Hardware/Software-Plattform wird in Kapitel 4.5 dargestellt und begründet. Diese umfasst die Wahl der Programmiersprache, das Ansprechen des Lagesensors der Videobrille und das Verwenden der Kinect-Daten. Im Anhang wird in Kapitel A.1 eine Referenz zu den nach außen angebotenen Schnittstellenfunktionen der Subsysteme gegeben.

[...]

---

^[1] http://www.redmine.org/

^[2] http://gitscm.org