Projektgruppe Virtual Reality

Transcription

Abschlussbericht
Erstellt von:
Studienbereich:
Betreuer:
Matthias Bruns, Justin Heinermann,
Christian Herz, Tim Jörgen,
Jendrik Poloczek, Robert Schadek
Informatik
Prof. Dr. Wolfgang Kowalk,
Dipl.-Inf. Stefan Brunhorn
©2012. Dieses Werk einschließlich seiner Teile ist urheberrechtlich geschützt. Jede Verwertung
außerhalb der engen Grenzen des Urheberrechtgesetzes ist ohne Zustimmung des Autors unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen
sowie die Einspeicherung und Verarbeitung in elektronischen Systemen.
Projektgruppe
Virtual Reality
Inhaltsverzeichnis
Inhaltsverzeichnis
Abbildungsverzeichnis
V
1. Einführung
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2. Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3. Voraussetzungen und Grundlagen zum Verständnis der Arbeit . . .
1
1
2
2
2. Projektorganisation und Vorgehen
2.1. Gruppenarbeit und Aufgabenteilung . . . . . . . . . . . . . . . . .
2.2. Vorgehensmodell und Zeitplanung . . . . . . . . . . . . . . . . . . .
3
3
4
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 . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
6
6
10
10
11
12
12
12
13
13
14
14
15
15
16
I
Projektgruppe
Virtual Reality
Inhaltsverzeichnis
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 . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
17
18
18
19
19
20
20
21
22
22
23
27
.
.
.
.
.
.
29
29
31
33
33
34
34
.
.
.
.
.
.
.
36
36
36
36
37
37
37
37
. 40
. 42
. 43
II
Projektgruppe
Virtual Reality
Inhaltsverzeichnis
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. Bereiststellung 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 . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
43
44
45
46
47
47
48
48
51
52
53
54
54
55
.
.
.
.
57
57
58
58
59
62
. 62
. 62
. 62
.
.
.
.
.
.
.
63
63
64
64
64
65
67
III
Projektgruppe
Virtual Reality
Inhaltsverzeichnis
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. Persönliche Fazite
8.1. Persönliches Fazit
von
von
von
von
von
von
Robert Schadek . .
Christian Herz . . .
Jendrik Poloczek . .
Matthias Bruns . .
Justin Heinermann
Tim Jörgen . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
69
69
70
71
73
74
78
79
80
.
.
.
.
.
.
82
82
82
83
84
85
86
9. Fazit und Ausblick
87
Literaturverzeichnis
89
A. Anhang
A.1. Schnittstellenfunktionen . . . . . .
A.1.1. registerPose, registerGesture
A.2. Installation . . . . . . . . . . . . .
A.2.1. Windows . . . . . . . . . . .
A.2.2. Unix . . . . . . . . . . . . .
A.3. Fragebogen . . . . . . . . . . . . .
A.4. Erhobene Daten der Fragebögen . .
A.5. Probandeninformation . . . . . . .
A.6. Einwilligungserklärung . . . . . . .
A.7. Seminararbeiten . . . . . . . . . . .
i
i
ii
ii
iii
iv
v
viii
xii
xiv
xv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
IV
Projektgruppe
Virtual Reality
2.1. Vorgehensmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1. Kinect (Quelle: Microsoft) . . . . . . . . . . . .
3.2. Vuzix Wrap 920 VR (Quelle: Vuzix) . . . . . . .
3.3. Anwendungsfalldiagramm des Nutzers . . . . .
3.4. Sequenzdiagramm: Welt laden . . . . . . . . . .
3.5. Sequenzdiagramm: Skeletterkennung kalibrieren
3.6. Sequenzdiagramm: Skelett bewegen . . . . . . .
3.7. Sequenzdiagramm: Pose Einnehmen . . . . . . .
3.8. Sequenzdiagramm: Geste durchführen . . . . . .
3.9. Sequenzdiagramm: Gegenstand berühren . . . .
3.10. Squenzdiagramm: Kameraposition und -rotation
3.11. Sequenzdiagramm: Kopflage kalibrieren . . . . .
3.12. Klassendiagramm . . . . . . . . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
anpassen
. . . . . .
. . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
8
9
16
22
23
23
24
24
25
25
26
28
4.1. Systemzerlegung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2. Hard- und Softwareplattform . . . . . . . . . . . . . . . . . . . . . . 34
5.1.
5.2.
5.3.
5.4.
Lagesensorparameter . . . . . . . . . . . . . . . . .
Darstellung der Skelettdaten in Ogre3d . . . . . . .
Zustandsdiagramm der Middleware . . . . . . . . .
links: Oger von Ogre 3D, rechts: modifizierter Oger
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
40
42
51
54
7.1.
7.2.
7.3.
7.4.
Spiegel, Sideboard und Plattenspieler
Fernseher und Eingangstür . . . . . .
Couch und Fensterfront . . . . . . . .
Ein Proband nutzt das VR-System .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
66
66
67
68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
V
Projektgruppe
Virtual Reality
7.5. Ein Proband füllt den Fragebogen aus . . . . . . . . . . . . . . . .
7.6. Boxplots - alle Versuchsaufbauten . . . . . . . . . . . . . . . . . . .
7.7. Boxplots - Bewegung im Raum mit und ohne Kinect . . . . . . . .
7.8. Boxplots - Bewegung im Raum mit und ohne Videobrille . . . . . .
7.9. Boxplots - Präsenzempfinden mit und ohne Videobrille . . . . . . .
7.10. Boxplots - Präsenzempfinden mit und ohne Kinect . . . . . . . . . .
7.11. Boxplots - Versetzung in die virtuelle Welt mit und ohne Videobrille
7.12. Boxplots - Versetzung in die virtuelle Welt mit und ohne Kinect . .
7.13. Boxplots - Geräusche lokalisieren mit und ohne Videobrille . . . . .
7.14. Boxplots - Natürlichkeit der virtuelle Welt mit Kinect/HMD und
ohne Kinect/HMD . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
72
73
74
75
76
77
78
79
80
A.1. Abhängigkeiten Middleware/Frontend . . . . . . . . . . . . . . . . .
ii
VI
Projektgruppe
Virtual Reality
1. Einführung
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. Die PG bestand aus sechs Studenten und wurde betreut von
Prof. Dr. Wolfgang Kowalk und Dipl.-Inf. Stefan Brunhorn. 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
Projektgruppe
Virtual Reality
1. Einführung
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. Kapitel 8 beinhaltet persönliche Fazite aller Mitglieder und in Kapitel 9 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. Für die Einarbeitung in die Thematik des Projektes und als Grundlage für diese Arbeit wurden
in der Seminarphase die folgenden Aspekte betrachtet:
Konfigurationsmanagement Tim Jörgen
Virtual Reality - Geschichte und Entwicklung Matthias Bruns
Virtual Reality und der Einsatz in der Praxis Justin Heinermann
Datenverarbeitung der Kinect Robert Schadek
Bildverarbeitung mit OpenCV Christian Herz
Präsenzempfinden in virtuellen Umgebungen Jendrik Poloczek
Auf diese Ausarbeitungen sei hier als Grundlage verwiesen. Alle Seminararbeiten
befinden sich im Anhang.
2
Projektgruppe
Virtual Reality
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.
3
Projektgruppe
Virtual Reality
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
1
2
http://www.redmine.org/
http://gitscm.org
4
Projektgruppe
Virtual Reality
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.)
Anforderungsanalyse
Systementwurf
Implementierung MS1: Grundfunktionen
Implementierung MS2: Erweiterte Funktionen
Implementierung MS3: Alle Anwendungsfälle
Umfangreiche Anwendung
Evaluation
Abbildung 2.1.: Vorgehensmodell
5
Projektgruppe
Virtual Reality
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.
6
Projektgruppe
Virtual Reality
In der Seminararbeit “Präsenzempfinden in virtuellen Umgebungen“ Poloczek [2011]
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 (vgl. Heinermann [2011], Poloczek [2011]), die im Rahmen der Projektgruppe ausgearbeitet wurden, sind verschiedene Arten von VRSystemen 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
7
Projektgruppe
Virtual Reality
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 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.
8
Projektgruppe
Virtual Reality
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
9
Projektgruppe
Virtual Reality
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
10
Projektgruppe
Virtual Reality
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.
11
Projektgruppe
Virtual Reality
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 Nutzer für die Kinect.
12
Projektgruppe
Virtual Reality
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 640x480 Pixel zur
Verfügung, mit der aufgrund des physischen Abstands von RGB-Kamera und IRSensor 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 640x480 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
13
Projektgruppe
Virtual Reality
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.
14
Projektgruppe
Virtual Reality
3.7.2. Anwendungsfälle des Assistenten
3.7.2.1. Anwendung starten
Name
Anwendungs starten
Akteure
Initiiert von Assistent
Ablauf
1. Der Assistent ruft die Anwendung mit
den gewünschten Parametern auf. Die
möglichen Parameter sind:
• Gewünschte Szene
• Stereoskopie verwenden
• Zu verwendender Augenabstand
• Kinect verwenden
• Lagesensor verwenden
• Musik ein- oder abschalten
2. Das System startet die Anwendung mit
den gewünschten Parametern.
Anfangsbedingung
Alle zu verwendeten Geräte sind vorm Starten angeschlossen. Die Bildschirmauflösung
der Videobrille wurde sachgemäß im Betriebssystem eingestellt.
Abschlussbedingung
Alle Parameter werden von der Anwendung
berücksichtigt.
Qualitätsanforderungen
Bei fehlerhaften oder unvollständigen Eingaben wird eine entsprechende Meldung ausgegeben.
15
Projektgruppe
Virtual Reality
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.
Kameraposition anpassen
Kopflage kalibrieren
Geste durchführen
Skeletterkennung kalibrieren
nutzer
Gegenstand berühren
Skelett holen
Pose einnehmen
Abbildung 3.3.: Anwendungsfalldiagramm des Nutzers
16
Projektgruppe
Virtual Reality
3.7.3.1. Skeletterkennung kalibrieren
Name
Skeletterkennung kalibrieren
Akteure
Nutzer
Ablauf
1. Der Nutzer wählt die Funktion zum
Kalibrieren des Skeletts.
2. Das System bestätigt dies und fordert den Nutzer dazu auf, die Kalibrierungspose einzunehmen.
3. Der Nutzer nimmt die Kalibrierungspose ein.
4. Das System nimmt die Kalibrierung vor
Anfangsbedingung
Sowohl nach Start der Anwendung als auch
während des Betriebes möglich
Abschlussbedingung
Die Skeletterkennung wurde korrekt kalibriert bzw. ein Skelett gefunden.
17
Projektgruppe
Virtual Reality
3.7.3.2. Kopflage kalibrieren
Name
Kopflage kalibrieren
Akteure
Nutzer
Ablauf
1. Der Nutzer wählt die Funktion zum
Kalibrieren der Kopflage.
2. Das System sichert die Kopflage als
Null-Ausrichtung.
Anfangsbedingung
Sowohl nach Start der Anwendung als auch
während des Betriebes möglich
Abschlussbedingung
Die Kopflage wurde erfolgreich kalibriert.
3.7.3.3. Kameraposition und -Rotation anpassen
Name
Kameraposition und -rotation anpassen
Akteure
Nutzer
Ablauf
1. Der Nutzer bewegt seinen Kopf
2. Das System passt Position und Rotation der Kamera an.
Anfangsbedingung
Die Kopflage wurde korrekt kalibriert.
Abschlussbedingung
Die Kameraposition und -Rotation wurden
angepasst.
Die Bewegung der virtuellen Kamera darf
nicht zu ruckartig wirken. Die Bewegung
wird so schnell wie möglich ausgeführt. Ideal
wäre eine Verzögerung <15ms, durch die die
Bewegung verzögerungsfrei wirkt.
18
Projektgruppe
Virtual Reality
3.7.3.4. Geste durchführen
Name
Geste durchführen
Akteure
Nutzer
Ablauf
1. Der Nutzer führt eine vordefinierte Geste durch
2. Das System erkennt diese und löst
ein entsprechendes Event aus.
Anfangsbedingung
Die Skeletterkennung wurde kalibriert und
ein Skelett erkannt.
Abschlussbedingung
Die korrekte Geste wurde erkannt.
Die richtige Geste wurde mit hoher Wahrscheinlichkeit erkannt.
3.7.3.5. Pose einnehmen
Name
Pose einnehmen
Akteure
Nutzer
Ablauf
1. Der Nutzer nimmt eine Pose ein.
2. Das System erkennt diese Pose und
löst ein entsprechendes mit der Pose verknüpftes Event aus.
Anfangsbedingung
Die Pose wurde neu eingenommen: D.h. sie
hat sich geändert.
Abschlussbedingung
Die Pose wurde mit großer Erfolgswahrscheinlichkeit richtig erkannt.
Das Einnehmen einer Pose muss innerhalb
von wenigen Millisekunden erkannt werden.
19
Projektgruppe
Virtual Reality
3.7.3.6. Gegenstand berühren
Name
Gegenstand berühren
Akteure
Nutzer
Ablauf
1. Der Nutzer berührt in der virtuellen
Welt einen Gegenstand.
2. Das System erkennt, welcher Gegenstand berührt wurde und führt
eine entsprechende Aktion aus
(Bspw. Gegenstand aufheben).
Anfangsbedingung
Das Skelett des Nutzers ist korrekt in der virtuellen Welt vorhanden. Kollisionsabfrage ist
aktiv.
Abschlussbedingung
Der korrekte Gegenstand wurde erkannt.
3.7.3.7. Skelett bewegen
Name
Skelett bewegen
Akteure
Nutzer
Ablauf
1. Der Nutzer bewegt sich.
2. Das System aktualisiert die SkelettDaten
Anfangsbedingung
Die Skeletterkennung wurde kalibriert.
Abschlussbedingung
Die Skelett-Daten wurden korrekt aktualisiert.
Im Fehlerfall wird auf alte Daten zurückgegriffen.
20
Projektgruppe
Virtual Reality
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
21
Projektgruppe
Virtual Reality
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 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.
22
Projektgruppe
Virtual Reality
3.8.1.1. Skeletterkennung kalibrieren
Abbildung 3.5.: Sequenzdiagramm Skeletterkennung kalibrieren: Der Nutzer
nimmt die Kalibrierungspose ein, damit die Skeletterkennung kalibriert werden kann.
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.
23
Projektgruppe
Virtual Reality
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 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.
24
Projektgruppe
Virtual Reality
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 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.
25
Projektgruppe
Virtual Reality
Abbildung 3.11.: Sequenzdiagramm Kopflage kalibrieren: Die Erkennung der Kopflage wird auf plausible Werte eingestellt.
26
Projektgruppe
Virtual Reality
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 Idenfikation der Objekte darstellt und diese
im Systementwurf verfeinert werden.
27
checkCollision(Skeleton)
Object
0..*
1
checkCollision(Skeleton)
World
1
1..*
loadLevel(World)
ChooseLevelView
1
1
1
Application
1..*
setCamera()
Camera
1
Skeleton
1
1
triggerPoseEvent()
triggerGestureEvent()
loadLevel()
triggerSkeletonEvent()
1
1
1
Skeleton
1
1
getHeadDirection()
calibrateSkeleton()
triggerSkeletonEvent()
getSkeleton()
Middleware
1
Head
1
1
1
1
1
getHeadDirection()
HeadTrackerWrapper
calibrateSkeleton()
getRGBImage()
getSkeleton()
KinectWrapper (OpenNI)
Projektgruppe
Virtual Reality
Abbildung 3.12.: Klassendiagramm
28
Projektgruppe
Virtual Reality
4. Systementwurf
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/SoftwarePlattform 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.
4.1. Entwurfsziele
„Entwurfsziele sind Eigenschaften, die es uns ermöglichen, Prioritäten bei der Entwicklung des Systems zu setzen. Entwurfsziele entstehen
aus den nichtfunktionalen Anforderungen, die während der Anforderungsermittlung spezifiziert wurden und aus technischen sowie Verwaltungszielen.“
Bernd Brügge [2004] Die folgende Tabelle listet unsere Entwurfsziele auf.
29
Projektgruppe
Virtual Reality
4. Systementwurf
Entwurfsziel
Antwortzeit
Speicherbedarf
Robustheit
Fehlertoleranz
Schutz
Sicherheit
Kosten
Entwicklungskosten
Dokumentation
der Schnittstelle
(Middleware)
Dokumentation
des Quellcodes
Erweiterbarkeit
und Modifizierbarkeit
Portierbarkeit
Priorität
sehr hoch
Kommentar
Für eine interaktive Anwendung
ist eine geringe Antwortzeit wichtig.
hoch
Niedriger Speicherbedarf
hoch
Das System soll auch bei ungültigen
Benutzereingaben stabil weiterlaufen.
hoch
Das Auftreten von Fehlern soll
das System nicht beeinflussen.
unerheblich Offline-Anwendung, kein sensiblen Daten.
mittel
Die Gefährdung menschlichen Lebens
und Suchtgefahr sind eher gering, sollen
aber auch bestmöglich ausgeschlossen werden.
hoch
Das System soll prinzipiell
kostengünstig auch für
Heimanwender verfügbar sein.
fest vorge- System muss für Implementierung mit sechs
geben
Personen geplant werden.
sehr hoch
Die Middleware soll von SoftwareEntwicklern genutzt werden und muss
daher sehr gut und verständlich dokumentiert werden.
sehr hoch
Das der Quellcode auch als lernenUmgebung dienen soll, ist die Dokumentation desselben sehr wichtig.
mittel
Festgelegte Features,
aber erweiterbare Architektur.
hoch
Nützlichkeit
hoch
Nutzbarkeit
hoch
Verfügbarkeit auf vielen Plattformen, universelle Architektur
Nicht nur als Spiel, sondern vielfältig einsetzbar (insbesondere Middleware)
Intuitive Nutzung und gute Bedienbarkeit
Tabelle 4.1.: Entwurfsziele
30
Projektgruppe
Virtual Reality
4. Systementwurf
4.2. Systemzerlegung
In diesem Abschnitt ist die Systemzerlegung in Subsysteme dokumentiert. Wie
in C++ üblich, werden die unterschiedlichen Komponenten nach Zusammengehörigkeit in Namespaces getrennt. Die Systemzerlegung ist in Abb. 4.1 als UMLKlassendiagramm dargestellt.
Es existieren Middleware- und Frontend-Subsystem. Die Middleware abstrahiert
die Eingabemedien Kinect und Lagesensor der Videobrille und kapselt dementsprechend den Zugriff auf die jeweiligen Hardwarekomponenten. Auf Grundlage
der Middleware wird in dem Frontend-Subsystem die Beispielanwendung realisiert. Im Folgenden werden zunächst die wichtigen Klassen und Funktionen der
Middleware erläutert, anschließend die des Frontend-Subsystems.
Die Hauptklasse Middleware::Main der Middleware wird als Schnittstelle benutzt,
um das Skelett und die Lagesensordaten anzufragen. Ferner wird in der Hauptklasse ein Thread erzeugt, der unabhängig von der Anwendung die Hardwarekomponenten über die Klassen KinectAbstraction und AttitudeSensor anfragt. Mithilfe
des GestureManagers und des PoseManagers lassen sich benutzerdefinierte Gesten
und Posen verwenden. Eine detaillierte Ausführung der Funktionalität wird in
X dargeboten. Das Frontend-Subsystem umfasst den Einstiegspunkt für die Beispielanwendung. Die virtuelle Umgebung wird in der Klasse BasicScene geladen,
ferner werden dort Eingabeereignisse wie Tastatur und Mauseingaben verarbeitet.
Die Klasse CharacterController behandelt die Anzeige und Aktualisierung des virtuellen Charakters auf Basis der Middleware-Daten. Der DotSceneLoader ist eine
Hilfsklasse zum Parsen von DotScene-Format Level-Dateien. Die Klasse parst und
erstellt die korrespondierende Umgebung.
31
Projektgruppe
Virtual Reality
4. Systementwurf
Frontend
sound
CharacterController
BasiscScene
SoundManager
1
1
notify(ge)
notify(pe)
main()
update()
keyPressed()
keyReleased()
createViewports()
setupRessources()
loadSound()
playSound()
stopSound()
setListenerPosition()
1
1
1
1
injectKeyDown()
injectKeyUp()
updateBody()
DotSceneLoader
parseDotScene()
Middleware
KinectWrapper
Main
isCalibrated : bool
vuzixConnected : bool
kinectConnected : Integer
getHeadDirection()
getSkeleton()
registerGesture()
registerPose()
removePoseEvent()
removeGestureEvent()
resetHeadDirection()
work()
KinectAbstraction
1
isCalibrated : bool
isConnected : bool
1
getSkeleton() : Joint[]
init()
1
1
OpenNIConnector
isCalibrated : bool
isConnected : bool
GestureManager
1
getSkeleton() : Joint[]
1 init()
1
0..* GestureEvent
1
0..*
1
AttitudeSensor
registerGesture()
removeGesture()
getHeadDirection()
resetHeadDirection()
timerProc()
1
PoseManager
1
1
Head
PoseEvent
registerPose()
removePose()
yaw : float
pitch : float
roll : float
Abbildung 4.1.: Systemzerlegung
32
Projektgruppe
Virtual Reality
4. Systementwurf
4.3. Globaler Kontrollfluss
Da das zu entwickelnde System eine Grafikanwendung ist und die Ogre3D Grafikengine verwendet wird, findet die grafische Darstellung in der Anwendung in
einer Hauptschleife statt. Die Anwendung hält dabei eine Instanz der Middleware,
von der sie sich in jedem Durchgang der Hauptschleife die aktuellen Eingabedaten
holt und diese verwendet.
Die Middleware lässt mehrere Threads laufen, um immer die aktuellen Eingangsdaten liefern zu können und verarbeitet diese außerdem in Form der Posen- und
Gestenerkennung. Wenn eine Pose oder Geste erkannt wird, wird von der Middleware eine enstsprechende Funktion der Anwendung aufgerufen, um diese zu benachrichtigen.
4.4. Datenhaltung
Das zu verwendende Datenformat für die virtuelle Umgebung wird auf das DotScene Format festgelegt, das kompatibel zur Ogre 3D Engine ist und den Vorteil
bietet, dass ein Exporter für das quelloffene 3D-Werkzeug Blender existiert.
33
Projektgruppe
Virtual Reality
4. Systementwurf
4.5. Hard- und Softwareplattform
Abbildung 4.2.: Hard- und Softwareplattform
Die Hard- und Softwareplattform gliedert sich in drei Ebenen: Die Ebene der
externen Hardware umfasst die Vuzix Videobrille zur visuellen Ausgabe sowie die
Microsoft Kinect zum Erfassen der Bewegungen des Nutzers. Die Rechner Ebene
I beinhaltet die Middelware. Die Middelware umfasst drei Hauptkomponenten:
Skeletterkennung, Gestenerkennung und Systemadministration. Aufbauend auf der
Middleware liegt die Anwendungssoftware des Systems auf Rechner Ebene II. Sie
besteht aus der Grafikengine und der Contentverwaltung.
4.5.1. Wahl der Programmiersprache
Als mögliche Programmiersprachen kommen Java oder C++ infrage. Java und
C++ wurden bisher laut Aussagen der Teammitglieder verwendet und es existieren
34
Projektgruppe
Virtual Reality
4. Systementwurf
Grundkenntnisse in beiden Sprachen. Die notwendigen objekt-orientierten Sprachfunktionalitäten existieren in beiden Sprachen. Der verwendete Kinect-Treiber
OpenNI ist in C++ implementiert. Eine Verwendung des Treibers in Java ist über
die Verwendung eines Wrappers möglich. Da Frontend und Middleware als Echtzeitanwendung entworfen werden, ist die Performanz eine wichtige nicht-funktionale
Anforderung, die nicht durch die Wahl der Programmiersprache eingeschränkt werden soll. Bezogen auf die Performanz von C++ und Java sind keine markanten
Unterschiede zu erkennen. Die Kinect liefert 30f ps und C++ und Java scheinen
sich in der Verarbeitung und Ausgabe nur minimal zu unterscheiden. Hier kann
also kein Grund gefunden werden, der mehr für eine der beiden Programmiersprachen spricht. In Absprache mit dem gesamten Team haben wir uns für die
Programmiersprache C++ entschieden.
35
Projektgruppe
Virtual Reality
5. Implementierung
5. Implementierung
5.1. Meilensteine der Implementierung
Im Rahmen der Implementierung haben wir Entwicklungsschritte und Ergebnisse
definiert, die zu einem festgelegten Zeitpunkt erreicht werden sollen. Durch dieses
Vorgehen können wir den Implementierungsvorgang zielorientiert planen und die
fristgerechte Fertigstellung des Projekts sicherstellen. Im Folgendem werden die
festgelegten Meilensteine beschrieben.
5.1.1. Erster Meilenstein (30.09.2011)
• Einfache Test-Anwendung mit der Ogre-Engine
• Kamerasteuerung per Vuzix-Brille
• Darstellung der Kinect-Skelett-Daten durch eine Figur in der Engine
• Build-Skript
5.1.2. Zweiter Meilenstein (01.11.2011)
• Sound-Integration
• Stereoskopische Ansicht über die Videobrille
• Posen
• Scene-Loader
• Bewegung im Raum
36
Projektgruppe
Virtual Reality
5. Implementierung
5.1.3. Dritter Meilenstein (06.12.2011)
• Exceptions der Middleware ergänzen
• Gesten
• Abrufen des Zustandes der Middleware wie z.B. Status der Geräte und Kalibrierung
• Linuxtreiber der Vuzix-Brille
• Kollisionserkennung
• Soundintegration mit Skripten
• Licht und Schatten
• Spiegel und Fernseher
• Modifizierter Oger
5.2. Implementierung der einzelnen
Systemkomponenten
Im Folgenden wird die Implementierung einzelner Komponenten des Systems bezüglich Herausforderungen und Probleme erläutert. Die implementierten Komponenten sind dabei nach den Meilensteinen gegliedert.
5.2.1. Erster Meilenstein
5.2.1.1. Head-Mounted-Display
Die Klasse AttitudeSensor ist Bestandteil der Middleware und beinhaltet Komponenten zur Kommunikation der Vuzix Wrap 920 mit der Schicht der Middleware.
In unserer Hauptklasse (M iddleware :: M ain) wird mit Aufruf des Konstruktors
37
Projektgruppe
Virtual Reality
5. Implementierung
eine Instanz des AttitudeSensors erstellt, wobei anschließend ein Thread gestartet wird, der kontinuierlich die Ausrichtung der Brille, also die Lage des Kopfes,
bestimmt. Über die Middleware ist somit jederzeit die Kopfposition abrufbar.
Die Klasse AttitudeSensor beinhaltet Programmcode für Win32- und Linux-Systeme.
Bei der Entwicklung sind wir auf das Problem gestoßen, dass die bisherigen LinuxTreiber nur das Vorgängermodell Vuzix VR 920, nicht jedoch die von uns genutzte Vuzix Wrap 920 unterstützen. Unsere falsche Annahme der Kompatibilität
des Treibers mit der Vuzix Wrap 920 beruht auf einer fehlerhaften Beschreibung
auf der Vuzix-Homepage. Diese irreführende Beschreibung wurde erst nach unserem Erhalt der Brille korrigiert. Aus diesem Grund wurde manuell eine LinuxUnterstützung von uns implementiert. Die Inkompatibilität des alten Treibers mit
dem neuen Modell beruht auf einem neu entwickelten Bewegungssensor, der 6 anstatt 3 Freiheitsgrade bietet und die Messdaten in anderer Reihenfolge über den
USB-Port kodiert. Dies wird von uns entsprechend angepasst, um unser Ziel der
Plattformunabhängigkeit zu erreichen.
Unter Windows werden die Messdaten der Vuzix Wrap 920 korrekt an die Middleware übertragen. Jedoch muss die Brille über den Vuzixmanager abseits unserer Softwareumgebung kalibriert werden, da die Funktion der Kalibrierung im
von Vuzix gelieferten Windows-Treiber nicht implementiert wurde. Die Roll- und
Pitch-Rohdaten werden vom Lagesensor ermittelt und vom Treiber direkt verarbeitet. Die Yaw-Werte (Links-Rechts-Drehung) werden über ein Gyroskop ermittelt
und über die Daten des Magnetfeldsensors permanent abgeglichen (IWRSetMagAutoCorrect), um die Richtungsabweichungen des Gyrometers zu kompensieren
(Norden bleibt dauerhaft Norden).
Tests haben weiterhin ergeben, dass die X,Y,Z-Daten des Lagesensors zur Bestimmung der Position im Raum für unser Projekt nicht verwendbar sind, da sie keine
hinreichend genauen Werte liefern, sondern sich nur Informationen über die Laufrichtung ableiten lassen. Daher werden von der AttitudeSensor.cpp nur die Yaw-,
Roll- und Pitch-Daten an das Frontend übergeben.
Für das Auslesen der Daten von der Vuzix 3D-Brille sind unter Windows folgende
Schritte notwendig:
38
Projektgruppe
Virtual Reality
5. Implementierung
1. Starten einer Trackersession:
DWORD IWROpenTracker (void)
2. Schließen einer Trackersession:
void IWRCloseTracker (void)
3. Kalibrierungsdaten des iWear-Monitors holen:
void IWRGetVersion(IWRVERSION *ver)
4. Ausgangsblickrichtung festlegen:
void IWRZeroSet (void)
5. Daten vom Tracker holen:
DWORD IWRGetTracking (LONG * yaw, LONG * pitch, LONG * roll)
6. Für die Bestimmung der Position im Raum 6-dimensionale Daten vom Tracker
holen:
DWORD IWRGet6DTracking(LONG *yaw, LONG *pitch, LONG *roll, LONG
*xtrn, LONG *ytrn, LONG *ztrn)
Drei Datenströme stehen durch die 3D-Brille zur Verfügung:
• Pitch: Vertikale Neigung der Kopfes
• Yaw: Drehung der Kopfes
• Roll: Horizontale Neigung des Kopfes
Für die Veranschaulichung der verwendeten Parameter siehe Abbildung 5.1
39
Projektgruppe
Virtual Reality
5. Implementierung
Abbildung 5.1.: Lagesensorparameter
5.2.1.2. Darstellung der Kinect-Skelett-Daten durch eine Figur in der
Engine
Dieser Teil der Implementierung bezieht sich zum einen auf die benötigten Funktionen in der Middleware und die dazugehörigen angebotenen Schnittstellen (M iddleware ::
M ain), zum anderen auf die Repräsentation im Frontend.
Die Middleware stellt dem Anwendungsprogrammierer die Funktion getSkeleton
zur Verfügung. Dabei soll der Anwendungsprogrammierer insbesondere auf die manuelle Initialisierung der Hardware und der Treiber verzichten können. Nachdem
im Anwendungsprogramm eine Instanz der Klasse M iddleware :: M ain erzeugt
wurde, können über die getSkeleton-Funktion einfach die aktuellen Skelettdaten
geholt werden. Die Skelettdaten bestehen aus einem 24 Elemente großen Array
des Types M iddleware :: KinectW rapper :: Joint. Ein solches Gelenk hat eine
Position sowie eine Orientierung (Rotationsmatrix). Um auf die einzelnen Elemente des Feldes zugreifen zu können, muss der Anwendungsprogrammierer natürlich wissen, welcher Index welchem Gelenk zugeordnet ist. Dies ist im Enum
M iddleware :: KinectW rapper :: Joints dokumentiert. Wichtig zu beachten ist
hierbei, dass die Joints wie im verwendeten OpenNI-Framework nicht von 0 bis 23
numeriert sind, wie für die Feld-Indizes anzunehmen wäre, sondern von 1 bis 24.
Daher muss von den Werten aus dem Enum jeweils 1 subtrahiert werden!
40
Projektgruppe
Virtual Reality
5. Implementierung
In der Middleware selbst wurde der Zugriff auf drei Ebenen verteilt:
Main Schnittstelle nach außen, zentrale Verwaltung aller Aspekte der Middleware
KinectAbstraction Zugriff auf Kinect oder ähnliche Geräte in abstrakter Form,
Bindeglied zwischen Main und Hardware-Treiber
OpenNIConnector Zugriff auf Kinect-Hardware-Treiber/Framework OpenNI
Durch diese Trennung soll erreicht werden, dass der Zugriff auf verschiedenartige
Hardware mit verschiedenen Treiberanbindungen ohne viel Aufwand ermöglicht
werden kann.
Der eigentliche Schritt der Kommunikation mit dem Kinect-Framework OpenNI
findet in der Klasse OpenN IConnector statt. Hierbei wird zunächst in der initMethode ein OpenNI-Kontext erzeugt, sowie alle nötigen Aufrufe getätigt, um
einen Benutzer zu erkennen und dessen Skelettdatenerkennung auf ihn zu kalibrieren. In der zentralen Methode OpenN IConnector :: getSkeleton werden die
Skelettdaten vom OpenNI-Framework geholt und in ein Array verpackt.
41
Projektgruppe
Virtual Reality
5. Implementierung
Abbildung 5.2.: Darstellung der Skelettdaten in Ogre3d
Zur Darstellung der Skelettdaten in der Beispielanwendung wurde eine modifizierte Fantasy-Gestalt in Form eines hautfarbenen Ogers (siehe Abb. 5.2) gewählt.
Diese liegt als objekthierarchisch modelliertes 3D-Modell vor, so dass die einzelnen
Gelenke mit Rotationsdaten des aus den Daten der Kinect gewonnenen Skelettes
gedreht werden können. Dieses Vorgehen findet im
SinbadCharacterController statt.
5.2.1.3. Build-Skript
Aufgrund seiner schnellen Anpassungsfähigkeit an unterschiedliche Plattformen
entschieden wir uns für das plattformunabhängige Programmierwerkzeug „CMake“. CMake bietet eine Vielfalt an Optionen, die das Kompilieren von Quellcode für
42
Projektgruppe
Virtual Reality
5. Implementierung
unterschiedliche Plattformen und Entwicklungsumgebungen wie z. B. Visual Studio auf einfache Weise ermöglicht. Weitergehend kann im Build-Skript die Art der
zu kompilierenden Anwendung festgelegt werden, die bestimmt ob eine ausführbare Datei oder lediglich eine statische oder dynamische Bibliothek erstellt werden
soll. Sourcedateien und Headerdateien, sowie Abhängigkeiten von anderen Bibliotheken werden auch im Build-Skript beschrieben. Dem Anwender wird dadurch
die Arbeit erspart in Visual Studio oder unter Unix alle Bibliotheken manuell zu
linken.
In unserem Build-Skript unterscheiden wir zwischen 32-Bit-Anwendungen unter
Windows für Visual Studio 10 und 32-Bit-Anwendungen unter Linux-Distributionen.
Weitergehend wurde für beide Plattformen ein automatisches Build-Skript konzipiert, durch dessen Ausführung sämtliche Teilprojekte, die für eine Benutzung
der Middleware unentbehrlich sind, kompiliert werden. Durch diese Funktionalität muss der Middleware-Benutzer nur die Bibliothek der Middleware linken. Das
Kompilieren der Middleware setzt jedoch voraus, dass die in Abschnitt A.2 erläuterten Abhängigkeiten installiert wurden.
5.2.2. Zweiter Meilenstein
5.2.2.1. Szenenverwaltung
Zur Erstellung und Laden einer Szene wird das im OGRE 3D Umfeld gebräuchliche DotScene-Format verwendet. Das DotScene-Format basiert auf XML. Für das
Modellierungs- und Animationswerkzeug Blender, das im Rahmen der Entwicklung als Standardwerkzeug festgelegt wurde, existiert ein entsprechendes ExportPlugin. Mithilfe des Plugins kann eine in Blender erstellte Szene im DotSceneFormat gespeichert werden. Die Möglichkeit die Szene im DotScene-Format zu
laden ist jedoch nicht standardgemäß in der gegenwärtigen OGRE 3D Version gegeben, sodass diese Funktionalität eigens implementiert wurde. Für die Funktionalität wurde die Klasse DotSceneLoader als Singleton implementiert. Die Klasse
ist in der Lage eine angegebene DotScene-Datei zu laden und diese an eine bereits
vorhandene SceneNode anzuhängen.
43
Projektgruppe
Virtual Reality
5. Implementierung
5.2.2.2. Sound-Subsystem
Im Rahmen der Anwendung, die mithilfe der Grafikengine OGRE 3D entwickelt
wird, muss ferner ein Sound-Subsystem implementiert werden, da die Funktionalität für Geräusch und Musikwiedergabe nicht gegeben ist - jedoch von den
Anforderungen an die Anwendung formuliert wird. Das Sound-Subsystem muss
zur Erfüllung der Anforderungen verschiedene, hier nochmal wiederholte, Funktionalitäten anbieten. Die Basisfunktionalitäten beziehen sich auf die Geräuschwiedergabe. Dabei soll der freie Audio-Codec OGG Vorbis zur Datenspeicherung
der Audiodaten dienen. Die Geräusche sollen über eine API des Sound-Subsystems
angelegt, abgespielt, gestoppt und pausiert werden können. Aufbauend auf diesen
Kernfunktionalitäten soll es ferner möglich sein Raumklang zu simulieren. Mithilfe des Raumklangs soll die Grundlage dafür geschaffen werden, dass der Anwender Geräusche in der virtuellen Umgebung orten kann. Für die Erfüllung der,
hier nochmals wiederholten, Anforderungen wird die plattformunabhängige Sound
API OpenAL und die OGG Vorbis Bibliothek benutzt. Aufbauend auf diesen Abhängigkeiten für die Anwendungen wird das Sound-Subsystem den Rahmenbedingungen entsprechend entwickelt. Dabei soll neben den Funktionalitäten auch eine
Interoperabilität mit dem Scripting-Subsystem und der Grafikengine OGRE 3D
gewährleistet werden.
Nachfolgend soll die Modellierung des Sound-Subsystems veranschaulicht werden.
Dafür werden zunächst die wichtigen Klassen genannt und deren Aufgaben geschildert. Die Klasse SoundManager kapselt die angesprochenen Kernfunktionalitäten,
beispielsweise Laden, Abspielen und Stoppen, die durch OpenAL und die OGG
Vorbis Bibliothek realisiert werden können. Der SoundManager ist als Singleton
realisiert, dementsprechend gibt es nur ein Objekt dieser Klasse. Um die Interoperabilität mit dem Scripting-Subsystem und der Grafikengine OGRE 3D wird
auf Grundlage des SoundManagers auch eine objektorientierte Repräsentation von
Geräuschen angeboten, s.d. ein Geräusch durch ein Objekt der Klasse Sound verwendet werden kann. Zur Erstellung von Sound-Objekten wird die Klasse SoundFactory verwendet, die über den SoundManager angefordert werden kann. Die
SoundFactory konstruiert Sound Objekte, deren öffentliche Methoden die Kern-
44
Projektgruppe
Virtual Reality
5. Implementierung
funktionalitäten wiederspiegeln. Die Sound Objekte kommunizieren intern mit dem
SoundManager, der, wie bereits erörtert, für die interne Verwaltung mit OpenAL
zuständig ist.
Für die Entwicklung und die Beseitigung von Fehlern ist eine grafische Repräsentation für Geräusche erstrebenswert. Die Grafikengine OGRE 3D verwendet die
Technik eines Szenengraphens, um die anzuzeigenden Objekte als SceneNodes zu
verwalten. Eine SceneNode beinhaltet die notwendigen Informationen für die grafische Repräsentation. Die angesprochenen Sound-Objekte werden zum Zweck der
Repräsentation und Verwaltung im Szenengraphen um Sound-Nodes erweitert. Die
Repräsentation wird bei der Erstellung der Sound-Objekten über die SoundFactory
der Geräuschkonfiguration entsprechend angepasst.
Bei der Translokation und Veränderung der Orientierung der Geräuschquelle im
Szenengraphen (der Sound-Node) soll eine automatische Aktualisierung der Position und Orientierung auf den Sound-Objekten und transitiv auf dem SoundManager für das entsprechende Geräusch stattfinden. Diese Modellierung ermöglicht
eine Gleichbehandlung der grafischen 3D-Modelle und der Geräuschquellen. Das
Skripting-Subsystem soll als Werkzeug für den szenischen Ablauf während des
Aufenthaltes in der virtuellen Umgebung dienen. Für die Erstellung eines szenischen Ablaufs muss dementsprechend auch die Translokation und Orientierung von
3D-Modellen und Geräuschquellen möglich sein. Durch die bereits angesprochene Gleichbehandlung von 3D-Modellen und Geräuschquellen wird dieser Verwaltungsaufwand minimiert und eine Interoperabilität mit dem Skripting-Subsystem
gewährleistet.
5.2.2.3. Stereoskopische Ansicht (stereoPlugin)
Die stereoskopische Ansicht in der OGRE 3D-Engine wird über ein 3D-Plugin
für OGRE 1.7 realisiert. Das Plugin erlaubt das Setzen von zwei Viewpoints und
ermöglicht Anpassungen der Parameter Augenabstand und Tiefeneffekt. Das Plugin rechnet anhand der Viewpoints die Ausgabe wahlweise in ein Anaglyphenbild
(Rot/Grün-Überlagerung / Stereogramm) um oder rendert zwei seperate Views,
die nebeneinander dargestellt werden. Für die verwendete Vuzix 920 kommt die
45
Projektgruppe
Virtual Reality
5. Implementierung
zweite Methode zum Einsatz. Die Implementierung einer Zeitmultiplex-Methode
ist durch die zwei Displays in der Videobrille nicht nötig.
5.2.2.4. Posen
Das Abbilden der Körperbewegung auf einen virtuellen Avatar birgt für den Benutzer bereits interessante Erlebnisse. Bewegung in der virtuellen Umgebung gibt
dem Benutzer theoretisch alle Interaktionsmöglichkeinen wie die wirkliche Welt.
Allerdings fehlen die Eingabegeräte, wie Maus und Tastatur, die für einen PC typisch sind. Um diese Eingabegeräte elegant nachzubilden, wurde der Middleware
Posen- und Gestenerkennung hinzugefügt.
Durch die flächendeckende Verbreitung von Touchscreens, sind Benutzer an die
Bedienung von technischen Geräten durch Gesten gewöhnt. Ein grundsätzlicher
Unterschied zwischen Gesten die auf Touchscreens gezeichnet werden und Gesten
die durch den Körper dargestellt werden ist die dritte Dimension, dies macht die
Erkennung der richtigen Geste um ein vielfaches schwerer. Im Folgenden wird die
Posenerkennung beschrieben, die im Rahmen des zweiten Meilensteins implementiert wurde.
Posen werden erkannt, indem einzelne Gelenke mit vordefinierten Transformationen verglichen werden. Da OpenNI in Verbindung mit NITE alle Transformationsinformationen über die Gelenke des verfolgten Benutzers liefert, kann diese
Überprüfung leicht durchgeführt werden.
Damit ein Programmierer bei Nutzung der entwickelten Middleware einfach Posen
definieren kann und beim Auftreten einer Pose ein Ereignis ausgelöst wird, kam das
Observer -Entwurfsmuster zum Einsatz. Bei diesem implementiert eine Klasse das
Interface Middleware::Observer und die Methode notify. Nun kann die Klasse eine
Pose in Form eines Middleware::PoseEvent erzeugen und sich bei der Middleware
mit diesem mit der Methode registerPose „anmelden“. Beim Auftreten einer Pose
ruft die Middleware die notify-Methode auf und übergibt diesem das aufgetretene
PoseEvent.
Eine Pose wird wie folgt überprüft:
46
Projektgruppe
Virtual Reality
5. Implementierung
1. Transformationsinformationen des Skelettes abrufen.
2. Für alle Posen werden alle definierten Gelenke überprüft. Bei der Überprüfung eines Gelenkes, werden die drei Vektoren, die die Orientierung im Raum
definieren, mit den für die Pose festgelegten Orientierungsvektoren verglichen.
3. Wenn eine Pose für einen definierte Zeit eingenommen wird, wird im angemeldeten Observer-Objekt ein Ereignis ausgelöst, indem die notify-Methode
aufgerufen wird
4. Das Observer-Objekt reagiert anhand der übergebenen PoseEvent-ID.
5.2.3. Dritter Meilenstein
5.2.3.1. Exceptions
In unserem Projekt exisitieren drei Arten von Exceptions:
• AttitudeSensorException
• MiddlewareException
• SoundException (FrontEnd)
Die AttitudeSensorException enthält Fehlermeldungen, die die Vuzix 3D-Brille
betreffen. In der MiddlewareExceptions werden Fehlermeldungen gehalten, die die
Middleware betreffen, z. B. dass die Microsoft nicht verbunden oder kalibriert ist.
Weiterhin enthält die Soundexception aus dem FrontEnd Fehlermeldungen, die
den Sound betreffen. Beispielsweise, wenn ein Soundfile nicht geladen oder die Soundschnittstelle nicht gefunden werden kann.
Durch die Verwendung von try-catch-Blöcken werden so Fehler abgefangen und
ggf. werden Exceptions geworfen bzw. an eine höhere Hierarchieebene weitergegeben.
47
Projektgruppe
Virtual Reality
5. Implementierung
5.2.3.2. Gestenerkennung
Im Gegensatz zu den in 5.2.2.4 beschriebenen statischen Posen sind Gesten dynamischer Natur: Durch Bewegungen des Anwenders werden Ereignisse ausgelöst.
Dies kann zum Beispiel das Ziehen eines Schwertes durch eine intuitive Bewegung
umfassen oder das Aufrufen eines Menüs durch eine Click-Geste. Während bei den
Posen statisch vordefinierte Eigenschaften eines oder mehrerer Gelenke mit dem
aktuellen Skelett verglichen werden, werden bei der entwickelten Gestensteuerung
Bewegungen der einzelnen Gelenke betrachtet. Diese können sich entweder in der
Position oder in einem Winkel verändern.
Das verwendete Framework zur Nutzung der Kinect liefert zwar eine eigene Gestenerkennung mit, welche aber schwer zu verwenden ist. Wir haben uns daher für
eine eigene Gestensteuerung entschieden, welche sehr einfach zu verwenden ist und
der einer einfachen Implementierung zu Grunde liegt.
Die zentrale Komponente der Gestenerkennung ist der GestureM anager. Die
Hauptkomponente der Middleware (M iddleware :: M ain) ruft als Thread die
Methode work des GestureM anagers auf und übergibt dieser als Argument das
aktuelle Skelett des Benutzers. Jede Geste wird in einem Zustandsautomaten erkannt. Dieser wird jeweils durch Transistionen definiert, die entweder eine Gelenkwinkeländerung oder eine Positionsänderung beschreiben. Diese Änderungen
werden mit einer bestimmten Geschwindigkeit und einer Timeout-Zeit angegeben.
Die Überprüfung findet anhand der Änderungen der Skelettdaten statt.
5.2.3.3. Linuxtreiber der Vuzix-Brille
Für die verwendete stereoskopische Videobrille mit Lagesensor wird ein Treiber
und SDK nur für Microsoft Windows mitgeliefert. Für andere System wie Linux
kann die stereoskopische Ausgabe per VGA zwar ohne weiteres verwendet werden,
die Nutzung des Lagesensors ist aber nicht ohne weiteres möglich. Es ist zwar
ein Linux-Treiber für eine ältere Brille von Vuzix frei verfügbar, welcher aber für
die vorliegende Brille nicht funktioniert. Da wir unsere Middleware plattformunabhängig konzipiert haben und diese also auch unter Linux-Systemen lauffähig
48
Projektgruppe
Virtual Reality
5. Implementierung
sein sollte, musste ein eigener Treiber programmiert werden. Das Verhalten des
Originaltreibers diente als Vorbild für unseren Treiber, sodass die Middleware sich
unter Windows und Linux nach außen gleich verhält.
Zunächst stellte sich die Frage, wie die Daten der Brille, welche per USB an den
Computer angeschlossen wird, am besten auszulesen sind. Der erste Ansatz war
hier die Nutzung von libusb. Allerdings hat es sich hier als einfacher erwiesen, das
Gerät als Human Interface Device (HID) anzusprechen, da aktuelle Versionen des
Linux-Kernels die Brille sofort als solches erkennen. Die Verwendung eines HID in
eigenen Programmen gestaltet sich so einfach wie das Auslesen einer Datei.
Als nächstes muss man nun wissen, wie die Datenpakete der Brille beschaffen sind.
Anhand des Windows-Treibers des Herstellers1 konnte das Format und der Bereich
der Sensorwerte, welche als Rohdaten von der Hardware ausgelesen werden, festgestellt werden:
3 mal 2 Byte Magnetsensor x,y,z
3 mal 2 Byte Beschleunigungssensor x,y,z
3 mal 2 Byte High Bandwidth Gyroskop x,y,z
3 mal 2 Byte Low Bandwidth Gyroskop x,y,z
Dabei haben wir festgestellt, dass die ersten zwei Bytes der Daten von der Brille
nicht zu berücksichtigen sind, sondern beim Auslesen ein Offset von 2 zu benutzen
ist. Des Weiteren sind die Byte-Paare für die einzelnen Sensorwerte so geordnet,
dass das niederwertige Byte jeweils als erstes im Speicher liegt und als zweites das
höherwertige.
Für die Berechnung von Winkeln aus den Sensordaten müssen diese zunächst kalibriert werden. Die Kalibrierung stellt den minimalen und maximalen Wert jedes
Sensors fest. Der wahrgenommene Wertebereich kann je nach physikalischer Umgebung verschieden sein. Dies umfasst zum einen das Magnetfeld in der Umgebung,
die Erdbeschleunigung am aktuellen Ort und die Ruhedaten des Gyroskops. Die
Kalibrierungsdaten werden in einer Konfigurationsdatei abgespeichert und können
1
http://www.vuzix.com/UKSITE/support/downloads_drivers.html
49
Projektgruppe
Virtual Reality
5. Implementierung
zu einem späteren Zeitpunkt wiederverwendet werden. Soll das System an einem
anderen Ort betrieben werden, muss lediglich die Konfigurationsdatei attitudesensor.conf gelöscht werden.
Wie im originalen Windows-Treiber wurden bei der Berechnung des Pitch-Winkels
sowohl Beschleunigungssensor (im Vuzix-Handbuch „accelerometer“ genannt) als
auch Gyroskop verwendet. Hierbei wurde insbesondere überprüft, dass beide Werte auf plausible Weise zusammenpassen. Prinzipiell liefert das Gyroskop bessere
Ergebnisse, da es sehr gut die Bewegungen des Benutzers überträgt, dabei sehr
präzise ist und im Gegensatz zum Beschleunigungssensor nicht „zittert“ bzw. verrauschte Daten liefert. Allerdings besteht das Problem, dass das Gyroskop eine gewisse Trägheit aufweist und sich so mitunter große Fehler ergeben. Daher werden
diese mit dem Pitch-Wert, der aus den Daten des Beschleunigungssensors berechnet wird auf Plausibilität überprüft und gegebenenfalls korrigiert. Die Berechnung
des Pitch-Winkels des Beschleunigungssensors erfolgt als
pitch = atan2(sqrt(x2 + z 2 ), y)
wobei x,y,z die Sensorwerte sind. Da die Daten vom Beschleunigungssensors ein gewisses „Zittern“ aufweisen, haben wir eine Glättungsfunktion mit einem Ringpuffer
und einer geometrischen Reihe als Gewichtungsvorschrift gemessener Werte umgesetzt, sodass die vom Treiber berechneten Winkel auf den Benutzer nicht „ruckelig“,
sondern sehr natürlich und angenehm wirken. Mit diesem Verfahren werden sehr
gute Ergebnisse erzielt, welche mit dem Original-Treiber zu vergleichen sind. Der
Roll-Winkel wird analog zum Pitch berechnet.
Der Yaw-Winkel wurde ebenfalls wie im Originaltreiber berechnet: Hier dient das
Gyroskop als Grundlage. Die Daten werden im Gegensatz zum Pitch mit den
Magnetsensordaten korrigiert.
Es ist geplant, den Treiber auch separat unter einer freien Lizenz zu veröffentlichen,
sodass dieser uneingeschränkt benutzt und erweitert werden kann.
50
Projektgruppe
Virtual Reality
5. Implementierung
5.2.3.4. Bereiststellung des Zustandes der Middleware
Für die Überwachung des Zustands der Middleware existieren drei statische boolsche Variablen.
• static bool M ain :: isCalibrated
Diese Variable gibt an, ob eine Person kalibriert wurde.
• static bool M ain :: vuzixConnected
Diese Variable gibt an, ob die Vuzix 3D-Brille verbunden ist.
• static bool M ain :: kinectConnected
Diese Variable gibt an, ob die Microsoft Kinect verbunden ist.
Mit jedem Frameupdate wird die statische Variable für die Vuzix 3D-Brille abgefragt und ggf. wird anschließend der Blickwinkel angepasst, sofern der Lagesensor
der 3D-Brille verwendet werden soll.
Weitergehend prüft das FrontEnd, ob sich eine Person kalibriert hat und holt sich
ggf. dann das Skelett der kalibrierten Person, um es auf den Charakter zu übertragen.
Der Zustand des Frontends ist somit abhängig vom Zustand der Middleware. In
Abb. 5.3 ist ein Zustandsdiagramm für die Middleware zu sehen.
Abbildung 5.3.: Zustandsdiagramm der Middleware
51
Projektgruppe
Virtual Reality
5. Implementierung
5.2.3.5. Licht und Schatten
Die verwendete 3d-Engine Ogre3D unterstützt Shadow Mapping (über die fixed
pipeline) oder Stencil Volume Shadows. Das Shadow Mapping-Verfahren ist in
Ogre3D fehlerhaft implementiert: Es werden nicht nur Schatten auf den eigentlichen Receiver geworfen sondern auch auf Objekte, die sich zwischen Lichtquelle
und schattenwerfendem Objekt befinden. Des Weiteren besteht der Nachteil, dass
Ogre3D beim Shadow Mapping die Occluder und Receiver in disjunkte Mengen
einteilt, sodass sich Objekte nicht selbst beschatten können. Dies ist für eine heutige 3D-Anwendung mit dem Ziel einer möglichst realistischen Darstellung nicht
akzeptabel.
Die Shadow Volumes hingegen funktionieren einwandfrei, fordern allerdings gemäß
dem Shadow Volumes-Verfahren geschlossene Geometrie für alle Schattenwerfer.
Große Teile der Szene lagen jedoch nicht als solche vor. Des Weiteren wurde festgestellt, dass sich das Verfahren bei vielen Schattenwerfern negativ auf die Performance auswirkt. Aus diesen Gründen wurde die dynamische Schattierungsberechnung nur für den Character (Spielerfigur) als Occluder durchgeführt, da dieser
meist der einzige bewegte Bestandteil der Szene ist.
Die statischen Objekte wurden hingegen mit Lightmaps vorberechnet, welche realistische weiche Schatten liefern. Da die Erstellung der Szene bereits mit Blender
erfolgte, sollte auch die Erstellung von Lightmaps mit Blender getätigt werden.
Voraussetzung für gelungene Lightmaps ist die identische Positionierung der Lichtquelle in Blender und im Frontend. Die Berechnung einer Lightmap für das betrachtete Objekt benötigt lediglich zwei UV-Maps. Eine der beiden UV-Maps dient der
Texturierung des statischen Objekts. Die andere dient als Overlay für die Textur.
Dieses Overlay beinhaltet die berechnete Lightmap. Man wählt also die Textur,
die das Objekt haben soll, wählt dann die zweite UV-Map und lässt die Lightmap
auf diese UV-Map projizieren. Dazu wählt man den Layer mit der Lightquelle und
alle Layer, die einen Schatten auf das Objekt werfen sollen, aus. Dann erfolgt die
Berechnung der Lightmap, die dann im Normalfall als gestückelte Textur auf der
UV-Map erscheint. Die berechnete Lightmap kann anschliessend als Bild gespeichert werden, so dass beim erneuten Öffnen der Szene keine erneute Berechnungen
52
Projektgruppe
Virtual Reality
5. Implementierung
erforderlich ist. Dieser Vorgang musste für jedes statische Objekt aus der Szene,
das einen Schatten aufnehmen soll, durchgeführt werden. Anschließend konnte die
Szene zu Ogre3D exportiert werden.
5.2.3.6. Spiegel und Fernseher
Für das Erreichen einer intensiveren Immersion wurde zusätzlich ein Spiegel mit
Ogre3D in die Szene integriert. Dieser Spiegel bzw. die dahinter stehende Mathematik orientiert sich an der Dokumentation „Lerne OpenGL mit GL_Sourcerer“,
wobei Teile des Sourcecodes von Java in C++ umgesetzt wurden.
Die richtige Projektion des Spiegels auf die Spiegeloberfläche setzt den richtigen
Umgang mit der Viewmatrix voraus.
Das Vorgehen bei der der Berechnung des Spiegels geht wie folgt vonstatten: Drei
Eckpunkte des erstellten Spiegelobjekts (hier ein flacher Würfel, der die Maße des
Spiegels aufweisen soll) werden ermittelt. So kann später das Spiegelbild in der korrekten Skalierung dargestellt werden. Anschließend wird die Position der virtuellen
Kamera ermittelt, die das Bild aufnimmt welches später auf den Spiegel projiziert
werden soll. Für gewöhnlich befindet sich diese Kamera hinter dem Spiegel und
nimmt das Umfeld vor dem Spiegel auf. Mit den Berechnungsmethoden aus „Lerne OpenGL mit GL_Sourcerer“ wird der im Spiegel gezeigte Bereich berechnet.
Die Viewmatrix wird also dadurch angepasst. Das Frustum, die Nearplane und die
Farplane werden je nach Position des Betrachters, der in den Spiegel schaut, angepasst. Auf den mathematischen Hintergrund wird hier nicht weiter eingegangen.
Sind alle nötigen Berechnungen abgeschlossen, so kann das Spiegelbild gemäß der
Viewmatrix aufgenommen werden. Abschließend wird das erhaltene Bild mit der
Methode RTT (Render To Texture) in jedem Frame auf das erstellte Spiegelobjekt
projiziert.
Der Fernseher funktioniert ähnlich, nur dass dort keine Veränderung der Position vorgenommen wird. Das Kamerabild, welches der Fernseher zeigt, wird von
einer statischen Kamera aufgenommen. Das bedeutet, dass sich der Blickwinkel
in keinem Fall ändert. Die Projektion des Fernsehbildes wird wiederum mit der
RTT-Methode verabschiedet.
53
Projektgruppe
Virtual Reality
5. Implementierung
5.2.3.7. Modifizierter Oger
Aufgrund des Aussehens des in Ogre3D integrierten Ogers sollte das Äußere des
Ogers so angepasst werden, dass er menschlicher erscheint. Es existierte bereits eine
angelegte Datei in Blender, der den Oger enthielt. Mit einem Bildbearbeitungsprogramm wurde die Textur angepasst, so dass der Oger nicht mehr grün, sondern in
menschlicher Hautfarbe erscheint. Außerdem wurden die Armreifen sowie Nieten
und die Schwerter entfernt. Zum Schluss wurde das Gesicht des Ogers angepasst.
Es wurden die aus dem Kiefer ragenden Zähne entfernt und das Gesicht wurde
verformt, so dass es menschlicher aussieht. Das Verformen von Objekten erfolgte
mit Blender im Sculpt Mode. In Abbildung 5.4 ist das Ergebnis zu sehen.
Abbildung 5.4.: links: Oger von Ogre 3D, rechts: modifizierter Oger
5.2.3.8. Scripting
Die Möglichkeit zur Interaktion mit der virtuellen Welt ist ein integraler Part, um
Immersion zu erreichen. Eine interaktive Welt zu realisieren ist mit einem nicht zu
vernachlässigenden Aufwand verbunden, insbesondere die einzelnen Interaktionen
direkt in C++ zu implementieren.
Dieser Aufwand lässt sich auf lange Sicht durch den Einsatz einer Scripting-Sprache
umgehen. Die Scripting-Sprache wird zur Ausführungszeit interpretiert. Das hat
54
Projektgruppe
Virtual Reality
5. Implementierung
den Vorteil, dass maximal ein Neustart der Anwendung vonnöten ist, um Veränderungen im Script sichtbar zu machen.
Im Zuge unserer Einarbeitung in die Thematik stellten sich zwei Sprachen als mögliche Alternativen heraus: Zum einem Python, eine stark verbreitete ScriptingSprache, zum anderen Lua, eine Sprache, die insbesondere Verbreitung in der
Computerspiele-Brache gefunden hat. Die Wahl viel auf Lua, aufgrund der einfacheren Integration. Um Lua zu integrieren, musste lediglich ein Header eingebunden, sowie ein Objekt auf dem Stack mit der Script-Datei erzeugt werden. Die
Einbindung von Python wäre über ein Boost-Paket erfolgt, dessen Kompilierung
bereits die ersten Schwierigkeiten bereitete.
Das Scripting ist äußerst eng mit der Physik-Engine verbunden. Diese Verbindung
beruht darauf, dass die Physik-Engine beim Feststellen von Kollisionen zwischen
zwei Objekten bei beiden Objekten ein Event auslöst. Die Objekte leiten dieses
Kollisions-Event letztendlich an ein Script weiter, das genau für diesen Zweck dem
Objekt zugewiesen wurde.
5.2.3.9. Kollision
Wie das Scripting, trägt auch die physische Interaktion mit der Welt stark zum
Immersionsgefühl bei. Da die von uns verwendete Grafik-Engine keine eigene Kollisionserkennung bietet, mussten wir eine eigene Lösung erstellen bzw. eine externe
Lösung einbinden.
Aufgrund von kleineren Test-Projekten erwies sich ODE als geeignetere Wahl. Zur
Auswahl stand ebenfalls die Bibliothek Bullet. Von der Entwicklung einer eigenen
Physik-Engine wurde aufgrund des großen Zeitaufwands abgesehen.
Bei der Integration von ODE kam es zu einigen Problemen. Zum Beispiel das interne Mesh-Format von OGRE 3D nach ODE zu konvertieren. Der Grund hierfür war
zum einen, dass OGRE 3D den Mesh in sogenannte Sub-Meshes aufteilen kann.
ODE tut dies nicht. Zum anderen verwenden OGRE 3D und ODE unterschiedliche Koordinatensysteme. OGRE 3D benutzt Quantoren, ODE benutzt hingegen
einfache Vektoren. Als weitaus größtes Problem erwies sich die Ungenauigkeit von
55
Projektgruppe
Virtual Reality
5. Implementierung
ODE für Fälle, in denen die Step-Intervals2 Schritte nicht gleichmäßig sind. Diese
Ungenauigkeit führte dazu, dass Objekte, die bereits zum Stillstand gekommen
waren, ohne jeden Grund anfingen sich zu bewegen. Diese Eigenschaft zerstörte
das Immersionsgefühl vollständig. Aus diesem Grund ist die Physikberechnung in
der zur Evaluation genutzten Version nicht aktiviert.
2
Physik-Engines simulieren die Welt in diskreten Schritten, diese Schritte nennt man gemeinhin
auch Step-Intervals.
56
Projektgruppe
Virtual Reality
6. Testen
6. Testen
Um die Funktionalität der einzelnen Programm-Komponenten zu gewährleisten
sind Unittests zu einer unausweichlichen Notwendigkeit geworden. Die Middleware
libpgvr nutzt daher eine geeignete Software ausführlich.
6.1. C++ Unittest-Frameworks
Für die Middleware wurde als Programmiersprache C++ gewählt, somit stehen
eine Vielzahl von Unittest-Frameworks zu Verfügung. Um ein geeignetes UnittestFramework auszuwählen, müssen bestimmte Kriterien gegeneinander abgewogen
werden. Folgende Kriterien erschienen uns besonders relevant.
Einfache Nutzung ist als das wichtiges Kriterium bei der Auswahl des Frameworks zu betrachten.
Einfache Integration spielt ebenso ein wichtige Rolle, da der Zeitaufwand bis das
Framework zur Verfügung steht möglichst gering sein soll.
Anpassbarkeit erlaubt es das Unittest-Framework an bestimmt noch nicht abgedeckte Bedürfnisse anzupassen.
In die engere Auswahl kamen Boost Testing Library, CppUnit sowie TestDog. Obwohl CppUnit, von der von uns genutzten Grafikengine Ogre verwendet wird, kam
es aufgrund seiner Komplexität nicht in die engere Auswahl. Die Wahl fiel auf
TestDog, da es einfach zu benutzen ist und die Integration einfacher ausfiel als die
von Boost Testing Library.
57
Projektgruppe
Virtual Reality
6. Testen
6.2. TestDog
Kurz nach Beginn der Nutzung von TestDog, wurde das Projekt eingestellt. Der
Internet-Auftritt des Projekts wurde ebenfalls entfernt. 1 Da das Build-Management
von TestDog auf einer handgeschrieben Makefile basierte, wurde kurzerhand eine
CMakeFile für TestDog erstellt.
6.3. Ziele und Vorgehensweise
Das Unittest-Framework wurde eingeführt mit dem Ziel, für alle testbare Funktionen Tests zu erstellen. Eine testbare Funktion ist eine Funktion, deren erfolgreiche
Ausführung, durch einen boolschen Vergleich überprüft werden kann. Ein typischer
Test könnte wie folgt aussehen. 6.1
Listing 6.1: Typischer Test
double angle(const vec3f& a, const vec3f& b) {
double vn = sqrt(pow(a.x, 2) + pow(a.y, 2) + pow(a.z, 2));
double wn = sqrt(pow(b.x, 2) + pow(b.y, 2) + pow(b.z, 2));
double vw = (a.x ∗ b.x) + (a.y ∗ b.y) + (a.z ∗ b.z) ;
double t = vw / (vn ∗ wn);
return acos(t) ∗ 180 / PI;
}
TDOG_TEST_SUITE(PoseEvent0) {
TDOG_TEST_CASE(angleFunction) {
TDOG_SET_AUTHOR("burner");
vec3f a, b;
a.x = 1; a.y = 1; a.z = 0;
b.x = 1; b.y = 0; b.z = 0;
double angleR = angle(a,b);
TDOG_ASSERT_DOUBLE_EQUAL(angleR,45.0,0.1);
a.x = 1; a.y = 0; a.z = 0;
b.x = 1; b.y = 0; b.z = 0;
angleR = angle(a,b);
a.x = 0; a.y = 1; a.z = 0;
b.x = 1; b.y = 0; b.z = 0;
angleR = angle(a,b);
}
}
Wie der Name der Funktion suggeriert, berechnet die Funktion den Winkel zwischen zwei Vektoren. Die Aufrufe der Funktion TDOG_ASSERT_DOUBLE_EQUAL
1
URL des TestDog Projektes http://sourceforge.net/projects/test-dog/.
58
Projektgruppe
Virtual Reality
6. Testen
überprüfen in diesem Fall ,ob die zwei übergebenen Floats mit einer Abweichung
von 0.1 übereinstimmen. Ist dies nicht der Fall, wird der TDOG_TEST_CASE
(angleFunction) als fehlgeschlagen markiert. Alle Test-Suits werden in einem TestReport zusammengefasst.
6.4. Code-Review
Im Rahmen des Projektes haben wir aus verschiedenen Gründen ein formelles Code
Review durchgeführt. Dabei handelt es sich um ein analytisches Verfahren, mit dem
wir im Rahmen unserer Qualitätssicherungsmaßnahmen sicherstellen wollten, dass
wir unsere nicht-funktionalen Anforderungen und insbesondere die Code-Qualität
unbedingt einhalten und die uns selbst gesetzen Ziele termingerecht erreichen.
Wir haben durch das Codereview folgende Ziele erreicht:
• Verbesserung der Code-Qualität
• Lesbarkeit
• Wartbarkeit
• Einhaltung von Standards
• Fehleranfälligkeit
• Programmier Fehler auffinden
• Design Fehler auffinden
• Verständnis für fremden Code erhöhen
Es war schon vor dem ersten offiziellen Termin des Code Reviews eine deutliche
Auswirkung des anstehenden Reviews bemerkbar. So wurden viele Fehler kurz
vor dem Review behoben und Programmteile zu modifiziert, dass diese Standards
entsprechen, damit die untersuchenden Personen auf möglichst wenig Probleme
stoßen und ein zügiges Arbeiten ermöglicht wird. Dies wurde sicherlich durch unsere geringe Gruppengröße begünstigt, da durch die kurzen Kommunikationswege
bei Unklarheiten sofort weitere Meinungen eingeholt werden konnten.
59
Projektgruppe
Virtual Reality
6. Testen
Das eigentliche Vorgehen während des Reviews gestaltete sich dabei recht formell
und benötigte einige Zeit an Vorbereitung. Die Projektleitung hat die wichtigsten
Klassen dabei gruppiert und an verschiedene Personen zum Review verteilt. Jede
Person hatte dann eine Woche Zeit die ihm zugeteilten Klassen auf Kriterien hin
zu untersuchen, welche vorher festgelegt wurden.
Die Kriterien umfassten dabei folgende Kategorien, welche sich dann wiederum in
verschiede Unterpunkte unterteilten:
• Allgemeines
• Datendeklarationen
• Definition von Funktionen
• Definition von Klassen
• Datenreferenz
• Berechnungen
• Vergleich
• Steuerfluss
• Fehlerbehandung
• Input / Output
Dabei wurde darauf geachtet, dass niemand Code untersucht, welcher von ihm
selbst erstellt wurde. Nachdem jeder eine Woche Zeit hatte die Kriterien abzuarbeiten, wurde in einer Gruppensitzung noch einmal jeder gefundene Kritikpunkt
diskutiert. Dafür wurde ingesamt ca. ein halber Arbeitstag benötigt. Die gefundenen und akzeptierten Fehler wurden dann an die eigentlichen Autoren zur Verbesserung zurück gegeben und im Laufe des Projektes korrigiert.
Das Code Review hat sich für unsere Gruppe als gute Wahl erwiesen und uns wurde
so die Möglichkeit eröffnet viele Fehler zu beheben, welche sich sonst eventuell zu
einem späteren Projekt Zeitpunkt zu schwierigen und zeitaufwendigen Problemen
60
Projektgruppe
Virtual Reality
6. Testen
entwickelt hätten. Der return of investment (ROI) wurde so sicherlich schon nach
kurzer Zeit erreicht.
61
Projektgruppe
Virtual Reality
7. Evaluation
7. Evaluation
7.1. Formulierung von Thesen
Das System und sein Nutzen in Hinblick auf Immersion und Bedienbarkeit soll
durch die Durchführung eines Experimentes empirisch untersucht werden.
Dabei sollen folgende Thesen überprüft werden:
• Die Nutzung des Systems ist für den Anwender selbsterklärend und bedarf
keiner Anleitung.
• Das VR-System erhöht die Immersion im Vergleich zu einem klassischen
Desktop-PC deutlich.
• Die Kinect lässt die Bewegung im Raum natürlicher wirken.
• Die Videobrille erhöht maßgeblich das Präsenzempfinden.
7.1.1. Erläuterung der Thesen
7.1.1.1. Die Bedienbarkeit des Systems (Hypothese 1)
• Die Nutzung des Systems ist für den Anwender selbsterklärend und bedarf
keiner Anleitung.
Durch Untersuchen der ersten Hypothese soll ermittelt werden, ob das von uns
entwickelte System ohne Vorwissen, wie zum Beispiel durch Videospiele, genutzt
werden kann oder ob Nutzer, die zuvor noch nie mit einer ähnlichen Technologie
62
Projektgruppe
Virtual Reality
7. Evaluation
in Berührung gekommen sind, vorher eine Anweisung benötigen um das System
im vollen Umfang zu benutzen.
Der Proband wird vor der Nutzung nicht instruiert und weiß daher nicht was ihn
erwartet, bzw. welche Funktionen das Virtual-Reality-System unterstützt. Nach
dem Aufsetzen der Video-Brille wird er vom System selbst eingewiesen und soll
so feststellen, dass sich die Bewegungen seines Körpers genauso auf die virtuelle
Umwelt auswirken wie in der realen Welt. Die Erhebung der Daten erfolgt dabei
passiv durch Beobachtung. Wenn der Proband die Anweisungen des Systems befolgt und sich in der virtuellen Welt frei bewegt und die Funktionen im vollem
Umfang nutzt, dann ist die Hypothese bestätigt.
7.1.1.2. Grad der Immersion bei Nutzung des gesamten Systems
(Hypothese 2)
• Das VR-System erhöht die Immersion im Vergleich zu einem klassischen
Desktop-PC deutlich.
Durch Überprüfung dieser Hypothese soll festgestellt werden, in wie weit das
Hauptziele des Projekts (die Entwicklung eines möglichst immersiven VR-Systems)
erfüllt wurde. Der Grad der Immersion ist also der zu untersuchende Wert dieser
Evaluation. Wir vergleichen dabei die Anwendung bei Nutzung unseres vollständigen VR-Systems mit der Anwendung an einem klassischen Desktop-PC.
7.1.1.3. Vorteil durch Bewegungssteuerung (Hypothese 3)
• Die Kinect lässt die Bewegung im Raum natürlicher wirken.
Es ist davon auszugehen, dass die Bewegungssteuerung für das Präsenzempfinden
des Nutzers von sehr großer Bedeutung ist. Daher möchten wir feststellen, ob
sich die Bewegung durch den Raum durch die Bewegungssteuerung natürlicher
anfühlt.
63
Projektgruppe
Virtual Reality
7. Evaluation
7.1.1.4. Präsenzempfinden durch das HMD (Hypothese 4)
• Die Videobrille erhöht maßgeblich das Präsenzempfinden.
Die Untersuchung dieser Hypothese soll aufzeigen, ob sich das Präsenzempfinden
des Systems durch das Head Mounted-Display mit Stereoskopie erhöhen lässt.
Wir erwarten, dass das Head-Mounted-Display großen Einfluss auf die Immersion
hat.
7.2. Vorbereitung der Evaluation
Zum Überprüfen der genannten Thesen sind vier Testreihen pro Probanden notwendig. Zum Einsatz kommt dabei das Repeated-measures Design. Die Reihenfolgen der Versuchsaufbauten sind angelehnt an das Vorgehen nach Tognazzini. Die
unabhängige Variable ist die verwendete Technologie und die abhängige Variable
der Grad der Immersion. Dabei verwenden wir einen auf Immersion ausgerichteten
Fragebogen (siehe Anhang), der von den Probanden nach jedem Versuchsaufbau
ausgefüllt werden muss.
Die Versuchsaufbauten:
• Aufbau A: Monitor + Tastatur/Maus
• Aufbau B: HMD + Lagesensor/Kinect
• Aufbau C: Monitor + Lagesensor/Kinect
• Aufbau D: HMD + Tastatur/Maus
7.2.1. Der Fragebogen zum Messen der Immersion
Der Entwurf eines Fragebogens zum Messen von Immersion in virtuellen Welten ist
ein Unterfangen, welches intensiven Forschungsaufwand benötigt und im Rahmen
des Projektes nicht zu leisten gewesen wäre. Wir haben uns daher dafür entschieden auf standardisierte Fragebögen zurückzugreifen und versucht einen Fragebogen
64
Projektgruppe
Virtual Reality
7. Evaluation
zu finden, welcher unsere Anforderungen möglichst gut erfüllt. Dadurch haben wir
weiterhin sichergestellt, dass typische Fehler beim Design von Fragebögen ausgeschlossen werden.
Wir haben uns nach intensiver Suche für den „Measuring Presence in Virtual Environments: A Presence Questionnaire“ Fragebogen von Bob G. Witmer und Michael J. Singer des Forschungsinstitutes der US Army für „Behavioral and Social
Science“ entschieden. Dieser Fragebogen besteht aus sehr vielen Fragen, welche in
verschiedenen Kategorien eingeteilt werden können. Jede Frage verfügt zusätzlich
über einen Korrekturfaktor, welcher die Frage gewichtet und ihren Anteil an dem
Endergebnis bestimmt. Es waren jedoch minimale Anpassungen notwendig. Da
wir unser Experiment nicht mit anderen Experimenten vergleichen wollten, welche
ebenfalls auf Grundlage des selben Fragebogens ausgewertet wurden, bestand für
uns keine Notwendigkeit uns hundertprozentig an den Fragebogen zu halten. So
haben wir Fragen modifiziert, welche Themen abdecken, die in unserer virtuellen
Umgebung keine Rolle spielen (z. B. Fragen nach Geruch).
Die Fragen konnten von den Probanden mit den Werten Null bis Zehn beantwortet
werden, wobei eine Null für eine negative Antwort hinsichtlich der Frage stand und
eine Zehn entsprechend für eine positive Antwort.
7.3. Die virtuelle Umgebung
Es wird nun die virtuelle Umgebung beschrieben, die für die Evaluation verwendet
wird. Die Umgebung besteht aus einem Wohnzimmer, weiße Rauhfaser-Tapete
und Parkettboden, mit zwei Fensterfronten in Richtung eines weitläufigen Areals
im mediteranen Stil und in Richtung einer berankten Wand eines Nachbarhauses.
Aus Richtung des Areals sind Wind, Stimmen und Vögel zu hören. In dem Raum
gibt es eine Eingangstür gegenüber der Fensterfront.
65
Projektgruppe
Virtual Reality
7. Evaluation
Abbildung 7.1.: Spiegel, Sideboard und Plattenspieler
Aus Richtung der Eingangstür sind manchmal Stimmen und Geräusche beim Öffnen einer Tür zu hören. Neben der Eingangstür steht ein Fernsehschrank inklusive
Fernseher. Links daneben ein Sideboard mit einem Plattenspieler. Über dem Plattenspieler hängt ein Bild in einem Bilderrahmen. Links und rechts neben dem
Sideboard sind zwei Stereolautsprecher aufgestellt.
Abbildung 7.2.: Fernseher und Eingangstür
66
Projektgruppe
Virtual Reality
7. Evaluation
Auf dem Plattenspieler wird ruhige klassische Musik gespielt, die über die beiden
Stereolautsprecher ertönt. Auf dem Fernseher wird eine Echtzeitübertragung einer
virtuellen Überwachungskamera angezeigt. Wenn der Proband dem Fernseher nahe
genug kommt, wird die Echtzeitübertragung durch ein Pinguin-Video ersetzt. An
einer Fensterfront steht eine rote Couch. Bei der anliegenden Fensterfront stehen
Weinfässer und Kisten. Dem Probanden wird vermittelt, dass er sich in Florenz
befindet und er wird von einer computergenerierten Frauenstimme in die Szenarie
eingeführt. Sie weist ihn an sich frei im Raum zu bewegen und sich dem Fernseher
zu nähern.
Abbildung 7.3.: Couch und Fensterfront
7.4. Durchführung der Evaluation
Die Evaluation fand mit einem Umfang von 16 Probanden am 29.2.2012 und
1.3.2012 in der Universität statt. Pro Proband wurden 30 Minuten eingeplant.
Dabei nutzten die Testpersonen jeden Versuchsaufbau ca. 90 Sekunden. Der Fragebogen wurde im Durchschnitt in ca. zwei Minuten ausgefüllt. Vor Beginn der
Evaluation mussten die Probanden eine Einverständniserklärung unterschreiben,
die umfangreich über Risiken und Ablauf informierte. Eine Kopie der Einverständniserklärung befindet sich im Anhang. Bei der Untersuchung wurde der Raum
abgedunkelt um die Ablenkung der Probanden durch die natürliche Umwelt zu
67
Projektgruppe
Virtual Reality
7. Evaluation
minimieren. Bei den Tests kam es zu keinen nennenswerten Störung im Ablauf, so
dass die Ergebnisse aller 16 Probanden gewertet werden können.
Abbildung 7.4.: Ein Proband nutzt das VR-System
68
Projektgruppe
Virtual Reality
7. Evaluation
Abbildung 7.5.: Ein Proband füllt den Fragebogen aus
7.5. Ergebnisse der Evaluation
7.5.1. Qualitative Auswertung
Während der Evaluation sind, neben den durch den Fragebogen erhobenen Daten, zusätzlich qualitative Beobachtungen gemacht worden. Wir haben dazu die
einzelnen Probanden beobachtet und ihr Verhalten protokolliert. Diese Informationen haben wir informell ausgewertet und sind dabei zu folgenden Schlüssen
gekommen:
• Die Steuerung mit der Kinect ist zuerst nicht intuitiv. Es hat meistens eine
kurze Zeit gedauert, bis die Probanden bemerkt haben, dass sie sich im
Raum bewegen können. Sofern die Probanden vorher einen Versuchsaufbau
69
Projektgruppe
Virtual Reality
7. Evaluation
mit Maus und Tastatur durchlaufen sind, ist dieses Problem weniger relevant
gewesen.
• Im Gegensatz zum vorherigen Punkt, ist die Steuerung mit Maus und Tastatur in der Regel bekannt gewesen. Zwar gab es auch einige Teilnehmer,
die diese Steuerung noch nicht kannten, jedoch waren keine großen Schwierigkeiten zu beobachten.
• Die 3D Brille wurde von vielen Probanden als zu schwer oder unhandlich
bemängelt. Teilweise mussten Probanden während des Versuchs die Brille
festhalten, um diese beim Umgucken nicht zu verlieren oder zu beschädigen.
• Drehungen mit dem HMD wurden als schwierig empfunden, während man
am PC saß.
Aufgrund des jungen Durchschnittsalters der Probanden vermuten wir, dass die
Steuerung mit Maus und Tastatur durch Computerspiele bekannt war und daher
keiner genaueren Erklärung bedurfte. Die Kinect hingegen ist erst seit kurzer Zeit
für Endkunden verfügbar, wodurch im kollektiven Bewusstsein die genaue Funktionsweise noch nicht verankert ist.
7.5.2. Mathematische Auswertung
Die Fragebögen aller Probanden wurden mathematisch ausgewertet. Dabei wurde grundsätzlich zwischen den vier verschiedenen Versuchsaufbauten differenziert.
Zum Messen des Immersionsgrades wurde jede der 19 Fragen mit einem Gewichtungsfaktor multipliziert. Anschließend wurden für jeden Versuchsaufbau die Werte aller 19 Fragen addiert, der Mittelwert aller Probanden ermittelt und abschließend durch die möglich Maximal-Punktzahl (67,5) dividiert. Das Ergebnis ist der
Grad der Immersion, der zwischen 0 uns 1 liegt.
Um die Aussagefähigkeit unserer Ergebnisse zu bestimmen, wurden die Daten mit
einem Zweistichproben-t-Test untersucht. Der Zweistichproben-t-Test ist ein Signifikanztest der mathematischen Statistik und überprüft, ob zwei Stichproben signifikant unterschiedlich verteilt sind. Für unsere Evaluation haben wir den abhängi-
70
Projektgruppe
Virtual Reality
7. Evaluation
gen two-tailed t-Test verwendet, da wir zwei von einander abhängige Stichproben
durch das Repeated-measures design erhalten. Liegt das Ergebnis des t-Tests nicht
unter einem gewählten Signifikanzniveau, so kann die Nullhypothese (Daten beider
Stichproben sind gleich verteilt) nicht abgelehnt werden. Liegt das Ergebnis jedoch
unterhalb des Signifikanzniveaus kann, so kann die Nullhypothese zugunsten der
Hypothese (Daten beider Stichproben sind signifikant unterschiedlich verteilt) abgelehnt werden. Für unsere Untersuchung haben wir ein Signifikanzniveau von 5
Prozent gewählt. Das bedeutet, dass das Verwerfen der Nullhypothese mit einer
Wahrscheinlichkeit von über 95 Prozent richtig ist und die Wahrscheinlichkeit, dass
die Daten nur zufällig unterschiedlich verteilt sind, unter 5 Prozent liegt.
Um die Ergebnisse weiterhin grafisch zu veranschaulichen nutzen wir BoxplotDiagramme. Boxplots geben schnell und übersichtlich Aufschluss darüber, wie Daten verteilt sind. Die dabei verwendeten Größen sind (von oben nach unten):
• Maximum
• Oberes Quantil (75 Prozent der Daten liegen unterhalb des Wertes)
• Median (50 Prozent der Daten liegen unterhalb des Wertes)
• Unteres Quantil (25 Prozent der Daten liegen unterhalb des Wertes)
• Minimum
Die Box zwischen dem oberen und unteren Quantil zeigt dabei auf, wo 50 Prozent
der erhobenen Daten liegen.
(Die Daten der ausgefüllten Fragebögen befinden sich im Anhang)
7.5.2.1. Immersionsgrad der Versuchsaufbauten
Bei der Auswertung aller Fragebögen wurden die folgenden Immersionsgrade für
die vier unterschiedlichen Versuchsaufbauten ermittelt:
• Versuchsaufbau A = 0,5195
• Versuchsaufbau B = 0,6750
71
Projektgruppe
Virtual Reality
7. Evaluation
• Versuchsaufbau C = 0,4845
• Versuchsaufbau D = 0,5596
Versuchsaufbau A (Verwendung der Kinect und des HMD) hat demnach den größten Immersionsgrad erzielt. Überraschenderweise ist bei der Verwendung der Kinect ohne Videobrille (Versuchsaufbau C) der Immersionsgrad geringer als bei der
klassischen PC-Nutzung mit Maus und Tastatur (Versuchsaufbau A)
Abbildung 7.6.: Boxplots - alle Versuchsaufbauten
Das Boxplot-Diagramm zeigt für jeden Versuchsaufbau die Verteilung der Messergebnisse und macht deutlich, dass sich nur Versuchsaufbau B bedeutsam von den
anderen Aufbauten abhebt. Der Zweistichproben-t-Test zwischen Versuchsaufbau
A und B ergibt einen Wert von 0,000642 und liegt damit deutlich unter dem Signifikanzniveau von 0,05. Die Nullhypothese kann damit abgelehnt werden und es gibt
einen essenziellen Unterschied zwischen der Immersion durch einen Desktop-PC
72
Projektgruppe
Virtual Reality
7. Evaluation
und der Immersion durch unser VR-System. Unsere Hypothese „Das VR-System
erhöht die Immersion im Vergleich zu einem klassischen Desktop-PC deutlich“
wurde dabei bestätigt. Deutlich wird weiterhin, dass dies nur durch Kinect und
Videobrille zusammen erreicht wird. Die alleinige Nutzung der Kinect oder des
HMD führt zu keinem signifikanten Immersionsgewinn im Vergleich zum DesktopPC.
7.5.2.2. Bewegung in der virtuellen Welt
Im Folgenden wird auf die Bewegung in der virtuellen Welt eingegangen. Anhand
der Frage „Wie natürlich empfanden Sie die Bewegung in der virtuellen Welt?“
wird ausgewertet, ob und wodurch sich die Natürlichkeit der Bewegung erhöhen
lässt. Verglichen werden dabei die Antworten der Frage für Versuchsaufbau A
(Desktop-PC) mit Versuchsaufbau C (Monitor und Kinect).
Abbildung 7.7.: Boxplots - Bewegung im Raum mit und ohne Kinect
73
Projektgruppe
Virtual Reality
7. Evaluation
Das Diagramm zeigt, dass die Bewegungssteuerung über die Kinect die Bewegung
im virtuellen Raum deutlich natürlicher erscheinen lässt. Ein durchgeführter t-Test
mit dem Ergebnis von 0,0000237 bestätigt die Annahme. Unsere Hypothese „Die
Kinect lässt die Bewegung im Raum natürlicher wirken“ ist damit bestätigt.
Abbildung 7.8.: Boxplots - Bewegung im Raum mit und ohne Videobrille
Dieses Diagramm zeigt die Boxplots der selben Frage für Versuchsaufbau A (ohne
HMD) und Versuchsaufbau D (mit HMD) und macht deutlich, dass die Videobrille
keinen positiven Einfluss auf die Natürlichkeit der Bewegungen im virtuellen Raum
hat.
7.5.2.3. Präsenzempfinden
In diesem Unterkapitel wird untersucht, ob und wodurch sich das Präsenzempfinden steigern lässt. Die Ergebnisse der Frage „Wie intensiv waren Sie in der virtuel-
74
Projektgruppe
Virtual Reality
7. Evaluation
len Welt integriert?“ werden für Versuchsaufbau A (Desktop-PC ohne HMD) mit
Versuchsaufbau D (mit HMD) verglichen.
Abbildung 7.9.: Boxplots - Präsenzempfinden mit und ohne Videobrille
Das Diagramm zeigt, dass die Videobrille den Nutzer intensiver in die virtuelle
Welt eintauchen lässt. Bestätigt wird dies durch ein Ergebnis von 0,0017248 beim
t-Test.
75
Projektgruppe
Virtual Reality
7. Evaluation
Abbildung 7.10.: Boxplots - Präsenzempfinden mit und ohne Kinect
Dieses Diagramm zeigt die Boxplots der selben Frage für Versuchsaufbau A (ohne
Kinect) und Versuchsaufbau C (mit Kinect) und zeigt, dass die Kinect keinen
messbaren Einfluss auf die Intensität des Präsenzempfinden hat.
Weiterhin wird die Frage „Wie schnell haben Sie sich in die virtuelle Welt versetzt
gefühlt?“ untersucht. Die Ergebnisse werden im folgenden für Versuchsaufbau A
(Desktop-PC ohne HMD) und Versuchsaufbau D (mit HMD) dargestellt.
76
Projektgruppe
Virtual Reality
7. Evaluation
Abbildung 7.11.: Boxplots - Versetzung in die virtuelle Welt mit und ohne
Videobrille
Die Verteilung der Daten verdeutlicht, dass die Videobrille den Nutzer schneller in
die virtuelle Welt versetzt. Bestätigt wird dies durch ein Ergebnis von 0,0003739
beim t-Test. Unsere These „Die Videobrille erhöht maßgeblich das Präsenzempfinden“ ist damit bestätigt.
77
Projektgruppe
Virtual Reality
7. Evaluation
Abbildung 7.12.: Boxplots - Versetzung in die virtuelle Welt mit und ohne Kinect
Dieses Diagramm zeigt die Werteverteilung der selben Frage für Versuchsaufbau
A (ohne Kinect) und Versuchsaufbau C (mit Kinect) und macht deutlich, dass die
Kinect den Nutzer nicht schneller in die virtuelle Welt versetzt.
7.5.2.4. Geräusche in der virtuellen Welt
Die Frage „Wie gut konnten Sie Geräusche lokalisieren?“ hat für Versuchsaufbau
A (Desktop-PC ohne HMD) und Versuchsaufbau D (mit HMD) folgende Datenverteilungen:
78
Projektgruppe
Virtual Reality
7. Evaluation
Abbildung 7.13.: Boxplots - Geräusche lokalisieren mit und ohne Videobrille
Das Diagramm zeigt, dass die Geräusche mit Videobrille signifikant besser lokalisierbar sind als ohne Videobrille. Ein durchgeführter t-Test mit dem Ergebnis von
0,0014441 bestätigt die Annahme.
7.5.2.5. Vergleich zur realen Welt
Im Folgenden soll ermittelt werden, ob das von uns entwickelte VR-System die
Bedienung im Vergleich zum klassischen Desktop-PC natürlicher erscheinen lässt
und der Nutzer sich dadurch mehr an die reale Welt erinnert fühlt. Die Frage
„Wie ähnlich waren ihre Erfahrungen in der virtuellen Welt im Vergleich zur realen
Welt?“ hat für Versuchsaufbau A (Desktop-PC) und Versuchsaufbau B (mit Kinect
und mit HMD) folgende Datenverteilungen:
79
Projektgruppe
Virtual Reality
7. Evaluation
Abbildung 7.14.: Boxplots - Natürlichkeit der virtuelle Welt mit Kinect/HMD und
ohne Kinect/HMD
Die Verteilung Boxplots zeigt deutlich, dass die Nutzung von Videobrille und
Bewegungssteuerung über die Kinect die Nutzung des Systems maßgeblich realer erscheinen lassen. Der Zweistichproben-t-Test zwischen Versuchsaufbau A und
Versuchsaufbau B ergibt einen Wert von 0,0002130. Unsere Annahme ist damit
bestätigt.
7.6. Fazit
Die Evaluation wurde erfolgreich abgeschlossen und hat die von uns erwarteten
Ergebnisse geliefert. Die Resultate zeigen deutlich, dass wir unser Projektziel (ein
möglichst immersives VR-System zu entwickeln) erfüllt haben. Weiterhin zeigen
80
Projektgruppe
Virtual Reality
7. Evaluation
die Ergebnisse, dass unser Vorgehen, die Kinect und die Videobrille zusammen
einzusetzen, die richtige Entscheidung war. Denn nur, wenn beide Komponenten
zusammen zum Einsatz kommen, wird der Grad der Immersion signifikant erhöht.
Die Kinect hat dabei erwartungsgemäß einen positiven Einfluss auf natürlich erscheinende Bewegungen. Die Videobrille hingegen ist essenziell für das Präsenzempfinden und lässt den Nutzer in die virtuelle Welt eintauchen.
81
Projektgruppe
Virtual Reality
8.1. Persönliches Fazit von Robert Schadek
Grundsätzlich ist ein positives Fazit zu ziehen. Die aufgetretenen Probleme waren
hauptsächlich handwerklicher Natur.
Insbesondere Ogre3d stellte einige unnötige Herausforderungen bereit. Die Trennung von Sourcen und Headern führte insbesondere zu unnötig langen Wartezeiten, die einem effizientes Arbeiten oft im Weg standen. Der Versuch von Ogre3d
durch diese Trennung eine Java ähnliche Entwicklung zu ermöglichen führt noch
an anderen Stellen zu unangenehmen Problemen. So wurde z. B. versucht durch
typedef s kurze Namen für Typen einzuführen. Allerdings führte dies dazu, dass
man, bevor man Methoden des eigentlichen Typen verwenden konnte, erst einmal
den eigentlichen Typen bestimmen musste.
OpenNI und Nite waren im Vergleich zu Ogre3d relativ einfach zu nutzen. Die
größte Schwierigkeit bestand darin eine Version zu finden und zu installieren, die
bei allen Gruppenmitglieder funktioniert.
Abschließend kann ich nur sagen, dass das Projekt für mich ein voller Erfolg war.
Sowohl was die Gruppe als auch die Bearbeitung der Aufgabe angeht.
8.2. Persönliches Fazit von Christian Herz
Mein persönlicher Eindruck dieser Projektgruppe ist sehr positiv. Die Zusammenarbeit mit den Projektgruppenmitgliedern war stets sehr angenehm. Streitpunkte
gab es selten, was für mich von sehr großer Sympathie und ein gutes Team zeugt.
82
Projektgruppe
Virtual Reality
Traten einmal Verständnisprobleme oder Meinungsverschiedenheiten auf, so wurden diese immer gemeinsam bewältigt.
Zu Ogre3D muss ich sagen, dass es anfangs ziemlich einfach aussah, wobei sich letzten Endes herausstellte, dass teilweise Dinge unzureichend implementiert wurden,
wie z. B. das Shadow Mapping. Auch bei den Beispielen auf deren Webseite hätten sie grundlegende Dinge, wie die Implementierung eines Spiegels zeigen sollen.
Zugute kam mir persönlich auf jeden Fall das gut besuchte Forum von Ogre3D.
OpenNI und Nite haben uns auf jeden Fall die Projektarbeit erleichtert, weil es
für Linux sowie Windows verfügbar ist und bereits eine Skeletterkennung existiert.
Hätte solch eine Skeletterkennung noch nicht existiert, dann wären wir sicherlich
nicht so weit mit unserem Projekt gekommen wie es jetzt der Fall ist.
Weitergehend hatte ich die Möglichkeit weitere Kenntnisse in C++, dem Teamwork
sowie dem Erstellen von CMake-Skripten zu sammeln. Erste Eindrücke in der 3DModellierung mittels Blender bereitete mir sehr viel Freude.
Abschließend kann ich sagen, dass ich wirklich froh bin diese Projektgruppe gewählt zu haben. Wir haben viel erreicht und niemals vergessen, dass ein gutes
Arbeitsklima von großer Bedeutung ist. Grillabende oder das Bestellen von Pizza
hat das Arbeitsklima stets aufgelockert und man konnte sich auch außerhalb der
Universität kennenlernen.
8.3. Persönliches Fazit von Jendrik Poloczek
In Bezug auf das Team kann ich sagen, dass meine Kollegen und ich versucht haben stets, bis auf wenige Ausnahmesituationen, rational zu argumentieren. Das
Arbeitsklima war mir und meinen Mitstreitern, sehr wichtig, sodass wir stets darauf geachtet haben, dass sich keine Missverständnisse oder Ungereimtheiten hochschaukeln. Alle Mitglieder haben versucht sich einzubringen. Besonders gut fand
ich die Kompetenz des Teams, und die Möglichkeit sich in seinen eigenen Interessengebieten ausgiebig, aber durch die Anforderungen begrenzt, auszuleben. Wenn
83
Projektgruppe
Virtual Reality
man das Augenmerk auf die Technik und die Umsetzung legt, bleibt zu erwähnen, dass unser System aufgrund vieler Abhängigkeiten sehr komplex, durch sehr
viele Abhängigkeiten, und in meinen Augen nur durch den Einsatz des Buildsystems CMake zu bändigen war. Die verwendeten Abhängigkeiten waren teils
schwierig einzusetzen, da die Dokumentation verschiedener Teilsysteme nur befriedigend war. Die Gruppe hat es dennoch sehr gut geschafft auf Grundlage der
Anforderungen, eine entsprechend gut funktionierende Architektur zu entwerfen.
Ich habe viel über OpenAL, Ogre3D und Blender gelernt. Und für mich war es das
erste Teamprojekt mit der Programmiersprache C++.
8.4. Persönliches Fazit von Matthias Bruns
Beim Projekt Virtual Reality habe ich viele Erfahrungen gesammelt und vieles gelernt, in Bereichen mit denen ich bisher wenig in Kontakt gekommen bin.
Mein bisheriges Studium der Wirtschaftsinformatik an der Universität Göttingen war stark betriebswirtschaftlich orientiert und beinhaltete nur ein Semester
Java-Programmierung. Die Projektgruppe hat mir die Möglichkeit gegeben meine
Programmierfähigkeiten auszubauen und ich habe das erste mal mit C++ arbeiten
können. Auch die Arbeit mit Ogre3D, der Versionsverwaltung Git und das Modellieren mit Blender waren neu für mich und ich habe viel dazu gelernt. Aufgrund
der Vielseitigkeit und dem Zeitraum über zwei Semester, bin ich mir sicher, dass
mich die Projektgruppe in meinem Studium wesentlich weiter gebracht hat, als
mehrere einzelne Module mit gleichem KP-Umfang es ermöglicht hätten.
Auch das Arbeitsklima im Team war durchgehend angenehm. Meinungsverschiedenheiten traten nur bezüglich Projektentscheidungen auf und konnten immer
schnell gelöst werden. Auch die Grillabende und andere gemeinsame Aktivitäten
außerhalb der Uni bleiben positiv in Erinnerung.
Zusammenfassend hat mir das Projekt Virtual Reality sehr viel Spass gemacht.
Das Thema empfand ich als sehr interessant und ich habe dabei viel lernen können. Wir haben die Komponenten Kinect, Videobrille und 3D-Engine erfolgreich
84
Projektgruppe
Virtual Reality
zusammengebracht. Das Ergebnis der Evaluation zeigt, dass wir unser Projektziel erreicht haben und ich denke, dass wir durchaus stolz auf unsere Arbeit sein
können.
8.5. Persönliches Fazit von Justin Heinermann
Die Wahl der Projektgruppe für das zweite und dritte Semester des M.Sc.-Studienganges
Informatik ist oft keine einfache, da man sich ein Jahr lang mit der Thematik
des Projektes, der Gruppe und den Betreuern zurechtfinden muss. Da in unserer
Projektgruppe eine sehr interessante Thematik behandelt wurde und wir unsere Aufgabenstellung erfolgreich umgesetzt haben, beurteile ich meine Wahl der
Projektgruppe als positiv.
Weil bei mir die persönliche Motivation für die Beschäftigung mit Grafikprogrammierung und technischen Neuheiten gegeben ist, war auch die Motivation für das
Projekt hoch. Da die Konkretisierung der Aufgabenstellung bei uns Projektmitgliedern selbst lag, konnten wir das Projektziel nach unseren eigenen Wünschen
formulieren. Was wir mit dem Projekt zu sechst in einem Jahr realisiert haben, ist
in meinen Augen als Erfolg zu werten.
Zu den persönlichen Erfahrungen in der Projektgruppe ist zunächst die Gruppenarbeit zu nennen, die die Projektmitglieder vor eine neue Situation gestellt hat. Das
wichtigste ist hier, dass alle Mitglieder gemeinsam auf die Ziele der Gruppe hinarbeiten. In unserem Fall hat sich gezeigt, dass sich durch die relativ kleine Gruppengröße, Organisation und Kommunikation relativ einfach gestaltet haben.
Auf technischer Seite hat sich gezeigt, dass wir viele verschiedene Softwarebibliotheken verwenden mussten, was softwaretechnisch für mich eine neue Arbeitsweise
bedeutete. Leider ist man hier auf manchmal spärliche Dokumentation von den
verschiedenen Bibliotheken angewiesen und es ist nicht unbedingt im Vorfeld ersichtlich, welche Aufgaben tatsächlich zuverlässig und wie gewünscht von der jeweiligen Software verrichtet werden. Für meine persönliche Erfahrung hat sich hier
gezeigt, dass man im Vorfeld noch sorgfältiger beurteilen sollte, welche Bibliotheken sich eignen und wie ausgereift diese sind.
85
Projektgruppe
Virtual Reality
Bei der Grafikprogrammierung würde ich in Zukunft eher auf eine eigene Grafikengine (z.B. mit OpenLG) setzen als auf eine fertige Engine wie Ogre3d. Die
Vorteile, die einem versprochen werden und die tatsächlich zum Tragen kommen,
werden erkauft durch eine oft eingeschränkte Flexibilität und ein großes, schwer
zu verstehendes System. Falls ein solches System Unzulänglichkeiten hat, muss
zusätzlicher Aufwand betrieben werden ,um diese zu umschiffen.
Als besonders positiv für den Lerneffekt empfand ich, abseits von den Kernaufgaben des Projektes, die Entwicklung des Linux-Treibers für den Lagesensor, da
dieser eine neue Herausforderung für mich darstellte.
Für das Projektmanagement habe ich als Lektion mitgenommen, dass Ziele eindeutig und gemeinsam formuliert werden sollten und dass Zeitpläne realistisch gesetzt
werden sollten.
8.6. Persönliches Fazit von Tim Jörgen
Mein Fazit bezüglich der Projektgruppe ist durchaus positiv. Persönlich habe ich
gelernt, dass Plattformunabhängigkeit auch beim Einsatz von darauf spezialisierten Tools eine extrem kostenaufwendige Sache ist, deren Wirtschaftlichkeit man
sich genau überlegen sollte.
Angenehm war das Arbeitsklima, bei dem sehr flexibel gearbeitet werden konnte,
wodurch es nie zu Schwierigkeiten gekommen ist, wenn andere Termine anstanden. Durch unsere lockere Arbeitsweise konnte man auch unkompliziert Termine
finden.
Was ich künftig anders machen würde, ist eine Sprache wie C++ für ein solch
umfangreiches Projekt zu verwenden. Eine moderne Sprachen mit Garbage Collection hätten meiner Meinung nach die vorhandenen Human Resourcen deutlich
geschont. Ein Zugriff auf die OpenNI libs wäre problemlos über JNA möglich gewesen.
Insgesamt sind wir aber denke ich alle froh, dass wir diese Gruppe gewählt haben,
da wir sehr viel gelernt haben.
86
Projektgruppe
Virtual Reality
Die Projektgruppe Virtual Reality begann im April 2011 und endete im März
2012. In dieser Zeit haben wir es uns zur Aufgabe gemacht, die Herausforderung zu
meistern, aus Consumer Products und freier Software ein immersives VR-System
zu entwickeln. Wir haben dabei eine 3D-Engine mit einer Bewegungssteuerung per
Microsoft Kinect und der Videobrille Vuzix Wrap 920 kombiniert.
Bei der Entwicklung lag unser Fokus auf der Erstellung einer Middleware, auf
der auch andere VR-basierte Software aufsetzen kann, die die Kinect und Vuzix
Videobrille als Eingabegeräte verwendet. Im Laufe der Projektgruppe sind wir
dabei auf viele Probleme gestoßen. So waren beispielsweise für die Vuzix Wrap 920
keine Linux-Treiber verfügbar und die Grafik-Engine Ogre3D ließ sich aufgrund
diverser Defizite in der Implementierung, zum Teil nur unter sehr großem Aufwand
in unser Projekt integrieren. Zum Ende des Projekts konnten wir allerdings alle
Probleme lösen und haben alle unsere Meilensteine erfolgreich erreicht.
Das Ergebnis ist ein VR-System, das den Nutzer in eine virtuelle Welt eintauchen
lässt. Körper- und Kopfbewegungen werden in Echtzeit verarbeitet und über die
Videobrille ausgegeben. Um abschließend zu klären, ob unser System auch wirklich
immersiver ist als ein klassischer Desktop PC, haben wir das VR-System umfangreich evaluiert. Dabei haben 16 Probanden unsere Entwicklung getestet und einen
auf Immersion ausgerichteten Fragebogen ausgefüllt. Das Ergebnis der Evaluation
ist eindeutig: Das von uns entwickelte VR-System ist signifikant immersiver als
die Nutzung von Tastatur und Maus am Computer-Monitor. Unser Projektziel,
ein möglichst immersives VR-System zu entwickeln, haben wir damit nachweislich
erfüllt. Die Evaluation hat weiterhin gezeigt, dass unsere Entscheidung, die Kinect
und die Videobrille zusammen einzusetzen, richtig war. Denn nur die Zusammenarbeit beider Geräte führt zu einer maßgeblichen Erhöhung der Immersion.
87
Projektgruppe
Virtual Reality
Trotz des Erfolges bei der Entwicklung, bietet das System noch viel Potential zur
Verbesserung und Weiterentwicklung, die allerdings bessere Hardware erfordert
die noch nicht verfügbar ist. Insbesondere die Videobrille hat ein großes Defizit:
die Auflösung der Displays ist sehr gering und man hat bei der Nutzung das Gefühl, auf weit entfernte Projektionsflächen zu schauen. Auch die zweite Version der
Microsoft Kinect, die 2013 erscheinen soll, könnte die Genauigkeit der Körpererfassung deutlich erhöhen und würde den Nutzer noch präsenter in der virtuellen
Welt erscheinen lassen.
Die Präsentation unseres VR-Systems auf einer Schülerveranstaltung an der Universität hat gezeigt, dass das Thema virtuelle Realität auf sehr großes Interesse
stößt. Aber nicht nur für Privathaushalte sind VR-Systeme interessant. Auch Unternehmen nutzen vermehrt VR-Anwendungen um zum Beispiel neue Produkte
noch vor der Herstellung realitätsnah anschaulich machen zu können. Das von uns
entwickelte System könnte beispielsweise von Architekten dazu verwendet werden, um Bauprojekte schon im Entwurfsstatus virtuell begehen und erkunden zu
können.
Zusammenfassend haben wir unser Projekt erfolgreich abgeschlossen. Das von uns
entwickelte VR-System ermöglicht das Eintauchen in eine virtuelle Welt und ist
dabei messbar immersiver als klassische Desktop-PCs. Weiterhin haben wir alle
viel dazu gelernt, positive Erfahrungen gesammelt und uns allen hat die Arbeit an
unserem Projekt sehr viel Spass gemacht. Wir bedanken uns auch bei Prof. Dr.
Wolfgang Kowalk und Dipl.-Inf. Stefan Brunhorn für die sehr gute Betreuung mit
konstruktiven Vorschlägen und einer freundlichen Arbeitsatmosphäre.
88
Projektgruppe
Virtual Reality
[Bernd Brügge 2004] Bernd Brügge, Allen H. D.: Objektorientierte Softwaretechnik mit UML, Entwurfsmustern und Java. Pearson Studium, 2004 3.8,
4.1
[Heinermann 2011] Heinermann, Justin P.: Virtual Reality und der Einsatz in
der Praxis. 2011. – Forschungsbericht 3.2
[Michael Dixon 2012] http://dev.pointclouds.org/attachments/download/
358/Sensor-Win-OpenSource32-5.0.3.msi 1e
[Poloczek 2011] Poloczek, Jendrik: Präsenzempfinden in virtuellen Umgebungen.
2011. – Forschungsbericht 3.2
[Sense 2012] http://www.openni.org/Downloads/OpenNIModules.aspx 1a, 1c,
1d
[Streeting 2012] http://www.ogre3d.org 3.6
[Vuzix-Corporation
2012a]
wrap920vrbundle.html 3.6
http://www.vuzix.com/consumer/products_
[Vuzix-Corporation
drivers.html 2a
http://www.vuzix.com/support/downloads_
2012b]
89
Projektgruppe
Virtual Reality
A. Anhang
A. Anhang
A.1. Schnittstellenfunktionen
Ein kurzes Beispiel, dass die Benutzung der Middleware kurz darstellt.
// so the destructor won’t fail
this −>middleware = NULL;
// create an instance of the middleware
this −>middleware = new Middleware::Main();
try {
this −>head = this−>middleware−>getHeadDirection();
} catch (AttitudeSensorException∗ e) {
std :: cout << e−>message() << std::endl;
}
try {
joints = this−>middleware−>getSkeleton(NULL);
} catch (Middleware::MiddlewareException∗ e) {
std :: cout << e−>message() << std::endl;
};
Ein wichtige Anmerkung ist hier, dass die Methode getSkeleton der Middleware
Speicher alloziert wenn ihr NULL übergeben wird. Übergibt man hingegen ein
24 elementiges Array von Joints wird kein Speicher alloziert sondern die Daten
werden in das Übergebene Array geschrieben.
Die Methode getHeadDirection gibt einen Pointer auf das Head Objekt zurück.
Dieses Objekt wiederrum enthält einen Member names headDirection, welches wiederum den Yaw, Pitch und der Roll enthält.
Eine neuere Dokumentation der verschiedenen Schnittstellen befindet sich in der
Doxygen Dokumentation.
i
Projektgruppe
Virtual Reality
A. Anhang
A.1.1. registerPose, registerGesture
RegisterPose sowie registerGesture sind im Prinzip gleich, der Unterschied liegt
in den Funktionsparamter. Bei registerGesture übergibt man je einen Middleware::KinectWrapper::GestureEvent* , sowie einen Middleware::KinectWrapper::GestureObserver*.
GestureObserver implementieren eine Methode names notify. Diese Methode übernimmt als Parameter einen GestureEvent.
Das selbe gilt für registerPose, mit dem Unterschied das GestureEvent und GestureObserver PoseEvent und PoseObserver heißen.
In der jeweilen notify Methode kann dann abhängig von dem übergebenen Event
Funktionalität implementiert werden.
A.2. Installation
Im Folgenden wird die Installation der entwickelten Software unter Windows sowie
Linux erläutert. In Abbildung A.1 werden die Abhängigkeiten des Frontends sowie
der Middleware gezeigt.
FrontEnd
LibOgg
Boost
LibVorbis
OpenNI
OpenAL
Nite
Middleware
Vuzix SDK(Windows)
Ogre SDK
Testdog
TinyXml
SLB
LibUsb(unix)
Logger
Abbildung A.1.: Abhängigkeiten Middleware/Frontend
ii
Projektgruppe
Virtual Reality
A. Anhang
A.2.1. Windows
1. Installation der Kinect
Im Folgenden wird die Installation der Microsoft Kinect unter Windows beschrieben.
a) Installieren der “unstable OpenNI Binaries“ für 32Bit erhältlich unter
Sense [2012]
b) Installieren des Sensortreiber erhältlich unter https://github.com/
avin2/SensorKinect/tree/unstable/Platform/Win32/Driver (unstable branch). Je nachdem, welche Windowsversion benutzt wird, 32 oder
64 Bit, bitte die jeweilige ausführbare Datei benutzen.
c) Installieren der ünstable OpenNI Middleware Binaries“ für 32Bit erhältlich unter Sense [2012].
d) Installieren der ünstable OpenNI Hardware Binaries“ für 32Bit erhältlich unter Sense [2012].
e) Gegebenenfalls die prebuilt binary for Kinect sensor Version 5.0.3"von
Michael Dixon [2012] installieren.
2. Installation der Vuzix Wrap 920
Im Folgenden wird die Installation der Vuzix Wrap 920 3D-Brille beschrieben.
a) Installation des Vuzix VR Managers, der für die Kalibrierung der Brille
vor der Benutzung benötigt wird. Er ist erhältlich unter Vuzix-Corporation
[2012b].
b) Installation des Vuzix SDK erhältlich unter http://vrdeveloper.vr920.
com/downloads/w/Vuzix_SDK_3.1.1.zip.
3. Erstellen der Middleware mit im Repository enthaltenen Abhängigkeiten
Das Kompilieren der Einzelkomponenten ist unter Windows automatisiert.
Dafür muss lediglich die Datei Install.bat aus dem Verzeichnis /repository/projects/pgvr aufgerufen werden. Ein Kommandozeilenfenster startet und
iii
Projektgruppe
Virtual Reality
A. Anhang
die Einzelkomponenten sowie die Middleware werden kompiliert. Zu beachten sind die Hinweise in der README in demselben Verzeichnis, in dem sich
auch die Install.bat befindet.
A.2.2. Unix
1. Installation der Kinect
a) Kernel Module Blacklisten: Bevor die Kinect angeschlossen werden kann
muss dafür gesorgt werden, dass Linux nicht automatisch Treiber für
die einzelnen Devices1 der Kinect lädt. Die zu blockierenden Module sind gspca_main gspca_kinect. In der Regel wird dies in der Datei
/etc/modprobe.d/blacklist.config eingetragen.
b) OpenNI installieren: Um OpenNI zu installieren lädt man unter http:
//www.openni.org/downloadfiles/opennimodules/openni-binaries/
20-latest-unstable die Version 1.3.2.3 runter. Für die Installation
folgt man der, im Download mitgelieferten, platformspezifischen Anleitung.
c) Installation Sensor: Um Sensor zu installieren klont man aus GitHub
den unstable branch. https://github.com/avin2/SensorKinect Dann
wechselt man in das Platform abhängige Verzeichnis Platform/***/CreateRedist
und führt dort den RedistMaker aus. Hierbei ist zu beachten das das
Standard Python eine 2.x Version ist. Danach wechselt man in den Ordner Final, entpackt das Archive und installiert es mit sudo install.sh.
d) Intallation NITE: Für die Skeletterkennung wird NITE in der Version
1.4.1.2 benötigt. http://www.openni.org/downloadfiles/opennimodules/
openni-compliant-middleware-binaries/33-latest-unstable Nach
dem Entpacken des Archives erfolgt die Installation durch sudo install.sh. Bei der Installation wird ein Lizenzschlüssel verlangt. Dieser
lautet 0KOIk2JeIBYClPWVnMoRKn5cdY4=.
1
Unter einem Device versteht man in diesem Zusammenhang in dieses Fall ein Eingabegerät.
Die Kinect besitzt drei. Den Teifensensor, die Videokamera sowie das Mikrophone.
iv
Projektgruppe
Virtual Reality
A. Anhang
e) Compileren der Softwarekomponenten: Das Compileren der Softwarekomponenten ist immer gleich, einzig die Reihenfolge ist von belang.
Zum Compilieren begibt man sich in den jeweiligen Ordner und gibt
cmake . && make ein. Die Reihenfolge ist wie in Grafik A.1 zu erkennen Logger, Testdog, Middleware, Frontend. Danach befindet sich sich
das Frontend-Programm in frontend/dist/bin/OgreApp.
A.3. Fragebogen
Jeder dieser Fragen soll mit einem Wert zwischen 0 und 10 ausgefüllt werden,
wobei eine 0 eine minimale Zustimmung und eine 10 eine maximale Zustimmung
bedeutet. Der Fragebogen wurde durch ein Online Formular bereit gestellt.
Auf dem Fragebogen waren folgende Fragen vorhanden:
• Wie gut konnten Sie in der virtuellen Welt agieren?
• Wie stark hat die virtuelle Umgebung auf Ihr Verhalten reagiert?
• Wie natürlich empfanden Sie die Interaktion mit der virtuellen Umwelt?
• Wie intensiv wurden Ihre Sinne angesprochen?
• Wie stark wurden Sie durch die Geräuschkulisse in die virtuelle Welt integriert?
• Wie natürlich empfanden Sie die Bewegung in der virtuellen Welt?
• Wie viel haben Sie während der Nutzung noch von der echten Welt wahrgenommen?
• Wie stark haben Sie bei der Nutzung die verwendeten Geräten wahrgenommen?
• Wie ähnlich waren ihre Erfahrungen in der virtuellen Welt im Vergleich zur
realen Welt?
v
Projektgruppe
Virtual Reality
A. Anhang
• Wie gut konnten Sie voraussehen was ihre Bewegungen für Konsequenzen
auf die Umwelt in der virtuellen Welt haben?
• Wie gut konnten Sie die virtuelle Welt visuell erkunden?
• Wie gut konnten Sie Geräusche identifizieren?
• Wie gut konnten sie Geräusche lokalisieren?
• Wie gut konnten Sie einzelne Objekte der virtuellen Welt in Anschau nehmen
und/oder benutzen?
• Wie gut konnten Sie einzelne Objekte in der virtuellen Welt in Bewegen
versetzen?
• Wie intensiv waren Sie in der virtuellen Welt integriert?
• Wie stark wurden Sie durch die verwendete Hardware bei der Nutzung abgelenkt?
• Wie stark war die Verzögerung zwischen Ihren echten Bewegungen und den
Bewegungen in der virtuellen Welt?
• Wie schnell haben Sie sich in die virtuelle Welt versetzt gefühlt?
• Wie gut haben Sie Ihre Möglichkeiten sich in der virtuellen Welt zu bewegen
und mit ihr zu interagieren am Ende der Nutzung eingeschätzt?
vi
Projektgruppe
Virtual Reality
A. Anhang
vii
Projektgruppe
Virtual Reality
A. Anhang
A.4. Erhobene Daten der Fragebögen
viii
Projektgruppe
Virtual Reality
A. Anhang
ix
Projektgruppe
Virtual Reality
A. Anhang
x
Projektgruppe
Virtual Reality
A. Anhang
xi
Projektgruppe
Virtual Reality
A. Anhang
A.5. Probandeninformation
xii
Projektgruppe
Virtual Reality
A. Anhang
xiii
Projektgruppe
Virtual Reality
A. Anhang
A.6. Einwilligungserklärung
xiv
Projektgruppe
Virtual Reality
A. Anhang
A.7. Seminararbeiten
xv
Seminararbeit
im Rahmen der Projektgruppe Virtual Reality
Virtual Reality - Geschichte
und Entwicklung
Matthias Bruns
Mai 2011
Carl-von-Ossietzky-Universität Oldenburg
Fachbereich Informatik
Inhaltsverzeichnis
1
DER BEGRIFF VIRTUAL REALITY
3
1.1
Definition
3
1.2
Kategorien von Virtual Reality
6
2
2.1
HISTORISCHE ENTWICKLUNG
Erste Entwicklungsschritte
7
7
2.2
Meilensteine des Virtual Reality
2.2.1
Head-Mounted-Display (1. Meilenstein)
2.2.2
Hochentwickelte 3D-Grafiken (2. Meilenstein)
2.2.3
Der Körper als Eingabegerät (3. Meilenstein)
2.2.4
Visual Experience CAVE (4. Meilenstein)
8
8
10
10
11
2.3
Fortführende Entwicklung
2.3.1
HMD-Technologie
2.3.2
Eingabegeräte
2.3.3
Bewegungsfreiheit
12
12
13
13
3
VIRTUAL REALITY HEUTE
15
4
AUSBLICK
17
5
LITERATUR
19
6
ABKÜRZUNGSVERZEICHNIS
21
Virtual Reality – Geschichte und Entwicklung
2
Einleitung
Diese Seminararbeit gibt einen Überblick über die geschichtliche Entwicklung von Virtual
Reality (VR) und den beteiligten Schlüsseltechnologien. Dafür werden zunächst im 1. Kapitel
der Begriff Virtual Reality und dessen Ausprägungen untersucht. Das 2. und 3. Kapitel
behandelt die historische Entwicklung ausgehend von vier Meilensteinen, den aktuellen
technischen Stand und die Bedeutung in unserer Gesellschafft. Das 4. Kapitel gibt einen
Ausblick auf die Zukunft des Virtual Reality.
In dieser Ausarbeitung wird die Bedeutung und der psychologische Hintergrund von
Immersion1 nicht näher erläutert, da dies bereits thematischer Schwerpunkt der Seminararbeit
von Jendrik Poloczek ist.
1
Immersion bezeichnet das Eintauchen in eine künstliche Welt.
3
1 Der Begriff Virtual Reality
1.1 Definition
Der Begriff Virtual Reality wird in der Literatur sehr unterschiedlich aufgefasst. Während
beispielsweise die einen Definitionen für Virtual Reality einen möglichst hohen Grad an
Immersion thematisieren, ist das Kernelement anderer Definitionen nur das Erzeugen
möglichst realistischer 3D-Welten, die weder Immersion, noch Interaktion voraussetzen.
So wird Virtual Reality im Duden beispielsweise folgendermaßen definiert: "vom Computer
simulierte künstliche Welt, in der man sich mithilfe der entsprechenden technischen
Ausrüstung scheinbar hineinversetzten kann." (Der Duden 1999)
Im Kontrast dazu eine Definition von Hans-Jörg Bullinger: "Mit dem Begriff virtuelle
Realität wird meist die rechnergestützte Generierung eines möglichst perfekten sensorischen
Abbildes der realen Umwelt assoziiert." (Hans-Jörg Bullinger 1994)
Eine Gemeinsamkeit aller Definitionen ist jedoch die Schaffung einer computergenerierten
und vom Nutzer über Sinne aufgenommenen Realität. Mögliche Sinne sind Seh-, Hör-, Tastund Geruchssinn. Je mehr Sinne dabei genutzt werden, desto intensiver die Immersion.
Weiterhin wird in allen Definitionen von in Echtzeit gerenderten digitalen Welten gesprochen
und vorgerenderte Videosequenzen werden zum Teil ausgeschlossen. Computeranimierte
Filme in 3D und Surround-Sound, sowie Filme in Force-Feedback-Simulatoren sind demnach
nicht Virtual Reality zuzuordnen. (Bühl 1996, S.54 ff.)
Eine sehr allgemeingehaltene Beschreibung des Begriffs Virtual Reality stammt von
Alexander Henning: "Virtual Reality ist eine Mensch-Maschine-Schnittstelle, die es erlaubt,
eine computergenerierte Umwelt in Ansprache mehrerer Sinne als Realität wahrzunehmen."
(Alexander Henning, Die andere Wirklichkeit)
Diese Erläuterung ist sehr zutreffend, da sie im Vergleich zu vielen anderen Definitionen
nicht von einem „perfekten Abbild der realen Welt“ ausgeht, sondern von einer
computergenerierten Umwelt. Denn VR-Systeme setzen nur „mögliche“ künstliche Welten
voraus, nicht aber im Bezug zur Realität möglichst realitätsnahe Welten. Beispielsweise
können auch Sciencefiction-Elemente (zB. Raumschiffe, außerirdische Wesen usw.) in der
virtuellen Welt beim Anwender Immersion erzeugen und sind damit „mögliche Realitäten“.
4
Weiterhin ist die Interaktion mit der virtuellen Welt keine Voraussetzung für ein
VR-System. Auch eine digitale Welt durch die sich der Nutzer passiv frei bewegen kann, ohne
mit der Umwelt interagieren zu können, vermag immersiv auf den Nutzer des Systems zu
wirken. Stereoskopie/3D-Brillen, sowie (3D)-Sound sind ebenfalls nur optionale Bestandteile
eines visuellen VR-Systems. Auch ohne visuelle Komponente sind virtuelle Welten
realisierbar. So können Nutzer beispielsweise allein auf akustischer Ebene in virtuelle Welten
versetzt werden. Binaurale Audiosignale über Kopfhörer ermöglichen dabei einen sehr hohen
Grad an Immersion. Somit können beispielsweise auch blinde Nutzer virtuelle Welten erleben.
(Bormann 1994, S. 25)
Nach dem Großteil der Definitionen sind auch Videospiele dem Virtual Reality zuzuordnen.
Das erste weltweit populäre Videospiel Pong aus dem Jahr 1972 ist beispielsweise die digitale
Nachbildung eines Tischtennis-Spiels. Aufgrund der grafisch minimalen Umsetzung ist der
Immersionsgrad jedoch sehr gering. Moderne Videospiele mit leistungsstarken
Grafik-Engines, Surround-Sound und mitreißendem Story-Background können Spieler
hingegen schon nach wenigen Minuten die reale Welt vergessen lassen. Mit steigender
Spieldauer steigt auch der Immersionseffekt auf den Spieler und er fühlt sich mehr und mehr in
die virtuelle Welt hineinversetzt. (vgl. Fritz 1997 und Halbach 1997, S. 157)
Heutzutage werden VR-Systeme in der Regel jedoch nicht mehr mit klassischen
Videospielen assoziiert, sondern mit Systemen, die die virtuelle Welt durch Head-Mounted
Displays realitätsnah begehbar machen.
Das Videospiel Pong aus dem Jahr 1972
5
Zusammenfassend lässt sich Virtual Reality folgendermaßen definieren:
Virtual Reality bezeichnet Computer-Systeme, die den Nutzern über das Ansprechen
von ein oder mehreren Sinnen das Gefühl geben, sich an einem anderen Ort oder in einer
anderen Welt zu befinden, in der sie sich frei bewegen können. Die reale Welt soll dabei
von der virtuellen Welt aus dem Bewusstsein des Nutzers verdrängt werden und als
Realität wahrgenommen werden.
Weiterhin können die folgenden Mindestanforderungen an ein VR-System festgelegt werden:
-
Eine computergenerierte, dynamische und immersive Umwelt
Echtzeit Verarbeitung des Systems
Nutzer kann sich in der virtuellen Welt frei bewegen
Ansprechen des Nutzers über Seh-, Hör-, Tast- oder Geruchssinn
Um die Immersion zu erhöhen können dabei die folgenden Komponenten optional genutzt
werden:
-
2
Ansprechen weiterer Sinne
Interaktion mit der virtuellen Umwelt (z.B. Gegenstände bewegen)
Head-Tracking
Head-Mounted-Display (HMD)2
HMD mit 3DOF (Degrees of Freedom) Lagesensoren
HMD mit 6DOF Lagesensoren
Hoch entwickelte 3D-Engine
3D statt 2D Sounds (Binaural)
Stereoskopie (3D statt 2D Videowiedergabe)
Hand-Tracking
Skeleton-Tracking
Force-Feedback Systeme
Voice-Recording/Spracherkennung
Erläuterung der HMD-Technologie folgt in Kapitel 2.2.1
6
1.2 Kategorien von Virtual Reality
In der Literatur wird Virtual Reality in drei unterschiedliche Kategorien mit unterschiedlichen
Immersionsgraden aufgegliedert (Kalawsky 1997, S. 11 ff.):
Desktop Virtual Reality
Bei einem Desktop VR-System wird für die visuelle Ausgabe an den Nutzer ein
Computer-Monitor oder ein TV-Bildschirm verwendet. Das Bild kann monoskopisch oder
stereoskopisch dargestellt werden. Bewegungen und Kopflage des Nutzers haben jedoch
keinen Einfluss auf das System.
Fishtank Virtual Reality
Fish Tank-VR Systeme berücksichtigen bei der Berechnung der Darstellungsansicht die
Blickrichtung des Nutzers durch ein Head-Tracking-Verfahren. Die Darstellung kann
monoskopisch oder stereoskopisch erfolgen, findet aber wie bei Desktop VR-Systemen vor
einem Computer-Monitor oder einem TV-Bildschirm statt. Durch das Head-Tracking können
Objekte zum Beispiel von mehreren Seiten betrachtet werden. Dadurch fühlt sich der Nutzer
intensiver in die virtuelle Welt hineinversetzt.
Immersive Virtual Reality
Diese Methode ermöglicht den höchstmöglichen Immersionsgrad. Sie wird durch ein
Head-Mounted-Display oder durch ein CAVE-System 3 realisiert. Beide Verfahren
ermöglichen es dem Nutzer, sich frei in der virtuellen Welt zu bewegen und Objekte von allen
Seiten zu betrachten. Im Gegensatz zu den Bildschirm-Methoden ist dabei die reale Welt für
den Nutzer nicht mehr wahrnehmbar.
3
Cave Automatic Virtual Environment, Beschreibung in Kapitel 2.2.4
7
2 Historische Entwicklung
2.1 Erste Entwicklungsschritte
Viele Grundlagen, auf denen Virtual Reality aufbaut, stammen bereits aus einer Zeit weit vor
der Idee, künstliche Welten zu schaffen. Die stereoskopische Sicht wurde beispielsweise
bereits im 18. Jahrhundert erforscht. Erste Ansätze in Richtung Virtual Reality verfolgte die US
Air Force bei der Entwicklung der ersten Flugsimulatoren in den dreißiger Jahren. Diese
Systeme erlaubten jedoch keine Interaktion mit dem Nutzer und die Technik zur Erzeugung
von Immersion beschränkte sich dabei auf Erschütterungen des Piloten. (Halbach 1994, S. 231)
Ein sehr konkreter Entwurf eines VR-Systems stammt von Morton Heilig aus dem Jahr
1955. Doch erst 1962 baute er seine Idee “The Cinema of the Future” zu einem Prototypen aus,
das Sensorama. Doch auch diese Apparatur war analoger Natur und konnte nur 5 Kurzfilme
abspielen, ohne dass der Nutzer in den Ablauf eingreifen konnte. Die Filme wurden aber durch
Stimulation mehrerer Sinne begleitet. So wurde passend zum Inhalt der Filme Wind erzeugt,
Gerüche ausgegeben und der Sitz in Vibration versetzt. Weiterhin bot das Gerät Stereo-Ton und
eine stereoskopische 3D-Ansicht des Filmmaterials. Heilig setzte durch das Sensorama neue
Maßstäbe gemessen am Grad der Immersion. (Halbach 1994, S. 235)
Sensorama von Morton Heilig, 1962
8
2.2 Meilensteine des Virtual Reality
Im Folgenden werden vier maßgebende Entwicklungen in der Geschichte des Virtual Reality
aufgeführt.
2.2.1 Head-Mounted-Display (1. Meilenstein)
Nach Vorgabe der Definition für Virtual Reality waren alle bisherigen Systeme nicht dem
Virtual Reality zuzuordnen, da sie nicht das Konzept von einer computergenerierten Umwelt,
in der sich der Nutzer frei bewegen kann, verfolgten. Die beschränkte analoge Technik ließ eine
solche Umsetzung nicht zu. Erst mit dem Aufkommen hochentwickelter digitaler
Rechnersysteme konnten visuelle Ausgaben erzeugt werden, dessen Perspektive der Nutzer in
Echtzeit beeinflussen konnte. Diese Entwicklung ebnete den Weg für den ersten Meilenstein
des Virtual Reality, das Head-Mounted-Display.
1965 entwickelte der damalige Harvard-Student Ivan Sutherland das Konzept „Ultimate
Display“. Ein am Kopf getragenes Display sollte dabei als visuelle Schnittstelle zwischen
Mensch und Maschine fugieren und dem Nutzer als Fenster in eine virtuelle Welt dienen. 3
Jahre später verwirklichte Sutherland seine Vision des „Ultimate Display“. 1968 gehört damit
zur Geburtsstunde des Head-Mounted-Displays und gilt als erster Meilenstein des Virtual
Reality. (Rheingold 1992, S. 117)
Sutherlands HMD basierte auf zwei kleine Kathodenstrahlen-Monitore vor den Augen des
Nutzers, die stereoskopische 3D-Ansichten ermöglichten. Ein Computer generierte in Echtzeit
die visuelle Ausgabe in Form von digitalen Drahtgitter-Modellen (Wireframe). Weiterhin
kamen zwei Head-Tracking-Verfahren zum Einsatz: Ultraschall und eine mechanische Vorrichtung. Damit war das HMD Eingabe- und Ausgabegerät zugleich. Die Anzeige der virtuellen
Welt wurde dabei durch die Kopflage des Nutzers beeinflusst. Sutherlands Konstruktion war
jedoch so schwer, dass das System mit einem Metallarm an der Decke befestigt werden musste.
(Bormann 1994, S. 96)
Vor Ivan Sutherlands Entwicklung gab es bereits andere Monitor-Brillen. Diese Modelle
zeigten jedoch nur statisches Bildmaterial oder Live-Videoaufnahmen und keine
computergenerierte Umwelt, in der sich der Nutzer frei umsehen konnte. Sutherlands HMD ist
damit der Definition nach das erste VR-System.
HMD-Konstruktion von Ivan Sutherland, 1968
HMD-Brille von Ivan Sutherland, 1968
9
10
2.2.2 Hochentwickelte 3D-Grafiken (2. Meilenstein)
Die praktischen Einsatzmöglichkeiten von Sutherlands HMD-System blieben durch die
rudimentären 3D-Darstellungsmöglichkeiten der damaligen Computertechnologie jedoch
eingeschränkt. Das führte dazu, dass es in den 60er und 70er Jahren aufgrund der technischen
Limitation nur geringfügige Weiterentwicklungen im Bereich des Virtual Reality gab.
Erst mit dem Aufkommen leistungsfähiger Grafik-Computer und 3D-Engines in den 80er
und 90er Jahren, konnten vielseitige Anwendungen und realistische virtuelle Welten
verzögerungsfrei dargestellt werden. Diese neuen Möglichkeiten trieben auch die
Entwicklungen im Bereich der Virtual Reality wieder voran. Von nun an konnten Designer die
vollimmersive 3D-Umgebung spezifisch an verschiedene Einsatzbereiche für Virtual Reality
anpassen.
Dabei profitiert der VR-Forschungsbereich insbesondere vom „Grafik-Boom“ durch die
Verbreitung von 3D-Videospielen auf dem Massenmarkt, vorangetrieben durch die
Unterhaltungsindustrie. (Brooks 1999, S. 16ff. und Thürmel 1993, S. 42)
2.2.3 Der Körper als Eingabegerät (3. Meilenstein)
Die neuen Anwendungsbereiche für Virtual Reality stellen auch neue Anforderungen an die
Interaktionsmöglichkeiten. Infolge dessen gründeten Thomas Zimmermann und Jaron Lanier
1984 in Kalifornien das Unternehmen Virtual Programming Languages (VPL) und
entwickelten einen Sensor-Handschuh als Eingabegerät für interaktive Systeme. 1986 brachte
VPL den DataGlove auf den Markt. Dieser Handschuh erfasste in Echtzeit die Bewegungen der
Finger und bestimmte die Lage im Raum und die Ausrichtung der Hand des Nutzers. Dieses
System ermöglichte erstmals einen Körperteil einer Person zu digitalisieren und für
Interaktionszwecke in eine virtuelle Welt zu übertragen. Die Bewegungen der virtuellen Hand
gleichen dabei denen der Hand des Nutzers. In Kombination mit einem HMD konnten somit
beispielsweise Gegenstände im VR-Raum gegriffen, transportiert und wieder abgelegt werden.
(Bormann 1994, S. 41)
Ende der 80er entdeckte auch die Unterhaltungsindustrie das Potential von Virtual Reality.
So wurde der Power Glove als Weiterentwicklung des DataGlove als Consumer-Produkt für die
Spielkonsole Nintendo Entertainment System verkauft.
11
Power Glove, Nintendo, 1989
2.2.4 Visual Experience CAVE (4. Meilenstein)
Eine bis heute einflussreiche Alternative zu Head-Mounted-Displays für hoch immersives
Virtual Reality entwickelten Forscher an der University of Illinois in Chicago. 1992
präsentierten sie der Öffentlichkeit die Visual Experience CAVE (Cave Automatic Virtual
Environment), ein quaderförmiger Raum, an dessen Seitenflächen die grafische Ausgabe des
VR-Systems projiziert wird. Die projizierten stereoskopischen Bilder werden dabei von den
Nutzern mit LCD-Shutter-Brillen betrachtet. Die Position und Blickrichtung der in der CAVE
befindlichen Person wird von Trackern erfasst, an den verarbeitenden Computer weitergeleitet
und anschließend bei der visuellen Ausgabe berücksichtigt. Die dabei mögliche 360 Grad
Drehung des Kopfes, sowieso die hohe Auflösung der einzelnen Bildflächen erzeugen einen
sehr hohen Immersionsgrad. Nachteile der CAVE-Technologie sind hohe Kosten, hoher
Platzbedarf, hoher Rechenaufwand für die Grafikerzeugung und die eingeschränkte
Bewegungsfreiheit des Nutzers. (Sandin 1996, S. 84 ff.)
12
CAVE-Umgebung
2.3 Fortführende Entwicklung
Die Technologien rund um Virtual Reality wurden im Laufe der Zeit grundlegend
weiterentwickelt und neuen Anforderungsbereichen angepasst. Wichtige Fortschritte der
Schlüsseltechnologien werden im folgendem erläutert:
2.3.1 HMD-Technologie
Das Grundkonzept von Ivan Sutherlands HMD hat sich nicht geändert, jedoch haben neue
Technologien die Bauweise der Brille beeinflusst. Wichtigster Punkt ist dabei der Wechsel von
Kathodenstrahlen-Monitoren zu LC-Displays (Liquid Crystal Display), die eine wesentlich
leichtere und schmalere Bauweise ermöglichten. Das erste HMD mit LCD-Technologie wurde
1985 entwickelt. Auch neue Tracking-Verfahren sorgten für ein neues Erscheinungsbild der
Brillen. Heutige HMD´s verwenden im Gegensatz zu Sutherlands Modell keinen mechanischen
Arm zur Positionsbestimmung, sondern platzsparend in die Brille integrierte 6DOF (Degrees of
Freedom) Lagesensoren, die der Anwendung X-, Y-, Z-, sowie Richtungsdaten bereitstellen.
Weiterhin bieten heutige HMD´s hohe Display-Auflösungen und einen hohen Tragekomfort
durch kabellosen Betrieb und einer ergonomischen Bauform. HMD´s für den Consumer-Markt
mit einer Auflösung von 640*480 Pixeln werden bereits für 300€ angeboten.
13
2.3.2 Eingabegeräte
Die Entwicklung von Eingabegeräten für Virtual Reality wurde in erster Linie durch neue
Tracking-Verfahren vorangetrieben (Bormann 1994, S. 57). Kleinere Bauteile ermöglichten
beispielsweise die Herstellung von wesentlich ergonomischeren Datenhandschuhen, dessen
Elektronik immer weniger sicht- und spürbar wurde. Weiterhin wurden ganze Daten-Anzüge
hergestellt, die den kompletten Körper des Nutzers in der virtuellen Welt abbilden. Auch die
Unterhaltungselektronik hat neue Eingabegeräte zur Marktreife gebracht. Zu nennen ist
einerseits die Nintendo Wii, dessen Controller Beschleunigungs- und Lagedaten an die
Spielkonsole weitergibt. Und zum anderen die von Microsoft entwickelte Kinect, die durch
Infrarotkameras den kompletten Körper des Spielers digital erfasst und in Videospiele
integriert. Sowohl die Nintendo Wii, als auch die Microsoft Kinect finden häufig bei
Forschungsprojekten im Rahmen von Virtual Reality Verwendung.
2.3.3 Bewegungsfreiheit
VR-Systeme boten in ihrer bisherigen Form nur eine eingeschränkte Bewegungsfreiheit,
solange die Fortbewegung in der virtuellen Welt für einen möglichst hohen Immersionsgrad
durch Gehen/Laufen in der realen Welt umgesetzt werden sollte. Um diese Einschränkung zu
umgehen wurden zwei Systeme entwickelt, die das Laufen des Nutzers zulassen, aber ihn
dennoch immer an der selben Position im Raum halten. Ein Konzept basiert auf einer
Vorrichtung aus Laufbändern, die eine Person in alle Himmelsrichtung befördern kann. Damit
kann die laufende Person immer wieder in den Mittelpunkt der mechanischen Vorrichtung
gefahren werden. Der Immersionsgrad der durch diese Technik erreicht werden kann ist sehr
hoch. Nachteile dieser Methode sind jedoch der sehr hohe Platzbedarf, ein hoher
Energieverbrauch und die hohen Herstellkosten. (mpg.de - Max-Planck-Gesellschafft
Pressebericht)
14
Cyberwalk-Umgebung
Das zweite Konzept ist die sogenannte VirtuSphere. Dieses Modell ist mit dem Prinzip eines
Hamster-Rads zu vergleichen. Eine große Kugel, die den Nutzer vollkommen umschließt, dreht
sich beim Laufen in alle Himmelsrichtungen mit. Somit kann der Nutzer in der virtuellen Welt
beliebig weite Strecken zurücklegen, ohne seine Position in der realen Welt zu verändern.
(virtusphere.com)
VirtuSphere
15
3 Virtual Reality Heute
Die Bedeutung von VR-Technologien hat sich im Laufe der Jahre auf unterschiedliche Brachen
ausgeweitet. Während in den Anfangsjahren in erster Linie militärische Organisationen die
Forschung und Entwicklung von Virtual Reality vorantrieben, sind mittlerweile viele
unterschiedliche Branchen an der Weiterentwicklung beteiligt. In erster Linie sind hier der
kreative Sektor (Designprozesse durch Virtual Reality) und die Unterhaltungsbranche (neue
Eingabetechnologien und Entwicklung von leistungsstarken Grafik-Plattformen) zu nennen.
Bis heute haben sich die folgenden Einsatzbereiche für Virtual Reality hervorgehoben:
-
Simulation
In VR-Simulationen sollen möglichst realitätsnah Situationen durchgespielt werden, die
sonst nicht durchführbar sind oder bei Durchführung in der Realität sehr hohe Kosten
verursachen würden. Zum Beispiel die Piloten-Ausbildung im militärischen und
privaten Sektor. (DARPA.mil)
-
Entertainment
Im Bereich der Unterhaltungselektronik kommen VR-Systeme in erster Linie für
Videospiele zum Einsatz. Zum Beispiel Head-Mounted-Displays die sich an Personal
Computer anschließen lassen und von verschiedenen PC-Spielen unterstützt werden.
(Dysart 1994, S. 19)
-
CAD
Virtual Reality basiertes Computer Aided Design (CAD) kommt heute bereits in sehr
vielen Unternehmen im kreativen Sektor zur Anwendung. Dabei lassen sich die
entworfenen Modelle von allen Seiten betrachten oder begehen und ermöglichen es den
Designern, ein “Gefühl“ für das fertige Produkt zu erhalten. Teure Prototypen lassen
sich so teilweise vermeiden. Virtual Reality-CAD wird beispielsweise in Form von
CAVE-Systemen häufig beim Entwurf von Fahrzeugen oder bei der
Gebäudeplanung/Architektur eingesetzt. (Brooks 1986, S. 10 ff.)
16
-
Medizin
Im Gesundheitswesen werden bereits chirurgische Ausbildungen von VR-Systemen
unterstützt. Weiterhin werden häufig Head-Mounted-Displays in Kombination mit sehr
immersiven und unterhaltenden 3D-Welten verwendet, um Patienten bei medizinischen
Eingriffen zu beruhigen oder um Schmerzen zu lindern. (Völter 1995, Seite 5 ff.)
-
Bildung
In Museen und wissenschaftlichen Lehreinrichtungen werden teilweise VR-Systeme
genutzt, um Wissen an (in erster Linie jungen) Schülern zu vermitteln. Das für die
Schüler aufregende und außergewöhnliche Erlebnis hat einen nachhaltigeren
Lernprozess zur Folge. (Holloway 1995, S. 35 ff.)
17
4 Ausblick
Von einem hundert prozentigem Immersionsgrad, wie in der Hollywood Produktion „The
Matrix“ (Science-Fiction Film, 1999) oder das Holodeck 4 aus dem Star Trek Universum
(TV-Serie, 1987) ist der heutige Stand der Entwicklung noch viele Jahrzehnte und viele
Meilensteine entfernt.
Die zukünftigen Entwicklungen in der Virtual Reality werden vermutlich durch die stetige
Weiterentwicklung der bisherigen Schlüsseltechnologien geprägt sein. 3D-Engines werden
durch die Befeuerung der rasant wachsenden Gaming-Branche immer realistischere virtuelle
Welten generieren können. Head-Mounted-Displays werden immer leistungsfähiger
(Bildqualität), handlicher und in unsere Umwelt integriert. Die „Virtual Retinal
Display“-Technologie wird bei den HMD´s der nächste große Entwicklungsschritt sein. Diese
Technologie projiziert das Bild direkt auf die Netzhaut des Anwenders. (washington.edu)
Weiterhin ist davon auszugehen, dass sich HMD´s gegenüber den CAVE-Systemen
langfristig durchsetzen werden, da die CAVE-Technologie nicht das vollständige Ausblenden
des Nutzers selbst zulässt, was beispielsweise für das Tragen von Sensoranzügen notwendig ist.
Eines der größten Herausforderungen des Virtual Reality, die Entwicklung von haptischen
VR-Systemen, ist aktuell noch sehr rudimentär ausgeprägt. Der nächste Meilenstein dieses
Forschungsbereichs könnte ein Ganzkörperanzug sein, der einzelne Körperzonen des Nutzers
stimulieren kann, um Widerstände und andere Krafteinwirkungen auf den Körper der virtuellen
Welt zu simulieren.
Der aktuelle Trend von Augmented Reality (AR) Anwendungen durch die steigende
Verbreitung von Smartphones kann zu Synergieeffekten im Zusammenhang mit Virtual Reality
führen. Im Rahmen der Definition für Virtual Reality ist Augmented Reality jedoch kein
Teilbereich von Virtual Reality. AR-Systeme erweitern die reale Welt zwar um virtuelle
Komponenten, jedoch wird der Nutzer nicht aus seiner Welt gezerrt und in eine neue virtuelle
Realität befördert. Er befindet sich aus seiner Sicht noch immer in seiner realen Umwelt.
4
Das Holodeck ist ein fiktiver Raum, der ohne zusätzliche Geräte (z.B. HMD) virtuelle Welten darstellt und dabei
zu 100% immersiv ist. Ist eine virtuelle Welt geladen, kann eine darin befindliche Person nicht mehr spüren dass
sie sich noch im Holodeck befindet.
18
Immersion findet folglich nicht statt. Aufgrund der Ähnlichkeiten in der verwendeten
Hardware- und Softwarestruktur (HMD, Tracking, 3D-Engines) ist es jedoch demselben
Forschungsbereich wie Virtual Reality zuzuordnen.
Zusammenfassend lässt sich sagen, dass Virtual Reality nach den Startschwierigkeiten im
20. Jahrhundert, langfristig vermutlich eines der Schwerpunkt-Technologien sein wird, die
unser zukünftiges Leben in der digitalen Welt bestimmen werden. Wann und ob wir jemals
VR-Telefonate mit Freunden im Ausland führen oder uns das erste Mal per VR-Fernchirurgie
operieren lassen, lässt sich zum jetzigen Zeitpunkt jedoch noch nicht bestimmen.
19
5 Literatur
[Brooks 1986]
Jr. Brooks: Walkthrough - A Dynamic Graphics System for Simulating
Virtual Buildings. 1986.
[Brooks 1999]
Jr. Brooks/P. Frederick: What’s Real About Virtual Reality. 1999.
[Bühl 1996]
A. Bühl: CyberSociety - Mythos und Realität der Informationsgesellschaft. PapyRossa Verlag 1996.
[Bormann 1994]
S. Bormann: Virtuelle Realität: Genese und Evaluation. 1994.
[DARPA.mil]
Defense Advanced Research Projects Agency. http://www.darpa.mil.
22.05.2011.
[Dysart 1994]
J. Dysart: VR Goes to Hollywood - Virtual Reality World. 1994.
[Fritz 1997]
J. Fritz: Computerspiele - Theorie, Forschung, Praxis, Bundeszentrale
für Medien 1997.
[Halbach 1994]
W. Halbach: Reality Engines. Wilhelm Fink Verlag 1994.
[Halbach 1997]
W. Halbach: Virtual Realities, Cyberspace und Öffentlichkeiten. Wilhelm Fink Verlag 1994.
[Holloway 1995]
R. Holloway: Virtual Environments - A Survey of the Technology. 1995.
20
[Kalawsky 1997]
R. Kalawsky: VRUSE - a computerised diagnostic tool: for usability
evaluation of virtual/synthetic environment systems, Applied ergonomics. 1997.
[mpg.de]
Max-Planck-Gesellschafft.
http://www.mpg.de/497063/pressemitteilung20050420. 23.05.2011.
[Rheingold 1992]
H. Rheingold: Virtuelle Welten. Reisen im Cyberspace. 1992.
[Sandin 1996]
D. Sandin: CAVE - das virtuelle Theater. 1996.
[Thürmel 1993]
S. Thürmel: Virtuelle Realität. Ursprung und Entwicklung eines Leitbildes in der Computertechnik. Karlheinz 1993.
[virtusphere.com]
Projekt VirtuSphere. http://www.virtusphere.com. 19.05.2011.
[Völter 1995]
S. Völter: Virtual Reality in der Medizin I - Stand, Trends, Visionen.
1995.
[washington.edu ]
„Virtual Retinal Display“-Technologie.
http://www.hitl.washington.edu/projects/vrd. 12.05.2011.
6 Abkürzungsverzeichnis
AR
= Augmented Reality
CAD
= Computer-Aided Design
CAVE
= Cave Automatic Virtual Environment
DOF
= Degrees of Freedom
HMD
= Head-Mounted-Display
HMD
= Head-Mounted-Display
LCD
= Liquid Crystal Display
VPL
= Virtual Programming Languages
VR
= Virtual Reality
21
Carl-von-Ossietzky-Universität Oldenburg
Projektgruppe Virtual Reality
Prof. Dr. Wolfgang Kowalk
Sommersemester 2011
Virtual Reality und der Einsatz in der Praxis
3. Juli 2011
Justin Philipp Heinermann, B.Sc.
Matrikel-Nr.: 9774500
Studiengang: M.Sc. Informatik, 2. Fachsemester
Anschrift: Lehms 2, 26197 Großenkneten
E-Mail: justin.heinermann@informatik.uni-oldenburg.de
Inhaltsverzeichnis
1 Einleitung
1
3 Der Einsatz von Virtueller Realität in der Praxis
3.1 Anwendungsmöglichkeiten . . . . . . . . . . . . . . . . . . . . . .
3.2 Planung des Einsatzes von VR . . . . . . . . . . . . . . . . . . . .
3.3 VR-Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
5
6
7
2 Virtuelle Realität
2.1 Ausgabe virtueller Welten . . . . . . . . . . . . . . . . . . . . . . .
2.2 Eingabemöglichkeiten . . . . . . . . . . . . . . . . . . . . . . . . .
4 Einsatz im Automobilbereich
5 Virtuelle Realität im medizinischen Bereich
5.1 Neurochirurgie . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Radiologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Psychologische Behandlung . . . . . . . . . . . . . . . . . . . . . .
6 Fazit und Ausblick
Literatur
1
3
4
9
10
11
11
12
14
16
i
1 Einleitung
Die Idee von virtuellen Realitäten ist zwar nicht allzu neu, wurde aber in den
letzten Jahren stark fortentwickelt und findet eine immer weitere Verbreitung.
Dies gilt insbesondere für das industrielle Umfeld, in dem durch Virtual Reality
wirtschaftliche Vorteile erzielt werden und das Arbeiten oft stark vereinfacht
wird [Hau10, p. 17]. Lösungen, die als Beweisstudien mit Prototypen und Selbstbauten im Forschungs- und Hobbybereich bereits beeindruckende Ergebnisse
liefern, müssen als industrielle Werkzeuge sorgfältig für die Anforderungen im
produktiven Umfeld geprüft und angepasst werden.
Diese Arbeit widmet sich dem praktischen Einsatz virtueller Realitäten. Hierbei
sind Anwendungsgebiete im ingenieursmäßigen und industriellen Umfeld von
besonderem Interesse. In Kapitel 2 sollen zunächst die Konzepte von virtueller Realität sowie verschiedener Implementierungen beschrieben werden. Der
tatsächliche Einsatz dieser Techniken in der Praxis ist Gegenstand von Kapitel
3. Neben möglichen Techniken und den Möglichkeiten, die sich hier eröffnen
werden hier auch die Anforderungen für einen sinnvollen Einsatz erläutert, die
sich insbesondere im industriellen Umfeld ergeben. Anschließend sollen noch
zwei konkretere Szenarien als wichtige Beispiele für den heutigen Einsatz von
Virtual Reality dienen: Kapitel 4 befasst sich mit dem Einsatz in der Automobilindustrie, Kapitel 5 hat medizinische Anwendungen zum Gegenstand. Diese sollen
einen exemplarischen Ausschnitt aus den vielfältigen und unterschiedlichen
Anwendungsmöglichkeiten geben.
Bei allen Anwendungen stellt sich die Frage, inwieweit diese neuartigen Techniken Akzeptanz finden und wie sich dies in Zukunft ändern wird. In Kapitel 6 wird
dies abschließend beurteilt und ein kurzer Ausblick auf mögliche Entwicklungen
gegeben.
2 Virtuelle Realität
In diesem Kapitel soll nun zunächst der Begriff der virtuellen Realität, im Folgenden auch mit VR abgekürzt, eingeführt werden. Anschließend werden die
verschiedenen existenten Einsatzformen und Techniken beschrieben. Die verschiedenen Einsatzszenarien werden im nachfolgenden Kapitel 3 behandelt.
1
Schlägt man den Begriff „virtuelle Realität“ im Lexikon nach, findet man dort
folgende Begriffsklärung:
„virtuelle Realität, Cyberspace [’saIb@speIs], mittels Computer simulierte
dreidimensionale Räume, in denen sich der Benutzer mithilfe elektron.
Geräte (wie Monitorbrille, Datenhandschuh) sowie umfangreicher Software
(u.a. für die Spracherkennung und Geräuschsynthese) bewegt.“ [BR03]
Diese Beschreibung des Begriffes bleibt recht allgemein und liefert nur eine
eingeschränkte Sicht auf die möglichen Bedeutungen. Bei den vielen möglichen
Definitionen sind für Hausstädter [Hau10] die drei wichtigsten Eigenschaften
von virtuellen Realitäten die folgenden:
• Es liegt eine Echtzeitumgebung vor.
• Der Benutzer verspürt Immersion, also das Gefühl, sich tatsächlich in der
virtuellen Realität zu befinden.
• Die virtuelle Welt kann interaktiv verändert werden.
Mit diesen Eigenschaften als Definition lässt sich der Begriff der virtuellen Realität
auf sinnvolle Weise abgrenzen von anderen Präsentationsformen wie z. B. einer
realistisch wirkenden Filmdarbietung.
Abbildung 1: Stereoskop
Die ersten technischen Bestrebungen, die den Grundstein für VR legten, liegen
schon lange zurück [Bri08]: Bereits 1832 schuf Charles Wheatstone das Stereoskop für die räumliche Sicht (siehe Abb. 1). Flugzeugsimulatoren kamen bereits
während des ersten Weltkrieges zum Einsatz, um Piloten zu schulen. Das erste
Head-Mounted-Display wurde 1970 an der Universität von Utah aufgebaut. Es
wurde jedoch klar, dass die zu dieser Zeit verfügbare Hardware noch nicht für
diese Art der Anwendung ausreichte. Dies sollte sich erst in den 1980er Jahren
ändern, als bessere Head-Mounted-Displays und der Datenhandschuh eingeführt wurden. Zu Beginn der 1990er Jahre wurde die CAVE (Cave Automatic
2
Virtual Environment) entwickelt: Hierbei handelt es sich um einen würfelförmigen Raum, der dem Benutzer eine neue Art der virtuellen Realität bot. War man
in den Anfangstagen von VR noch sehr weit entfernt von einem realitätsnahen
Erleben, können diese Techniken heutzutage Anwendung in vielen Bereichen
finden: Hierzu zählen Medizin, Entertainment, industrielle Entwicklung von
Produkten und viele weitere. Die technischen Entwicklung auf diesem Gebiet
laufen in einem rasanten Tempo und führt zu immer höheren erreichten Immersionsgraden. Auch gibt es neue Anwendungsgebiete wie z. B. Augmented Reality.
Bei dieser Technik wird die reale Welt mit virtuellen Elementen ergänzt. Auf
diese Techniken soll aber in dieser Arbeit wegen des Umfangs nicht detaillierter
eingegangen werden.
2.1 Ausgabe virtueller Welten
Wichtig für die Wirkung einer VR-Umgebung ist die optische Darstellung der
Welt. Damit eine räumliche Wirkung mit Tiefeneindruck entsteht, ist hier insbesondere die perspektivische Darstellung von Bedeutung [Bri08].
Für die realistische Wirkung und Immersion ist insbesondere das Konzept der
Stereoskopie wichtig: Das menschliche Gehirn vereint die beiden Einzelbilder
zu einem räumlichen Bild [Bri08]. Für die Ausgabe eines Computerprogrammes
bedeutet dies, dass pro Auge ein Bild berechnet werden muss. Es stehen hierfür
verschiedene Möglichkeiten zur Verfügung [Hau10, Bri08]: Beim AnaglyphenVerfahren trägt der Benutzer eine Rot/Grün bzw. Rot/Blau-Brille. Die Bilder werden je Auge so eingefärbt, dass sie nur das linke bzw. das rechte Brillenglass
passieren können. Diese ist das kostengünstigste und einfachste Verfahren. Der
größte Nachteil ist aber, dass die Farben sehr stark verfälscht werden und die
Wirkung sehr darunter leidet. Daher kommt es für eine industrielle Anwendung
nicht in Frage.
Ein weit verbreitetes Verfahren ist der Einsatz von Polarisationsfiltern (auch
Passiv-Stereo genannt [Hau10]), welche in den Gläsern einer Brille zum Einsatz
kommen und so beispielsweise das jeweilige Bild von zwei Projektoren nur das
jeweils richtige Auge erreichen lassen. Im Gegensatz zum Anaglyphen-Verfahren
gehen hier keine Farbinformationen verloren.
Eine andere Möglichkeit ist das Aktiv-Stereo-Verfahren, bei dem sogenannte
3
Shutter-Brillen zum Einsatz kommen. Hier wird in hoher Frequenz jeweils nur
eine Seite der Brille geöffnet. Synchron dazu muss per Monitor oder Projektor
das Bild für das jeweilige Auge gezeigt werden. Dieses Verfahren ist teurer als
die beiden erstgenannten, liefert aber auch die deutlich besten Ergebnisse, da die
beiden Bilder wirklich getrennt dargestellt werden.
Im Gegensatz zu den drei genannten Verfahren mit Brillen mit Wellenlängenoder Zeitmultiplex besteht bei Head-Mounted-Displays auch die Möglichkeit, zwei
kleine Bildschirm direkt vor den Augen zu platzieren. Dies liefert beispielsweise
mit eingebauten Kopfhörern und Neigungssensoren eine gute Immersion, ist
jedoch mitunter unbequem und hat die Einschränkung, dass es nur für eine
Person geeignet ist [Bri08].
Für die Immersion ist auch die akustische Wahrnehmung sehr wichtig. Diese
liefert dem menschlichen Gehirn wesentliche Informationen zu den räumlichen
Gegebenheiten der Umgebung. Insbesondere das Zusammenspiel zwischen optischen und akustischen Reizen steigert die Immersion [Bri08]. Eine Möglichkeit
der Wiedergabe-Hardware sind Stereo-Lautsprecher oder Kopfhörer. Eine bessere räumliche Ortung machen jedoch in den meisten Fällen Surround-Boxen
möglich, die den Benutzer z. B. mit fünf Lautsprechern aus fünf verschiedenen
Richtungen beschallen[Bri08].
Außer den beiden genannten Ausgabemöglichkeiten ist auch noch die haptische
Ausgabe zu nennen, die dem Benutzer taktile Signale übermittelt. Dies ist zum
Beispiel bei einem Force-Feedback-Eingabegerät der Fall: Hier wird durch eine
Gegenkraft das „realitätsnahe Manipulieren mit Objekten“ [Hau10] gestattet.
2.2 Eingabemöglichkeiten
Damit der Benutzer mit der virtuellen Welt interagieren und Daten manipulieren
kann, benötigt man Techniken für die Eingabe. Für immersives Arbeiten kommt
meistens eine Form des Tracking, also Positions- und Lagebestimmung, zum
Einsatz. Dabei kommen mechanische, elektromagnetische, optische, akustische
und inertiale Wirkprinzipien zum Einsatz sowie verschiedene hybride Verfahren. Denkbar sind Kameras, Datenhandschuhe, Zeigegeräte oder Lagesensoren.
Welches Verfahren eingesetzt wird, hängt von Anwendung und Budget ab.
4
3 Der Einsatz von Virtueller Realität in der Praxis
In vielen Bereichen findet virtuelle Realität immer weitere Verbreitung. Einer
davon ist das industrielle Umfeld, in dem sich durch VR neue Möglichkeiten
eröffnen. In Abschnitt 3.1 werden verschiedene Szenarien beschrieben, in denen
sich der VR-Einsatz als sinnvoll erwiesen hat. Bei den vielen Vorteilen darf jedoch
nicht vergessen werden, dass es auch eine Reihe von Nachteilen gibt. Die daher
notwendige sorgfältige Planung wird in Abschnitt 3.2 erläutert. Abschnitt 3.3 hat
die in Frage kommenden VR-Systeme und Softwarewerkzeuge zum Gegenstand.
3.1 Anwendungsmöglichkeiten
Es gibt viele denkbare Formen der Anwendung. Neben der eigentlichen Präsentation bietet sich insbesondere die Nutzung für technische Anwendungen an. Zu
den Aufgaben, für die VR in Frage kommt, zählen folgende:
Kunst und Kultur Von Unterhaltung über Bildung und künstlerisches Gestalten
ergeben sich hier vielfältige Möglichkeiten.
Medizin Unterstützung und Vorbereitung von Operationen, Schulung, Psychologie (siehe Kapitel 5)
Militär Kriegsführung, Training, Simulation
Architektur Visualisierung, Planung, Variantenvergleiche, Machbarkeitsstudien
Technische Anwendungen Produktion, Computer Aided Design, Computer
Aided Manufacturing, Visualisierung, Statik, Konfiguration, Simulation,
Logistik [Hau10]
Bei den einzelnen Einsatzgebieten gibt es große Überschneidungen.
Auch wenn die Leistungsfähigkeit der verfügbaren Hardware weiter steigt, ist
immernoch ein relativ großer Aufwand damit verbunden, hochwertige Ergebnisse zu erzielen [Hau10]. Es stellt sich die Frage, welche Vor- und Nachteile
die Nutzung von VR mit sich bringt. Nach Hausstädtler ist der größte Vorteil
von „immersiv-stereoskopischer Visualisierung [. . . ] die genaue Einhaltung des
Objektmaßstabs“[Hau10]. Neben den Vorteilen der immersiven Visualisierung
und Eingabe ergeben sich auch erhebliche Nutzeffekte, die vor allem aus betriebswirtschaftlicher Sicht positiv zu bewerten sind[Hau10]:
5
• Zeiteinsparung bei der Produktentwicklung und Vermarktung
• Steigerung der Qualität
• Reduktion der Kosten
Problematisch ist hierbei, dass die Effekte oft erst langfristig erkennbar sind und
auf der anderen Seite hohe Anschaffungs- und Wartungskosten ins Gewicht fallen.
Die daher nötige sorgfältige Planung wird im folgenden Abschnitt beschrieben.
3.2 Planung des Einsatzes von VR
Da es viele verschiedene Techniken gibt um VR zu verwenden, wie in Abschnitt
3.3 erläutert wird, müssen bei der Planung des Einsatzes grundlegende Fragen geklärt und die Anforderungen genau analysiert werden. Einer Über- oder
Unterdimensionierung des Investitionsbedarfes kann nur mit klar formulierten
Anforderungen vorgebeugt werden [Hau10].
Bei der Analyse der Visualisierungsaufgabe aus betrieblicher Sicht sollten zunächst Ziele und Schwerpunkte formuliert werden sowie festgelegt werden,
welches Publikum angesprochen werden soll. Es ist zu berücksichtigen, wie
häufig die Technik zum Einsatz kommt und welche Mitarbeiter sich um diese kümmern können. Ebenso sind Platzbedarf und laufende Kosten wichtige
Fragen, die im Vorfeld geklärt werden müssen. Eine vollständigere Liste von
Entscheidungskriterien kann man in [Hau10, Kapitel 2.1] nachlesen.
Eine Kosten-Nutzen-Rechnung für den VR-Einsatz lässt sich nur relativ schwierig
aufstellen. Neben einfach messbarer Fakten wie der anfänglichen Investition und
Personal-, Wartungs- und Betriebskosten, spielen hier auch schwerer zu beurteilende Faktoren eine Rolle: Lassen sich Zusammenkünfte und Präsentationen
vereinfachen und verbessern? Lassen sich Kosten einsparen? Wird interdisziplinäre Kommunikation vereinfacht?
Ob ein VR-System zum Einsatz in einem bestimmten Gebiet geeignet ist, hängt
also von vielen Faktoren ab. Oft muss man hier abwägen zwischen Anforderungen, die sich gegenseitig ausschließen oder erschweren. Im nächsten Abschnitt
werden die grundsätzlich verfügbaren Arten von VR-Umgebungen dargestellt,
die unterschiedliche Vor- und Nachteile haben.
6
3.3 VR-Systeme
„Ein minimales VR-System benötigt einen Computer und die Möglichkeit
einer stereoskopischen grafischen Ausgabe. Ob Audio oder ein Datenhandschuh verwendet werden, hängt vor allem von der Anwendung ab.“ [Bri08]
Da eine VR-Anwendung oft sehr viel Rechenleistung erforderlich macht, ist ein
einzelner Computer oft nicht ausreichend und es kommen Cluster von beispielsweise zehn leistungsfähigen PC zum Einsatz [Hau10].
Die ersten Anwendungen im VR-Bereich verwendeten ein Head Mounted Display (kurz HMD). Ein solches ist in Abb. 2(a) dargestellt. Ein HMD bietet neben
der stereoskopischen Ausgabe oft Positionsverfolgung sowie Stereokopfhörer.
Die Immersion ist hier sehr groß, da die reale Welt großenteils ausgeblendet
werden kann [Bri08]. Für industrielle Anwendungen kommt dieses Verfahren
oft nicht in Frage, da man aus ergonomischen Gesichtspunkten meist nicht sehr
lange mit einem solchen Gerät arbeiten kann und sie außerdem nur für einen
Benutzer geeignet sind [Hau10].
(a) „Head Mounted Display“ [HMD]
(c) „Powerwall“ [Pow]
(b) „CAVE“ [Cav]
(d) „Bench“ [Wor]
Abbildung 2: Verbreitete VR-Systeme
Seit den 1990er Jahren werden meist Projektoren eingesetzt, die das stereoskopische Bild auf eine Leinwand werfen [Bri08]. Für den räumlichen Eindruck
7
kommen hier oft mehrere Leinwände zum Einsatz, die den bzw. die Benutzer
umgeben. Es haben sich für den industriellen Einsatz drei Gerätetypen etabliert
[Hau10]:
CAVE Die Cave Automatic Virtual Environment (siehe Abb. 2(b)) bietet mit einem
würfelförmigen Raum aus 3-6 Projektionswänden einen sehr hohen Grad an
Immersion. Sie kann für Automobilbau, Anlagen- und Fabrikplanung sowie
Entertainment verwendet werden und ist für mehrere Personen geeignet.
Die Kosten belaufen sich auf bis zu 1 Mio. e.
Powerwall Eine Powerwall (siehe Abb. 2(c)) ist eine ebene oder gekrümmte
Projektionswand, die für viele Personen geeignet ist. Bei mittelhohem
Immersionsgrad bietet sie universelle Anwendung. Die Kosten belaufen
sich auf ca. 100T - 500T e.
Bench Eine Bench (siehe Abb. 2(d)) ist angelehnt an das Konzept einer Werkbank.
Dieses kompakte Tischsystem ist für kleinere Objekte geeignet und bietet
eher einen geringen Immersionsgrad, kostet dafür aber auch nur ca. 150T e.
Neben diesen gibt es auch eine Vielzahl an speziell angefertigten Unterarten.
Außerdem existieren auch portable Geräte in Tischform, die sich für die Präsentation außer Haus nutzen lassen [Hau10].
Bei allen diesen Ausgabeformen können unterschiedliche Bedienarten zum Einsatz kommen, wie sie in Kapitel 2.2 vorgestellt wurden. Abhängig ist die Wahl
u.a. von Performance und Genauigkeit.
Neben der beschriebenen Hardware sind die verwendeten Softwarewerkzeuge
von zentraler Bedeutung. Bei der Anzeigesoftware kann grob zwischen CADSoftware für industriellen Einsatz sowie allgemeinen Grafik-APIs wie OpenGL
oder Microsoft Direct3D unterschieden werden [Hau10]. Die verfügbaren Anzeigeprogramme unterscheiden sich sowohl in den Kosten als auch im Lizenzmodell:
Es sind sowohl kostenlose Freeware- Programme als auch Programme für mehrere 10.000 e auf dem Markt erhältlich. Neben fertigen Lösung existieren auch
Sonderanfertigungen und Entwicklungsumgebungen. Die genutzte Software
muss sorgfältig für die jeweilige Anwendung ausgewählt werden. Hierbei sollten unbedingt auch langfristige Kosten berücksichtigt werden. Eine Liste von
erhältlichen Produkten und Entscheidungshilfen ist [Hau10] zu entnehmen.
8
4 Einsatz im Automobilbereich
Auch für die Automobilindustrie, die bereits seit vielen Jahren Computer Aided
Design verwenden, bieten sich viele Anwendungen der virtuellen Realität an.
Darunter fallen Produktentwicklung, Präsentation, Simulation und Analyse.
Zimmermann von der Volkwagen Foeschungsabteilung beschreibt bereits 2001:
„Die Fahrzeugindustrie macht es vor: das virtuelle Auto existiert lang
vor dem ersten realen Prototyp. Am Rechner wird es entworfen, in der
virtuellen Fabrik wird es (virtuell) gefertigt und danach im Cyberspace
erprobt. Schließlich kommt der virtuelle Crashtestdummy zum Einsatz. Die
neuen Technologien bringen die Branche in Schwung doch die Potenziale
sind noch längst nicht ausgeschöpft. Was möglich ist, zeigt das Beispiel aus
Wolfsburg.“ [Zim01]
Neben der eigentlichen Produktentstehung wird hier auch eine Product Clinic
beschrieben, in der Testpersonen virtuelle Prototypen von Autos beurteilen. Dadurch werden nicht nur der Zeitaufwand und die Kosten reduziert, sondern auch
die Qualität des Fahrzeuges gesteigert.
Abbildung 3: Augmentierung eines realen Modells mit einem virtuellen.
Neben VR-Anwendungen spielt im Automobilbereich auch die Augmented
Reality eine große Rolle. So kann ein Auto z. B. in realen Umgebungen eingebettet
betrachtet werden oder verschiedene Varianten von Fahrzeugen kombiniert
werden, wie in Abb. 3 dargestellt. Mit Augmented Reality kann auch die Fertigung
selbst unterstützt werden:
9
„Die BMW Group setzt Augmented Reality bereits heute im Prototypenbau ein. Zu diesem Zweck wurden spezielle Schweißpistolen entwickelt. Ihr
Display zeigt den optimalen Schweißpunkt auf der Rohkarosse an und erleichtert so die schnelle und passgenaue Bearbeitung des Bauteils.“ [BMW06]
In der Automobilindustrie kommen neueste Techniken zum Einsatz: Beim Automobilhersteller Audi beispielsweise wird zu Präsentation eine sechs Meter breite
und zwei Meter hohe Powerwall verwendet, die statt mehrerer Projektoren lediglich einen einzigen Projektor verwendet [Com]. Dieser liefert bis zu 7,4 Mio. Pixel.
Mercedes brachte mit der C-Klasse das erste Serienfahrzeug auf den Markt, „das
auf Basis eines digitalen Prototyps konzipiert und entwickelt wurde“ [Com]. Die
Computersimulation umfasste 2130 Gigabyte an Daten. Simuliert wurden hier:
• Crashsicherheit
• Insassenschutz
• Geräusch-, Schwingungs- und Abrollkomfort
• Betriebsfestigkeit
• Energiemanagement
• Klimatisierung
• Aerodynamik
Neben der Zeitersparnis konnte so der Reifegrad des ersten fahrbereiten Prototyps stark erhöht werden, was insgesamt eine höhere Fahrzeugqualität mit sich
bringt.
Insgesamt zeigt sich mit diesen Beispielen, dass der Einsatz von Virtual und
Augmented Reality sehr vielfältig ist, aber auch erhebliche Vorteile auf dem
Automobilmarkt bringt.
5 Virtuelle Realität im medizinischen Bereich
Ein interessantes Einsatzfeld für VR ergibt sich mit medizinischen Anwendungen.
Mit dem Begriff der Telemedizin wurde ursprünglich die Idee formuliert, „im
Kriegsfall Operationen an verwundeten Soldaten mit ferngesteuerten Robotern
10
aus sicherem Abstand heraus durchzuführen“ [TSB+ 00]. Eine verwandte Anwendung wäre es, Astronauten von der Erde aus zu behandeln. Die Grenzen
und Anforderungen dieser Art von Medizin sowie anderen Anforderungen sind
dadurch gegeben, dass hier u.U. das menschliche Leben von der Genauigkeit und
Zuverlässigkeit der Methode abhängt. Es sind bereits einige Verfahren im Einsatz,
die sich als effektiv erwiesen haben. Von diesen sollen in Kapitel 5.1 und 5.2 kurz
chirurgische und radiologische Anwendungen vorgestellt werden. Anschließend
wird in Kapitel 5.3 die Anwendung in der psychologischen Therapie vorgestellt,
die bereits große Erfolge zeigt.
5.1 Neurochirurgie
Die computerintegrierte Chriurgie soll die Kooperation zwischen Mensch und
Maschine verbessern, sodass „Effektivität des Eingriffs, die Sicherheit für den
Patienten und das Nutzen-Risiko-Verhältnis gesteigert werden“ [TSB+ 00]. Chirurgen sind zwar dazu ausgebildet, Eingriffe „sicher, schnell und manuell“ [TSB+ 00]
geschickt auszuführen. Die Qualität des Eingriffes ist aber begrenzt durch Geschicklichkeit und menschliche Präzisionsarbeit. Maschinen können den Menschen hier unterstützen ohne zu ermüden und liefern eine hohe Präzision.
Die computerassistierte Chrirurgie verwendet virtuelle Realität u.a. für sog.
Navigationssysteme, die ein präoperatives Modell liefern. Die echte virtuelle
Chrirurgie würde dem Operierenden per Joystick oder Datenhandschuh die Möglichkeit geben, einen Medizinroboter zu steuern. Dies ist aber je nach benötigter
Genauigkeit nur teilweise möglich Es ist aber zu erwarten, dass mit wachsender
Rechenleistung in der Neurochriurgie VR-Techniken noch intensiver zum Einsatz
kommen werden [TSB+ 00].
5.2 Radiologie
An diesen medizinischen Anwendungen wird deutlich ersichtlich, dass virtuelle
Realität weit mehr als nur ein Spielzeug ist. In der Radiologie liefert VR bspw.
den Vorteil, dass es neben dem geometrischen Modell auch eine funktionales
Modell bietet und Manipulation und Analyse desselben erlaubt [PP00]. Während
bei anderen Anwendungen wie der Automobilindustrie der kostspielige Einsatz
von VR durch hohe Gewinne und Produktionszahlen leicht zu rechtfertigen
ist, könnte dies im klinischen Umfeld nur mit einem relativ günstigen Preis
11
geschehen.
Anders als beispielsweise bei CAD-Anwendungen hängt die Genauigkeit bei
radiologischen Anwendungen, die hauptsächlich auf auf präzise Diagnosen
ausgerichtet sind, ab von den bildgebenden Verfahren. Dank der technischen
Weiterentwicklungen, der größeren Akzeptanz von Technik an sich und dem sich
positiv entwickelnden Preis/Leistungsverhältnis von VR-Techniken sind viele
der anfänglichen Zweifel an VR in der Radiologie aus dem Weg geräumt. Für
Anwendungen, die über Visualisierung hinaus gehen, sind die vorhandenen
Werkzeuge jedoch oft nicht flexibel und universell genug, sodass zukünftig noch
mehr Potenzial der Techniken ausgeschöpft werden kann.
Abbildung 4: Resektionsvorschlag mit Sicherheitsabstand einer Leber [PP00]
Mögliche Nutzungen von VR in der Radiologie sehen Peitgen und Preim [PP00]
beispielsweise bei der Planung von Operationen anhand Magnet-ResonanzTomographie-Bildern. Ein Beispiel hierfür ist in Abb. 4 dargestellt: Hier kann für
eine Leber ein möglicher Schnitt bei einer Operation visualisiert werden. Das
Hauptproblem bei VR in der Radiologie sehen Peitgen und Priem darin, dass
Aufwand und Nutzen schwer einzuschätzen sind.
5.3 Psychologische Behandlung
Auch im psychologischen Bereich ist eine sinnvolle Nutzung von VR möglich:
Zum Einsatz kommen entsprechende Techniken bei der Konfrontations-Therapie.
Diese ist eine wirkungsvolle Verhaltenstherapie, die bei Angststörungen eingesetzt wird. Dabei wird der Patient „wiederholt, stufenweise und systematisch“
[BBGP+ 08] der Situation ausgesetzt, die beim irrationale Angst hervorruft. Durch
12
Gewöhnung und emotionale Verarbeitung können so Ängste überwunden werden. Dies kann entweder in der realen Welt, also in-vivo, oder in der Imagination
des Patienten geschehen. Im Gegensatz dazu bietet eine Behandlung mittels VR
folgende Vorteile [BBGP+ 08]:
• Die Konfrontation ist für den Patienten oft einfacher akzeptierbar.
• Feine Abstufung der Konfrontationsschritte sowie exakte Wiederholung
von Situationen
• Erweitern der Realität wie z. B. Veränderung des Raumes
• Einfache Umsetzung, die Zeit und Geld spart
• Verbesserung der Vertraulichkeit
Studien haben gezeigt, dass diese Therapieform sehr wirksam ist [BBGP+ 08].
Abbildung 5: Die Landschaften in EMMA’s Welt [BBGP+ 08]
Für eine andere Anwendung, die Behandlung der Post-Traumatischen Verhaltensstörung (PTBS) ist ebenfalls eine Behandlung mit VR möglich. Diese muss
jedoch i.Allg. sehr spezialisiert sein und ist daher teuer. Daher schlagen Baños et
al. [BBGP+ 08] eine VR-Welt namens „EMMA’s Welt“ vor, die im Rahmen des europäischen Gemeinschaftsprojektes EMMA (Engaging Media for Mental Health
13
Application) entstanden ist. Hier kann der Patient wahlweise zwischen der realen
und der virtuellen Welt wechseln. Die Inhalte der virtuellen Welt werden vom Therapeuten on-the-fly angepasst an die Bedürfnisse des Patienten. Die virtuelle Welt
besteht unter anderem aus Landschaften mit Wiese, Strand, Wüste, Wald oder
Schnee, die für verschiedene Emotionen eingesetzt werden können (siehe Abb. 5).
Da für das System lediglich zwei PC, zwei Projektoren, eine Projektionsleinwand,
eine drahtlose Konsole und Lautsprecher benötigt werden, ist es relativ kostengünstig. Dadurch, dass kein HMD zum Einsatz kommt, können Therapeut
und Patient sich gleichzeitig in der VR-Welt befinden. Baños et al. [BBGP+ 08] beschreiben Szenarien, wo EMMA’s Welt sehr erfolgreich zur Anwendung kommt,
wenngleich die VR-Erfahrungen in der psychologischen Behandlung noch am
Anfang stehen.
In dieser Arbeit wurde zunächst das Konzept der virtuellen Realität und die
praktische Nutzung von VR-Anwendungen vorgestellt. Es wurde gezeigt, dass
die Einsatzgebiete sehr vielfältig und unterschiedlich sind und dass das Potenzial
längst nicht ausgeschöpft ist.
Aus den vielen verschiedenen Anwendungen wurden zwei konkretere Beispiele
vorgestellt: Die Automobilindustrie und der medizinische Bereich. Während im
Automobilbereich längst virtuelle Realitäten das Mittel der Wahl für Präsentation,
Produktentwicklung und Simulation sind, sind mit dem Fortschritt der Technik
immer lohnenswertere Anwendungen zu beobachten. Im Gegensatz zu anderen
Branchen und kleineren Unternehmen fällt hier die Kosten-Nutzen-Rechnung
deutlich einfacher und positiver aus. Anders ist dies auch im medizinischen Bereich, wo der lohnenswerte Einsatz von VR sich nicht so sehr und kurzfristig aus
betriebswirtschaftlicher Sicht zeigt. Dennoch sind diese Ansätze für die Medizin
ein Fortschritt: Beispielsweise in Operationsplanung, Chirurgie und Psychologie
kommt VR vorteilhaft zum Einsatz. Anhand dieser durchaus verschiedenen Beispiele aus dem medizinischen Bereich wurde deutlich, dass VR längst mehr als
ein Spielzeug ist und den Menschen bei wichtigen Aufgaben behilflich sein kann.
Eines der Hauptprobleme besteht darin, dass mit den vorhandenen Techniken
derzeit noch keine solche Genauigkeit erzielt werden kann, die das Risiko großen
menschlichen Schadens auf ein Minimum reduziert.
14
Diese Arbeit konnte einen kleinen Ausschnitt der Thematik zeigen. Es bieten
sich aber auch noch weitere Sichten an, wie z.B. die ethische Frage nach dem
immer größer werdenden Einfluss von virtuellen Realitäten auf unser tägliches
Leben. Die Entwicklung von Techniken der virtuellen Realität wird mit der
Entwicklung der verfügbaren Rechenleistung in den kommenden Jahren voraussichtlich deutlich voranschreiten und noch weiter an Wichtigkeit und Akzeptanz
gewinnen.
15
Literatur
[BBGP+ 08] Baños, Rosa M. ; Botella, Cristina ; Garcia-Palacios, Azucena ; Quero, Soledad ; Alcañiz, Mariano ; Guillén, Verónica: Virtuelle Realität
und psychologische Behandlungen. In: Bauer, Stephanie (Hrsg.) ;
Kordy, Hans (Hrsg.): E-Mental-Health. Springer Berlin Heidelberg,
2008. – ISBN 978–3–540–75736–8, S. 191–204
[BMW06]
BMW Group PressClub Deutschland. https://www.press.bmwgroup.
com/pressclub/p/de/pressDetail.html?outputChannelId=
7&id=T0002397DE&left_menu_item=node__2369. Version: 2006
[BR03]
Brockhaus-Redaktion: Virtuelle Realität. In: Paulick, Siegrun
(Hrsg.):
Der Brockhaus in einem Band. 10., neu bearbeitete Auflage. Leipzig,
Mannheim : F.A. Brockhaus, 2003. – ISBN 3–7653–1680–6, S. 957
[Bri08]
Brill, Manfred: Virtuelle Realität. Berlin : Springer, 2008. – ISBN
978–3540851172
[Cav]
http://www.vrarchitect.net/anu/cg/Display/cave.en.html
[Com]
Computerwoche: Virtueller Erlkönig: Autodesigner lieben Computergrafiken. http://www.computerwoche.de/mittelstand/1856079/
[Hau10]
Hausstädtler, Uwe: Der Einsatz von Virtual Reality in der Praxis.
Berlin : Rhombos Verlag, 2010. – ISBN 978–3–941216–14–3
[HMD]
http://www710.univ-lyon1.fr/~sbrandel/en/research/VR/
[LGD+ 99] Lamadé, W. ; Glombitza, G. ; Demiris, A. M. ; Cardenas, C. ; Meinzer,
H. P. ; Richter, G. ; Lehnert, T. ; Herfarth, C.: Virtuelle Operationsplanung in der Leberchirurgie. In: Der Chirurg 70 (1999), S. 239–245. –
ISSN 0009–4722. – 10.1007/s001040050637
[Pow]
http://de.wikipedia.org/w/index.php?title=Datei:
3d-powerwall.jpg&filetimestamp=20101030063735
[PP00]
Peitgen, H. O. ; Preim, B.: Virtuelle Realität in der Radiologie. In: Der
Radiologe 40 (2000), S. 203–210. – ISSN 0033–832X
[Tho11]
Thompson, Craig W.:
Next-Generation Virtual Worlds: Architecture, Status, and Directions.
In: IEEE Internet Computing 15 (2011), S. 60–65.
http://dx.doi.org/http://
DOI
doi.ieeecomputersociety.org/10.1109/MIC.2011.15. –
http://doi.ieeecomputersociety.org/10.1109/MIC.2011.15. – ISSN 1089–
7801
[TSB+ 00]
Tronnier, V. M. ; Staubert, A. ; Bonsanto, M. M. ; Wirtz, C. R. ;
Kunze, S.: Virtuelle Realität in der Neurochirurgie. In: Der Radiologe
40 (2000), S. 211–217. – ISSN 0033–832X. – 10.1007/s001170050659
[Wor]
http://www710.univ-lyon1.fr/~sbrandel/en/research/VR/
[Zim01]
Zimmermann, Peter: Virtual Reality - Forschung und Anwendung bei Volkswagen. www.umi.cs.tu-bs.de/full/information/
literature/sonderheft/shvirt7.pdf. Version: 2001
Bildverarbeitung mit OpenCV und
PCL
Seminararbeit
im Rahmen der Projektgruppe Virtual Reality“
”
Themensteller:
Vorgelegt von:
Abgabetermin:
Prof. Dr. Wolfgang P. Kowalk
Christian Herz
07. Juli 2011
Inhaltsverzeichnis
Inhaltsverzeichnis
Inhaltsverzeichnis
1 Motivation
3
2 Einleitung
4
3 OpenCV - Open Computer Vision
3.1 Aufbau von OpenCV . . . . . . . . . .
3.2 Funktionalitäten . . . . . . . . . . . .
3.2.1 Optical Flow Tracking . . . . .
3.2.2 Camshift Tracking . . . . . . .
3.2.3 Gesichtserkennung mit OpenCV
3.2.4 Skeletterkennung . . . . . . . .
3.2.5 Maschinelles Lernen . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5
6
6
7
8
9
10
4 PCL - Point Cloud Library
12
4.1 Was sind Punktwolken und wozu dienen sie? . . . . . . . . . . . . . . 12
4.2 Aufbau von PCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3 Funktionalitäten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5 Fazit/Nutzbarkeit
15
16
2
1 MOTIVATION
1 Motivation
Die Motivation dieser Arbeit besteht darin, in der Computer Vision verwendete
Bibliotheken vorzustellen und anhand dieser einige interessante Möglichkeiten aufzuzeigen. Computer Vision ist ein weites Feld mit einer Menge von Potenzial. Faszinierend daran ist, maschinelles Sehen zu ermöglichen und dadurch beispielsweise Roboter dazu zu bringen, Gegenstände zu identifizieren, diese zu greifen und
durch Räume mit vielen Hindernissen zu einer Person zu transportieren. Für viele
Menschen könnte, gerade in hohem Alter, ein solches System den Lebensalltag in
enormen Maße erleichtern. Gerade durch die Kinect wurde ein revolutionärer Fortschritt erreicht, der es ermöglicht mit wenig Mitteln (insbesondere finanziell gesehen)
in Echtzeit Tiefeninformationen der Umgebung zu bekommen. Dadurch stehen der
Computer Vision neue Wege offen und schon befassen sich viele Interessierte mit
der Analyse und Verarbeitung der Daten von der Kinect. Weitergehend liegt die
Motivation in der erfolgreichen Implementierung einer Arbeit, die es ermöglicht, etwas entwickelt zu haben, das womöglich einigen Menschen das Leben erleichtern
könnte.
3
2 EINLEITUNG
2 Einleitung
Im Rahmen der Computer Vision spielen Bildverarbeitungsbibliotheken eine wichtige Rolle. Computer Vision ist die Verarbeitung von Bilddaten, kommend von einer
Kamera oder einer Videokamera, um Entscheidungen zu treffen, Bilder zu verstehen
oder diese in eine andere Repräsentation zu überführen. All diese Veränderungen
von Bilddaten haben einen speziellen Grund. So kann zum Beispiel die Segmentierung eines Tumors innerhalb der Leber ein Grund sein oder die Erkennung einer
Hand in Bilddaten. OpenCV - Open Computer Vision“ stellt dabei ein mächtiges
”
Toolkit dar, das eine Reihe von Algorithmen für die Bildverarbeitung anbietet, die
stets ergänzt werden. Außerdem ist OpenCV eine OpenSource-Bibliothek und somit für alle frei zugänglich. Speziell für die Thematik Kinect“ in der Projektgruppe
”
Virtual Reality“ kann die Verarbeitung von Punktwolken von Interesse sein. Die
”
OpenSource-Bibliothek PCL - Point Cloud Library“ stellt hier das Mittel der Wahl
”
dar. Aufgrund der aktuellen Kooperation mit OpenCV spannt es ein weites Feld
von Möglichkeiten auf. Deswegen werden in dieser Ausarbeitung sowohl OpenCV,
als auch PCL aufgeführt, wobei das Hauptaugenmerk auf OpenCV liegt. Außerdem
wird der Zugang zur Kinect mit OpenCV und PCL untersucht, sowie Funktionalitäten, die interessant und nützlich für die Verarbeitung der erhaltenen Daten aus
der Kinect sein könnten.
In Abschnitt 3 wird OpenCV behandelt, wobei dort der Aufbau und Nutzungsmöglichkeiten erwähnt werden. Abschnitt 4 beschreibt PCL, dessen Funktionalitäten
und Aufbau. Zum Schluss wird in Abschnitt 5 eine kurze Zusammenfassung und
Bewertung der verwendeten Bibliotheken, bezogen auf die Projektgruppe Virtual
”
Reality“, gegeben.
4
3 OPENCV - OPEN COMPUTER VISION
3 OpenCV - Open Computer Vision
OpenCV ist eine OpenSource-Bibliothek, die der BSD-Lizenz unterliegt und folglich für kommerzielle und Forschungszwecke zur Verfügung steht. Die Bibliothek
wurde ursprünglich in C geschrieben, wobei für C++ und Python jeweils ein Interface existiert und jede Weiterentwicklung in C++ stattfindet. Außerdem soll es
laut [BK08] eine aktive Entwicklung von Interfaces für Ruby, Matlab und weiteren
Programmiersprachen geben. Eine weitere wichtige Eigenschaft ist die Plattformunabhängigkeit. OpenCV kann auf Linux, Windows, Mac OS X und seit Version
2.2 sogar auf Android benutzt werden. Dem Anwender stehen durch OpenCV eine Vielzahl an Möglichkeiten zur Verfügung, durch die unterschiedliche Bereiche
der Computer Vision abgedeckt sind. Dabei legt OpenCV Wert auf die medizi”
nische Bildverarbeitung“, Sicherheit“, Kamerakalibrierung“ und Stereoskopie“,
”
”
”
sowie auf maschinelles Lernen“ besonderen Wert. Abschließend ist zu bemerken,
”
dass OpenCV besonders darauf ausgelegt ist Echtzeitanwendungen zu entwickeln.
(vgl. auch [BK08])
3.1 Aufbau von OpenCV
OpenCV ist in fünf Hauptkomponenten eingeteilt, von denen jedoch nur vier in Abbildung 1 aufgeführt sind.
Abbildung 1: Basisstruktur von OpenCV aus [BK08]
5
3.2 Funktionalitäten
Die Komponente cv“ stellt grundlegende Algorithmen für die Bildverarbeitung
”
zur Verfügung. Diese beinhalten insbesondere Bild -und Bewegungsanalyse, Objektverfolgung, Objekt -und Gesichtserkennung, sowie Kamerakalibrierung und 3DRekonstruktionen. Die Komponente highgui“ beinhaltet Funktionen für die Bild”
und Videoaufnahme, sowie eine einfache Oberflächendarstellung. In der Komponente cxcore“ sind, wie der Name schon sagt, die Kernfunktionalitäten vertreten.
”
Darunter fallen beispielsweise Arrayoperationen, mathematische Funktionen, XML,
Zeichenfunktionen in 2D, sowie komplexe Datenstrukturen. Die MLL - Machine
”
Learning Library“ enthält Funktionen für neuronale Netze, Entscheidungsbäume,
statistische Klassifikationen und andere. Die letzte, nicht in der Abbildung aufgeführte Komponente, hat die Bezeichnung CvAux“. Sie wurde nicht in der Abbil”
dung abgebildet, weil sie experimentelle Algorithmen enthält und außerdem nicht
gut dokumentiert wurde. (vgl. auch [BK08])
In diesem Abschnitt werden interessante Funktionalitäten für die Projektgruppe
Virtual Reality“ behandelt und mit etwaigen Beispielen veranschaulicht.
”
3.2.1 Optical Flow Tracking
Bei dem Verfolgen von Objekten beliebiger Art über den optischen Fluss“ (engl.
”
Optical Flow) wird anhand von Helligkeitsmustern die Bewegung eines Pixels innerhalb aufeinander folgender Bilder einer Bildsequenz berechnet. Dabei wird die
Annahme gemacht, dass der Helligkeitswert der betrachteten Pixel über die Zeit konstant bleibt, sich also von einem Bild in das nächste nicht verändert. Es resultiert
ein Vektorfeld, das Orientierung und Bewegungsgeschwindigkeit jedes betrachteten
Pixels angibt. Durch OpenCV ist eine solche Verfolgung ohne weiteres möglich.
Problematisch wird es nur, wenn sich das betrachtete Objekt zu sehr von der äußerlichen Erscheinung verändert oder rapide Intensitätsveränderungen auftreten. (vgl.
auch [BK08])
In [ehc] verwendet Daniel Baggio Optical Flow“ für die Verfolgung des Gesichts.
”
Dort wird vorerst auf dem erkannten Gesicht nach Punkten mit einem markanten Charakteristikum gesucht. Anschließend werden diese Punkte verfolgt. Nachteil
6
bei diesem Verfahren ist, dass diese Punkte verloren gehen, sobald sie im darauf
folgenden Bild nicht mehr gefunden werden. Statt einmal die Robustheit des implementierten Systems zu zeigen, bewegt der Entwickler sich besonders langsam und zu
sehen ist, dass auch dort Punkte verloren gehen. Um dies zu umgehen, initialisiert
er immer wieder manuell neue Punkte auf dem erkannten Gesicht. Dadurch kommt
die Vermutung auf, dass der Entwickler dies besser automatisieren hätte sollen, so
dass eine erneuerte Initialisierung stattfindet, sobald die Anzahl der Punkte unter
einen Schwellwert fällt. Womöglich wäre dadurch eine effizientere Lösung gegeben,
die jedoch immer noch gegen eine Rotation des Kopfes empfindlich ist.
3.2.2 Camshift Tracking
Der Camshift Algorithmus (Camshift - continuously adaptive mean shift) ermöglicht
es, Verschiebungen von Objekten nachzuvollziehen und diese ggf. zu verfolgen. Der
Algorithmus sucht im Bereich eines vorher definierten Suchfensters nach lokalen
Gipfeln (Maxima) einer Verteilung beliebiger charakteristischer Merkmale (z. B.
Farbverteilung, Form usw.). So könnte z. B. eine Farbe das besondere Merkmal der
Verteilung sein oder die geometrische Form eines Objektes. Im Suchfenster würden
dann, sobald Pixel dieser Form/Farbe zu sehen sind, unterschiedliche Gipfel auftauchen, anhand derer dann ein Objekt verfolgt werden könnte. Je nachdem, welches
Charakteristikum für die Wahrscheinlichkeitsdichtefunktion gewählt wurde, ändern
sich dementsprechend die Maxima. Bei Objekten, die sich in der Größe verändern
können, wird eine automatische Größenänderung des Suchfensters vorgenommen.
Wenn sich das zu verfolgende Objekt beispielsweise weiter von der Kamera entfernt
und das Objekt kleiner wird, dann resultiert darin die Verkleinerung des Suchbereichs. Gleiches gilt bei Vergrößerungen von Objekten. (vgl. auch [BK08])
Als Vorgehensweise des Camshift-Algorithmus werden folgende Aktionen abgearbeitet:
1. Wahl einer intitialen Umgebung und Größe für das Suchfenster (Könnte zum
Beispiel durch einen initialen Bereich oder eine Geste gemacht werden)
2. Berechnung von dem Massezentrum des Suchfensterinhalts
3. Zentrieren des Suchfenstermittelpunkts auf das Massezentrum
7
4. Anpassung der Suchfenstergröße
5. Wiederholung ab Schritt 2, sofern Suchfenster in Bewegung ist
Bezogen auf die Kinect könnte ein Camshift-Tracking anhand der Farbe des initialisierten Anwenders erfolgen. Dabei müsste entweder ein Bereich definiert werden, in
dem sich der Anwender befinden soll und darf oder der Anwender muss zu Beginn
der Applikation eine initiale Geste machen. Auch wäre eine manuelle Selektion des
Anwenders durch dessen Markierung im Bild mit Tiefeninformationen möglich.
3.2.3 Gesichtserkennung mit OpenCV
In OpenCV existiert die Möglichkeit eine Gesichtserkennung durchzuführen und anschließend das Gesicht zu verfolgen. Dabei orientiert sich OpenCV an Kontrasten in
unterschiedlichen Regionen des Bildes. Diese Besonderheiten werden auch als Haar”
like Features“ bezeichnet. Das menschliche Gesicht kann durch den Zusammenhang
dieser Regionen definiert werden. Ein Problem bei dieser Vorgehensweise ist jedoch,
dass das Gesicht vor der Erkennung über mehrere hundert Bilder trainiert werden muss. Aus den gelernten Gesichtern wird anschließend eine XML-Datei erstellt,
anhand dieser anschließend Gesichter erkannt werden können. OpenCV bietet bereits eine solche XML-Datei an, so dass dem Entwickler das Training erspart wird.
Grundlegender Nachteil ist die Anwendung eines Templates der Größe 20x20, der
für eine Gesichtserkennung über das gesamte Bild gezogen wird. Dabei wird dieses
Template auf jeweils eine ROI (Region Of Interest) der selben Größe angewendet.
Sobald eine Region dem Template entspricht, gibt der Algorithmus eine 1“ zurück.
”
Damit sichergestellt werden kann, dass das Gesicht auch bei anderen Entfernungen von der Kamera erkannt werden kann, wird das Template bei unterschiedliche
Auflösungen auf das Bild angewendet. Diese Methode nimmt einen ziemlich großen
Rechenaufwand ein und deswegen eine Gesichtserkennung in Echtzeit fragwürdig.
Der Test ergab kein zufriedenstellendes Ergebnis. Zwar wird das Gesicht in Videobildern erkannt, aber dazu muss das Gesicht gerade auf die Kamera gerichtet sein.
Zudem darf der Kopf nicht geneigt oder gedreht werden. Leider ist diese Feature von
OpenCV viel zu langsam für eine Echtzeitanwendung. Auch ändert sich nichts an
der Geschwindigkeit, wenn die Auflösung auf 180 x 144 runterskaliert wird. In Abbil-
8
dung 2 ist ein Beispielbild zu sehen. Womöglich wird es mit einem leistungsstärkeren
Prozessor bessere Ergebnisse geben. (vgl. auch [fac])
Abbildung 2: Gesichtserkennung bei einer Auflösung von 180x144
3.2.4 Skeletterkennung
In [Rus11] zeigen Corey Manders und Farzam Farbiz eine Skeletterkennung. Benutzt wird dafür eine 3D-Webcam, die in der PG Virtual Reality“ jedoch nicht
”
benötigt wird, da bereits Tiefeninformationen über die Kinect vorhanden sind. Lediglich müssen die ausgegebenen Werte mit der tatsächlichen Entfernung abgeglichen
werden, um eine Konsistenz zwischen Bild und Realität herzustellen. Der Algorithmus für die Positionsbestimmung geht wie folgt vor:
1. Gesichtserkennung aus OpenCV
2. Annahme, dass sich der Nacken des Benutzers 0.5*Kopfradius unter dem erkannten Gesicht befindet.
3. Schultern des Anwenders ab dem Hals 2*Kopfradius auf einer horizontalen
Linie.
4. Erkennung der Hände (erst die linke Hand, dann die rechte Hand) anhand der
Bilder mit Tiefeninformationen und Annahme, dass die Hände näher als der
9
Kopf des Anwenders an der Kamera sind.
a) Linksseitig vom Kopf nach der linken Hand suchen
b) Dafür ROI (Region Of Interest) definiert
c) Innerhalb der ROI maximalen Wert feststellen (Tiefeninformation)
d) Thresholding, so dass nur noch die Werte der Hand im Bild zu sehen sind
e) Massenzentrum bestimmen und Hand identifizieren
f) Gleiches Vorgehen für die rechte Hand
5. Erkennung des Unterarms entlang der y-Achse mit der jeweiligen Hand als
Starpunkt.
6. Erkennung des Oberarms durch das Zeichnen einer Linie vom untersten Punkt
des Unterarms bis zu den Schultern.
Zwar werden in den Veröffentlichungen gute Ergebnisse gezeigt, dennoch ist zu bezweifeln, dass die implementierte Anwendung eine Verarbeitung in Echtzeit ermöglicht.
Mit der Benutzung der Gesichtserkennung von OpenCV, die in Abschnitt 3.2.3
erläutert und getestet wurde, sind keine zufriedenstellenden Ergebnisse zu erwarten. Dennoch könnte die Gesichtserkennung für eine Initialisierung des Gesichts
benutzt werden, so dass anschließend weitere Aktionen, z. B. mit in Abschnitt 3.2.5
aufgeführten Möglichkeiten, ausgeführt werden können.
3.2.5 Maschinelles Lernen
OpenCV ermöglicht das maschinelle Lernen aus vorhandene Daten. So können z.
B. Rückschlüsse aus gesammelten Daten gezogen, Modelle erstellt und Vorhersagen
über mögliche Folgezustände getroffen werden. Unter das maschinelle Lernen in
OpenCV fallen folgende Klassifikatoren:
• statistische Modelle
• Bayes Klassifikator
• KNN - K Nearest Neighbors
10
• Entscheidungsbäume
• Boosting
• Expectation-Maximization-Algorithmus
• Neuronale Netzwerke
• Support Vector Machine
Näheres zu den Algorithmen ist in [BK08] zu finden.
11
4 PCL - POINT CLOUD LIBRARY
4 PCL - Point Cloud Library
PCL stellt einen wichtigen Teil des ROS - Robot Operating System“ dar. Sie ist
”
eine vollständig in C++ implementierte Bibliothek mit einem Eigen“-Backend für
”
die Verarbeitung von n-dimensionalen Punktwolken und 3D Geometrieverarbeitung.
Enthalten sind aktuelle Algorithmen für Filterung, Oberflächenrekonstruktion, Registrierung und Segmentierung. PCL unterliegt der BSD-Lizenz und ist somit frei
zugänglich und verwendbar für alle. Außerdem bietet PCL eine weitgehend plattformunabhängige Benutzung (Linux, Windows, MacOS und sogar Android. (vgl.
[Rus11])
4.1 Was sind Punktwolken und wozu dienen sie?
Eine Punktwolke (engl. point cloud) stellt ein n-dimensionales Konstrukt bestehend
aus einer Anzahl von Punkten und optional zusätzlichen Informationen, wie z. B.
Farbe, Intensität, Distanz etc., im Raum dar. Ein Punkt kann somit wie folgt beschrieben werden.
pi = {xi , yi , zi , ri , gi , bi , disti , ...}
wobei eine Punktwolke definiert ist als:
P = {p1 , p2 , ..., pi , ..., pn }
Die Menge der Punkte hängt dabei von der Komplexität des betrachteten Objekts
ab. In der Regel werden solche Punktwolken mit teuren 3D-Laser-Scannern (hohe
Qualität) oder Stereo-Kameras (abhängig von den Texturen) erstellt. Mit der Kinect
hingegen ist dies ohne den Einsatz von Lasern möglich. Die Kinect macht sich das
TOF - Time of Flight“-Prinzip zunutze, durch das Tiefeninformationen ermittelt
”
werden können. Auch interessant ist, dass die Kinect neben 2D-Bilder sogar Punktwolken in Echtzeit ausgibt. Im Vergleich zu dem 3D-Laser-Scanner ist diese Methode also vergleichsweise günstiger. Verwendung finden Punktwolken in verschiedenen
Bereichen wie z. B. der Visualisierung, also der Darstellung von Objekten oder
Oberflächen auf Computern. Auch verwendet werden sie in der Modellierung zur
Rekonstruktion von Oberflächen mit sogenannten “Meshes“ und Polygonen. Wei-
12
4.2 Aufbau von PCL
tergehend ist eine geometrische Berechnung wie z. B. das Objekte vermessen von
Bedeutung, sowie die Erkennung von Menschen und Gegenständen oder die Navigation entlang einer Umgebung mit räumlichen Informationen möglich. [vgl. [Teu07],
[PCL], [Mic]]
4.2 Aufbau von PCL
Der Aufbau von PCL ist modular. Durch die Nutzungsmöglichkeit auf verschiedenen
Plattformen mit unterschiedlicher Leistung war dies nötig, da jedem System ein
anderes Leistungsspektrum zur Verfügung stehen kann. Deswegen ist PCL in eine
Serie von einzelnen Bibliotheken aufgegliedert, so dass diese auch separat kompiliert
werden können. Unter die wesentlichen Bibliotheken fallen:
• common: Datenstrukturen, mathematische Funktionen wie Kovarianz oder
Entfernungsberechnung
• filters: Datenfilter, z. B. für das Entfernen von Rauschen aus Punktwolken
• features: Berechnung der Normalen einer Oberfläche, Grenzpunkte finden,
Integralbilder etc.
• io: Ein -und Ausgabefunktionen
• segmentation: Segmentierungsalgorithmen, z. B. das Teilen einer Punktwolke
und die unabhängige Verarbeitung der Teile
• surface: Oberflächenrekonstruktion, sowie Funktionen für die Vermaschung
und für konvexe Hüllen
• registration: Registrierung von Datensätzen anhand der Position und Orientierung in Punktwolken
• keypoints: Featurebeschreibung (Punkte, die als besonders erscheinen) vorverarbeiten und extrahieren
• range image: Bilder mit Tiefeninformationen anhand der Kalibrierungswerte
der Kamera in Punktwolken überführen
13
• octree: Hierarchische Datenstrukturen in Form eines Baumes von Punktwolkendaten erstellen. Ermöglichung der räumlichen Trennung, Suchoperationen
auf den Datensätzen und Downsampling
Es existieren eine Reihe von Funktionalitäten die für die Verarbeitung und Benutzung von Punktwolken interessant sein könnten. Infrage kommen würde sicherlich die
Registrierung von Punktwolken und eine daran angelehnte Verfolgung des registrierten Objekts, wobei sich dies bei flexiblen Objekten als sehr schwierig herausstellen
kann. Auch wäre es interessant die Normalen von Oberflächen zu berechnen, um
etwaige Orientierungen zu ermitteln, was wahrscheinlich auch in Verbindung mit
OpenCV möglich ist. Insbesondere die Erkennung von räumlichen Veränderungen,
so dass z. B. Menschen als eine Veränderung im Bild erkannt werden können sobald
sie sich bewegen, sollte von Interesse sein. Da Punktwolken nicht nur Informationen
über die dreidimensionale Position der einzelnen Punkte enthalten können, gibt es
weitergehend die Funktionalität, Punktwolken zu komprimieren. Dadurch können
selbst große Punktwolken mit vielen zusätzlichen Informationen verarbeitet werden.
Auf http://www.pointclouds.org/documentation/ befinden sich eine Reihe von
Anleitungen, die weitere Möglichkeiten beschreiben.
14
5 FAZIT/NUTZBARKEIT
5 Fazit/Nutzbarkeit
Für die von der Kinect ausgegebenen Bilddaten und deren Verarbeitung kann sowohl
OpenCV, als auch PCL verwendet werden, wobei PCL natürlich eher auf Punktwolken und deren Verarbeitung, Analyse und Ausgabe spezialisiert ist. Sicher ist,
dass eine Verbindung mit der Kinect mit OpenCV möglich ist. Leider war es bis
zum Abschluss dieser Seminararbeit nicht möglich unter Windows eine Verbindung
via PCL zur Microsoft Kinect herzustellen, die 30 Frames/s zeigt. Die Entwickler
arbeiten bereits daran den Fehler zu beheben. Für eine Verbindung der Microsoft
Kinect nutzen beide Bibliotheken unterschiedliche Komponenten. OpenCV nutzt
zum Einen den Treiber libfreenect“ oder die CL NUI Platform“ und PCL nutzt
”
”
die Middleware OpenNI“ in Verbindung mit Nite“ von der Firma PrimeSense,
”
”
welches zusätzlich eine Skeletterkennung und -Verfolgung implementiert. Weiterhin
ist zu sagen, dass sowohl PCL, als auch OpenCV mit C++ ansprechbar sind und
beide Bibliotheken untereinander kommunizieren können sollten. Wenn also zusätzliche Funktionalitäten erwünscht sind, die nicht in PCL implementiert sind, kann
noch immer auf OpenCV zurückgegriffen werden. Weitergehend stellt OpenCV viele
Algorithmen zur Verfügung, die von Interesse sein könnten. Insbesondere das maschinelle Lernen kommt für die Erkennung von Gesten infrage. Durch Trainingssätze
können die in Abschnitt 3.2.5 gezeigten Klassifikatoren trainiert und anschließend
für Vorhersagen verwendet werden. Abschliessend ist noch zu sagen, dass auch die
Möglichkeit besteht Motion Capturing“ durchzuführen und die erhaltenen Daten
”
beispielsweise in einem XML-Format zu speichern. Die gemessenen Daten können
vorzugsweise in Verbindung mit einem 3D-Modell (z. B. ein Gesicht) gebracht werden und in einer Animation resultieren.
15
Literatur
Literatur
Literatur
[BK08] Bradski, Gary ; Kaehler, Adrian: Learning OpenCV: Computer Vision
with the OpenCV Library. Cambridge, MA : O’Reilly, 2008
[ehc]
http://code.google.com/p/ehci/
[fac]
http://opencv.willowgarage.com/wiki/FaceDetection
[Mic]
http://research.microsoft.com/en-us/um/redmond/events/
latamfacsum2011/presentations/day_2/Barahona_3/Hrvoje_Benko.
pdf
[Ope]
http://opencv.willowgarage.com/wiki/FullOpenCVWiki
[PCL]
http://pointclouds.org/
[ROS]
http://www.ros.org/
[Rus11] 3D is here: Point Cloud Library (PCL). Shanghai, China, May 9-13 2011
[Teu07] Teutsch, Christian: Model-based Analysis and Evaluation of Point Sets
from Optical 3D Laser Scanners. Aachen, Germany, Germany : Shaker
Verlag GmbH, Germany, 2007. – ISBN 3832267751, 9783832267759
16
Konfigurationsmanagement
Seminararbeit
Projektgruppe Virtuelle Realität
Tim Jörgen
31.05.201
1 Inhalt
1
2
Inhalt .................................................................................................................................... i
1.1
Einleitung..................................................................................................................... 1
1.2
Übersicht über das eingesetzt KM ............................................................................... 1
Versionsverwaltung ............................................................................................................ 2
2.1
Vergleich von Git und SVN ........................................................................................ 3
2.2
Hooks ........................................................................................................................... 4
2.2.1
2.3
3
Entscheidung ............................................................................................................... 5
Projektmanagement Tools .................................................................................................. 5
3.1
Übersicht ...................................................................................................................... 5
3.2
Vergleich von Issue-Tracking und Projektmanagement Systemen ............................. 6
3.2.1
Trac....................................................................................................................... 6
3.2.2
Retrospectiva ........................................................................................................ 6
3.2.3
Redmine ............................................................................................................... 7
3.3
4
Verwendete Hooks ............................................................................................... 5
Entscheidung ............................................................................................................... 7
Build Management .............................................................................................................. 8
4.1
CMake Einleitung ........................................................................................................ 8
4.2
Beispiel ........................................................................................................................ 8
4.3
Weitere Funktionen ..................................................................................................... 9
4.4
Integration in das Projekt ............................................................................................. 9
5
Fazit................................................................................................................................... 10
6
Literaturverzeichnis .......................................................................................................... 11
i
1.1 Einleitung
Softwareentwicklung ist typischerweise ein Prozess, welcher von mehreren Personen
vorgenommen wird. Daraus ergeben sich zwangsläufig starke Prozessverluste und Probleme,
die unterschiedlich große Auswirkungen auf das resultierende System, sowie auf die
Wirtschaftlichkeit der Entwicklung haben können. Oftmals werden bereits funktionierende
Teile eines Systems wieder fehlerhaft, es ist nicht klar, wer etwas geändert hat, oder es ist
einfach nicht klar, ob der aktuelle Zustand eines Systems bereits den durch das
Qualitätsmanagement geforderten Anforderungen entspricht (z.B. ob bereits getestet wurde).
Das Konfigurationsmanagement versucht auf diese Probleme einzugehen, koordiniert die
verschiedenen Versionen von Komponenten und stellt eine wichtige Instanz bei der
Minimierung von Prozessverlusten da.
Das Konfigurationsmanagement (KM) ist ein Bestandteil des Projektmanagements und
diesem untergeordnet. Es wurde vor allem 2003 von der DIN ISO 10007:2003 spezifiziert,
welche den bis dahin geltenden Standard ISO 10007:1996 ersetz.
Seinen Ursprung findet es in der Entwicklung von Hardware für den militärischen Bereich in
den 60er Jahren, doch es sei im wesentlichen unabhängig davon, was entwickelt und
hergestellt wird (Versteegen & Weischedel, 2003, S. 1). Das KM beinhaltet "alle technischen,
organisatorischen und beschlussfassenden Maßnahmen und Strukturen, die sich mit der
Konfiguration eines Produktes befassen" (Angermeier, 2004), wobei eine Konfiguration
"miteinander verbundende funktionelle und physische Merkmale eines Produktes [...]" sind
(Braun, 2009, S. 97).
Diese Arbeit beschäftigt sich mit dem Konfigurationsmanagement, welches im Rahmen der
Projektgruppe "Virtuelle Welten" der Carl von Ossietzky Universität eingesetzt wird und der
Organisation, sowie der Entwicklung behilflich ist. Dabei wird vor allem auf Technologien
eingegangen, die im Rahmen der Projektgruppe eingesetzt werden und nun der Projektgruppe
bei der Bewältigung der bevorstehenden Aufgaben zur Verfügung stehen.
1.2 Übersicht über das eingesetzt KM
In dem Projekt "Virtuelle Welten" wird über den Zeitraum von einem Jahr ein Projekt
entwickelt werden, dessen Anforderungen zum Anfang größtenteils unklar waren und erst im
Laufe der ersten Monate spezifiziert wurden. Parallel zur Spezifikation der Anforderungen
entstand das vorliegende Konfigurationsmanagement, welches der Projektleitung die
Möglichkeit gibt eine Aufgabenverteilung zu planen und den Überblick über den aktuellen
Systemzustand zu bekommen. Dabei wurde versucht ein großes Feld an Aufgaben und
Problemen zu adressieren, und eine möglichst wartungsfreie Umgebung zu schaffen, welche
sparsam mit den Vorhandenen Humanressourcen umgeht. Folgende Teilaufgaben wurden
dabei gelöst:




Versionsverwaltung
Dateiaustausch1
Informationsmanagement
Bug Tracking
1
Hiermit ist vor allem der Austausch von Binär Dateien gemeint, die aufgrund ihrer Größe nicht von dem
Versionskontrollsystem verwaltet werden können, ohne die Effektivität von diesem zu reduzieren.
1

Aufgabenverteilung mit Zeiterfassung
Es wurde versucht eine hohe vertikale Integration2 des KM innerhalb der Projektgruppe zu
erreichen, indem die einzelnen Teilbereiche durch den Einsatz von Tools miteinander
verknüpft wurden. Zudem wurde auf Standartsoftware und Lösungen gesetzt um wie bereits
erwähnt ein möglichst wartungsfreies System zu erhalten.
Folgende Software und Tools werden eingesetzt:




Ubuntu 10.10 LTS3
Git
VSFTP
Redmine
Wobei sehr viele Features direkt von Redmine geboten werden, was die Zahl der benötigten
Tools deutlich reduziert hat.
2 Versionsverwaltung
Eine
Versionsverwaltung
ist
für
Software
Projekte
unerlässlich.
Ein
Versionsverwaltungssystem stellt eine Funktionalität bereit, mit der Unterschiedliche
Zustände von Dateien und Dokumenten gespeichert werden können. So kann nach
Änderungen an einer Datei zurückverfolgt werden, wer was und wann geändert hat. Auch
kann zu alten Zuständen zurückgekehrt werden.
Dadurch dass mehrere Programmierer an demselben Projekt arbeiten ergeben sich zudem
verschiedene Probleme. Das bekannteste ist sicherlich das Lost Update Problem, bei dem
Änderungen, die von einer Person vorgenommen wurden die Änderungen einer anderen
Person überschreiben (siehe Abbildung 1).
Abbildung 1 - Lost Update (Hasselbring, 2007)
2
Die vertikale Integration bezeichnet in einem Unternehmen den Grad der Integration von der strategischen
Ebene bis hin zur operativen Ebene.
3
LTS = Long Time Service
2
Dieses Problem wird von allen aktuelleren Versionsverwaltungssystemen durch das
Einführen von Locks und das teilweise automatisierte Zusammenführen von Dateien
behoben. Gerade bei älteren Systemen (wie z.B. RCS) ist diese Funktionalität allerdings nicht
gegeben, wodurch diese Systeme für unser Projekt als unbrauchbar angesehen werden.
Aufgrund der Erfahrungen in der Gruppe wurden vor allem zwei Systeme verglichen, welche
sich grundlegend im Aufbau unterscheiden: SVN und Git.
Nicht betrachtet wurden Systeme, die grundlegend ähnlich wie SVN sind (z.B. CVS), oder
grundlegend ähnlich wie GIT (z.B. Mercurial (hg) oder Bazaar), da in der Gruppe mit diesen
keine großen Erfahrungen vorliegen und eine Einarbeitungszeit erforderlich gewesen wäre.
Auch kommerzielle Systeme wie Microsoft Visual Source Safe (Microsoft VSS) wurden
nicht betrachtet. Die Versionsverwaltung war das erste was im Rahmen des
Konfigurationsmanagements beschlossen und umgesetzt wurde und aufgrund der startenden
Entwicklung engen zeitlichen Grenzen unterworfen.
2.1 Vergleich von Git und SVN
Der Hauptunterschied zwischen Git und SVN ist, dass es sich bei Git um ein sogenanntes
verteiltes Versionsverwaltungssystem handelt. Im Gegensatz zu SVN wird nicht ein zentraler
Server benötigt, sondern es gibt mehrere redundante Instanzen des gesamten Repositories,
wodurch alle Nutzer den vollständigen Funktionsumfang von Git nutzen können, auch wenn
sie den Haupt Server, welcher auch oft als Master bezeichnet wird, nicht erreichen können.
Jeder Nutzer kann also lokal in sein eigenes Repository Änderungen übertragen, welche dann
nach Belieben auf einmal zum Server gesendet werden (man spricht hier von pushen). Auch
ist es möglich, dass zwei oder mehrere Nutzer gegenseitig commits (also Übertragungen)
austauschen,
was
das
kollaborative
Arbeiten
deutlich
erhöht.
Auch wird es so ermöglicht lokal mehrere Zustände (Konfigurationen) der eigenen Arbeit zu
speichern, ohne jeweils den kompletten Ordner kopieren zu müssen. Gerade bei großen
Projekten ist dies sehr hilfreich, da beim Übertragen nur die Zahl der Änderungen von zwei
Konfigurationen untereinander, also die Deltas, gespeichert werden müssen.
Diese Funktionalität fehlt komplett bei SVN. Es ist lediglich möglich nach erledigter Arbeit
die vorgenommenen Änderungen zum Server zu schicken.
Ein weiterer großer Vorteil von Git gegenüber SVN ist die Geschwindigkeit, mit der das
Repository Dateien austauscht. Bei SVN werden Änderungen einzeln und nacheinander
übertragen. Dies ist gerade bei sehr vielen Dateien, oder bei extrem großen Dateien sehr
zeitaufwendig. Git hat aufgrund dieses Problems eine komprimierte Übertragung eingeführt,
welche die Geschwindigkeit deutlich erhöht. In einem ersten Schritt werden dabei die
Unterschiede zwischen dem Zustand der lokal vorliegenden, sowie des entfernten Repositorys
komprimiert und gemeinsam als ein einziger Stream über das Netzwerk versandt. Gerade
Projekte, welche aus Dateien bestehen, bei denen sich hohe Kompressionsraten erzielen
lassen profitieren deutlich von diesem Feature.
Bei der Einrichtung und Wartung sind die Unterschiede nicht sonderlich groß. Beide Systeme
lassen sich entweder als Teil eines Apache Servers laufen lassen, was den Vorteil mitbringt,
dass ein ausgereiftes Sicherheitsmanagement (z.B. htaccess) genutzt werden kann, sowie ein
sehr performanter Server existiert, welcher auch eine große Zahl an Zugriffen verarbeiten
kann. Alternativ lässt sich auch für beide Systeme eine Authentifikation über SSH
3
ermöglichen, welche das Unix Rechte Management nutzt. Dabei werden auf einem beliebigen
Unix artigem Betriebssystem normal Nutzer angelegt und einer gemeinsamen Nutzergruppe
zugewiesen. Das SVN oder Git Repository befindet sich dann ein einem normalen Ordner im
Verzeichnissystem und die komplette Kommunikation erfolgt danach über SSH. Ein eigener
Prozess für einen Server muss nicht mehr laufen. Aufgrund des geringeren
Wartungsaufwands haben wir uns für diese Lösung entschieden, da die Zahl der
Gruppenmitglieder mit sechs Personen doch eher überschaubar ist und eine hochperformante
Lösung nicht zu den Anforderungen gehört.
Für beide Systeme gibt es eine unterschiedlich gute Integration in die verbreiteten IDEs, was
sicherlich historische Gründe hat. So begann die Entwicklung von Git erst 2005 durch Linus
Torvalds, SVN hingegen existiert schon seit 2000 und erreichte ein Jahr vor dem Beginn der
Entwicklung Gits die Version 1.0. Zudem ist SVN eine quasi Weiterentwicklung des
Concurrent Versiosn System (CVS), welches seit 1989 entwickelt wird und als
Weiterentwicklung des Revisions Control Systems (RCS, seit 1982) gilt. Während SVN auf
weit verbreiteter Software basiert und Konzepte benutzt, die seit Jahrzenten in der Praxis
bewährt sind, ist Git erst seit einigen Jahren dabei Verbreitung zu finden. Es konnten leider
Keine Zahlen zur aktuellen Verbreitung gefunden werden, bei denen Angaben zur
eingesetzten wissenschaftlichen Methodik gemacht wurden, mit welcher diese erhoben
wurden, bzw. die einem Review Verfahren unterlagen und damit wissenschaftlichen
Ansprüchen genügen.4
Beide Systeme bieten zudem noch die Möglichkeit von Pre- und Post-commit Hooks, auf
welche im Folgenden noch näher eingegangen wird.
2.2 Hooks
Ein Hook ist ein Programm oder Skript, welches durch ein Event, welches im Repository
ausgelöst wird ausgeführt wird. Wichtig ist dabei vor allem der Post-commit Hook, welcher
nachdem Dateien in das Repository übertragen wurden ausgelöst wird. Dieser Hook kann für
verschiedenste Aufgaben genutzt werden, so müssen zum Beispiel die Meisten Groupware
Systeme und Bug Tracker, welcher oftmals eine nahezu nahtlose Integration in
Versionskontrollsysteme haben (oder umgekehrt) über Änderungen benachrichtigt werden.
Oder es können automatisch Emails versandt werden, nachdem bestimmte Änderungen
vorgenommen wurden.
Die Einrichtung eines solchen Hooks ist bei beiden betrachteten Systemen recht einfach
gehalten. Es gibt jeweils einen Ordner, in welchem die Programme, bzw. Skripte kopiert
werden. Diese müssen lediglich eine Konvention hinsichtlich des Dateinamens erfüllen (z.B.
pre-commit.sh) und die notwendigen Dateirechte haben (unter Unixoiden Systemen vor allem
das +x Flag). Relevante Daten werden diesen Skripten dann automatisch per Startargument
durch das jeweils verwendete System übergeben. Eine weitere Konfiguration ist nicht
notwendig, was einen sehr positiven Eindruck bei beiden Systemen hinterlassen hat.
4
Deshalb sei hier lediglich in einer Fußnote erwähnt, das in (Hammon, 2010) SVN mit einem Marktanteil von
33,4% auf dem ersten Platz gesehen wird, gefolgt von Microsoft VSS mit 12,5%. Git wurde auf dem siebten
Platz mit 2,7% gelistet. Auffallend ist die große Zahl kommerzieller Systeme unter den Top 10.
4
2.2.1 Verwendete Hooks
Als einziger Hooks ist momentan ein Post-commit Hook aktiviert, welche von der
eingesetzten Groupware benötigt wird. Diese bietet dann die Möglichkeit weitere Features,
wie das bereits erwähnte Versenden von Emails nach Dateiänderungen nach Belieben und
komfortabel zu konfigurieren.
Ein weiterer Post-commit hook, welcher automatisch Unit Tests ausführt ist in dem aktuellen
Projektstadium leider noch nicht integrierbar, allerdings geplant, sofern eine Testumgebung
beschlossen wird.
2.3 Entscheidung
Nach Abwägung aller Vor- und Nachteile haben wir uns letztlich für den Einsatz von Git
entschieden. Gerade der verteilte Ansatz verspricht die Produktivität deutlich zu erhöhen.
Auch die Möglichkeit lokal ein Repository zu benutzen, in welchem verschiedene
Konfigurationen des Projektes bei der Arbeit gespeichert werden können, und zwar ohne das
jedes Mal eine Änderung auf den Remote Server geschrieben werden muss, ist etwas das
eindeutig ein deutlich effizienteres Arbeiten verspricht, als es Subversion bietet.
Auch sind die Erfahrungen in der Gruppe mit Git überaus positiv, auch wenn noch nicht alle
dieses System kennen und bereits Erfahrungen damit sammeln konnten.
3 Projektmanagement Tools
Das Projektmanagement ist dazu da, um die vorhandene Arbeit so auf die einzelnen
Teilnehmer zu verteilen, dass die Effizienz maximiert wird und die Prozessverluste minimiert
werden. Auch ist es wichtig Aufgaben zu priorisieren, da keine unbegrenzten Ressourcen zur
Verfügung stehen.
Die Informationsfunktion bezeichnet alle Aufgaben, die zur Information und Kommunikation
gehören. In Projekten ist es im Rahmen der Business Intelligence wichtig über geeignete
Informationssysteme zu verfügen, die durch einen hohen Integrationsgrad die
Informationsfunktion gut und geeignet abbilden und vor allem repräsentieren. "Business
Intelligence umfasst Verfahren, Methoden und Werkzeuge, um entscheidungs- und
analyserelevante Daten aus unternehmensinternen und -externen Quellen zu integrieren und
für Analysezwecke optimiert aufzubereiten." (Gronau, 2010, S. 306)
Es ist wünschenswert ein System zu finden, dass dieser Aufgabe gewachsen ist.
3.1 Übersicht
Für den Einsatz in Softwareprojekten existieren mehrere, teilweise frei verfügbare
Programme, welche häufig als sogenannte Issue-Tracking-Systeme bezeichnet werden. Diese
Systeme bieten in der Regel eine Funktionalität um Aufgaben, Anfragen und ggf. Bugs als
"Tickets" zu speichern. Diese Tickets können dann in Kategorialen eingeteilt werden und im
simpelsten Fall an eine oder mehrere Personen zur Bearbeitung gegeben werden. Wir haben
früh beschlossen, dass alle erfolgreich identifizierten Aufgaben als Ticket gespeichert werden,
damit der Soll Zustand des Systems jederzeit abrufbar ist. Sobald eine Aufgabe erledigt
wurde, kann dieses in dem Entsprechenden Ticket vermerkt werden und dieses wird
5
aktualisiert und evtl. geschlossen. Durch automatisierte Benachrichtigungsfunktionen erhalten
zudem alle Gruppenmitglieder eine Email, welche über den geänderten Ist Zustand informiert.
3.2 Vergleich von Issue-Tracking und Projektmanagement Systemen
In der Gruppe existieren einige Vorerfahrungen mit dem System Trac von Edgewall Software
(Edgewall Software, 2011), die teilweise nicht nur positiv waren. Erfahrungen mit andren
Systemen existieren nicht. Nach einem anfänglichen groben Vergleich werden mehrere
Systeme verglichen um das geeignetste System zu finden. Die meisten Systeme bieten
Funktionalitäten an, die eigentlich nicht zu einem Issue-Tracking-System gehören (z.B.
Wikis), der Einfachheit halber wird im Folgenden allerdings weiterhin von Issue-TrackingSystemen gesprochen.
3.2.1 Trac
Bei Trac handelt es sich um eine Web basierte Applikation, welche in Python geschrieben ist.
Trac kann dabei entweder per WSGI, mod python, CGI oder FastCGI in einen bestehenden
Webserver eingebunden werden, oder falls dieser nicht vorhanden ist, bzw. der administrative
Aufwand für den Betrieb eines Servers zu hoch erscheint als eigener Prozess gestartet werden.
Der mitgelieferte Webserver lässt sich vergleichsweise einfach starten, es gibt jedoch einen
teilweise spürbaren Geschwindigkeitsnachteil. Die Konfiguration ist zudem überaus
kompliziert, fehleranfällig und zeitaufwendig.
Trac steht momentan in der Version 0.13, ist seit 2006 in der Entwicklung und steht zur Zeit
unter einer modifizierten BSD Lizenz.
Die zentralen Features sind ein Ticket System, welches allerdings nicht ermöglicht einzelnen
Tickets weitere Tickets als Unterticket zuzuweisen. Zudem existiert ein Wiki, welches eine
sehr simple Syntax verwendet (Moin Moin, 2011). Es gibt zudem noch viele verschiedene
Ansichten. Darunter befinden sich Ansichten, die die letzten Änderungen anzeigen, oder
Ansichten für geplante Features u.Ä.. Teilweise wirken diese allerdings vergleichsweise
unübersichtlich und überladen.
Eine Integration von Subversion ist zudem fehlerlos nutzbar, eine Git Integration ist zur Zeit
allerdings nicht ohne weiteres möglich.
Trac lässt sich durch seinen modularen Aufbau per Plugins erweitern, was allerdings häufig
vielerlei Probleme mit sich bringt. Die Plugins setzen teilweise sehr spezifische Versionen
voraus und erfordern mitunter einen hohen administrativen Aufwand.
Positiv ist die Stabilität. Nach persönlichen Erfahrungen ist es in zwei Jahren Dauerbetrieb,
lediglich unterbrochen von Reboots des kompletten Servers, nicht einmal zu einem Absturz
gekommen.
3.2.2 Retrospectiva
Retrospectiva (Retrospectiva, 2011) ist ein Open-Source Projekt, welches einen sehr
aufgeräumten und übersichtlichen Eindruck macht. Es handelt sich ebenfalls um eine Web
Anwendung und setzt eine eigens zu administrierende Datenbank, wie z.B. MySql voraus. Ein
eigener Webserver wird mitgeliefert und das gesamte Projekt ist in Ruby implementiert. Das
Ticket System macht einen übersichtlichen Eindruck und sehr positiv ist die Git Integration,
6
welche ohne Plugins auskommt und selbst zu den beworbenen Core Features gehört. Die
Weiterentwicklung des Projekts wird mit sich selbst verwaltet und geplant. Dabei wird Git als
Versionskontrollsystem eingesetzt. Es ist also anzunehmen, dass dieses Feature nicht plötzlich
seine Funktion einstellt (wie bei Git Plugins für Trac geschehen).
Meilensteine können verwaltet werden und über Plugins können Features wie ein Blog und
ein Wiki zugefügt werden. Auch agile Softwareentwicklung wird unterstützt, so gibt es zum
Beispiel Möglichkeiten einen Scrum Sprint komplett in Retrospektiva zu verwalten.
Die Administration erfolgt ebenfalls komplett über ein Web Frontend, welches ebenfalls
aufgeräumt und übersichtlich ist.
Trotz der sehr positiv wirkenden Feature Liste und dem übersichtlichen Interface ist der
Einsatz in Produktiv Umgebungen allerdings momentan nicht ratsam. Im eigenen Bug
Tracker häufen sich die Einträge von Usern, welche Tickets erstellt haben um Bugs zu
melden, und in vielen Fällen wird nicht geantwortet. So gab es bei der ersten Test Installation
Probleme durch einen Bug und auch nach über einem Monat ist das Ticket noch nicht
beantwortet wurden (Retrospectiva, 2011). Der letzte Blog Eintrag liegt auch schon lange
zurück und anscheinend ist das Projekt aufgrund mangelnder Entwicklung gestorben.
3.2.3 Redmine
Redmine ist eine Web Applikation, die in Ruby geschrieben ist und Rails verwendet. Es
macht einen sehr übersichtlichen Eindruck, ist seit 2006 in Entwicklung und unter der GNU
GPL v2 Lizenz veröffentlicht. Eine eigene Datenbank, in unserem Fall MySQL muss jedoch
manuell installiert werden.
Es gibt eine große Zahl an Features, die ohne Plugins auskommen. Das Ticket System
ermöglicht sogar das erstellen von Untertickets, was eine sehr flexible Aufgabenverteilung
ermöglicht. Die Aufgaben können in Gant-Diagrammen visualisiert werden.
Besonders positiv ist die Wandlungsfähigkeit einzelner Ansichten. So ist es möglich nahezu
jede Seite zu verändern und weitere Eingabefelder zuzufügen. So lässt sich z.B. in der
Nutzerübersicht ein weiteres Feld mit einem Eintrag für einen Jabber Account zufügen. Diese
Felder sind dabei beliebig und müssen nicht aus vorgefertigten Listen ausgewählt werden.
Alle Ereignisse im System lassen sich so konfigurieren, dass sie automatisch Emails
versenden, ähnlich wie post-commit Hooks. Eine Integration von Git und SVN ist problemlos
möglich, auch wenn ein Bug momentan verhindert, dass in den Beschreibungen einer
Übertragung direkt die Ticket Nummer des zugehörigen Tickets angegeben werden kann.
Ein Forum und ein Wiki sind ebenfalls enthalten und lassen sich in der Konfigurationsansicht
an und aus schalten.
Redmine wird von sehr vielen großen Projekten eingesetzt, darunter Ruby, Typo3 und KDE.
3.3 Entscheidung
Alles in allem macht Redmine den robustesten Eindruck. Die von Haus aus unterstützten
Features sind wirklich beeindruckend und der Administrationsaufwand ist sehr gering.
7
Nachdem das System einmal läuft kann alles Weitere bequem per Web Frontend administriert
werden.
Auch die Git Integration ist ein ausschlaggebender Punkt gewesen, die wir uns bereits in
einem frühen Projektabschnitt für Git entschieden hatten. Trac ist hinsichtlich Git leider nicht
kompatibel und fällt damit raus. Retrospektiva ist wie bereits erwähnt für einen Produktiven
Einsatz momentan ungeeignet und es bleibt abzuwarten ob es weiterentwickelt wird. Gerade
in Sachen Bedienbarkeit hat es Trac einiges voraus und die Git Integration ist ebenfalls ein
großes Pluspunkt.
Letztlich fiel die Entscheidung zugunsten von Redmine.
4 Build Management
Im Rahmen dieses Kapitels möchte ich den automatisierten Prozess beschreiben, mit dem das
letztlich resultierende Projekt erstellt wird.
Momentan wird höchstwahrscheinlich C++ als Programmiersprache verwendet. Für diese gibt
es verschiedene Tools, welche das automatisierte Erstellen des resultierenden Programes aus
dem Quellcode ermöglichen. Das bekannteste ist sicherlich make. Weitere bekannte Vertreter
sind noch CMake und Automake. Da viele der bis jetzt im Rahmen des Projektes untersuchte
Libraries CMake verwenden, wird dieses im Folgenden genauer betrachtet.
4.1 CMake Einleitung
CMake (CMake, 2011) ist ein Open Source Programm, welches von Kitware entwickelt wird.
Entstanden ist das Projekt im Jahr 1999, die eigentliche Entwicklung startete jedoch erst im
Jahr 2000 und seit dem in Entwicklung. Das besondere an CMake ist, dass es sich um ein
plattformunabhängiges Tool handelt und auch mit Hilfe von cross Compiling für
verschiedene Plattformen das resultierende Programm erstellt werden kann. Dies ermöglicht
einem Programmierer unabhängig vom Betriebssystem zu entwickeln.
CMake erstellt dazu mit Hilfe einer Datei namens CMakeLists.txt, welche für jedes Projekt
erstellt werden muss, das eigentliche resultierende Makefile. Dieses kann für die wichtigsten
Plattformen und IDEs erstellt werden. CMake ist sozusagen ein Meta Build Tool.
4.2 Beispiel
Im Folgenden soll die Funktionsweise anhand eines Beispiels verdeutlicht werden. Gegeben
sei folgendes C++ Programm, welches in der Datei hallo.cpp gespeichert ist.
#include <iostream>
#include <ostream>
int main()
{
std::cout << "Hallo Welt!" << std::endl;
}
8
Zudem wird im selben Ordner eine CMakeLists.txt erstellt, welche folgenden Inhalt hat:
Dies ist schon das komplette CMake Makefile. Durch den Aufruf von "cmake .." aus einem
cmake_minimum_required(VERSION 2.6)
project(hallo)
add_executable(hallo hallo.cpp)
beliebigen Unterordner heraus wird dann das eigentliche Makefile erstellt. Durch den Aufruf
von "make" wird dann eine Ausführbare Datei namens "hallo" erstellt.
Die Syntax ist dabei sehr simpel. mit cmake_minimum_required(VERSION 2.6) wird
angegeben, welche minimale CMake Version vorhanden sein muss. Der Projektname wird
dabei in Zeile zwei festgelegt und in der letzten Zeile wird der Name der Ausführbaren Datei,
sowie die Datei mit der main Funktion definiert. Befehlen in CMake können Argumente in
der Form cmake_minimum_required(Arg1 Arg2 ...) übergeben werden.
Dies ist ein minimales Beispiel und verdeutlicht gut die Funktionsweise von CMake,
allerdings nicht einmal ansatzweise den kompletten Funktionsumfang.
4.3 Weitere Funktionen
CMake bietet zudem weitere Funktionen, darunter das setzen und speichern von Variablen
mit SET(VARIABLE VALUE), sowie logische Operationen mit if(A AND B) [...]. In
Kombination mit Möglichkeiten das Betriebssystem abzufragen lassen sich individuelle
Skripte für verschiedene Plattformen erzeugen. Dies ist vor allem beim Einbinden von
weiteren Libraries sinnvoll, welche oftmals nur als Binärdateien ausgeliefert werden.
Weitere Ordner können mit INCLUDE_DIRECTORIES(/some/directory) angegeben
werden. Libraries können über das find_library sowie target_link_libraries
Kommando referenziert werden.
Die meisten Features können in recht kurzer Zeit umgesetzt werden. Hilfreich ist dabei das
sehr ausführliche Wiki5.
4.4 Integration in das Projekt
Zum aktuellen Zeitpunkt stehen immer noch wichtige Entscheidungen aus, welche für ein
fertiges Build Skript absolut notwendig sind. So ist zum Beispiel noch nicht klar, ob die
Ogre3D Engine, oder die Irrlicht Engine eingesetzt werden wird.
Beide Engines lassen sich mit CMake bauen, bzw. setzen dieses sogar voraus. Es gibt jedoch
sehr gute Beispiele und es sollte relativ schnell gehen ein fertiges Build Script zu erstellen.
5
http://www.cmake.org/Wiki/CMake, zuletzt aufgerufen am 30.05.2011
9
5 Fazit
Das im Rahmen des Projektes entstandene Konfigurationsmanagement ist vielen Aufgaben
gewachsen und bindet vor allem wenige der ohnehin begrenzten Humanressourcen. Es wurde
vor allem darauf geachtet, ein stabiles System zu erschaffen, welches von allen
Gruppenmitgliedern problemlos genutzt werden kann.
Am aufwendigsten war die Einrichtung der verschiedenen Projektmanagement Tools, was
dazu geführt hat, dass das gesamte Konfigurationsmangement jetzt auf einem eigenen Server
läuft da die Integration in einen bestehenden Server mit Mehrbenutzerbetrieb, welcher von der
Uni Oldenburg bereitgestellt worden war nicht problemlos ablief. Mit Redmine konnte jedoch
ein System gefunden werden, dass allen Anforderungen mehr als gerecht wird.
10
6 Literaturverzeichnis
Angermeier, D. G. (3. Februar 2004). ProjektMagazin. Abgerufen am 25. Mai 2011 von
http://www.projektmagazin.de//glossarterm/konfigurationsmanagement
Braun, R. (2009). Referenzmodellierung. Münster: Logos Verlag Berlin GmbH.
CMake. (29. 05 2011). Abgerufen am 29. 05 2011 von http://www.cmake.org/
Edgewall Software. (26.
http://trac.edgewall.org
05
2011).
Trac.
Abgerufen
am
26.
05
2011
von
Gronau, P. D. (2010). Enterprise Resource Management (2. Auflage Ausg.). München:
Oldenbourg Wissenschafts Verlag.
Hammon, J. (26. Janur 2010). Forrester Databyte: SCM Tool Adoption. Abgerufen am 27.
Mai 2011 von http://blogs.forrester.com/application_development/2010/01/forrester-databytedeveloper-scm-tool-adoption-and-use.html
Hasselbring, P. D. (2007). Modul Sofware Engineeing (Skript). Oldenburg.
Moin Moin. (2011). Abgerufen am 26. 05 2011 von http://mainmo.in
Retrospectiva. (26. 05 2011). Abgerufen am 26. 05 2011 von http://retrospectiva.org/
Retrospectiva. (2011). Abgerufen am 26. 05 2011 von http://retrospectiva.org/tickets/889
Versteegen, G., & Weischedel, G. (2003). Konfigurationsmanagement. Heidelberg: Springer.
11
Seminararbeit
Präsenzempnden in virtuellen
Umgebungen
Erstellt von:
Studienbereich:
Professor:
Tutor:
Jendrik Poloczek
Informatik
Prof. Dr. Wolfgang Kowalk
Dieses Werk einschlieÿlich seiner Teile ist urheberrechtlich geschützt. Jede Verwertung auÿerhalb der engen Grenzen des Urheberrechtgesetzes ist ohne Zustimmung
des Autors unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen,
Übersetzungen, Mikroverlmungen sowie die Einspeicherung und Verarbeitung in
elektronischen Systemen.
Inhaltsverzeichnis
1 Einleitung
1
2 Grundlagen
2
2.1
Historie virtueller Umgebungen
. . . . . . . . . . . . . . . . . .
3
2.2
Anwendungsgebiete virtueller Umgebungen . . . . . . . . . . . .
4
2.3
Technische Realisierung virtueller Umgebungen
. . . . . . . . .
5
2.4
Projektziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
3 Präsenzforschung
7
3.1
Wahrnehmungsprozess
. . . . . . . . . . . . . . . . . . . . . . .
8
3.2
Virtueller Körper
. . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.3
Präsenzempnden . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.4
Räumliche Präsenz
. . . . . . . . . . . . . . . . . . . . . . . . .
11
3.5
Soziale Präsenz
. . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.6
Eigenwahrnehmung . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.7
Sensomotorische Koordination . . . . . . . . . . . . . . . . . . .
15
4 Projektbezogene Untersuchung
4.1
Räumliche Präsenz
4.2
Soziale Präsenz
15
. . . . . . . . . . . . . . . . . . . . . . . . .
16
. . . . . . . . . . . . . . . . . . . . . . . . . . .
17
4.3
Eigenwahrnehmung . . . . . . . . . . . . . . . . . . . . . . . . .
17
4.4
Virtuelle Umgebung für das Präsenzempnden . . . . . . . . . .
18
5 Zusammenfassung
18
6 Ausblick
20
21
I
Motivation
Die vorliegende Arbeit wurde im Rahmen der Projektgruppe Virtual Reality
im Fachbereich Informatik im Sommersemester 2010/2011 an der Carl-vonOssietzky Universität Oldenburg verfasst. Prof. Dr. Wolfgang Kowalk leitet
die Projektgruppe. Die Projektgruppe bietet den Studenten den Erwerb praxisnaher Erfahrungen bei der selbständigen Bearbeitung forschungsorientierter
Projekte.
Die Projektgruppe Virtual Reality befasst sich mit dem Entwurf eines VirtualReality-Systems mit dem es möglich ist in virtuelle Umgebungen einzutauchen. Dabei sind folgende Aspekte unter anderen als besonders bedeutsam
für das Gefühl der Präsenz in der virtuellen Umgebung eingestuft worden:
Übertragung der Körperbewegung des Benutzers, einschlieÿlich Blickrichtung,
auf einen virtuellen Körper, Interaktion mit der Umgebung, eine Kollisionserkennung zwischen dem Benutzer und Gegenständen in der Umwelt und eine
authentische Klanguntermalung.
Die Einstufung dieser Aspekte ist jedoch nur eine Annahme. Ausgehend von
der Frage, ob die genannten Elemente zu einem Gefühl von Präsenz in der virtuellen Umgebung führen, wird im Folgenden eine genauere Auseinandersetzung mit der interdisziplinären Thematik der Präsenzempndung in virtuellen
Umgebungen dargeboten. Es wird dabei ferner untersucht, welche Faktoren
für das Gefühl des Eintauchens in eine virtuelle Umgebung relevant sind
und wie sich dieses Gefühl intensivieren lässt. Mithilfe dieser Untersuchung
kann die Projektzielsetzung hinsichtlich des Präsenzempndens analysiert und
verbessert werden.
1
1 Einleitung
Die vorliegende Arbeit setzt sich mit dem Präsenzempnden in virtuellen Umgebungen auseinander. Es wurden dabei folgende Fragen motiviert: Welche
Faktoren sind für die Präsenzempndung relevant?, Wie lässt sich die Präsenzempndung intensivieren? und Wie hoch ist das Präsenzempnden des
Projekts auf Basis der Zielsetzung einzuschätzen?. Zur Beantwortung der Fragen wird ausgehend von einem Grundlagenkapitel, die erste Frage im Kapitel
Präsenzforschung (siehe Kapitel 3) beantwortet. Der zweiten und dritten
Frage ist das Kapitel Projektbezogene Untersuchung (siehe Kapitel 4) gewidmet.
Im Grundlagenkapitel werden die Historie der virtuellen Realtität (siehe Abschnitt 2.1, ab hier: VR), die Anwendungsgebiete der VR (siehe Abschnitt 2.2),
die technische Realisierung der VR (siehe Abschnitt 2.3) und das Projektziel
(siehe Abschnitt 2.4) erläutert. Nachfolgend wird der Wahrnehmungsprozess
des Menschen (siehe Abschnitt 3.1) und die Beziehung zwischen dem physischen, dem virtuellen Körper und der virtueller Umgebung untersucht (siehe
Abschnitt 3.2). Diese zwei Abschnitte bilden den Einstieg in die Präsenzforschung. Im Anschluss wird der Begri Präsenzempndung auseinandergenommen und in relevante Teilkomponenten zerlegt (siehe Abschnitt 3.3). Mithilfe der gewonnenen Erkenntnisse wird die Zielsetzung des zu entwerfenden
VR-Systems auf das Präsenzempnden hin untersucht (siehe Kapitel 4) und
eine virtuelle Umgebung skizziert, die das Präsenzempnden im Rahmen der
Projektzielsetzung intensiviert (siehe Abschnitt 4.4). Am Schluss wird die vorliegende Arbeit zusammengefasst (siehe Kapitel 5) und ein Ausblick gegeben
(siehe Kapitel 6).
2
Seminararbeit
Präsenzempnden in virtuellen Umgebungen
2 Grundlagen
2 Grundlagen
Im folgenden Kapitel werden die Grundlagen von VR-Systemen vermittelt.
Dieses Wissen wird für die Untersuchung des Präsenzempndens benötigt. Es
wird zunächst die Historie von VR beleuchtet. Anschlieÿend werden die Anwendungsgebiete dargestellt. Danach folgt eine Einführung in die technische
Realisierung von VR-Systemen und am Schluss werden die Anforderungen und
Rahmenbedingungen des Projektziels erläutert.
2.1 Historie virtueller Umgebungen
Die Idee der VR ist seit Kindertagen der Mikrocomputer ein Thema in der Literatur. In dem bereits 1964 erschienenem Sciencection Roman Simulacron-3
von Daniel Francis Galouye wird die Geschichte eines Informatikers erzählt,
der an einem Simulationscomputer arbeitet. Der Computer simuliert eine Kopie der Stadt in der er wohnt. Ein ungewöhnlicher Todesfall in seinem Unternehmen veranlasst ihn in die virtuelle Stadt einzutauchen um den Mord
aufzudecken. Dieser Roman wurde zweimal verlmt und inspirierte Schriftsteller und Drehbuch-Autoren der folgenden Jahre.
Im Jahr 1965 wurde von Sutherland erstmals eine wissenschaftliche Veröffentlichung in Bezug auf die technologische Umsetzung von VR gemacht (vgl.
Sutherland [1965]). Der Begri Display (zu deutsch: Bildschirm) wird dabei als medialer Vermittler für die audiovisuellen Reize benutzt. Er beschreibt,
dass in Verbindung mit einem Computer die Chance ensteht nicht realisierbare
Konzepte der physikalischen Welt virtuell zu erproben.
Später, im Jahre 1968, folgte die erste Umsetzung mit einem sogenannten
stereoskopischen Head-Mounted-Display (ab hier: HMD) und einem Sensor,
der die Lage des Kopfes misst (vgl. Sutherland [1968]). Das HMD, seinerzeit als
Helm entworfen, besitzt typischerweise zwei eingebaute Bildschirme für visuelle
Reize, mit denen Stereoskopie möglich ist, und einen Kopfhörer für akustische
Reize. Dabei erlaubt die Stereoskopie dem Benutzer die gewöhnliche optische
Tiefe auch in der virtuellen Welt wahrzunehmen.
3
Seminararbeit
2 Grundlagen
2.2 Anwendungsgebiete virtueller
Umgebungen
In den folgenden Jahren wurde das Konzept der VR in verschiedenen Anwendungsgebieten erprobt. Die Anwendungen lassen sich in die Bereiche Bildung,
Psychologie, Konferenzen, Prototyping, Marketing und Unterhaltung einordnen. In Bezug auf die Bildung können beispielsweise Gebäude und Konstruktionen mithilfe von VR-Systemen unabhängig von dem realen Standort des
Gebäudes oder Existenz der Konstruktion studiert werden (vgl. Kahkonen u.
Whyte [2003]). Diese Möglichkeit unterstreicht zudem den Vorteil der VR im
Bereich der Produkt Prototyping (vgl. Sá u. Zachmann [1998]).
Ferner bietet sich das VR-System für virtuelle Labore an. Zweck dieser Labore
ist das Erlernen des Umgangs mit Apparaturen, die Durchführung von Experimenten und eine Erlangung von Wissen (vgl. Hoyer u. a. [2004]). Weitere
Anwendungen in denen Fachwissen vermittelt wird, sind das virtuelle Cockpit
(vgl. Bauer [2010]) und der virtuelle chirugische Eingri (vgl. Moraes u. a.).
Oensichtlich ist, dass eine Simulation zum Training von risikobehafteten Gefahrensituationen für den Menschen zum Training einen signikaten Vorteil
bietet.
Weitere Anwendungen des VR-Systems sind im Bereich der Psychologie angesiedelt. Forschungsprojekte der Psychologie untersuchen die Reaktion und
den Zustand des Probanden in bestimmten medial vermittelten Situationen.
Ein Beispiel dafür ist die Untersuchung von Paranoia in einer Population (vgl.
Freeman u. a. [2008]). Darüber hinaus werden VR-Systeme zur Therapierung
von Essstörungen, beispielsweise Magersucht, und Angststörungen, beispielsweise Phobien, verwendet (vgl. Gorini u. Riva [2008], Bush [2008]).
4
Seminararbeit
2 Grundlagen
2.3 Technische Realisierung virtueller
Umgebungen
Die technische Realisierung eines VR-Systems lässt sich in zwei Teilkomponenten zerlegen: Software- und Handwarekomponente. Es existieren verschiedene
Softwareimplementierungen für den Entwurf von virtuellen Umgebungen (vgl.
Backman [2005], Lennerz u. a. [1999]). Wesentliche Kernkomponenten sind dabei die grasche Anzeige, die Modellierung von Umgebungen und Avataren
inklusive Skripting, die Simulation von 3D-Klang und eine Schnittstelle zur
Ansteuerung der Hardwarekomponente.
Die Hardwarekomponente des VR-Systems dient als Benutzungsschnittstelle
zwischen Mensch und Computer. Sie besteht aus Eingabe- sowie Ausgabemöglichkeiten. Eingabemöglichkeiten sind beispielhaft die 3D-Maus oder der sogenannte Datenhandschuh (vgl. Steuer [1992]). Die 3D-Maus kann dabei als
Erweiterung der normalen Computermaus angesehen werden, die zudem die
Position im dreidimensionalen Raum registriert.
Bei dem Datenhandschuh wird die Neigung der gesamten Hand und die Neigung der Gelenke durch Neigesensoren gemessen. Dabei können verschiedene
Freiheitsgrade erreicht werden. Nach dem gleichen Prinzip arbeitet der Datenanzug. Der Messbereich schlieÿt jedoch auch Gliedmaÿen des gesamten Körpers
ein. Da eine Vielzahl an unterschiedlichen Eingabemöglichkeiten existieren sei
auf Bowman u. a. [2008] hingewiesen. In dieser Veröentlichung werden aktuelle 3D-Eingabemethoden untersucht. Im Folgenden werden die bekanntesten
Ausgabemöglichkeiten von VR-Systemen vorgestellt.
Das HMD stellt ein wesentliches Konzept für frühe VR-Systeme dar (vgl.
Sutherland [1968]). Auch heute dient das HMD als eine wichtige HardwareKomponente bei der Realisierung eines VR-Systems (vgl. And u. a.). Es können
mit dem HMD sowohl akustische als auch visuelle Reize vermittelt werden. Wie
bereits diskutiert, können HMDs stereoskopische Bilder erzeugen, mit denen
es dem Benutzer möglich ist die optische Tiefe wahrzunehmen. Ein integrierter Stereo-Kopfhörer dient zur Wahrnehmung von Geräuschen. Die StereoKopfhörer können dabei eine dreidimensionale Geräuschkulisse emulieren.
5
Seminararbeit
2 Grundlagen
Als Alternative zu dem HMD existieren verschiedene andere Ansätze: Das
CAVE

System ist ein begehbarer Würfel. Der Benutzer benötigt statt einem
HMD eine 3D-Brille. Auf die Wände des Würfels werden Bilder der virtuellen Umgebung projeziert. Der Benutzer hat somit die Möglichkeit sich frei
in dem Würfel zu bewegen. Das Konzept wird in Cruz-neira u. a. [1993] und

Gross u. a. [2003] erläutert. Eine kostengünstige Alternative zum dem CAVE
System ist die Single-Wall-Methode. Statt einen ganzen Raum zu simulieren
wird nur auf
eine
Wand projiziert. Dementsprechend muss der Benutzer zu
der Wand ausgerichtet sein. In Bezug auf kollaboratives Arbeiten gibt es auch
Ansätze mit denen mehrere Benutzer die VR erfahren können. Die sogenannte Holobench ist eine Werkbank-artige Konstruktion, die mithilfe einer 3DProjektionstechnik ein holographisches Bild über der Holobench erzeugt (vgl.
Büscher u. a. [2000]).
Die vorgestellten Systeme konzentrieren sich jediglich auf die audiovisuelle
Reizübermittlung. Mit dem Forschungsprojekt Lemoine u. a. [2004] soll jedoch auch ein System aufgegrien werden, das die Vermittlung von haptischem
Feedback ermöglicht.
2.4 Projektziel
Um eine Untersuchung der Zielsetzung der Projektgruppe VR in Bezug auf
die Präsenzempndung durchführen zu können, muss eine kurze Beschreibung
des Projektziels vornehmlich des technischen Aufbaus erfolgen.
Ziel des Projekts ist es, mithilfe von öentlich erhältlichen Hardwarekomponenten und auf Basis von freier Software ein VR-System zu entwerfen. Dabei
wurde das VR-System in zwei Teilsysteme aufgeteilt: die Middleware und die
Anwendung. Die Middleware soll in der Lage sein Körperbewegungen und Lage
des Kopfes in ein digitales Skelett zu transformieren und Gesten zu erkennen.
Die Anwendung verarbeitet die Eingabedaten, digitales Skelett und Gesten,
und erzeugt auf Basis einer simulierten virtuellen Umgebung die Ausgabedaten, die künstlich erzeugten Reize.
Folgende Anforderungen wurden für das VR-System formuliert: Der Benutzer
soll sich in der virtuellen Umgebung umschauen können. Ferner sollen seine
6
Körperbewegungen wahrgenommen und auf einen virtuellen Körper übertragen werden. Mithilfe des virtuellen Körpers soll der Benutzer in der Lage sein
mit der virtuellen Umgebung zu interagieren. Es wurden dabei besonders das
Präsenzempnden, die Kollionserkennung mit virtuellen Gegenständen und die
3D-Geräuschkulisse hervorgehoben.
Zur Umsetzung dieser Anforderungen wurde das Projektziel auf folgende Eingabeund Ausgabemethoden für die Reizvermittlung festgelegt: Ein stereoskopisches
HMD mit Stereo-Kopfhörer und Lagesensor zur Übertragung von audiovisuellen Reizen und Messung der Lage beziehungsweise Neigung des Kopfes. Für
die Messung von Körperbewegungen und die Erzeugung eines virtuellen Ske-

letts wird die Microsoft Kinect
verwendet. Mithilfe dieser Komponente ist
es möglich Tiefenwerte in einem Raum auszulesen. Durch die Anwendung des
in Shotton u. a. [2011] vorgestellen Algorithmus kann der physische Körper in
Echtzeit in eine digitales Skelett überführt werden.
Anforderungen für die virtuelle Umgebung, die Szenarie, sind jedoch noch nicht
festgelegt. Dies kann als Chance angesehen werden, da die vorgelegte Arbeit die
Faktoren des Präsenzempnden untersucht und die Erkenntnisse dieser Arbeit
in die Anforderungen an die virtuelle Umgebung einieÿen können.
3 Präsenzforschung
Die nachfolgenden zwei Kapitel bilden den Kern der Arbeit. In diesem Kapitel
wird intensiv auf die Thematik der Präsenz eingegangen. Das Präsenzempnden (im englischen: presence) beschreibt den subjektiven Zustand, das Gefühl,
sich in einer medial vermittelten virtuellen Umgebung anwesend zu fühlen.
Biocca beschreibt das Präsenzempnden mit: [Presence is] the illusion of feeling of being there whether there exists in a physical space or not (vgl. Biocca
[1997]). Slater macht deutlich, dass es sich bei der Präsenzempndung um ein
psychisches Phänomen handelt: Presence is a state of consciousness, the (psychological) sense of being in the virtual environment (vgl. Slater u. Wilbur
7
Seminararbeit
3 Präsenzforschung
[1997]). Das Präsenzempnden ist jedoch nicht auf virtuelle Umgebungen zu
beschränken. In Bracken u. Skalski [2010] wird verdeutlicht, dass das Präsenzempnden auch in klassischen Medien wie dem Fernsehen auftaucht. In allen
Medienformen soll laut Bracken u. Skalski [2009] gelten, dass mit gesteigertem
Präsenzempnden die Freude am Medienkonsum steigt.
Auch im relativ jungen Forschungsbereich der Game Studies werden Computerspiele auf die Präsenzempnden hin untersucht (vgl. Pietschmann [2009]).
Die Frage: Was ist Präsenzempnden? lässt sich jedoch nicht leicht beantworten und ist eine der zentralen Frage im Forschungsbereich der VR (vgl. Biocca
[1997]). Um bestehende Modelle zum Präsenzempnden vorzustellen muss zunächst der Wahrnehmungsprozess des Menschen und die Beziehung zwischen
dem physischen, dem virtuellen Körper und der virtuellen Umgebung dargelegt
werden.
3.1 Wahrnehmungsprozess
In Biocca [1997] wird argumentiert, dass alles was die Person wahrnimmt
zunächst, von den Sinnen produziert, in Form von Energie existiert. Mithilfe dieser Information erzeugt der Mensch automatisch und unterbewusst ein
mentales Modell seiner Umgebung. Dabei werden bereits erfahrene Situationen, Bilder im abstrakten Sinne, mit den aufgenommenen Reizen assoziert.
Gibt es Lücken in der Wahrnehmung, so werden diese aus alten Informationen
(Schemata) abgeleitet (vgl. Slater u. a. [2009]). Entspricht ein Schema nicht
der Realität, so muss es angepasst werden. Ein Beispiel soll die Funktionsweise des Wahrnehmungsapperates verdeutlichen: Eine Person steht auf einem
Metallboden. Sie sieht, dass groÿe Felsbrocken in Richtung Boden fallen. Im
Augenblick des Aufschlags hört sie jedoch kein Geräusch. In Slater u. a. [2009]
werden solche Situationen als Breaks in Presence bezeichnet. Die Person verliert das Gefühl in ihrer Welt anwesend, präsent zu sein. Da das mentale Modell
den Bezug zum Wahrgenommenen verliert. Je nach dem wie fest ein Muster in
der Person verankert ist lassen sich Irrtümer kompensieren. Es soll bereits an
dieser Stelle festgehalten werden, dass die Plausibilität der wahrgenommenen
Reize einer der entscheidenen Bedingungen für das Präsenzempnden ist (vgl.
Slater u. a. [2009], Biocca [1997]).
8
Seminararbeit
3 Präsenzforschung
3.2 Virtueller Körper
In Biocca [1997] wird mit dem Begri progressive embodiment die steigende
Tendenz immer engerer Kopplung zwischen Mensch und Benutzungsschnittstelle zum Computer bezeichnet. Eine engere Kopplung zwischen dem Menschen und der Schnittstelle impliziert eine engere Bindung zwischen physischem
und virtuellen Körper.
Der physische Körper stellt mit seinen Sinnen eine Schnittstelle zur der physischen Umgebung dar. Sekuler und Blake bezeichnen die Sinne als communication channels to reality (vgl. Sekuler u. Blake [1994]). In Gegenrichtung spricht
Biocca [1997] von Sinnen als Kanäle zum Verstand. Loomis argumentiert: [all]
Contact with the physical world is mediated (vgl. Loomis [1992]).
Da die Reizwahrnehmung unsere Welt beziehungsweise das mentale Modell
formt, lässt sich unsere Welt durch künstlich erzeugte Reize beliebig denieren. In diesem Zusammenhang spricht Biocca [1997] von der physischen Transzendenz: Der Mensch kann unabhängig von seiner physischen Verkörperung
an beliebigen Orten existieren. Laut Biocca [1997] existiert seit der Antike
der Wunsch nach physischer Transzendenz. Deutlich wird dieser Wunsch in
Sutherland [1965]:
A display connected to a digital computer gives us a chance to
gain familiarity with concepts not realizable in the physical world.
It is a looking glass into a mathematical wonderland.
Der virtuelle Körper ist dabei nicht nur ein Avatar mit dem sich der Benutzer
identiziert, wie beispielsweise in Computerspielen. Sondern in Analogie zu
unserem physischen Körper und der physischen Welt eine Schnittstelle, mit
der die virtuelle Umgebung wahrgenommen wird (vgl. Biocca [1997]). Loomis
argumentiert, dass aus Sicht des Benutzers der virtuelle Körper zu ihm gehört
und das er gleichzeitig die Trennschicht zwischen dem
Sein
und der virtuellen
Umgebung ist (vgl. Loomis [1992]).
9
Seminararbeit
3 Präsenzforschung
Präsenzempﬁnden
räumliche Präsenz
soziale Präsenz
Eigenwahrnehmung
Abbildung 3.1: Aufspaltung des Präsenzempndens
3.3 Präsenzempnden
Das Präsenzempnden wurde bisher abstrakt als ein psychologischer Zustand
beziehungsweise als ein Gefühl deniert sich an einem Ort präsent zu fühlen
(vgl. Abschnitt 3). Ferner wurde im Abschnitt 3.2 der Zusammenhang zwischen
dem Wahrnehmungsprozess und der Modellbildung dargelegt. Bereits an dieser
Stelle wurde eine wichtige Komponente für das Präsenzempnden hervorgehoben: Plausibilität. Im darauf folgendem Abschnitt 3.2 wurde auf den virtuellen
Körper als Schnittstelle zur virtuellen Umgebungen eingegangen. Mit diesen
grundlegenden Erkenntnissen werden in den folgenden Abschnitten die Modelle
von Lombard u. Ditton [1997] und Biocca [1997] vorgestellt.
Laut der Arbeit Pietschmann [2009], die verschiedene empirische und theoretische Arbeiten unter anderem Lombard u. Ditton [1997] und Biocca [1997]
zusammenfasst, lässt sich das Gesamtkonzept des Präsenzempndens in Teilbereiche aufspalten (vgl. Abbildung 3.1): räumliche Präsenz, auch physische
Präsenz genannt, soziale Präsenz und die Eigenwahrnehmung (im Orginal:
Spatial Presence, Social Presence und Self-Presence). Die räumliche Präsenz
beschreibt dabei die Illusion, sich in einem virtuellen Raum aufzuhalten. Die
soziale Präsenz umfasst die Empndung sich mit einer oder mehreren medial vermittelten Personen oder künstlichen Avataren zusammen an einem Ort
zu sein. Mit der Eigenwahrnehmung, auch als Selbstwahrnehmung bezeichnet,
wird ein Zustand beschrieben, in dem der Benutzer seinen virtuellen Körper
so wahrnimmt, als sei dieser sein reales Selbst (vgl. Pietschmann [2009]).
10
Seminararbeit
3 Präsenzforschung
Räumliche Präsenz
Lebendigkeit
Interaktivität
Abbildung 3.2: Aufspaltung der räumlichen Präsenz
3.4 Räumliche Präsenz
Die räumliche Präsenz wird durch technische Merkmale wie Lebendigkeit
(im Orginal: vividness) und Interaktivität deniert (vgl. Abbildung 3.2). Der
Begri Lebendigkeit beschreibt dabei die technische Möglichkeit eine sensorisch reichhaltige virtuelle Umgebung zu erzeugen (vgl. Steuer [1992]). Die
Lebendigkeit wird durch die Terme Breite und Tiefe deniert. Die Breite
der Lebendigkeit beschreibt die Anzahl simultaner Sinneskanälen, während die
Tiefe die Auösung der einzelnen Sinneskanäle beschreibt (vgl. Pietschmann
[2009]).
Beispielsweise erzeugt ein Telefon akustische Reize niedriger Auösung und ist
folglich schmal und ach im Sinne der Lebendigkeit. Eine virtuelle Umgebung
hingegen bietet hochauösende audiovisuelle Reize und möglicherweise haptisches Feedback an. Sie ist dementsprechend in Bezug auf die Lebendigkeit
breit und tief. Biocca beschreibt mit dem Begri sensory engagement ein
Maÿ, das die Quantität und Qualität von nicht-medial vermittelten Reizen der
physischen Umgebung mit medial-vermittelten Reizen in Beziehung setzt (vgl.
Biocca [1997]).
Der Begri Interaktivität bezieht sich auf die Möglichkeit eines Benutzers
die virtuelle Umgebung zu beinussen. Laut Steuer [1992] ist die Interaktivität
abhängig von Geschwindigkeit, Reichweite und Zuordnung.
Der Faktor Geschwindigkeit beschreibt die Reaktionszeit der Umgebung auf
Eingaben. Die Menge aller Einussmöglichkeiten und Handlungsalternativen
wird durch die Komponente Reichweite abgedeckt.
Die Zuordnung bezieht sich auf die Authentizität bzw. die Natürlichkeit und
Zuordnung der Eingabe (vgl. Pietschmann [2009]). Wie bereits in Abschnitt
11
Seminararbeit
3 Präsenzforschung
Soziale Präsenz
Kopräsenz
Psychische
Involvierung
Verhaltensaustausch
Abbildung 3.3: Aufspaltung der sozialen Präsenz
3.1 angesprochen, ist auch die Plausiblität der wahrgenommenen Umgebung
eine weitere wichtige Bedingung für das Präsenzempnden in virtuellen Umgebungen und lässt sich der räumlichen Präsenz zuordnen.
3.5 Soziale Präsenz
Ursprünglich wird der Begri Soziale Präsenz in der Kommunikationsforschung verwendet. Die soziale Präsenz beschreibt die Wahrnehmung der Verkörperung einer anderen Person oder mehrerer Personen. Im Zusammenhang
mit VR können dies auch Verkörperungen künstlicher Intelligenzen sein. Laut
Biocca [1997] ist die Wahrnehmung anderer Intelligenzen nur über deren Handlung abzuleiten. Dementsprechend sorgt eine starke Interaktion in der virtuellen Umgebung dafür, dass sich die Teilnehmer untereinander als intelligente
Wesen erkennen. Biocca deniert die soziale Präsenz (vgl. Biocca [1997]):
The amount of social presence is the degree to wich a user feels
access to the intelligence, intentions, and sensory impressions of
another
Ferner vermutet Biocca, dass sich der Turing-Test als nützliches Werkzeug zur
Überprüfung von sozialer Präsenz mit einem künstlichen Gegenüber eignet.
Biocca und Lombard gehen davon aus, dass Avatare, Verkörperungen künstlicher Intelligenzen den Umgang mit Computern revolutionieren werden. Anstatt einer graschen Oberäche sollen Computer der Zukunft digitale Repräsentationen von künstlichen Personen oder Wesen beherbergen mit denen eine
Unterhaltung, wie sie zwischen Menschen geführt wird, möglich ist (vgl. Biocca
[1997], Lombard u. Ditton [1997]).
12
Seminararbeit
3 Präsenzforschung
Die soziale Präsenz wird in Pietschmann [2009] aus den Teilkomponenten Kopräsenz, Psychische Involvierung und Verhaltensaustausch zusammengesetzt (vgl. Abbildung 3.3). Die Kopräsenz beschreibt die gegenseitige Wahrnehmung von Verkörperungen, aber auch: mit einer anderen Person in einer
entfernten Umgebung sozial anwesend zu sein (vgl. Pietschmann [2009]). Die
zweite Teilkomponente Psychische Involvierung umfasst die Wahrnehmung
von anderen Intelligenzen. Kann der Benutzer durch Handlung auf Intelligenz schlieÿen, so werden die Personen als sozial gleichwertig angesehen. In
Pietschmann [2009] wird in Bezug auf Computerspiele hervorgehoben, dass
die künstliche Intelligenz von Agenten meist nicht ausreicht um diese als völlig
gleichwertige soziale Wesen akzeptieren zu können. Es wird betont, dass der
Agent zumindest Hinweise auf Handlungsabsichten oder emotionale Zustände
geben sollte.
Die Komponente Verhaltensaustausch wird als nächstes beleuchtet. Der Verhaltensaustausch, wie er in den physischen Umgebung zwischen Personen möglich ist, kann dabei komplexe Kommunikationsabläufe umfassen, die beispielsweise durch Verhaltensmuster des Menschen bedingt sind. Es sind jedoch auch
kulturell abhängige Verhaltenstraditionen denkbar. Dabei werden verschiedene
Sinnenskanäle wie verbale (beispielsweise Voice-Chat) und nonverbale Kommunikation (beispielsweise Mimik und Gestik) verwendet (vgl. Pietschmann
[2009]). Es ist klar ersichtlich, dass die soziale Präsenz besonders im Anwendungsgebiet virtueller Konferenzen eine vorrangige Anforderung darstellt. Verhandlungen erfordern Menschenkenntniss und Fingerspitzengefühl im Lesen
von Emotionen und beim Umgang des Gegenüber. Im folgenden Abschnitt
wird die Eigenwahrnehmung als letzte Teilkomponente des Präsenzempndens
untersucht.
3.6 Eigenwahrnehmung
Die Eigenwahrnehmung wurde bereits im Abschnitt 3.2 angerissen. Es wurde
die Notwendigkeit des virtuellen Körpers und die Beziehung zwischen dem Benutzer, seinem physischen Körper, seinem virtuellen Körper und der virtuellen
Umwelt verdeutlicht. Im Folgenden wird die Unterteilung der Eigenwahrnehmung in Pietschmann [2009] aufgerien und auf bereits erläuterte Aspekte
13
Seminararbeit
3 Präsenzforschung
Eigenwahrnehmung
Physischer Körper
Virtueller Körper
Mentales Modell
Abbildung 3.4: Aufspaltung der Eigenwahrnehmung
Stellung bezogen. Die Eigenwahrnehmung wird, wie in Pietschmann [2009],
in die Teilkomponten Physischer Körper, Virtueller Körper und Mentales
Modell des Körpers zerlegt (vgl. Abbildung 3.4).
Der physische Körper ist mit den Eingabe- und Ausgabemöglichkeiten des VRSystems verbunden. Der Benutzer identiziert sich, abhängig vom Grad des
allgemeinen Präsenzempndens, mit dem virtuellen Körper. Der virtuelle Körper ist dabei, wie bereits in Abschnitt 3.2 diskutiert, analog zum natürlichen
Wahrnehmungsprozess, die Schnittstelle zu der virtuellen Umgebung.
In Slater u. Usoh [1994] wird hervorgehoben, dass es ein Schock sein kann, die
virtuelle Umgebung zwar als präsent zu empnden, jedoch die eigene Hand als
Drahtgitter-Modell zu sehen. Dies ist darin begründet, dass der Mensch seit Geburt an eine mentale Vorstellung seines Körpers hat, auch als Körperschema
bezeichnet. Entspricht der wahrgenommene Körper nicht dem Körperschema,
so ensteht ein innerer Konikt und das Körperschema wird an den wahrgenommenen Körper angepasst. Der wahrgenommene Körper kann mithilfe des
VR-Systems frei deniert werden. Psychologen machen sich das Verhalten des
Menschen, in Bezug auf Anpassung des Körperschemas, und die Möglichkeit,
den wahrgenommenen Körper frei zu denieren, zu nutze. Sie untersuchen neue
Therapiemethoden für Esstörungen, mit denen es anhand der genannten Vorteile möglich ist, ein verzerrtes Körperschema zu entzerren (vgl. Bush [2008],
2.2).
14
3.7 Sensomotorische Koordination
Das in Pietschmann [2009] vorgeschlagene Modell wird an dieser Stelle noch
um die sensomotorische Koordination aus Biocca [1997] erweitert. Die Erweiterung tangiert die Teilkomponente Geschwindigkeit der Interaktivität in der
räumlichen Präsenz (vgl. Abschnitt 3.4) und die im voherigen Abschnitt dargebotene Eigenwahrnehmung.
Die sensomotorische Koordination (vgl. Biocca [1997]), auch sensormotorische
Schleife (vgl. Slater u. a. [2009]) oder I/O-Loop (vgl. Pietschmann [2009]) bezeichnet den stetigen latenzarmen koordinierten Wechsel zwischen Aktion mit
und Reaktion von der virtuellen Umgebung. Hebt die Person ihren Arm, so
weiÿ sie, ohne visuelle Reize aufzunehmen, dass sich ihr Arm in der Umgebung anhebt. Entspricht jedoch das Körpergefühl nicht dem Gesehenen: der
Arm bewegt sich nicht, ensteht ein Konikt zwischen Körperschema und den
externen Reizeinüssen.
In Slater u. a. [2009] wird berichtet, dass das dargelegte Beispiel bei den Probanden zur Panik führte. Im Zusammenhang mit diesem Phänomen wurde der
Begri simulation sickness geprägt (vgl. Held u. Durlach [1991]). Es wird in
Biocca [1997] argumentiert, dass ein unvollständiges Abbilden von Sinnen und
Interaktionsmöglichkeiten zu diesem Zustand führt.
Im nachfolgenden Kapitel wird das Projektziel anhand der gesammelten Erkenntnisse auf die Intensität des Präsenzempndens hin untersucht. Ferner
wird eine beispielhafte virtuelle Umgebung beschrieben, die auf Grundlage der
voherigen Untersuchung begründet, und im Rahmen der technischen Möglichkeiten des Projekts, dem Benutzer ein starkes Präsenzempnden vermittelt.
Das Projektziel wurde bereits in Abschnitt 2.4 im Grundlagenkapitel dargeboten. Die folgende Untersuchung bezieht sich dabei auf die Rahmenbedingungen
15
Seminararbeit
und Anforderungen des Projekts. Das Präsenzempnden wurde in Abschnitt
3.3 als die Summe der drei Teilkomponenten Räumliche Präsenz, Soziale
Präsenz und Eigenwahrnehmung vorgestellt. Nachfolgend wird das Projektziel auf Grundlage der Teilkomponenten hin untersucht.
4.1 Räumliche Präsenz
Die räumliche Präsenz wird durch die beiden Faktoren Lebendigkeit und Interaktivität gebildet (vgl. Abschnitt 3.4). Durch die medial vermittelten akustischen sowie visuellen Reize werden die beiden wichtigsten Sinne, Sehen und
Hören, angesprochen. Der Vermittler ist das HMD. Die Breite der Lebendigkeit ist somit gewährleistet. Die Tiefe der Lebendigkeit ist durch die Auösung
deniert, in der die Reize von den Sinnen wahrgenommen werden.
In Bezug auf die Akustik kann mit Hilfe der Stereotechnik eine dreidimensionale Geräuschkulisse emuliert werden. Durch das Umschlieÿen der Ohrmuscheln können externe Reize der physischen Umgebung ausgeblendet werden.
Mithilfe dieser Konstruktion werden verfälschende Störungsgeräusche unterbunden. Wie bereits erwähnt, kann allein durch die Verwendung eines HMD
das Präsenzempnden signikant intensiviert werden (vgl. Biocca [1997] und
Abschnitt 2.3).
Der andere Teilaspekt der räumliche Präsenz bildet die Interaktivität (vgl.
Abschnitt 3.4). In Bezug auf die Geschwindigkeit der Interaktivität kann für
das Projektziel festgehalten werden, dass die Notwendigkeit einer latenzarmen
Verarbeitung von sensomotorischen Schleifen (vgl. Abschnitt 3.7) zur Unterbindung von simulation sickness (vgl. Abschnitt 3.7) und Intensivierung des
Präsenzgefühls (vgl. Abschnitt 3.4) von der Projektgruppe bei der Festlegung
der Ziele bereits intuitiv bedacht wurde.
Die Reichweite der Interaktivität (vgl. Abschnitt 3.4) ist, bezogen auf die
Bewegung von Gliedmaÿen des physischen beziehungsweise virtuellen Körpers,
sehr exibel. Ein Konzept für die Bewegung in virtuellen Umgebungen wurde
jedoch noch nicht ausgearbeitet und ein Fehlen dieser Funktion schränkt den
Benutzer bei der Erkundung der Umgebung signikant ein.
16
Seminararbeit
Die authentische Zuordnung der Interaktivität ist, im Bezug auf das Umsehen
durch die Verwendung eines Lagesensors und auf die Körperbewegung durch

die Verwendung der Microsoft Kinect , gewährleistet. Eine unauthentische Zuordnung würde beispielsweise die Verwendung eines Joysticks zur Erkundung
der Umgebung darstellen.
4.2 Soziale Präsenz
Die soziale Präsenz setzt sich aus den Teilkomponenten Kopräsenz, Psychische Involvierung und Verhaltensaustausch zusammen (vgl. Abschnitt 3.5).
Da das Projektziel keine Mehrbenutzerumgebung vorsieht, fehlt die soziale
Präsenz vollständig. Eine mögliche Lösungen um diesen Aspekt zu kompensieren ist die Erzeugung virtueller Lebewesen, wie beispielsweise Vögel mit
einem künstlich repräsentierbarem Verhaltensmodell, wie beispielsweise dem
Schwarmverhalten. Eine andere Lösung ist: die virtuelle Umgebung so zu entwerfen, dass es
plausibel
erscheint, dass sich dort keine Lebewesen oder andere
Personen aufhalten.
4.3 Eigenwahrnehmung
Es wird nun die Eigenwahrnehmung untersucht. Diese setzt sich aus dem Physischen Körper, dem Virtuellen Körper und dem Mentalen Modell des Körpers zusammen (vgl. Abschnitt 3.6). Die Eigenwahrnehmung des physischen
Körpers wird durch Verwendung des HMD akustisch sowie visuell ausgeblendet. Der virtuelle Körper wird nach Zielsetzung durch die Egoperspektive erfahren. Der Benutzer kann sich umsehen und seine eigenen virtuellen Gliedmaÿen erkennen. Es wurde bei der Zielsetzung jedoch nicht auf die Aufrechterhaltung des Körperschemas eingegangen. Dieser Aspekt ist besonders wichtig,
da die enstehenden Konikte zu einer Verzerrung des Körperschemas führen
können 3.6. In Slater u. Usoh [1994] wird ein Fall dargestellt, in dem ein Proband, nach Aufhenthalt in der virtuellen Umgebung, nicht mehr in der Lage
war seinen physischen Körper korrekt zu steuern.
17
4.4 Virtuelle Umgebung für das
Präsenzempnden
Im nachfolgenden Abschnitt wird eine virtuelle Umgebung beschrieben, die
auf Grundlage der festgelegten Rahmenbedingungen für das Projekt (vgl. Abschnitt 2.4) ein möglichst intensives Präsenzempnden erzeugt. Die räumliche
Präsenz des Projektziels wurde in Abschnitt 4.1 beschrieben. Das fehlende
Konzept sich frei fortzubewegen stellte dabei ein wesentliches Manko für die
räumliche Präsenz dar. Um dies zu kompensieren, bietet es sich an, den Benutzer in der physischen sowie virtuellen Welt auf einen Stuhl zu setzen. In
diesem Zustand ist die freie Fortbewegung nicht notwendig, sodass das Fehlen
erst nach Aufstehen von dem Stuhl zu wesentlichen Einbuÿen im Präsenzempnden führt.
Da das Projektziel keine Mehrbenutzerumgebung vorsieht, bietet es sich an,
wie in Abschnitt 4.2 erläutert, das Fehlen von anderen Personen dem Benutzer
plausibel
darzustellen. Vorzugsweise wird dem Benutzer nur ein kleiner
frei einsehbarer Bereich gewährt, wie beispielsweise ein kleiner Raum oder ein
Garten. Innerhalb dieser Umgebungen ist es
plausibler, dass keine anderen Per-
sonen anwesend sind, als beispielsweise in einem Kaufhaus oder einem Park.
Die Belebtheit der gesamten virtuellen Umgebung, auch das was der Benutzer nicht sieht, kann dabei durch Hintergrundgeräusche, beispielsweise durch
redende Menschen, kompensiert werden (vgl. Abschnitt 3.1). Eine dreidimensionale Positionierung der Geräusche kann auf Basis der Lage des virtuellen
Kopfes das soziale, räumliche Präsenzgefühl und ferner die Orientierung in der
virtuellen Umgebung unterstützten. Eine Simulation von Lebenwesen mit einfachem Verhaltensmuster, wie Vögel mit Schwarmverhalten, soll hier als weitere Möglichkeit zur Intensivierung und Kompensation der sozialen Präsenz
dienen.
Für den Entwurf einer virtuellen Umgebung, die die Eigenwahrnehmung intensiviert, bietet es sich zudem an, dynamischen Schattenwurf und dynamische
Reektionen des virtuellen Körpers auf Boden, Wänden und Gegenständen zu
simulieren (vgl. Slater u. a. [1995]).
18
Seminararbeit
5 Zusammenfassung
5 Zusammenfassung
Es wurden in dieser Arbeit die Fragen, ob die Anforderungen des Projektziels
zu einem Gefühl von Präsenz in einer virtuellen Umgebung führen, welche
Faktoren für das Präsenzempnden relevant sind und wie sich dieses Gefühl
intensivieren lässt, beantwortet. Ausgehend von der Historie der VR (vgl. Abschnitt 2.1), wurden zunächst technische Realisierungen vorgestellt (vgl. 2.3).
Anschlieÿend wurde die Zielsetzung der Projektgruppe VR dargeboten (vgl.
Abschnitt 2.4).
Als Einstieg in die Präsenzforschung wurden zu Beginn verschiedene Ansichten beleuchtet und es wurde auf den Wahrnehmungsprozess des Menschen eingangen (vgl. Abschnitt 3.3, Abschnitt 3.1). Nachfolgend wurde die Beziehung
zwischen dem physischen Körper, dem virtuellen Körper und der virtuellen
Umgebung dargestellt (vgl. Abschnitt 3.2).
Auf Basis des in Pietschmann [2009] zusammenfassenden Modells von Präsenzempnden wurden die relevanten Faktoren des Präsenzempndens aufgezeigt
(vgl. Abschnitt 3.3). Anhand dieser Erläuterung wurde die Frage, ob die Anforderungen des Projektziels zu einem Gefühl von Präsenz führen, im Kapitel 4
beantwortet. Am Schluss wurde sich der Frage, wie sich das Präsenzempnden
intensivieren lässt, zugewendet. Für die Beantwortung der Frage wurde eine
virtuelle Umgebung skizziert, die im Rahmen des Projektziels nicht mögliche
Aspekte kompensiert und damit das Präsenzempnden intensiviert.
19
6 Ausblick
Wie bereits 1997 in Biocca [1997] argumentiert gibt es verschiedene Gründe
sich besonders in Zukunft mit der Thematik des Präsenzempndens in virtuellen Umgebungen zu befassen: Es lassen sich verschiedene Anwendungsbereiche
für die VR angeben (vgl. Abschnitt 2.2) und die Tendenz zur immer engeren Kopplung zwischen Mensch und der Benutzungsschnittstelle zum Computer (progressive embodiment) impliziert, dass auch in Zukunft neue Anwendungsgebiete erschlossen werden, die auf Präsenzempnden hin untersucht
werden können. In Biocca [1997] wird beschrieben, dass die VR in Zukunft
als Alltagswerkzeug zur Lösung von Problemen und Aufgaben genutzt wird.
Ferner soll die VR die Aufgabe eines physisch transzendenten Ortes übernehmen, an dem sich Benutzer verschiedener physischer Orte treen können. Diese
Arbeit schlieÿt mit einer oenen Frage, rezitiert aus Biocca [1997], ab:
Es sei davon auszugehen, dass die Kopplung zwischen Mensch und der Schnittstelle zum Computer soweit verwoben ist, das progressive embodiment soweit
fortgeschritten, dass die Wahrnehmung vollständig virtuell ist. Der Mensch sich
der Maschine annähert, und die Maschine dem Menschen. So ist die physische
Transzendenz, unabhängig von einem physischen Ort an verschiedenen virtuellen Orten zu existieren, erreicht, da unsere wahrgenommene Umgebung das
Produkt unserer Sinne ist (vgl. Sekuler u. Blake [1994]). Es stellt sich jedoch
dann in Analogie zum Skeptizismus in der Philosophie die Frage: An welchem
Ort existiert der Mensch?.
20
Seminararbeit
[And u. a. ] And, Jannick R. ; Roll, Jannick ; Cakmakci, Ozan:
Present, and Future of Head Mounted Display Designs
The Past,
2.3
[Backman 2005] Backman, Anders: Colosseum3D Authoring Framework for
Virtual Environments. In:
In Proceedings of EUROGRAPHICS Workshop
IPT, EGVE Workshop, 2005, S. 225226
2.3
Einsatzmöglichkeiten heutiger Virtual-RealityTechnologie im zivilen Pilotentraining am Beispiel zweier Szenarien im
Rahmen einer Studie. http://tuprints.ulb.tu-darmstadt.de/2043/.
[Bauer 2010] Bauer, Marcus:
Version: February 2010 2.2
[Biocca 1997] Biocca, Frank: The Cyborg's Dilemma: Progressive Embodiment in Virtual Environments [1]. In:
Journal of Computer-Mediated Com-
munication 3 (1997), Nr. 2, 0. http://dx.doi.org/10.1111/j.1083-6101.
1997.tb00070.x. DOI 10.1111/j.10836101.1997.tb00070.x 3, 3.1, 3.2, 3.3,
3.3, 3.4, 3.5, 3.7, 4.1, 6
[Bowman u. a. 2008] Bowman, Doug A. ; Coquillart, Sabine ; Froehlich,
Bernd ; Hirose, Michitaka ; Kitamura, Yoshifumi ; Kiyokawa, Kiyoshi
; Stuerzlinger, Wolfgang: 3D User Interfaces: New Directions and Perspectives.
20-36.
In:
IEEE Comput. Graph. Appl.
28 (2008), November, Nr. 6,
http://dx.doi.org/10.1109/MCG.2008.109.
DOI 10.1109/M-
CG.2008.109. ISSN 02721716 2.3
[Bracken u. Skalski 2009] Bracken, Cheryl C. ; Skalski, Paul: Telepresence
and video games: The impact of image quality. In:
PsychNology
7 (2009),
Nr. 1, S. 101112 3
Immersed in media : telepresence in everyday life / edited by Cheryl Campanella Bracken and Paul D. Skalski. Routledge, New York :, 2010. xviii,
[Bracken u. Skalski 2010] Bracken, Cheryl C. ; Skalski, Paul D.:
21
Seminararbeit
254 p. : S. ISBN 9780415993395 0415993393 9780415993401 0415993407
9780203892336 020389233 3
[Büscher u. a. 2000] Büscher, Monika ; Christensen, Michael ; Grønbæk,
Kaj ; Krogh, Peter ; Mogensen, Preben ; Shapiro, Dan ; Ørbæk, Peter:
Collaborative Augmented Reality Environments: Integrating VR, Working
Materials, and Distributed Work Spaces. In:
In Proc. Collaborative Virtual
Environments 2000, ACM, ACM Press, 2000, S. 4756
[Bush 2008] Bush, Jimmy:
a treatment alternative.
3, 1032-1040.
2.3
Viability of virtual reality exposure therapy as
In:
Comput. Hum. Behav.
24 (2008), May, Nr.
http://dx.doi.org/10.1016/j.chb.2007.03.006.
DOI
10.1016/j.chb.2007.03.006. ISSN 07475632 2.2, 3.6
[Cruz-neira u. a. 1993] Cruz-neira, Carolina ; Sandin, Daniel J. ; Defanti,
Thomas A.:
Surround-screen projection-based virtual reality: The design
and implementation of the CAVE, 1993, S. 135142 2.3
[Freeman u. a. 2008] Freeman, Daniel ; Pugh, Katherine ; Antley, Angus ;
Slater, Mel ; Bebbington, Paul ; Gittins, Matthew ; Dunn, Graham ;
Kuipers, Elizabeth ; Fowler, David ; Garety, Philippa: Virtual reality
study of paranoid thinking in the general population. In:
of Psychiatry
192 (2008), apr, Nr. 4, 258-263.
1192/bjp.bp.107.044677.
The British Journal
http://dx.doi.org/10.
DOI 10.1192/bjp.bp.107.044677 2.2
[Gorini u. Riva 2008] Gorini, Alessandra ; Riva, Giuseppe: Virtual reality in
anxiety disorders: the past and the future. In:
peutics
8 (2008), Nr. 2, 215-233.
8.2.215.
Expert Review of Neurothera-
http://dx.doi.org/10.1586/14737175.
DOI 10.1586/14737175.8.2.215 2.2
[Gross u. a. 2003] Gross, Markus ; Würmlin, Stephan ; Naef, Martin ; Lam-
boray, Edouard ; Spagno, Christian ; Kunz, Andreas ; Koller-meier,
Esther ; Svoboda, Tomas ; Gool, Luc V. ; Lang, Silke ; Strehlke, Kai
; Moere, Andrew V. ; Oliver ; Zürich, Eth ; Staadt, Oliver: blue-c:
A Spatially Immersive Display and 3D Video Portal for Telepresence. In:
ACM Transactions on Graphics, 2003, S. 819827
2.3
[Held u. Durlach 1991] Held, Richard ; Durlach, Nathaniel: Telepresence,
time delay and adaptation. In:
Pictorial Communication in Virtual and Real
Environments, chapter 14, Taylor and Francis, 1991, S. 232246
3.7
22
Seminararbeit
[Hoyer u. a. 2004] Hoyer, H. ; Jochheim, A. ; Röhrig, C. ; Bischoff,
A.:
A Multiuser Virtual-Reality Environment for a Tele-Operated Labo-
ratory.
126.
In:
IEEE Transactions on Education
47 (2004), Nr. 1, S. 121
http://dx.doi.org/http://dx.doi.org/10.1109/TE.2003.822263.
DOI http://dx.doi.org/10.1109/TE.2003.822263 2.2
[Kahkonen u. Whyte 2003] Kahkonen, Kalle ; Whyte, Jennifer:
Industrial
Applications of Virtual Reality in Architecture and Construction.
2003 2.2
[Lemoine u. a. 2004] Lemoine, Patrick ; Gutierrez, Mario ; Vexo, Frederic
; Thalmann, Daniel: Mediators: Virtual Interfaces with Haptic Feedback.
In:
In Proceedings of EuroHaptics 2004, 5th-7th, 2004, S. 6873
2.3
[Lennerz u. a. 1999] Lennerz, C. ; Schömer, E. ; Warken, T.: A Framework for Collision Detection and Response. In:
Symposium, ESS'99, 1999, S. 309314
in 11th European Simulation
2.3
[Lombard u. Ditton 1997] Lombard, M. ; Ditton, T. B.: At the heart of
it all : The concept of presence. In:
munication
13 (1997), Nr. 3.
lombard.html
Journal of Computer- Mediated Com-
http://jcmc.indiana.edu/vol3/issue2/
3.3, 3.3, 3.5
[Loomis 1992] Loomis, Jack M.: Distal Attribution and Presence. In:
Presence
1 (1992), Nr. 1, S. 113119 3.2
[Moraes u. a. ] Moraes, Ronei Marcos D. ; Machado, Liliane Dos S. ; Souza,
Online Assessment of Training in Virtual Reality Simulators
Based on General Bayesian Networks 2.2
Ro Carlos D.:
[Pietschmann 2009] Pietschmann, Daniel:
Das Erleben virtueller Welten.
Verlag Werner Hülsbusch, 2009 (Game Studies) 3, 3.3, 3.4, 3.4, 3.5, 3.6, 3.7,
5
[Sá u. Zachmann 1998] Sá, Antonino Gomes d. ; Zachmann, Gabriel: Integrating Virtual Reality for Virtual Prototyping. In:
Design Engineering Technical Conferences.
Proc. of the 1998 ASME
Atlanta, Georgia, sep 1998. paper no. DETC98/CIE-5536 2.2
[Sekuler u. Blake 1994] Sekuler, R. ; Blake, R.:
Perception.
McGraw-Hill,
1994 3.2, 6
[Shotton u. a. 2011] Shotton, Jamie ; Fitzgibbon, Andrew ; Cook, Mat
; Sharp, Toby ; Finocchio, Mark ; Moore, Richard ; Kipman, Alex ;
23
Seminararbeit
Blake, Andrew: Real-Time Human Pose Recognition in Parts from Single
Depth Images, 2011 2.4
The inuence of dynamic shadows on presence in immersive virtual environments.
[Slater u. a. 1995]
In: Slater, M. ; Usoh, M. ; Chrysanthou, Y.:
Bd. 95. Springer-Verlag, 1995, 8-21 4.4
[Slater u. a. 2009] Slater, Mel ; Lotto, Beau ; Arnold, Maria M. ;
Sanchez-Vives, Maria V.: How we experience immersive virtual environments : the concept of presence and its measurement. In:
cología
Anuario de Psi-
http://www.raco.cat/index.php/
AnuarioPsicologia/article/view/143105 3.1, 3.7
40 (2009), Nr. 2773, 193-210.
[Slater u. Usoh 1994] Slater, Mel ; Usoh, Martin:
Self
Body Centred Inter-
http:
//scholar.google.com/scholar?hl=en\&btnG=Search\&q=intitle:
Body+Centred+Interaction+in+Immersive+Virtual+Environments#0
action in Immersive Virtual Environments.
In:
(1994), 1-22.
3.6, 4.3
[Slater u. Wilbur 1997] Slater, Mel ; Wilbur, Sylvia: A Framework for Immersive Virtual Environments (FIVE): Speculations on the Role of Presence
in Virtual Environments. In:
PresencePAGES
(1997) 3
[Steuer 1992] Steuer, Jonathan: Dening Virtual Reality: Dimensions Determining Telepresence. In:
JOURNAL OF COMMUNICATION
42 (1992), S.
7393 2.3, 3.4, 3.4
Proceedings of the Congress of the Internation Federation of Information Processing (IFIP) Bd. volume 2, 1965, 506-508 2.1, 3.2
[Sutherland 1965] Sutherland, Ivan E.: The Ultimate Display. In:
[Sutherland 1968] Sutherland, Ivan E.: A head-mounted three dimensional
Proceedings of the December 9-11, 1968, fall joint computer
conference, part I. New York, NY, USA : ACM, 1968 (AFIPS '68 (Fall, part
display.
In:
I)), 757-764 2.1, 2.3
24
Die Kinect
Robert Schadek
Carl von Ossietzky Universität Oldenburg
robert.schadek@informatik.uni-oldenburg.de
4. Juli 2011
Inhaltsverzeichnis
1 Einleitung
2
2 Infrarot Kamera
2.1 Structured Light . . . . .
2.1.1 Emitter Techniken
2.1.2 Emittierte Muster .
2.2 Kinect Tiefenbild . . . . .
2
2
3
3
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 RGB Kamera
4
4 Microphone
5
5 USB Anbindung
6
6 Motion Capture und Skelett Tracking
6.1 Einleitung . . . . . . . . . . . . . . . .
6.2 Techniken Motion Capture . . . . . . .
6.2.1 Passive optical system . . . . .
6.2.2 Active marker optical systems .
6.2.3 Inertial motion capture systems
6.2.4 Mechanical motion systems . .
6.3 Skelett Rekonstruktion . . . . . . . . .
6.4 Microsoft Bodypart Detection . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
. 6
. 6
. 7
. 7
. 8
. 8
. 8
. 10
11
1
1
Einleitung
Die Vorstellung der Kinect stößt auf großes Interesse. Von vielen als Innovation angesehen, werden doch Techniken eingesetzt, die teilweise bereits
Jahrzehnte existieren. In dieser Arbeit wird zu Beginn auf die in der Kinect
verbaute Hardware eingegangen und deren Funktionsweise erklärt. Darauf
aufbauend werden zuerst generelle Motion Capture Verfahren erklärt, sowie
die Skelett rekonstruktion aus einem Tiefenbild. Abschließend wird ein von
Microsoft entwickeltes Skelett Rekonstruktionsverfahren präsentiert, welches
zusammen mit der Kinect eingesetzt wird.
2
Infrarot Kamera
Die Kinect erzeugt ein Tiefenbild mit Hilfe einer Technik names Light Coding.
[1] Diese Technik ist im weitesten Sinne eine Technik aus der Klasse der
Structured Light sensors.
2.1
Structured Light
Unter Structured Light versteht man eine Technik, die mit Hilfe mindestens
einer Kamera, sowie mindestens einer Lichtquelle, ein Tiefenbild erstellt. Der
Name leitet sich von der Technik selbst ab. Eine Muster wird von einem
Punkt auf die zu scannende Oberfläche projiziert. Dieses Muster wird von
einem anderen Punkt durch eine Kamera aufgezeichnet. Durch diese Form der
Oberfläche und dem anderem Blickwinkel auf das Muster wird ein verzehrtes
Abbild des Musters aufgezeichnet. Aus dieser Aufzeichnung lässt sich die
Struktur der Oberfläche errechnen. [14] [3] Zur grafischen Erleuterung siehe
Abbildung 1.
Abbildung 1: Structured Light Aufbau
Auf den mittleren Bild ist das projektierte Muster zu erkennen.
2
2.1.1
Emitter Techniken
Structured Light Techniken lassen sich ein drei Kategorien unterteilen.
InfraRed Structured Light (IRSL) Wie der Name andeutet, handelt es
sich bei der Lichtquelle um intrarotes Licht.
Imperceptible Structured Light (ISL) Bei dieser Technik wird das Muster mit Licht aus dem sichtbaren Spektrum erzeugt. Um anderen Aufnahmemedien zu beeinflussen wird das Muster mit einer sehr hohen
Frequenz projiziert. Mit der Frequenz ist in diesem Fall gemeint wie
lange das Muster proziert wird.
Filtered Structured Light (FSL) Hierbei handelt es sich um eine Lichtquelle, dessen Licht durch einen Filter geleitet wird, der nur den infraroten Anteil des Licht passieren lässt.
[3]
2.1.2
Emittierte Muster
Ein weiterer wichtiger Aspekt bei Structured Light ist das projizierte Muster.
Es gibt verschiedene Arten von brauchbaren Mustern. Als Beispiel zu nennen sind parallele, horizontal sowie auch vertikal Linien. Häufig werden auch
komplexere Muster, wie zum Beispiel grids oder Punktwolken, projiziert. Einige Techniken benutzten variable Muster-Generatoren. Darunter versteht
man, dass Projizieren das Muster mehrfach auf verschiedene Orte des zu
scannenden Objektes. Dieser Ansatz birgt sowohl Vorteile als auch Nachteile. In Abbildung 2 sind einige Arten von Mustern dargestellt. Angenommen
es wird als Muster eine vertikalverlaufende Linie projiziert. Ein Vorteil wäre
es, dass eine Linie in einem verrauschten Bild einfacher zu detektieren ist, als
mehrere Linien dicht nebeneinander. Der große Nachteil dieser Technik ist,
dass das Neuausrichtung der Lichtquelle viel Zeit in Anspruch nimmt. Der
Grund dafür ist, dass der Emitter in der Regel mechanisch verstellt werden
muss. Im Zuge besserer Kamerasysteme, mit besserem Rauschverhalten, wird
diese Technik heutzutage weniger häufig eingesetzt. Grids, wie in rechten unteren Bild, ermöglichen es horizontale sowie vertikale Tiefenunterschiede zu
erkennen. Allerdings muss ein solches Grid feinmaschig genug sein um alle
Tiefenunterschiede zu erkennen. Wird ein sehr feines Grid projiziert kann es
zu Schwierigkeiten kommen, die einzelnen Linien zu erkennen.
3
Abbildung 2: Projizierte Muster
2.2
Kinect Tiefenbild
Die Kinect for XBox 360, oder kurz Kinect, verwendet kontinuilich projiziertes InfraRed Structured Light. Dieses projizierte Bild wird unter Zuhilfenahme eines Infrarot-Sensors aufgezeichnet. Das projizierte Infrarotbild ist
eine pseudozufällige Punktwolke. Nachdem das, durch die zu betrachtende
Oberfläche verzehrte, Bild aufgenommen wurde, wird die mit hilfe der StereoTriangulation das Tiefenprofil gewonnen. Der Trick hierbei ist, dass für die
stereo Triangulation zwei Bilder von Nöten sind, aber nur Eines aufgezeichnet
wird. Das zweite Bild liegt im Speicher der Kinect vor, da das pseudozufällig
Muster dort abgespeichert ist. [5] Das aufgezeichnete Graustufenbild hat eine Auflösung von 632x480. Die Auflösung pro Pixel beträgt 11Bit. [8] Das
Sichtfeld des Tiefenensensors beträgt 57◦ Horizontal sowie 43◦ vertical. [6]
Somit beträgt die Tiefenauflösungs, bei einer Distanz von 2m 1cm. [2] Es ist
wichtig zu erwähnen, dass Objekte nicht freigestellt werden.
3
RGB Kamera
Bei der Kamera handelt es sich um eine übliche CMOS Kamera. Sie hat eine
Auflösung von 640x480 Pixel bei einer Farbtiefe von 32Bit. Die Frabinfor-
4
mationen werden als Bayer-Pattern übertrage.1 [6] [8] Aufgrund des kleinen
physichen Abstands der RBG Kamera sowie des IR-Sensors ist es möglich,
die Farbwerte direkt auf die Tiefenwerte abzubilden. Das Ergebnis dieser
Überlagerung ist in Abbildung 3 zu sehen. Das Bild zeigt, wie das Tiefenbild
Abbildung 3: Farbiges Tiefenbild
mit den Farbwerten der RGB Kamera dargestellt wird. Es ist klar zu erkennen, dass es keine Informationen für die Rückseite der gezeigten Person gibt.
Dies ergibt sich daraus, dass die virtuelle Kamera, die die Szene aufzeichnet,
nicht dieselbe Position hat, wie die Kamera, die das Tiefenbild sowie das
RGB Bild aufzeichnet.
4
Microphone
Die Kinect besitzt vier Mikrophone, die es ermöglichen, Stimmerkennung für
eine Person durchzuführen. Aufgrund dieser vier Mikrophone ist es möglich,
die Position der Geräuschquelle zu bestimmen, sowie noise cancellation durchzuführen. [7] [13] Genauere Informationen über die angewandten Techniken
sind nicht verfügbar.
1
Bayer-Pattern ist eine Farbkodierung die speziellen Wert auf den Grünanteil in einem
Bild legt, da das menschliche Auge auf Grün-Werte empfindlicher wahrnimmt als z.B.
Rot-Werte.
5
5
USB Anbindung
Die Kinect wird über USB2 angesprochen. Die Fähigkeit von USB2 mit einer
Verbindung mehrere Divices anzusprechen, wird genutzt, um die einzelnen
Komponenten der Kinect unabhängig zu nutzten. So gibt es vier ansprechbare
Divices. [9]
• Stellmotor
• RBG-Kamera
• Depth-Kamera
• Mikrophone
Um die Kinect mit ausreichend Strom zu versorgen, besitzt das USB-Kabel
einen weiteren Anschluss, der an ein Netzteil angeschlossen werden kann.
6
6.1
Motion Capture und Skelett Tracking
Einleitung
Unter Skelett Erkennung bzw. Motion Capture versteht man Verfahren, bei
denen die Bewegungen einer Person digitalisiert werden. Das Ergebnis dieser Digitalisierung kann verschiedene aussehen: Es gibt Verfahren, bei denen
die gesamte Körperoberfläche aufgezeichnet wird, einschließlich aller Texturinformationen. Andere Verfahren hingegen erzeugen eine schemenhafte
Repräsentation der Person. Wieder Andere erzeugen ein sogenanntes Skelet.
Dieses Skelet enthält Information über die Position der einzelnen Körperteile.
Weitere Abstufungen zwischen den Verfahren sind ebenfalls denkbar.
6.2
Techniken Motion Capture
Motion Capture Techniken lassen sich grob in zwei Kategorien einordnen:
Die eine Kategorie sind die aktiven Verfahren. Hierbei befinden sich auf dem
zu verfolgenden Objekt Systeme, die aktiv ihre Position übermitteln bzw.
ermitteln. Der andere Kategorie gehören Systeme an, deren Position passiv ermittelt werden. Passive Systeme benötigen weitere Hardware um ihre
Position zu ermitteln.
6
Abbildung 4: Inertial motion capture system
6.2.1
Passive optical system
Das Passive optical system gehört zu der Kategorie der passiven Verfahren.
Beim Passive optical system motion capturing werden am aufzunehmenden
Objekt lichtreflektierende Systeme angebracht. Diese werden durch eine stationäre Lichtquelle angestrahlt. Das Licht befindet sich meist im InfrarotSpektrum und wird von mehreren Kameras aufgezeichnet. Aus der Menge
von einzelnen Bilder lässt sich die genaue Position jeder Markierung im Raum
rekonstruieren [10].
6.2.2
Active marker optical systems
Dieses Technik gehört in die Kategorie der aktiven Verfahren. Ähnlich wie
beim Passive optical system werden Markierungen auf dem zu verfolgenden
Objekt angebracht. Allerdings emittieren die Markierungen Licht. Je nach
Ausführung des Systems, kann entweder Licht in unterschiedlichen Spektren
oder unterschiedlichen Intervallen emittiert werden, um die einzelnen Markierungen zu unterscheiden.
7
Abbildung 5: Mechanical motion capture system
6.2.3
Inertial motion capture systems
Bei initialen Systemen werden am zu verfolgenden Objekt mehrere Beschleunigungssensoren befestigt. Jeder dieser Sensoren zeichnet Beschleunigungen
in allen drei Freiheitsgraden auf. Somit gehört diese Systeme zu den aktiven Motion Capture Systeme. Die aufgezeichneten Informationen werden je
nach System entweder von jedem Sensor einzeln verschickt oder zusammen
übertragen. Beide Ansätze haben Vor- und Nachteile. Wenn alle Sensoren
einzeln senden, müssen alle Signale genau synchronisiert werden. Wird nur
ein Signal gesendet, müssen die einzelnen Sensoren vernetzt werden. Diese
Vernetzung kann die Flexibilität des Trägers einschränken. Abbildung 4 zeigt
ein solches System.
6.2.4
Mechanical motion systems
Dieses Verfahren zählt zu den Verfahren der aktiven Kategorie. Mechanical
motion systems funktionieren, indem sie mechanische Gelenke am zu verfolgenden Objekt anbringen. Diese Systeme bieten eine hohe Genauigkeit, allerdings ist die Benutzung zuweilen nicht ergonomisch [12]. Ein solches System
ist in Abbildung 5 zu sehen.
6.3
Skelett Rekonstruktion
Ein grundsätzlich anderes Verfahren wird bei der Skelett Rekonstruktion verwendet. Hierbei wird aus einem Bild bzw. einem Tiefenbild das Skelett eines
Akteurs rekonstruiert. Der Vorteil hierbei ist, dass der Akteur keine speziellen Anzüge bzw. Markierungen am Körper tragen muss. Wie bereits im
Kapitel 2.2 beschrieben, können Objekte nicht freigestellt werden. Personen,
8
für die Skelette erstellt werden sollen, müssen durch Filterverfahren freigestellt werden.
Verfahren für diesen Schritt sind unter dem Namen Edge Detection bekannt.
Generell arbeiten diese Verfahren, indem sie starke Helligkeitsunterschiede
in einem Bild als Kante interpretieren. Obwohl, wie in 2.2 beschrieben, das
Tiefenbild ein Graustufenbild ist, lassen sich diese Verfahren anwenden, um
Kanten freizustellen.
Der nächste Schritt ist es, das freigestellt Objekt mit Mittellinien zu versehen. Diese teilen die Oberfläche so ein, dass der Abstand zu den Rändern
für jeden Punkt der Linie gleich ist. Zwei Verfahren werden für diese Aufgabe hauptsächlich benutzt: Zum einen Distance Transformation zum anderen
Voronoi diagrams.
Distance Transformation erzeugen die Mittellinien, indem zuerst alle Pixel des Bildes in feature und non-feature eingeteilt werden. Feature bedeutet soviel wie, Teil des Objektes. Danach wird eine Entfernungskarte
erzeugt, die für jeden Pixel angibt, wie weit der nächste Feature Pixel
entfernt ist. In der daraus resultierenden Karte werden alle Übergange
von feature zu non-feature Pixel als Kante markiert. Die Mittellinie
dieser Kanten ist dann die Mittellinie des Objektes. Abbildung 6a sowie 6b zeigen jeweils die Aufteilung in feature und nicht non-feature
Blöcke, sowie die Distanzen zu den feature Blöcken.
Voronoi diagrams erzeugen aus einer Eingabemenge von Punkten Zellen,
die genau einen Punkt als Zentrum haben. Aus der Position der Zellen zueinander entstehen die Grenzlinien zwischen den Zellen. Plaziert
man nun Punkte auf den Kanten zwischen freigestellten und nicht freigestellten Flächen, ist eine der Linien des Diagramm die Mittellinie
des freigestellten Objekts. Abbildung 7 zeigt zwei Mittellinien für eine
Echse sowie ein Nashorn.
Nachfolgend müssen die extrahierten Linien begradigt werden. Hierbei
ist darauf zu achten, dass keine Winkel, die durch Gelenke entstanden sind,
entfernt werden. Dieses Skelett lässt sich dann mit einem Referenz-Skelett
vergleichen, um die eigentliche Position der Knochen zu bestimmen. Dieses
Vergleichen ist beispielhaft durch Bayessches Netz möglich. [11] [4] Zusätzlich
besteht die Möglichkeit, die Bewegung des Skelett über die Zeit zu betrachten und in Kombination mit dem aktuell berechneten Skelett eine genauere
Annäherung an die wahre Position zu erhalten.
9
(a) feature, non-feature
(b) Distanz
Abbildung 6: Distance Transformation
6.4
Microsoft Bodypart Detection
Zeitgleich mit der Veröffentlichung der Kinect präsentierte Microsoft eine
Software, die Skelette mit bis zu 200 Frames pro Sekunde erkennt. Dieses
Verfahren arbeitet auf Tiefenbildern. In Kombination mit einer Menge an
Trainingsdaten ermöglicht es das schnelle Erkennen von Körperteilen, aus
denen sich ein Skelett erzeugen lässt. Die wichtigeste Komponenten des Systems sind die Trainingsdaten. Diese wurden erzeugt, indem eine vorher bestehende Menge von Motion Capture Aufnahmen auf zufällig erzeugte 3DKörpermodelle verschiedenster Form übertragen wurden. Diese Modelle wurde daraufhin mit hilfe bestehenden Grafikpiplines in Tiefenbilder umgewandelt. In Abbildung 8 und Abbildung 9 sind zum Vergleich Posen entstanden
aus Motion Capture Aufnahmen sowie zufällig erzeugt zu sehen. Die farbigen
Körper repräsentieren die erkannten Körperteile. Da es sich um 3D-Modelle
handelt, können beliebige Blickwinkel analysiert werden. Die somit prinzipiell
beliebig großen Menge an Bilder wurde dazu genutzt, ein lernendes System
zu trainieren, um Körperteile pixelweise zu identifizieren. Ein pixelweises
Verfahren eignet sich gut, da es effektiv auf Grafikkarten ablaufen kann.
Der Grund dafür ist, dass Grafikkarten über massive parallele Architekturen
verfügen. Die Genauigkeit dieses Verfahrens hängt von verschiedenen Parameter ab. Ein wichtiger Faktor ist beispielweise die Tiefe des Suchbaumes,
beim Plazieren der Pixel. Ebenso ausschlaggebend ist die Anzahl der Posen,
die zum Vergleich stehen. Je nach Wahl der Parameter liegt der durchschnittliche Fehler pro Pixel zwischen 30% und 1.2%.
10
Abbildung 7: Voronoi Diagram
7
Fazit und Ausblick
Der Structured Light Ansatz in Verbindung mit leistungsstarken Softwaresystemen, wie z.B. das Bodypart Detection Verfahren von Microsoft, ermöglichen
es einfach und kostengünstig die Bewegungen von Benutzern in Echtzeit auszuwerten. Die Kombination mehrerer Kinects sowie die Einführung höher
auflösender Structured Light Verfahren dürft in Zukunft auch intessante Alternative im professionellen Motion Capturing sein. Hierbei muss allerdings
erhöhter Aufwand für die Synchronization der Kinects betrieben werden. Die
Techniken der Kinect mögen nicht innovativ sein - ihre Kombination und An-
Abbildung 8: Motion Capture Daten
11
Abbildung 9: Zufällig erzeugte Posen
wendung hingegen schon.
Literatur
[1] PrimeSense, PrimeSense FAQ, http://www.primesense.com/?p=535 ,
2010.
[2] PrimeSense, PrimeSense FAQ, http://www.primesense.com/?p=514,
2010.
[3] David Fofi, Tadeusz Sliwa, Yvon Voisin, A comparative survey on invisible
structured light, Fofi EI2004.pdf, 2004.
[4] Yuan-Kai Wang, Kuang-You Cheng, Two-Stage Bayesian Network Method for 3D Human Pose Estimation from Monocular Image Sequences,
761460.pdf, 2009.
[5] Sergey Ten, How Kinect depth sensor works – stereo triangulation?,
http://mirror2image.wordpress.com/2010/11/30/
how-kinect-works-stereo-triangulation, 2010.
[6] play.com, Kinect Including Kinect: Adventures!, http://www.play.
com/Games/Xbox360/4-/10296372/Project-Natal/Product.html#
jump-tech, 2010.
[7] Microsoft Store, Kinect for XBox 360, http://store.microsoft.com/
microsoft/Kinect-Sensor-for-Xbox-360/product/C737B081,
Juli
2010.
[8] OpenKinect, What is the frame size/bitrate of the rgb/depth/IR
stream contained in the isochronous usb tranfers etc.?, http:
//openkinect.org/wiki/FAQ#What_is_the_frame_size.2Fbitrate_
12
of_the_rgb.2Fdepth.2FIR_stream_contained_in_the_isochronous_
usb_tranfers_etc..3F, 2011.
[9] OpenKinect,
Kinect
Protokoll,
Protocol_Documentation, 2011.
http://openkinect.org/wiki/
[10] Xsens.com,
Human
MoCap,
http://www.xsens.com/en/
company-pages/company/human-mocap/, 2011.
[11] Institute of Informatics Szeged Skeletonization , http://www.inf.
u-szeged.hu/~palagyi/skel/skel.html, 2011.
[12] metamotion.com, Gypsy 7, http://www.metamotion.com/gypsy/
gypsy-motion-capture-system.htm, 2011.
[13] Sennheiser, Hör-/Sprechgarnituren für die Luftfahrt mit aktiver
Lärmkompensation NoiseGardTM – Einführung Noisegard dt.pdf 2000.
[14] P.M. Will K.S. Pennington, GRID CODING: A PREPROCESSING TECHNIQUE FOR ROBOT AND MACHINE VISION,
10.1.1.96.2088.pdf, Pedings of the IEEE, 1972.
13

Projektgruppe Virtual Reality

Transcription

Similar documents

Leasing - Neue Lernwelten

Lehrstuhlbroschüre - Lehrstuhl für Produktentwicklung

Robert Allen Graded_Wholesale_July 2011_Layout 1

trackingsystem auf GPS Basis - Online

Linux Distribution HOWTO - The Linux Documentation Project

Robert Allen Graded_Wholesale_August 2012_Layout 1