Thesis - AIDA - Universität des Saarlandes

Transcription

Dynamische Positionierung
projizierter Displays im
instrumentierten Raum
Diplomarbeit
am Lehrstuhl für Künstliche Intelligenz
Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
Fakultät für Informatik
Universität des Saarlandes
von
Carsten Greiveldinger
30. Juni 2006
Eidesstattliche Erklärung
1
Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeit selbstständig
verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe.
Carsten Greiveldinger
Saarbrücken, den 30. Juni 2006
Danksagung
3
Ich möchte an dieser Stelle die Gelegenheit ergreifen und mich bei allen
Menschen bedanken, die durch ihre Unterstützung diese Arbeit ermöglicht haben. Prof. Wahlster und Prof. Krüger danke ich für die Möglichkeit ein so
interessantes Thema bearbeiten zu können und für die Bereitstellung der dazu
nötigen Ausrüstung. Den Mitgliedern und allen Mitarbeitern des Lehrstuhls für
Künstliche Intelligenz, die mir mit vielen fachlichen Tips und ihrer freundlichen
und kollegialen Art das Arbeiten erleichtert haben. Dabei gilt mein außerordentlicher Dank Mira und Michael, ohne deren Ratschläge, Anregungen und
Unterstützung diese Arbeit nicht geglückt wäre. Danken möchte ich ganz herzlich meinen Eltern, die mir durch ihre moralische und finanzielle Unterstützung
das Studium ermöglichten. Meiner Freundin Nadine möchte ich danken für ihr
Verständnis und ihre moralische Unterstützung. Zum Schluss, aber nicht zuletzt
gilt mein Dank denen, die die ersten Versionen dieser Arbeit Korrektur gelesen
haben und mir viele nützliche Hinweise geben konnten.
INHALTSVERZEICHNIS
5
Inhaltsverzeichnis
1 Einleitung
9
1.1
Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
Gliederung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3
Allgemeiner Hinweis zur Schreibweise . . . . . . . . . . . . . . . . 12
2 Grundlagen
9
13
2.1
Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2
FLUIDUM Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3
Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1
Dreheinheit . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.2
BeaMover . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.3
Kamera . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.4
Audiosystem . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.5
Infrarotbaken und RFID-Tags . . . . . . . . . . . . . . . . 20
2.3.6
Digitaler Kompass . . . . . . . . . . . . . . . . . . . . . . 22
2.4
Fluid Beam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5
SAFIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.6
Positionsbestimmung . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.7
Avatar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.8
2.7.1
Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.7.2
Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
The Virtual Room Inhabitant . . . . . . . . . . . . . . . . . . . . 34
2.8.1
Systemkomponenten . . . . . . . . . . . . . . . . . . . . . 34
2.8.2
Character Engine . . . . . . . . . . . . . . . . . . . . . . . 36
2.8.3
Aktuelle Erweiterung . . . . . . . . . . . . . . . . . . . . . 39
3 Verwandte Arbeiten
3.1
41
Migrating Characters . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.1.1
STEVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.1.2
MAEVIF . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.1.3
WhizLow . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
INHALTSVERZEICHNIS
3.2
3.3
3.4
6
3.1.4
Virtual Augsburg . . . . . . . . . . . . . . . . . . . . . . . 47
3.1.5
PEACH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.1.6
Resümee . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Raum- und Objektmodelle . . . . . . . . . . . . . . . . . . . . . . 55
3.2.1
CAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.2.2
Akustik . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.2.3
Computergraphik . . . . . . . . . . . . . . . . . . . . . . . 57
3.2.4
3.2.5
Resümee . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Wegenetze und Wege . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.3.1
3.3.2
Navigation in der Fußgängerzone . . . . . . . . . . . . . . 60
3.3.3
Navigation mittels RFID . . . . . . . . . . . . . . . . . . 62
3.3.4
Resümee . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4 Lösungsansatz
67
4.1
Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.2
Raummodell
4.3
Wegenetz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.4
Wege durch den Raum . . . . . . . . . . . . . . . . . . . . . . . . 81
4.5
Avatar Verhalten . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.6
Datensicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5 Implementierung des Systems
89
5.1
Sprache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.2
Portierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.3
Objektmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.4
Raummodell
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.4.1
Raum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.4.2
Wand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.4.3
Freie Darstellungsfläche . . . . . . . . . . . . . . . . . . . 94
INHALTSVERZEICHNIS
5.4.4
5.5
5.6
Hindernis . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Wegenetz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.5.1
Struktur des Wegenetz . . . . . . . . . . . . . . . . . . . . 96
5.5.2
Erzeugen des Wegenetzes . . . . . . . . . . . . . . . . . . 96
Wege durch den Raum . . . . . . . . . . . . . . . . . . . . . . . . 98
5.6.1
5.7
7
Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Avatar-Verhalten . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.7.1
Endlicher Automat . . . . . . . . . . . . . . . . . . . . . . 99
5.7.2
Subsumptionsansatz . . . . . . . . . . . . . . . . . . . . . 101
5.8
Avatar-Bewegung . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.9
Datensicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6 Zusammenfassung und Ausblick
107
6.1
Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.2
Einsatzmöglichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.3
Erweiterung des Systems . . . . . . . . . . . . . . . . . . . . . . . 110
7 Codeauszüge
Literatur
Abbildungsverzeichnis
Index
113
I
XI
XIII
1
EINLEITUNG
1
1.1
9
Einleitung
Einführung
In der heutigen Zeit spielt die Technik eine immer größere Rolle in unserem Leben. Nicht nur im beruflichen Umfeld, sondern auch an öffentlichen wie privaten
Plätzen werden wir mit einer Fülle von technischen Geräten konfrontiert. Mit
dem ständigen technologischen Fortschritt werden die Geräte immer kleiner und
unauffälliger, und in den letzten Jahren werden die Einzelgeräte immer häufiger
miteinander vernetzt. Die Entwicklung der vergangenen Jahrzehnte bewegt sich
vom Main Frame“-System, an dem mehrere Benutzer gleichzeitig arbeiteten,
”
hin zum Desktop-System, an dem ein einzelner Benutzer arbeitet. Mittlerweile
ist diese Entwicklung an einem Punkt angelangt, an dem ein einzelner Benutzer mehrere Geräte gleichzeitig nutzt. Dieser Trend wird sich in Zukunft noch
verstärken, wodurch wir fast überall in unserem Alltag mit unterschiedlichen
Geräten zu tun haben werden.
Das Ubiquitous Computing“ [Weiser06], [Weiser], [Mattern] beschäftigt
”
sich mit der Integration von Rechnern in unsere Umgebung, die dazu führt,
dass wir sie nicht mehr als einzelne Geräte wahrnehmen. Ziel ist es, die Geräte
so zu integrieren, dass die Benutzer sie intuitiv bedienen können, ohne daran erinnert zu werden, dass sie gerade mit einem oder mehreren Computern arbeiten.
Eine Möglichkeit, diesen Ansatz umzusetzen, sind sogenannte instrumentierte
”
Umgebungen“, bei denen einzelne Einrichtungsgegenstände oder ganze Räume
mit Computern und anderen technischen Geräten ausgestattet werden. Solche
Räume können mit den unterschiedlichsten Geräten ausgestattet sein, wie zum
Beispiel dem in [FLUIDUM06] beschrieben instrumentierten Tisch.
Mit der fortschreitenden Entwicklung des Bereichs Ubiquitous Computing“
”
werden unter anderem Bildschirme als Schnittstelle zum Benutzer immer wichtiger. Zwar geht der Trend in der Entwicklung zu immer größeren Bildschirmen,
aber dennoch ist es nicht möglich, einen ganzen Raum mit Bildschirmen so
1
EINLEITUNG
10
auszustatten, dass an beinahe jeder Stelle etwas dargestellt werden kann. Mit
Hilfe von Projektoren kann dieses Manko kompensiert werden, weshalb sie eine
wichtige Rolle bei visuellen Ausgaben in instrumentierten Umgebungen spielen.
Das Thema dieser Diplomarbeit ist das dynamische Positionieren von projizierten Displays, welche von einem Projektor in einer instrumentierten Umgebung erzeugt werden. Die instrumentierte Umgebung, in der diese Arbeit
entwickelt wurde, ist der instrumentierte Raum“ am Lehrstuhl für Künstliche
”
Intelligenz von Herrn Prof. Dr. Dr. h.c. mult. Wahlster an der Universität des
Saarlandes. Der instrumentierte Raum“ (Fluid Room) wurde im Rahmen des
”
FLUIDUM“-Projekts [FLUIDUM06] eingerichtet und basiert auf einer übli”
chen Büroumgebung (siehe Kapitel 2.2).
In einem instrumentierten Raum befindet sich eine Vielzahl von Geräten,
deren Bedienung intuitiv für den Benutzer sein sollte. Da nicht alle Geräte
selbsterklärend sind, müssen manche Geräte, die es nicht sind, dem Benutzer
vorgestellt werden. Zur Lösung dieser Aufgabe wird in [KrSpSc2] ein Avatar
(siehe 2.7) benutzt, der auf einem projizierten Display auf den Oberflächen
des instrumentierten Raums dargestellt wird. Wegen seiner deutlich sichtbaren
Präsenz verspricht das Konzept eines Avatars als Kontaktperson“ für den Be”
nutzer ein hohes Maß an Akzeptanz und somit auch an Effektivität. Beides kann
noch verbessert werden, wenn der Avatar auf den Benutzer reagiert und ihm begleitend zur Seite steht. Dazu muss er sich jedoch frei bewegen können, was mit
Hilfe der dynamisch positionierbaren Displays in dieser Diplomarbeit erreicht
wurde. Die Verwendung der Displays als Darstellungsfläche für einen Avatar
ist natürlich nur eine von vielen Anwendungsmöglichkeiten. Das in [KrSpSc2]
vorgestellte System wird als Anwendungsfall zur Demonstration der Funktionalität des Systems im Rahmen dieser Arbeit verwendet.
1
EINLEITUNG
1.2
11
Gliederung der Arbeit
Nach der soeben erfolgten Einstimmung auf das Thema dieser Diplomarbeit,
werden in Kapitel 2 die der Arbeit zu Grunde liegenden, bereits bestehenden Systemkomponenten erläutert. Dazu gehören die verwendete Hardware, die
im instrumentierten Raum installiert ist, genauso wie die auf dieser Hardware
aufbauenden Software-Systeme, die in den vergangenen Jahren am Lehrstuhl
entwickelt wurden. Dazu gehören eine drehbare Projektor-Kamera-Einheit, ein
räumliches Audiosystem, ein System zur Positionsbestimmung in Gebäuden
und ein Avatar, der im instrumentierten Raum lebt“.
”
Anschließend wird in Kapitel 3 ein Überblick über die Thematik der 3
Hauptkomponenten dieser Arbeit gegeben:
• Virtuelle Character, die mit dem Benutzer interagieren
• Ein Raummodell der betrachteten Umgebung
• Wegenetze
Nach diesem Überblick werden in Kapitel 4 die theoretischen Ansätze zur
Lösung der Aufgabenstellung dieser Arbeit erläutert, wie das entwickelte Raummodell, das Wegenetz und der Algorithmus zum Finden optimaler Wege, sowie
das Verhaltensmodell des Systems.
Die praktische Umsetzung der theoretischen Ansätze wird in Kapitel 5 detailliert veranschaulicht und mit Abbildungen verdeutlicht.
Abschließend wird im letzten Kapitel eine kurze Zusammenfassung der Arbeit gegeben sowie ein kurzer Ausblick auf zukünftige Einsatzmöglichkeiten und
eventuelle Erweiterungen des entwickelten Systems.
1
EINLEITUNG
1.3
12
Allgemeiner Hinweis zur Schreibweise
Für eine gleichberechtigte Ausdrucksweise müsste entweder die männliche und
die weibliche Schreibweise in zwei getrennten Wörtern hintereinander geschrieben oder jene mit großem I“ verwendet werden. Da dies das flüssige Lesen
”
erschwert, wird in der vorliegenden Arbeit die weibliche Schreibweise konsequent weggelassen. Ich bitte insbesondere die Leserinnen dies zu entschuldigen.
2
GRUNDLAGEN
2
13
Grundlagen
2.1
Aufgabenstellung
Das Ziel dieser Diplomarbeit war es, ein System zu entwickeln und zu implementieren, mit dessen Hilfe projizierte Displays zur Laufzeit dynamisch positioniert
werden können.
Die Displays werden auf beliebige Oberflächen im instrumentierten Raum
projiziert und dienen der Interaktion mit dem Benutzer. Daraus ergibt sich die
Notwendigkeit, dass die Displays möglichst in der Nähe des Benutzers sind und
auch bei dem Benutzer bleiben, selbst wenn sich dieser bewegt.
Dazu ist es erforderlich, die Möglichkeiten der bestehenden Systeme des
instrumentierten Raums zu identifizieren, um anschließend ihre spezifischen
Fähigkeiten zu kombinieren und gegebenenfalls zu erweitern. Das System soll
in die Java-Architektur des instrumentierten Raums integriert werden, so dass
es ohne Probleme in Zukunft erweiterbar ist.
Eine Voraussetzung für das System ist die Positionierung der projizierten
Displays in Echtzeit unter Berücksichtigung des Verhaltens des Benutzers, seiner Position und Blickrichtung, sowie der räumlichen Gegebenheiten. Damit
ist gemeint, dass die Displays während einer Bewegung von einem zu einem
anderen beliebigen Punkt auf einer Oberfläche im Raum nicht mit einem Einrichtungsgegenstand oder einer Raumstruktur kollidieren dürfen.
Mit Hilfe der projizierten Displays soll ein Avatar auf die Oberflächen des
instrumentierten Raums projiziert werden, dessen Gestiken und Bewegungen
mit den Bewegungen der Displays und der Umgebung synchronisiert werden
müssen. Die Bewegungen sollten mit Hilfe eines Wegenetzes, das sich über die
möglichen Darstellungsflächen im Raum erstreckt, systematisiert und optimiert
werden. Auf diese Weise soll es dem System ermöglicht werden, schnell und ef-
2
GRUNDLAGEN
14
fizient auf das Verhalten des Benutzers reagieren zu können.
2.2
FLUIDUM Projekt
Die DFG-geförderte FLUIDUM Forschungsgruppe (Flexible User Interfaces for
Distributed Ubiquitous Machinery) [FLUIDUM06] beschäftigt sich mit com”
putergestützten Interaktionstechniken und Ausdrücken für überall vorhandene
Rechner (Ubiquitous Computing)“ [FLUIDUM06].
Dies bedeutet, dass Möglichkeiten und Szenarien erforscht werden, in denen
sich der Benutzer in einer Umgebung befindet, die mit Technologie angereichert ist. Eine solche instrumentierte Umgebung ist ein Raum, in dem man
jeden Tag ist, wie zum Beispiel Büro- und Wohnumgebungen, die mit verschiedenen Technologien, wie etwa einem Projektor oder Touchscreen, ausgestattet
sind. An der Ludwig-Maximilians- Universität München und der Universität
des Saarlandes in Saarbrücken ist jeweils ein solcher instrumentierter Raum installiert. In den Räumen befinden sich unter anderem ein großer Bildschirm mit
Touchscreen-Funktionalität, ein Infrarot-System zur Positionsbestimmung, ein
räumliches Audio-System, ein beweglicher Projektor und Kameras. Durch die
verschiedenen Techniken wurden die Einrichtung des Raums und die Wände,
die als Displayflächen verwendet werden, zu interaktiven Schnittstellen für den
Benutzer.
Seit 2003, dem Projektstart sind mehrere Prototypen für Interaktionssysteme entstanden, aus denen man versucht, allgemeingültige Bedienkonzepte
herzuleiten. Ein solcher Prototyp ist zum Beispiel ein interaktiver Schreibtisch,
dessen Tischplatte als Bildschirm und Eingabemedium zugleich genutzt wird.
Diese Diplomarbeit nutzt den instrumentierten Raum am Lehrstuhl für
Künstliche Intelligenz von Prof. Wahlster an der Universität des Saarlandes
in Saarbrücken als Testumgebung. In Abbildung 1 ist ein Teil der installier-
2
GRUNDLAGEN
15
ten Hardware zu sehen. Der Teil der im instrumentierten Raum installierten
Hardware, die das in dieser Arbeit entwickelte System nutzt, wird im folgenden
Kapitel (2.3) detailliert beschrieben.
Abbildung 1: Der instrumentierte Raum am Lehrstuhl für Künstliche Intelligenz
an der Universität des Saarlandes, Quelle:[Wahlster05]
2.3
Hardware
Die im Rahmen dieser Diplomarbeit verwendete Hardware ist im instrumentierten Raum installiert. Die einzelnen Bestandteile wurden in unterschiedlichen
Projekten, Studien- und Forschungsarbeiten entwickelt und genutzt.
In diesem Kapitel wird ein kurzer Überblick über die Geräte, die im Rah-
2
GRUNDLAGEN
16
men dieser Diplomarbeit verwendet werden gegeben, um in den anschließenden
Kapiteln das mit dieser Hardware realisierte System vorzustellen.
Die verwendeten Geräte sind eine steuerbare Dreheinheit, an der ein Projektor und eine Kamera befestigt sind, mit deren Hilfe Displays auf die Oberflächen
im Raum projiziert werden, des Weiteren ein Audiosystem, mit dessen Hilfe beliebige Klänge räumlich positioniert werden. Fest installiert am Lehrstuhl von
Prof.Wahlster, und so auch im instrumentierten Raum, ist ein System das mit
Hilfe von Infrarotbaken und RFID-Tags die Position von Benutzern feststellt.
Die Mobile Hardware besteht aus einem digitalen Kompass, der die Blickrichtung des Benutzers ermittelt, sowie einem PDA (Personal Digital Assistant),
der im Rahmen des Infrarot-Systems zur Bestimmung der Benutzerposition verwendet wird.
2.3.1
Dreheinheit
Die Dreheinheit wird dazu verwendet einen Projektor auf einen bestimmten
Punkt im Raum auszurichten. Ursprünglich wurde diese Technik zur Beleuchtung von Bühnen und Studios entwickelt und wird unter dem Namen Moving
Yoke von der Firma Amptown Lichttechnik GmbH [Amptown06] hergestellt
und vertrieben.
Die Dreheinheit besteht aus einer rechteckigen Basisplattform, an der sie im
Raum befestigt wird, und einer darauf drehbar gelagerten u-förmigen Halterung.
In dieser Halterung kann zum Beispiel ein Scheinwerfer oder wie in unserem
Fall, ein Projektor, schwenkbar angebracht werden. Das so platzierte Objekt
ist dann um zwei Achsen drehbar, in horizontaler Richtung um ca. 340 Grad, in
vertikaler Richtung um ca. 270 Grad. Die Ausrichtung der Dreheinheit erfolgt
mittels zweier Motoren. Ein Computer spricht über ein USB/DMX-Interface
die 4 DMX Kanäle des Moving Yoke an, über die die Motoren gesteuert werden.
2
GRUNDLAGEN
17
DMX ist ein üblicherweise bei Bühnenshows benutztes Protokoll zur Steuerung der Beleuchtung, das mit 8-Bit Technologie arbeitet.
Die Ungenauigkeit der Motoren lässt dabei keine exakte Platzierung des
Bildes auf der Projektionsfläche zu. Ist die Projektionsfläche ca. 2m entfernt, so
kann das Bild bis auf etwa 1cm genau platziert werden, was jedoch im Rahmen
dieser Diplomarbeit völlig ausreichend ist.
2.3.2
BeaMover
Der BeaMover ist ein für die Musik-, Theater-, Film- und Studiobranche entwickelte Konstruktion bestehend aus einer mechanischen Dreheinheit (dem in
Kapitel 2.3.1 beschriebenen Moving Yoke) und einem lichtstarken Projektor.
Der verwendete Projektor ist der Sanyo PLC-XP41, der mit einer Lichtstärke
von 3.300 ANSI Lumen ein genügend helles Bild projiziert, so dass das System
problemlos auch in nicht abgedunkelten Räumen genutzt werden kann. Sollte
dies trotzdem nicht ausreichen, so ist der BeaMover auch mit noch stärkeren
Projektoren erhältlich.
Vertrieben wird der BeaMover von der Firma Publitec Präsentationssyste”
me & Eventservice GmbH“ [BeaMover06].
Von Vorteil beim BeaMover ist die Möglichkeit, die Funktionen des Projektors, wie Zoom, Fokus, Bildumkehr etc. über das gleiche DMX-Interface zu
steuern wie die Dreheinheit. Für die Steuerung der Funktionen des Projektors
werden 8 DMX-Kanäle verwendet.
So ist es mit dem BeaMover möglich, zum einen ein Bild an beinahe jede
Stelle im Raum zu projizieren und zum anderen dieses Bild dann während der
Projektion zu verschieben. Dazu ist das System an der Decke des instrumentierten Raums befestigt, wie man in Abbildung 2 erkennt. Am Projektor ist
2
GRUNDLAGEN
18
die in Kapitel 2.3.3 beschriebene Kamera befestigt, die von dem in Kapitel 2.4
beschriebenen Fluid Beam“-System benutzt wird.
”
Abbildung 2: Die Projektor-Kamera-Einheit an der Decke des instrumentierten
Raums.
Beim Positionieren und Verschieben von projizierten Bildern treten leider
unschöne Effekte auf. Die dargestellten Bilder werden wegen der verschiedenen
Blickwinkel des Projektors auf die Darstellungsflächen nicht verzerrungsfrei auf
die jeweilige Darstellungsfläche projiziert. Das Problem des verzerrungsfreien
Projizierens auf beliebige Flächen im Raum löst das in Kapitel 2.4 vorgestellte
Fluid Beam“-System [Spassova].
”
2
GRUNDLAGEN
2.3.3
19
Kamera
Im Rahmen des Fluid Beam“-Systems [Spassova] wurde eine Kamera am Pro”
jektor befestigt, mit deren Hilfe Marker und Gestiken erkannt werden. Die Kamera wurde dazu am Projektor befestigt, damit sie frei gedreht werden kann
und sie so die projizierten Bilder überblickt. Die im folgenden Abschnitt vorgestellte Kamera, nimmt die zum Erkennen von Markern und Gestiken nötigen
Bilder und Videos des instrumentierten Raums auf.
Die verwendete Kamera ist vom Typ PowerShot S45 von Canon mit einer maximalen Auflösung von 4 Megapixeln. Sie hat einen 3-fachen optischen
und 3,6-fachen digitalen Zoom und kann ein Videosignal mit 15 Bildern pro
Sekunde liefern. Canon stellt im Internet eine Software bereit, mit der man die
Kamera vom PC aus bedienen kann. Dazu wird sie über ein USB- bzw. ein
Videokabel mit dem Rechner verbunden, über das auch das Videosignal mit
einer Framegrabber-Karte ausgelesen wird.
Für das Fluid Beam“-System ist es wichtig, dass die Bilder der Kamera
”
aus einem anderen Blickwinkel aufgenommen werden, wie dem des Projektors,
der das Bild projiziert hat. Durch eine Verschiebung zur optischen Achse des
Projektors ist eine Triangulierung zu Markern möglich, mit deren Hilfe das System kalibriert werden kann. Aus diesem Grund wurde die Kamera so weit wie
möglich versetzt zur optischen Achse des Projektors befestigt, wie man in Abbildung 2 erkennen kann.
2.3.4
Audiosystem
Das Audiosystem verteilt Klänge durch eine gezielte Ansteuerung von mehreren
Boxen so, dass der jeweilige Klang vom Benutzer räumlich positioniert wahrgenommen wird.
Im instrumentierten Raum wurden acht Boxen vom Typ JBL Control 1
2
GRUNDLAGEN
20
Xtreme aufgehängt, die von zwei Verstärkern des Modells RX-V430RDS der
Firma Yamaha betrieben werden. Bei der Auswahl der Komponenten wurde
nach [Schmitz] darauf geachtet, ausschließlich Komponenten einzusetzen, welche im Heimanwenderbereich verfügbar sind und kostengünstig angeschafft werden können.
Die acht Lautsprecher wurden in gleicher Höhe knapp unter der Decke aufgestellt, um den Klang nicht durch Gegenstände oder mehrere Benutzer, die
sich gleichzeitig im Raum aufhalten, zu beeinträchtigen. Die räumliche Wahrnehmung wird hierdurch nicht besonders beeinträchtigt, da die menschliche
Richtungswahrnehmung in der horizontalen Ebene am genauesten ist. Im Gegensatz dazu ist die vertikale Sensibilität des Gehörs deutlich geringer, weshalb
eine vertikale Verschiebung kaum auffällt.
2.3.5
Infrarotbaken und RFID-Tags
In den Räumlichkeiten des Lehrstuhls für Künstliche Intelligenz von Prof.
Wahlster ist das in Kapitel 2.6 beschriebene System zur Bestimmung der
Position von Benutzern installiert. Dieses System greift zur Bestimmung der
Benutzerposition einerseits auf Infrarotbaken und andererseits auf RFID-Tags
zurück (siehe Abbildung 3), die in den Lehrstuhlräumen angebracht sind und
deren Signale von einem PDA aufgenommen werden.
Die Infrarotbaken werden von der Firma Eyeled GmbH“ [Eyeled06] herge”
stellt. In den von Eyeled vertriebenen Systemen werden sie zum Beispiel dazu
genutzt PDA-Besitzer durch Gebäude zu navigieren oder um objektbezogene
”
Informationen auf den PDAs anzuzeigen“ [Eyeled06].
Dazu senden die batteriebetriebenen Baken einen 16 Bit Code, der für jede
Bake individuell eingestellt werden kann. Der von der Bake ausgehende, kegelförmige Sendebereich ist ungefähr 6 Meter lang. Der Empfangssensor ist bei
2
GRUNDLAGEN
21
Abbildung 3: Der PDA mit RFID-Kartenleser (links), eine Infrarotbake (mitte)
und ein RFID-Tag (rechts), Quelle:[BrandSch]
fast allen PDAs schon integriert und wird normalerweise zum Datenaustausch
genutzt.
Die Radio Frequency Identification (RFID)-Tags sind in zwei unterschiedlichen Varianten erhältlich und können von einem speziellen Lesegerät mit Hilfe
eines Radiosignals ausgelesen werden.
Passive RFID-Tags beziehen ihre Energie aus dem Radiosignal des Lesegeräts, weshalb sie nur eine Reichweite von etwa 15 Zentimetern haben. Zur
Positionsbestimmung eines sich bewegenden Benutzers sind sie folglich ungeeignet.
Aktive RFID-Tags sind batteriebetrieben und haben eine deutlich höhere
2
GRUNDLAGEN
22
Reichweite. Die am Lehrstuhl verwendeten Modelle der Firma Identec Soluti”
ons AG“ [Identec06] haben eine Reichweite von etwa 10 Metern. Im Gegensatz
zu den Infrarotbaken wird das Signal der RFID-Tags radial ausgesendet, ist also
richtungsunabhängig. Außerdem ist kein direkter Sichtkontakt zwischen Sender
und Empfänger nötig, wie es bei den Infrarotbaken der Fall ist.
Dieses Signal wird mit Hilfe eines PCMCIA-Kartenleser in Verbindung mit
dem PDA ausgelesen. In Abbildung 3 sind der verwendete PDA vom Typ HP
iPAQ h5550 mit PCMCIA RFID-Kartenleser, eine Infrarotbake und ein RFIDTag abgebildet.
2.3.6
Digitaler Kompass
Zur Ergänzung des in Kapitel 2.6 beschriebenen Systems zur Erkennung der Benutzerposition wird ein digitaler Kompass benutzt, mit dessen Hilfe die Blickrichtung des Benutzers ermittelt wird. Der digitale Kompass wird von der Firma
Vectronics AG“ [Vectronics06] hergestellt und vertrieben und findet Verwen”
dung in verschiedenen Gebieten zur Koppelnavigation, wie zum Beispiel dem
Militär oder der Seefahrt.
Dank seines geringen Gewichts von weniger als 35 Gramm und den geringen
Abmessungen von nur wenigen Zentimetern behindert das Gerät den Benutzer
nicht. Der Kompass zeigt die Richtung bezogen auf 360 Grad mit einer Ungenauigkeit von einem Grad an. Abbildung 4 zeigt den verwendeten DRC (Dead
Reckoning Compass). Die vom Kompass ermittelten Richtungsdaten werden
auf einen Event-Heap [Johanson] gelegt, so dass sie jederzeit abrufbar sind.
Der Kompass sollte am Benutzer so angebracht werden, dass er aussagekräftige Richtungsdaten liefert. Möglich wäre eine Installation an einem PDA,
einer Armbanduhr oder einem Stirnband. Die Befestigung an der Hose oder an
einem Gürtel den der Benutzer trägt ist jedoch sinnvoller, da sich die Körper-
2
GRUNDLAGEN
23
Abbildung 4: Der Vectronics DRC Kompass, Quelle:[Vectronics06]
mitte sowohl bei Bewegungen als auch beim Stehen am wenigsten bewegt. Bei
einer Befestigung am Kopf wird die Blickrichtung am genauesten erfasst.
2.4
Fluid Beam
Das Fluid Beam-System[Spassova] wurde im Rahmen des FLUIDUM -Projekts
als Diplomarbeit entwickelt. Ziel der Arbeit war es, ein System zu entwickeln
”
und zu implementieren, das Projektionen auf beliebige Flächen in einer instrumentierten Umgebung realisiert“ [Spassova]. Diese Projektionen werden verzerrungsfrei auf den Darstellungsflächen im instrumentierten Raum abgebildet.
Die Darstellungen werden mit Hilfe des in Kapitel 2.3.2 vorgestellten
BeaMovers auf die gewünschte Fläche projiziert. Die Grundidee zum Entzerren
der projizierten Bilder auf den Flächen folgt der Tatsache, dass die Projektion
eines Bildes eine Umkehrung der Aufnahme des Bildes ist. Sofern die Kamera,
von der das Bild aufgenommen wurde, und der Projektor, der das Bild
projiziert, sich an der gleichen Stelle befinden und die gleichen optischen
Eigenschaften haben.
In Abbildung 5 wird dieser Sachverhalt für ein projiziertes Rechteck veran-
2
GRUNDLAGEN
24
Abbildung 5: Aufhebung von Projektionsverzerrung mit Kameraverzerrung,
Quelle: [Spassova]
schaulicht. Diese Vorgehensweise ist für eine einzelne Stelle auf einer Fläche gut
durchführbar. Da das Ziel aber die Projektion an beliebige Positionen auf beliebigen Flächen ist, müsste man jede Stelle auf jeder Fläche in der Umgebung des
Beamers, aus seiner Sicht fotografieren, was theoretisch unendlich viele Bilder
wären.
Da dies nicht praktikabel ist, wurde ein virtuelles 3D-Modell der Umgebung
mit der Java 3D-Bibliothek [?] erstellt. Dieses Modell besteht aus den dem Projektor zugewandten Flächen. An die Position des Projektors ist im Modell eine
virtuelle Kamera platziert, die so die virtuellen Objekte aus der Perspektive
des Projektors aufnimmt. Projektor- und Kamerabewegungen sind synchronisiert, wodurch die Objekte stets entsprechend verzerrt aufgenommen werden,
und korrekt entzerrt vom Projektor auf den Oberflächen im Raum dargestellt
2
GRUNDLAGEN
25
werden.
Man erhält den Eindruck eines virtuellen Layers, der alle Oberflächen im
Raum überzieht. Auf diesem virtuellen Layer können virtuelle Objekte an beliebige Positionen platziert werden. Der Projektionsstrahl wirkt dabei wie eine
virtuelle Taschenlampe. Wenn der Projektor auf die Position im realen Raum
gerichtet wird, an der sich im virtuellen Raum ein solches Display befindet, so
wird dieses Display im realen Raum vom Projektor verzerrungsfrei dargestellt.
Sobald der Projektionsstrahl nicht mehr auf das virtuelle Display gerichtet ist,
wird es nicht mehr angezeigt, obwohl es noch immer an seiner Stelle ist.
Das Fluid Beam“-System fokussiert automatisch, wodurch der Projektor
”
beliebig gedreht und geschwenkt werden kann, ohne dass das dargestellte Bild
unscharf wird. Es wurden Methoden implementiert, die das Projizieren von Bildern, MPEG Videos und Live-Streams ermöglichen.
Das Fluid Beam-System wurde in ein RMI [RMI06] Interface eingebettet,
wodurch es von beliebigen Rechnern aus bedient werden kann. Es stellt verschiedene Funktionen zur Ausrichtung des Projektors auf eine Stelle im Raum
und verzerrungsfreien Projektion von Bild- und Videoausgaben dorthin bereit.
Die vom System benutzte Hardware wurde in den Kapiteln 2.3.1 (Dreheinheit),
2.3.2 (BeaMover) und 2.3.3 (Kamera) beschrieben. Das Fluid Beam-System
wird in dem in Kapitel 2.8 beschriebenen System zur Darstellung und Positionierung von Displays in der instrumentierten Umgebung genutzt, welches ein
wichtiger Bestandteil dieser Diplomarbeit ist.
2.5
SAFIR
Das SAFIR-System [SAFIR] wurde im Rahmen des FLUIDUM Projekts als
Diplomarbeit entwickelt. SAFIR steht für Spatial Audio Framework for Instrumented Rooms und ist der Name einer Softwareplattform, die es erlaubt,
”
2
GRUNDLAGEN
26
beliebige Klänge programmgesteuert an beliebigen Stellen im Raum ertönen
zu lassen“ [Schmitz]. Besonders an diesem System ist, dass es möglich ist,
die Klänge auch dann an der entsprechenden Position der virtuellen Schallquelle wahrzunehmen, wenn man sich nicht an der optimalen Benutzerposition
(Sweet-Spot) befindet. Bei den üblichen Surround-Systemen, die zum Beispiel
im Home-Entertainment Bereich verwendet werden, ist das jeweilige System
auf eine optimale Benutzerposition und Blickrichtung ausgelegt, den sogenannten Sweet Spot. Das SAFIR System kann deshalb sogar von mehreren Benutzern gleichzeitig verwendet werden, ohne dass es zu größeren Qualitätseinbußen
kommt. Es wurde so entwickelt, dass man die Klänge nicht nur in der horizontalen Ebene wahrnimmt, sondern mit der geeignet installierten Hardware
(zusätzlich vertikal aufgestellte Lautsprecher) die Klänge dreidimensional im
Raum verteilen kann.
Das System benötigt verschiedene Parameter zum Betrieb, welche die Positionen der Lautsprecher, der virtuellen Schallquellen und des Benutzers sind.
Dabei sind nur die Positionen der Lautsprecher in Dateien gespeichert, die anderen Parameter werden dem System zur Laufzeit übergeben.
Eine Eigenschaft von Schall, die dem menschlichen Gehör ein Gefühl von
räumlicher Distanz vermittelt, ist der Effekt, dass Schall an Oberflächen reflektiert wird. Bei der Erstellung von SAFIR wurde zur Vereinfachung eine Kugel
als Raummodell angenommen, was bei der Berechnung von Reflektionen mehrere Vorteile hat. Zum einen kommen durch das Kugelmodell die reflektierten
Klänge aus der gleichen Richtung wie der ursprüngliche Klang, wodurch keine
weiteren virtuellen Schallquellen berechnet werden müssen. Zum anderen kommen die Klänge aus einer Schallquelle so immer aus der gleichen Richtung, wodurch die Lokalisierung dieser Schallquelle auch bei mehreren Benutzern nicht
beeinträchtigt wird.
Eine weitere wichtige Eigenschaft von Schall ist der sogenannte Doppler
”
2
GRUNDLAGEN
27
Effekt“, der ebenfalls vom SAFIR-System erzeugt wird. Er tritt auf, wenn sich
eine Schallquelle bewegt, was eine Änderung der Frequenz der Klänge zur Folge
hat.
Das SAFIR System wird in dem in Kapitel 2.8 beschriebenen System dazu
genutzt, Audioausgaben in einen räumlichen Zusammenhang mit den projizierten Displays zu bringen. So ist es möglich, dass der Benutzer sich ohne
Kopfhörer frei durch den instrumentierten Raum bewegen und trotzdem vom
System erzeugte Klänge an beliebigen Positionen hören kann.
2.6
Positionsbestimmung
Die Position zu kennen, an der sich der Benutzer gerade aufhält, ist für viele
Anwendungen essenziell. Insbesondere ist dieses Wissen wichtig zur Umsetzung
dieser Diplomarbeit, denn nur so kann gewährleistet werden, dass sich der Benutzer und die projizierten Displays in einer geeigneten Position zueinander
befinden.
Im Freien könnte man diese Aufgabe mit Hilfe des bekannten Global Positioning System (GPS) bewältigen, was jedoch in geschlossenen Räumen auf
Grund der fehlenden Satellitenverbindung nicht zu realisieren ist.
Am Lehrstuhl für Künstliche Intelligenz von Prof. Wahlster an der Universität des Saarlandes wurde ein System (siehe [BrandSch]) integriert, das die Position des Benutzers bestimmt und diesen zu ausgewählten Punkten innerhalb
des Gebäudes navigieren kann. Die Autoren des Artikels legten beim Entwurf
des System besonderes Augenmerk auf geringen Rechen- und Speicherbedarf,
”
so dass es auf einem mobilen System (wie dem Hewlett-Packard iPAQ) implementiert und ausgeführt werden kann“[BrandSch].
Prinzipiell gibt es zwei Varianten von Systemen zur Ortsbestimmung. Zum
2
GRUNDLAGEN
28
einen die, bei denen der Benutzer einen Sender trägt und in der Umgebung, in
der er sich bewegt, Sensoren eingebettet sind. In [BrandSch] werden diese Systeme exozentrisch“ genannt, da der Sender des Benutzers aktiv seine Position
”
angibt.
Zum anderen gibt es die egozentrischen“ Systeme, bei denen die Sender
”
in der Umgebung platziert wurden und der Benutzer einen mobilen Empfänger
mit sich führt, der dann die jeweilige Position berechnet. Das System weiß bei
dieser Methode nichts über die Position des Benutzers, er kann selbst entscheiden, ob er sie dem System mitteilt (etwa über Wireless LAN) oder eben nicht.
Das realisierte System verwirklicht den egozentrischen“ Ansatz, in dem es
”
die in Kapitel 2.3.5 beschriebenen Infrarotbaken (siehe [Eyeled06]) und RFIDTags (siehe [Identec06]) benutzt, welche in der Lehrstuhl-Umgebung installiert
sind.
Da die Sensoren keine absolut exakten Positionswerte liefern, ist es notwendig, die Benutzerposition mit einem probabilistischen Verfahren zu ermitteln.
Dazu werden dynamische Bayes’sche Netze (DBN) benutzt, die eine Erweiterung zu Bayes’schen Netzen (BN) sind. Mit Hilfe von Bayes’schen Netzen kann
man Entscheidungen unter Unsicherheit treffen, indem die Unsicherheit mit
Bayes’schen Wahrscheinlichkeiten modelliert wird. Bei DBNs kommt nun eine
Erweiterung hinzu, wodurch dynamische Prozesse modelliert werden können.
Wenn eine Infrarotbake oder RFID-Tag vom PDA erfasst wurde, wird ein
neues Geo referenziertes dynamisches Bayes’ sche Netzwerk“ [BrandSch] in”
stantiiert, und mit den Koordinaten des entsprechenden Geräts assoziiert. Die
Koordinaten werden nun gewichtet gegeneinander mit Wahrscheinlichkeiten
aufgerechnet, wodurch sich die erwartete Benutzerposition nach folgender Formel ergibt:
2
GRUNDLAGEN
U serP os(t) =
29
n
X
αω(GeoDBN [i])GeoP os(GeoDBN [i])
i=1
Dabei ist n die Anzahl an DBN zur Zeit t, GeoPos ( GeoDBN[i] ) ist die
Koordinate und ω(GeoDBN [i]) das Gewicht des i-ten GeoDBN. α ist ein Normalisierungsfaktor, der sicher stellt, dass die Summe aller Gewichte multipliziert
mit α 1 ergibt. Zur Effizienzsteigerung der Berechnung werden DBN mit einem
Gewicht, das unterhalb eines Schwellenwertes liegt, ignoriert.
Die so gewonnenen Positionswerte, werden vom PDA über Wireless LAN
zum Event-Heap [Johanson] weitergeleitet, von wo aus sie bei Bedarf abgerufen
werden können.
In Abbildung 6 sieht man einen begangenen Testweg durch die Räume des
Lehrstuhls. Die Strichmännchen zeigen die vom System berechneten Positionen
an, und die Kreise um die Strichmännchen herum die tatsächlichen Bereiche in
denen der Benutzer war.
Da die Positionsbestimmung, insbesondere im instrumentierten Raum, nicht
exakt genug ist für diese Diplomarbeit, wurden zusätzliche Infrarotbaken installiert. Hierdurch erhöhte sich die Genauigkeit des Systems auf das geforderte
Maß.
2.7
Avatar
Alle bisher beschriebenen Geräte sind im instrumentierten Raum installiert.
ER ist nicht nur ein Raum mit einer Ansammlung verschiedener miteinander
vernetzter Instrumente, der Raum ist sogar bewohnt“. Der virtuelle Bewoh”
”
ner“ des instrumentierten Raums ist ein weiblich aussehender Avatar namens
2
GRUNDLAGEN
30
Abbildung 6: Ein Testweg durch die Räume des Lehrstuhls für Künstliche Intelligenz, zum Testen des Positinierungssystems, Quelle: [BrandSch]
Minnie, der im Rahmen des in Kapitel 2.8 beschriebenen Systems eingesetzt
wird. An dieser Stelle wird nun kurz erläutert was ein solcher Avatar eigentlich
ist.
2.7.1
Definition
Dass ein Raum von Menschen oder Tieren bewohnt werden kann, ist hinlänglich
bekannt. Aber ein virtueller Bewohner, ein so genannter Avatar?
Laut Wikipedia [Wiki06], der freien Internet Enzyklopädie, ist ein Avatar
”
eine künstliche Person oder ein grafischer Stellvertreter einer echten Person in
der virtuellen Welt, beispielsweise in einem Computerspiel. (...) Avatare werden
beispielsweise in Form eines Bildes, Icons oder als 3D-Figur eines Menschen oder
2
GRUNDLAGEN
31
sonst irgend eines Wesens dargestellt. Die Verwendung des Begriffes Avatar in
diesem Zusammenhang wurde 1992 von Neal Stephenson in seinem ScienceFiction-Roman Snow Crash populär gemacht.(...)“.
Also ist ein Avatar ein Bild in der virtuellen Welt, das die Stelle einer Person einnimmt. Avatare sind jedoch nicht nur das bloße Abbild eines Menschen
oder eine Art virtueller Stellvertreter oder Konterfei, wie man sie in Foren,
Chat-Rooms oder Online-Rollenspielen in verschiedensten Formen antrifft. Die
Funktion und das Einsatzgebiet von Avataren haben sich deutlich weiterentwickelt. Von der einfachen Funktion eines Stellvertreters des Menschen in der
virtuellen Welt hin zu einem selbstständigen künstlichen Wesen, das mit dem
Menschen autonom interagiert. Der Avatar fungiert nicht mehr nur als virtuelle Darstellung des Benutzers, sondern mittlerweile als mit dem Benutzer
eigenständig agierende virtuelle Person. Ein Avatar kann als eine vertraut aussehende Benutzerschnittstelle für bessere Akzeptanz eines Produkts oder einer
Technologie verwendet werden. Wenn ein Benutzer mit einem menschenähnlichen Wesen am Bildschirm konfrontiert wird, das eventuell sogar mit ihm redet,
so akzeptiert er dies leichter als einen erklärenden Text, egal wie schön dieser
formatiert ist.
Im folgenden Abschnitt werden einige Beispiele für Avatare gegeben, die als
intelligente Benutzerschnittstellen fungieren. Damit erfüllen sie nach [DFKI06]
eine zentrale Vision des Forschungsbereich Intelligente Benutzerschnittstellen“.
”
Diese Vision ist die Entwicklung von persönlichen Informationsassistenten, die
dem Benutzer den Zugang zu den weltweiten Infobahnen erleichtern sollen. Im
Anschluss daran wird der Bewohner des virtuellen Raums erläutert.
2.7.2
Beispiele
Die im Folgenden genannten Beispiele für Avatare, sind sogenannte Lifelike
”
Characters“. Dies bedeutet, dass diese Avatare das Verhalten von in der Na-
2
GRUNDLAGEN
32
tur vorkommenden Wesen nachahmen. Avatare können beinahe jedes beliebige
Aussehen haben, sie müssen nicht unbedingt menschlich wirken, um akzeptiert
zu werden.
Ein sehr bekanntes Beispiel für ein dem Menschen nicht ähnlich sehender
Lifelike Character ist das bekannte und erfolgreiche Kinderspielzeug Poke”
mon“. Die weiteren Beispiele sind menschenähnlich aussehende Avatare, die als
Informationsassistenten mit dem Benutzer interagieren. Im Portal der Deutschen Bank AG hat man die Möglichkeit mit Cor@ zu sprechen. Ein Avatar
mit dem Aussehen einer jungen Frau, die über Texteingaben und -ausgaben
mit dem Benutzer kommuniziert. Cor@ präsentiert dem Benutzer Informationen über die Deutsche Bank AG. Dabei geht sie interaktiv auf die Fragen des
Benutzers ein.
Der Chatter-Bot Alice auf [Alice06] ist ebenfalls ein Avatar mit dem Aussehen einer jungen Frau. Alice ist darauf programmiert, sich mit dem Benutzer zu
unterhalten, zu “chaten“. Die Qualität einer solchen Unterhaltung ist natürlich
noch nicht vergleichbar mit einem Gespräch zwischen zwei Menschen, aber sie
gibt schon einen Einblick in die Möglichkeiten dieser Technologie. Denn obwohl diese Avatare nicht so intelligent wie ein menschlicher Gesprächspartner
interagieren, so sind sie doch sehr viel ansehnlicher als ein einfacher Text voller
Informationen, und es macht zuweilen Spaß mit ihnen zu interagieren.
Auf [?] erwartet Linda den Benutzer. Ein ebenfalls weiblich aussehender
Avatar, der sogar auch mit gesprochener Sprache kommunizieren kann. Linda
liegt ein Programm zugrunde, das sich an die Bedürfnisse und Vorlieben des Benutzers anpasst. Da dem Benutzer nur die Informationen präsentiert werden, die
ihn mit hoher Wahrscheinlichkeit am meisten interessieren, wird so zum einen
die Interaktion zwischen dem Benutzer und dem System weiter verbessert und
zum anderen auch die Akzeptanz erhöht. Denn der Benutzer muss sich nicht
lange mit uninteressanten Dokumentationen und Anweisungen beschäftigen, die
2
GRUNDLAGEN
33
ihn nicht interessieren, sondern nur mit dem Teil, der für ihn von Bedeutung ist.
Abbildung 7: Beispiele für Avatare: Ein Pokémon (links, Quelle: [Pokemon06]),
Chatterbot“ Alice (mitte, Quelle: [Alice06]) und Cyberella (rechts, Quelle:
”
[DFKI06])
Am Deutschen Forschungsinstitut für Künstliche Intelligenz“ (DFKI) in
”
Saarbrücken ist ein Avatar namens Cyberella installiert. Ähnlich den oben genannten Beispielen für installierte Avatare ist Cyberella ein Avatar mit dem
äußeren Erscheinungsbild einer attraktiven, jungen Frau. Cyberella wurde am
DFKI im Zuge des 1998 gestarteten Projekts PRESENCE“ [DFKI06] unter
”
der Leitung von Dr. Elisabeth André entwickelt. Ziel des PRESENCE-Projekts
war die Entwicklung eines Lifelike Characters, der als Ansprechpartner für
”
Gäste und Besucher fungieren und diese interaktiv über Projekte, Aktivitäten
und Mitarbeiter des DFKI informieren (...)“ [DFKI06] sollte. Heute ist sie unter anderem in das Informationssystem des DFKI integriert und präsentiert
den interessierten Besuchern interaktiv unterschiedliche Informationen über das
DFKI.
2
GRUNDLAGEN
2.8
34
The Virtual Room Inhabitant
Das Virtual Room Inhabitant(VRI )-System [KrSpSc1],[KrSpSc2] wurde mit
dem Ziel entwickelt, die Benutzerfreundlichkeit der oftmals komplexen Hardware in instrumentierten Umgebungen zu verbessern. Grundidee hierzu ist die
erhöhte Akzeptanz und intuitive Interaktion eines Benutzers mit einem Avatar.
Um dies innerhalb der instrumentierten Umgebung zu realisieren, sollte sich
der Avatar möglichst frei bewegen können und mit gesprochener Sprache und
begleitenden Gestiken kommunizieren.
Die zuvor vorgestellten Konzepte von Avataren realisieren diese immer in
Verbindung mit Bildschirmen, auf denen die Avatare dargestellt werden. Im
Fall des VRI -Systems sollte der Avatar den instrumentierten Raum bewoh”
nen“, sich also unabhängig von den installierten Bildschirmen bewegen und an
jeder Position, an der er sich aufhält, mit dem Benutzer interagieren können.
Um dies zu gewährleisten wurden verschiedene, bereits in der instrumentierten
Umgebung installierte Systeme miteinander verknüpft.
2.8.1
Systemkomponenten
Die einzelnen Komponenten des VRI -Systems werden in Abbildung 8 veranschaulicht. Alle Geräte der instrumentierten Umgebung müssen sich beim Device Manager anmelden. Dieser registriert die verfügbaren Geräte und deren
Ressourcen. Der Device Manager zeigt die angemeldeten Geräte an und erlaubt
uneingeschränkten Zugriff auf sie. Wenn mehrere Anwendungen gleichzeitig auf
das gleiche Gerät zugreifen möchten, dann käme es zu unschönen Störungen, da
der Device Manager jeder Anwendung vollen Zugriff erlaubt. Um dies zu verhindern wird der Presentation Planner verwendet. Er überwacht den Zugriff
auf alle angemeldeten Geräte und erlaubt den Anwendungen Zugriff auf nicht
verwendete Geräte. Auf diese Weise wird sichergestellt, dass eine laufende Anwendung, die ein Gerät benötigt, dieses benutzen kann, ohne dass eine andere
Anwendung auf dasselbe Gerät zugreifen kann. So ist es möglich die vorhan-
2
GRUNDLAGEN
35
Abbildung 8: Die Systemkomponenten des VRI-Systems, Quelle: [KrSpSc1]
denen Ressourcen mehreren parallel laufenden Anwendungen zur Verfügung zu
stellen. Der dezentrale Zugriff auf den Device Manager und die von ihm zur
Verfügung gestellten Geräte ist mit Hilfe von Java RMI-Objekten [RMI06] realisiert.
Um die gewollte Bewegungsfreiheit“ des Avatars zu gewährleisten, wird er
”
mit Hilfe des in Kapitel 2.4 vorgestellten Fluid Beam-Systems auf die Wände
des Instrumentierten Raums projiziert. Das in Kapitel 2.5 vorgestellte räumliche Audiosystem SAFIR wird dabei benutzt, um beim Benutzer den Eindruck
zu erwecken, dass der Avatar Geräusche macht und sprechen kann. Das Fluid
Beam-, ebenso wie das SAFIR-System, melden sich beim Device Manager an,
so dass Applikationen remote auf sie zugreifen können.
Die Komponente User with PDA steht für das in Kapitel 2.6 vorgestellte System zur Positionsbestimmung des Benutzers. Die Positionsdaten werden über
Wireless LAN auf den Event Heap [Johanson] gelegt, von dem aus sie jederzeit
2
GRUNDLAGEN
36
abrufbar sind. Auf dem Event Heap werden alle Informationen gelagert, die
der instrumentierte Raum liefert, wie zum Beispiel die Benutzerposition oder
Interaktionen mit dem System.
Der verwendete Avatar ist in seinem Erscheinungsbild an den in Kapitel
2.7.2 beschriebenen Avatar des DFKI [DFKI06] angelehnt und heißt ebenfalls
Cyberella“ (siehe Abbildung 10 rechts).
”
Die zentrale Komponente des VRI -Systems ist die Character Engine, welche
sich die benötigten Informationen vom Event Heap nimmt und über den Presentation Planner den Avatar mit Hilfe der SAFIR- und Fluid Beam-Systeme
im Raum positioniert. Im folgenden Abschnitt wird die Character Engine näher
beschrieben.
2.8.2
Character Engine
Die Character Engine-Komponente besteht aus den beiden Teilen Character
Engine Server (CE-Server ) und Character Animation (CA). Der CE-Server
ist in Java [JAVA] geschrieben und in ein RMI-Interface [RMI06] eingebunden,
wohingegen die eigentliche Animation des Avatars mit Macromedia Flash MX
[Flash05] realisiert wurde.
CE-Server und CA sind über eine XML-Socket Verbindung miteinander
verbunden und tauschen so XML-Skripte untereinander aus. Der CE-Server
kontrolliert dabei die Flash-Animation mit Hilfe dieser XML-Skripte, wobei die
CA Nachrichten über den aktuellen Status der Animation an den Server zurückschickt.
Die Flash-Animationen bestehen aus mehreren tausend gerenderten Einzelbildern, die einen erheblichen Speicherbedarf erzeugen. Um diesen so gering
wie möglich zu halten, ist die Animation in kleinere Teile aufgeteilt, die jeweils
2
GRUNDLAGEN
37
eine bestimmte Gestik oder Bewegung animieren. Des Weiteren existiert ein
sogenannte idle“-Teil, der den Avatar wartend an einer Stelle stehen lässt. Je”
de der anderen Animationen beinhaltet die Möglichkeit, dass der Avatar die
Lippen bewegt, wodurch er in fast jeder Position sprechen kann, während er
eine Geste macht. Diese Animationen werden von einem Hauptfilm gesteuert,
der beim Starten des Systems und nach jeder beendeten Gestik-Animation die
idle“-Animation lädt. Dieser Hauptfilm lädt die jeweiligen Animationen, wenn
”
er vom CE-Server ein entsprechendes XML-Skript bekommt. Ein Beispiel für
ein XML-Skript für die Character Engine ist in Abbildung 9 zu sehen.
Abbildung 9: Ein Beispiel für ein XML-Skript, das den Avatar den Benutzer
begrüßen lässt und dem Benutzer die Geräte im instrumentierten Raum erklärt
2
GRUNDLAGEN
38
Ein Skript ist durch script“-Tags bestimmt und kann aus mehreren parts“
”
”
bestehen. Jeder dieser Teile definiert eine bestimmte Gestik und die dazugehörige Audioausgabe. Nach der Ausführung eines Skripts kann das System mit dem
nächsten Schritt weitermachen, indem es zum Beispiel den Avatar mittels Fluid
Beam-Ansteuerung bewegt oder auch ein nächstes Skript abspielt. Damit die
Übergänge zwischen zwei Animationen fließend sind, wurden die Anfangs- und
Endbilder einer Animation so definiert, dass der Avatar auf ihnen immer in der
gleichen Pose erscheint.
Der CE-Server steuert über den Presentation Planner den Projektor und
die Audioausgabe. Beides wird durch Befehle, die der CE-Server generiert und
an den Presentation Planner schickt, mit der Avatar-Animation synchronisiert.
Dadurch kann der Avatar an beinahe jede Stelle im Raum platziert werden, und
seine Stimme ist genau an der Stelle, an der er sich befindet. So ist er in der
Lage das Setup der Umgebung zu erklären und dem Benutzer bei der Handhabung der Geräte zu unterstützen.
Ein typisches Szenario sieht wie folgt aus: Der Benutzer hat einen PDA (Personal Digital Assistant) in der Hand, mit dessen Hilfe seine Position bestimmt
wird, d.h. in welchem Raum er sich befindet. Sobald er den instrumentierten
Raum betritt, wird dies von dem Navigationssystem festgestellt, was wiederum
diese Information auf den Event Heap legt. Der CE-Server bekommt so die
Information und bittet um Zugriff auf die benötigten Geräte beim Device Manager. Sobald ihm der Zugriff gewährt wurde, bewegt er den Projektor und das
Audiosystem zu der initialen Position, von der aus die Animation starten kann.
Anschließend startet er die Animation, die dann vom Projektor auf die Wand
projiziert wird und sendet ein XML-Skript, das die Flash-Animation steuert
und dazu die entsprechende Sprachausgabe über das Audiosystem ausgibt.
2
GRUNDLAGEN
2.8.3
39
Aktuelle Erweiterung
Bisher wurde ein XML-Skript abgespielt, das sich nicht dynamisch anpassen
ließ. Es musste beim Starten des Programms vorliegen und wurde von Anfang bis Ende abgespielt. Im Laufe dieser Diplomarbeit wurde das VRI -System
dahingehend erweitert, dass auch einzelne Teile des Skripts abgespielt werden
können. Dies ist unbedingt notwendig, da sonst kein dynamisches Verhalten des
Avatars realisierbar ist.
Das Avatar-Modell wurde durch ein neues Modell namens Minnie“ ersetzt,
”
das auf Abbildung 10 zu sehen ist. Dies war aus Kostengründen erforderlich, da
sich das bestehende Cyberella-Modell nicht einfach um weitere Gestiken, wie
zum Beispiel Gehen, erweitern ließ.
2
GRUNDLAGEN
40
Abbildung 10: Rechts das alte Modell Cyberella“, links das neue Modell Min”
”
nie“
3
VERWANDTE ARBEITEN
3
41
Verwandte Arbeiten
Diese Diplomarbeit besteht hauptsächlich aus 3 Komponenten, die miteinander
verbunden wurden:
• Ein Avatar, der mit dem Benutzer interagiert
• Ein Raummodell der instrumentierten Umgebung
• Ein Wegenetz, auf dem sich der Avatar bewegt
Im Folgenden werden zu jedem dieser Komponenten einige Arbeiten vorgestellt,
die sich mit dem jeweiligen Thema befassen.
3.1
3.1.1
Migrating Characters
STEVE
Der erstmals 1999 vorgestellte und 2004 erweiterte Agent STEVE (Soar Training Expert for Virtual Environments) [Rickel1], [Marsella], [Rickel2] wurde
speziell entwickelt, um Studenten beim Lernen zu unterstützen. Er gibt den
Studenten Hilfestellungen beim Bewältigen von technischen, verfahrensorientierten Aufgabenstellungen. Dies tut STEVE in einer virtuellen 3D-Umgebung,
in der sich auch der Benutzer befindet und mit ihm interagiert. Die virtuelle
Umgebung, in der STEVE lebt“, besteht aus virtuellen Objekten, die zum
”
Beispiel Maschinen simulieren, die die Benutzer zu bedienen lernen sollen. In
dieser Umgebung befinden sich unter Umständen auch andere animierte Agenten sowie Avatare, die menschliche Benutzer repräsentieren.
Die Benutzer interagieren mit dem System mit Hilfe von Sensoren an Kopf
und Händen, Kopfhörern, einem Mikrofon und einem Datenhandschuh. So ist
es für die Benutzer möglich, intuitiv mit der virtuellen Realität zu interagieren.
Sie sind in der Lage, virtuelle Objekte zu greifen, auf sie zu zeigen und mit
3
VERWANDTE ARBEITEN
42
natürlicher Sprache zu kommunizieren. Dabei bewegen sich die Studenten ähnlich wie in einem 3D-Ego-Shooter (wie Unreal Tournament“ [Unreal06]) durch
”
die virtuelle 3D-Welt des Übungsgeländes, wie man in Abbildung 11 erkennt.
Während die Studenten versuchen, ihre Aufgaben zu bewältigen, kann
STEVE ihnen mit gesprochenen Bemerkungen und Erläuterungen zur Aufgabenstellung behilflich sein oder auch ihnen die entsprechende Aufgabe
demonstrieren. STEVE überwacht dabei die Benutzer beim Erledigen ihrer
Arbeit und kommentiert diese entsprechend des jeweiligen Verhaltens des
Benutzers. Dabei spielt es keine Rolle, ob gerade nur ein Benutzer das System
verwendet oder sich mehrere Benutzer gleichzeitig in der virtuellen Umgebung
befinden.
Sollten mehrere Benutzer oder Agenten sich gleichzeitig im System befinden, so wendet sich STEVE in Richtung des jeweiligen Gesprächspartners, um
Missverständnisse zu vermeiden. Die Welt, in der sich STEVE bewegt, wird
durch verschiedene äußere Einflüsse, wie unterschiedlich verlaufende Aufgaben
von Benutzern oder Bedienung der virtuellen Objekte ständig verändert.
Das Besondere an STEVE ist seine Fähigkeit, aufgabenbezogenes Verhalten
einerseits und persönliche Gespräche andererseits in einer solchen dynamischen
virtuellen Welt miteinander zu verschachteln. Um dies möglich zu machen, besteht STEVE aus den folgenden drei Hauptkomponenten:
• Ein Perception-Modul, das Nachrichten von einer zentralen Kommunikationsschnittstelle für alle anderen Komponenten bezieht. Es beinhaltet
eine Logik, die Reaktionen auf Nachrichten definiert. Diese Nachrichten
beinhalten Informationen über Veränderungen in der virtuellen Welt und
können zum Beispiel bewirken, dass virtuelle Bedienelemente ihren Zustand verändern. Nachdem das Perception-Modul diese Nachrichten auf
Wichtigkeit geprüft hat, sendet es sie an das
• Cognition-Modul weiter, das dann an Hand der Informationen entschei-
3
VERWANDTE ARBEITEN
43
Abbildung 11: Links: STEVE erklärt eine Schalttafel, Rechts: STEVE spricht
mit einem anderen Avatar (Quelle: [STEVE06])
det, was als nächstes zu tun ist. Anschließend sendet es die entsprechenden
Befehle an das
• Motor-Kontroll -Modul, welches die Bewegungen von STEVEs Körper kontrolliert.
STEVE wurde unter anderem in ein Schiffs-Szenario integriert, in dem die
Studenten lernen sollten, die Maschinen des Schiffs zu bedienen. Das Szenario
bestand aus mehreren Lektionen, an deren Beginn STEVE den Studenten die zu
erledigenden Aufgaben erklärte und vorführte. Den Studenten war es möglich,
die Vorführung für Fragen zu unterbrechen oder ganz abzubrechen, um die Aufgaben selbstständig zu beenden. In Abbildung 11 sieht man, wie STEVE eine
Kontrolltafel erklärt. Auf [STEVE06] kann man sich weitere Screenshots und
auch einige Demo-Videos ansehen.
3
VERWANDTE ARBEITEN
3.1.2
44
MAEVIF
Im Rahmen des MAEVIF -Projekts (Model for the Application of Intelligent
Virtual Environments to Education and Training) [MAEVIF06] wurde ein Modell entwickelt, das der Benutzung von virtuellen Umgebungen als Trainingsszenario zur Aus- und Fortbildung dient. Dazu wurde zunächst ein generisches
Modell für intelligente, virtuelle Lehrumgebungen definiert, dann eine dazu
passende Software-Architektur [Antonio2] und schließlich wurde ein Prototyp
implementiert, der auf dem entwickelten generischen Modell basiert. Das generische Modell [Antonio1], [Mendez2] basiert auf verschiedenen intelligenten
Agenten.
Intelligente Agenten [Klusch05] sind Software-Instanzen, die initiativ relevante Informationen für den Benutzer oder andere Agenten sammeln und sie
ihnen zur Verfügung stellen. Dazu greifen intelligente Agenten auf verschiedene,
eventuell verteilte, ihnen zur Verfügung stehende Daten- und Informationsquellen zurück. Die Agenten kommunizieren beim MAEVIF -System über ein sogenanntes schwarzes Brett“, auf das sie Anfragen setzen, die dann die anderen
”
Agenten zu lösen versuchen.
Bei der Realisierung eines generischen Modells wurden zum Beispiel mehrere
Agenten für die Kommunikation mit dem Benutzer verwendet und für diverse
Aufgaben des Systems, wie die Verwaltung der Umgebungsdaten. MAEVIF ist
ein verteiltes System, das von mehreren Benutzern gleichzeitig in einer Trainingsumgebung verwendet werden kann.
Zu Testzwecken wurde eine Prototyp-Applikation implementiert, die Studenten eine Trainingsumgebung bietet, in der sie Erfahrungen mit der Instandhaltung und der Kontrolle von Atomkraftwerken [Mendez1] sammeln können.
Dabei bewegen sich die Studenten ähnlich wie in einem 3D-Ego-Shooter, wie
auch schon in Kapitel 3.1.1 beschrieben, durch die virtuelle 3D-Welt des Kraftwerks, was man in Abbildung 12 erkennt. Während des Trainings können sie
3
VERWANDTE ARBEITEN
45
mit anderen Studenten und Avataren interagieren. Das Szenario wird dynamisch variiert, so dass die Studenten verschiedene Prozeduren und Aufgaben
aus unterschiedlichen Situationen heraus erledigen müssen.
Abbildung 12: Der Benutzer bewegt sich durch die virtuelle Welt und trifft
dabei auf andere Benutzer (Quelle: [Mendez2] und [Antonio2])
3
VERWANDTE ARBEITEN
3.1.3
46
WhizLow
Whizlow [Lester] ist ein Programm mit dem der Benutzer etwas erlernen soll,
ähnlich den in Kapitel 3.1.1 und 3.1.2 vorgestellten Systemen STEVE und
MAEVIF . In diesem Fall ist es ein kleiner Avatar, der in der virtuellen 3D-Welt
CPU City“ lebt und Studenten nicht-technischer Fachrichtungen die grundle”
gende Funktionsweise und den Aufbau eines Computers erklären soll.
Die CPU City“ besteht aus verschiedenen Häusern, die durch Straßen mit”
einander verbunden sind, und so stellt sie den schematischen Aufbau eines Motherboards dar. Die Häuser sind die zentralen Bestandteile des Motherboards,
wie zum Beispiel der Prozessor (CPU), der Arbeitsspeicher (RAM) und die
Festplatte, die wiederum eingerichtet“ sind mit den Komponenten aus denen
”
sie bestehen. So ist die CPU etwa mit Registern und einer Arithmetisch Logischen Einheit (ALU) eingerichtet. Die Straßen repräsentieren die Busse, die
die einzelnen Bestandteile miteinander verbinden und über die Datenpakete geschickt werden. Die Datenpakete werden während der Animation vom Avatar
von Haus zu Haus getragen, wodurch den Studenten Prozesse, wie zum Beispiel
Kompilieren“, verdeutlicht werden sollen.
”
Die Aufgaben, die der Avatar erledigt, werden zuvor vom Benutzer mit Hilfe
einer höheren Programmiersprache definiert. Diese Befehle werden dann intern
in Aktionen“ umgewandelt, die anschließend in der physischen Steuerung des
”
Verhaltens des Avatars definiert werden, um letztlich in Bewegung und Sprache
umgesetzt zu werden. Parallel dazu wird errechnet, wie sich die Kamerasicht
während der Bewegung ändern muss, und daraus wird eine Kamerafahrt generiert. Denn im Gegensatz zu den Systemen aus Kapitel 3.1.1 und 3.1.2 ist die
Sicht auf die virtuelle Szene nicht aus der Ich-Perspektive, sondern von oben,
wie man in Abbildung 13 sieht.
Die Studenten können in die bereits programmierte Abfolge von Aktionen“
”
nachträglich nicht mehr eingreifen. Sie können auch nicht selbstständig Ob-
3
VERWANDTE ARBEITEN
47
Abbildung 13: Whizlow bringt gerade ein Datenpaket zur CPU ,Quelle: [Lester])
jekte, wie etwa Datenpakete, manipulieren oder mit dem Avatar interagieren.
WhizLow erklärt jedoch während der Ausführung seine Taten. Die Studenten
können der Szene wie bei einem Film zusehen und sich so völlig auf das
Geschehen konzentrieren.
3.1.4
Virtual Augsburg
Die Forschungsgruppe Multimedia Concepts and their Applications“ der Uni”
versität Augsburg [MultConc06] leitet das Virtual Augsburg Projekt [Andre].
Der Ansatz zur Realisierung ist hier, anders als beim in Kapitel 3.1.1 vorgestellten STEVE -Projekt, eine Mixed Reality, ein Vermischen von virtueller Realität
und der realen Welt. Dabei erweitert der für das Projekt entworfene virtuelle
Charakter Ritchie die reale Umgebung des Benutzers.
Ein Szenario im Rahmen des Projekts ist die Verwendung von Ritchie als
virtuellen Führer eines Stadtrundgangs [Dorfm]. Der Benutzer steht vor einem
3
VERWANDTE ARBEITEN
48
Tisch, auf dem ein Stadtplan ausgelegt ist, und betrachtet diesen durch eine
Spezialbrille eines Head Mounted Displays, wie in Abbildung 14 rechts dargestellt. Mit Hilfe dieser Spezialbrille werden nun zum einen die Gebäude der
Stadt virtuell auf der Karte erzeugt und zum anderen auch Ritchie in den
Stadtplan integriert, wie man in Abbildung 14 links erkennt.
Abbildung 14: Rechts bewegt sich Ritchie dorthin, wo der Benutzer die Pyramide positioniert hat. Links sieht man einen Benutzer mit Head-Mounted Display,
der sich die Szene anschaut. Quelle: [Andre]
Neben der Spezialbrille ist im Head-Mounted Display eine Kamera integriert, die permanent das sich dem Benutzer bietende Bild aufnimmt. Mit Hilfe
einer Pyramide, auf deren Oberflächen sich Marker befinden, ist es dem Benutzer möglich, Eingaben an das System zu tätigen. Jeder dieser Marker steht
dabei für eine andere andere Aktion des Benutzers.
Zu Beginn ist Ritchie irgendwo auf der Karte positioniert. Wenn der Benutzer nun die Pyramide an eine Position gestellt hat, sucht Ritchie den kürzesten
Weg zu dieser Stelle. Sobald er beginnt sich zu bewegen, wird der Benutzer
3
VERWANDTE ARBEITEN
49
in die Szene eingebettet und folgt Ritchie durch die virtuelle Innenstadt von
Augsburg. Auf diese Weise teilen sich Benutzer und virtueller Charakter den
gleichen Raum. Dies führt beim Benutzer zu einer verstärkten Einbindung in das
System, da er die Situation zusammen mit dem Charakter erlebt und durchlebt.
Abbildung 15: Links folgt der Benutzer Ritchie durch die Stadt. Rechts ist
Ritchie in der realen Welt und betrachtet das Stadtmodell. Quelle: [Andre]
Ritchie kann jedoch nicht nur als Führer in der virtuellen Umgebung mit
dem Benutzer interagieren, wie in Abbildung 15 dargestellt, sondern er kann
sich ebenso in der realen Welt bewegen, wie ebenfalls in Abbildung 15 zu sehen
ist, wo er das Miniaturmodell der Stadt auskundschaftet. Auf diese Weise kann
sich der Charakter sowohl in der realen als auch in der virtuellen Welt frei bewegen. In der virtuellen Welt nimmt er den Benutzer mit auf eine Tour durch
die Stadt, in der realen Welt sind die Bewegungen von Benutzer und Charakter
unabhängig voneinander. Ritchie wird dann zum Beispiel neben einen Tisch
positioniert und betrachtet ein Modell auf dem Tisch, während der Benutzer
neben ihm steht (siehe Abbildung 15). Somit findet eine Vermischung von realer und virtueller Welt sowohl aus Sicht des Benutzers als auch aus Sicht des
3
VERWANDTE ARBEITEN
50
Charakters statt, die beide zwischen den Welten“ wechseln können.
”
3.1.5
PEACH
PEACH (Personalized Experiences with Active Cultural Heritage)[PEACH06]
ist ein wissenschaftliches Projekt verschiedener Institute und der Industrie unter Führung des Zentrums für Wissenschaftliche und Technische Forschung
am Kulturinstitut in Trento (ITC-irst) [ITC06], Italien. Ein Ziel des PEACH Projekts ist es, ein System zu entwickeln, mit dessen Hilfe Aufmerksamkeit,
Wertschätzung und vielleicht sogar Begeisterung für das Kulturerbe geweckt
werden sollen.
Dazu werden neueste Technologien getestet und genutzt, um besonders bei
jungen und weniger interessierten Menschen die gewünschte Wirkung zu erzielen. Für die Besucher von Kulturstätten wurde ein individueller Museumsführer
entwickelt, der auf die Wünsche und Vorlieben des jeweiligen Besuchers eingeht
und dabei das Wissen auf pädagogische und unterhaltsame Weise zugleich vermittelt.
Im Rahmen des PEACH -Projekts wurden am DFKI Avatare entwickelt, die
als Museumsführer eingesetzt werden. Das System wurde auf zwei unterschiedliche Museen angepasst. Zum einen das Museo Castello del Buonconsiglio in
Trento [Trento06], das sich in einer mittelalterlichen Burg mit vielen Fresken befindet. Das zweite Museum ist die Völklinger Hütte in Völklingen [VHuette06],
ein altes Stahlwerk mit verschiedenen Industrieanlagen.
Da die beiden Museen sehr verschieden sind, wurde für jedes Museum ein
eigenes Paar von Avataren entworfen. Für die Industrieanlage in Völklingen die
beiden oberen, modern aussehenden Avatare in Abbildung 16, für die mittelalterliche Burg die beiden unteren Avatare, deren Aussehen der damaligen Mode
angepasst wurde.
3
VERWANDTE ARBEITEN
51
Abbildung 16: Die vier Avatare des PEACH-Projekts. Quelle: [Kruppa]
Nicht nur das Aussehen der Avatare wurde angepasst, sondern auch ihre
Aufgabe während eines Museumsrundgangs. Jedem Charakter ist eine bestimmte Rolle zugewiesen, wodurch er je nach Interesse des Benutzers nur bestimmte
Themen präsentiert. Dieser kann jederzeit zwischen den beiden Avataren und
ihrem Teil der Erläuterungen wechseln. Jeder der Avatare spielt zwei Rollen
während einer Präsentation: die des Moderators und die des Redners. Als Redner erläutert er dem Benutzer mit Hilfe von entsprechenden Gesten die einzelnen
3
VERWANDTE ARBEITEN
52
Ausstellungsstücke im Detail. In der Rolle des Moderators bringt er die einzelnen Vorträge in einen großen Zusammenhang, wodurch sich dem Benutzer ein
Gesamtbild des Museumsrundgangs erschließen soll.
Während eines Rundgangs durch das Museum können die Avatare zwischen
verschiedenen Präsentationsmedien wechseln. Die Präsentationsmedien teilen
sich in die zwei Gruppen: stationäre und mobile Medien.
Als mobiles Medium dient ein Personal Digital Assistant (PDA), dessen
kleiner Bildschirm nur begrenzte Möglichkeiten zur Präsentation von komplexen Sachverhalten bietet. Deshalb wurden auch stationäre Präsentationsmedien
in das PEACH -Projekt aufgenommen. Diese stationären Medien sind fest installierte Bildschirme, auf denen viele Informationen gleichzeitig angezeigt werden können, da sie dazu genügend Platz bieten. Im Rahmen der Präsentation
werden sie als sogenannte Virtual Windows“ genutzt, die zusätzliche Informa”
tionen zu den Räumen geben, in denen sich der Benutzer befindet. Auf dem
PDA werden hingegen nur Informationen zu dem bestimmten Kunstwerk gegeben, vor dem sich der Benutzer gerade befindet. In Abbildung 17 sieht man
links die Darstellung eines Avatars auf einem PDA, und rechts das große Display eines Virtual Windows“.
”
Der Museumsführer erklärt dem Benutzer die jeweiligen Exponate mit Hilfe
gesprochener Sprache. Diese wurde mit Hilfe des AT&T’s Natural Voices“”
Systems [ATT06] generiert, da es eine hohe Sprachqualität erzeugt. Die so generierten Sounddateien werden im MP3-Format auf einem stationären Server
gespeichert und von dort bei Bedarf abgerufen (siehe [Kruppa]).
Da ein Benutzer während eines Rundgangs an verschiedenen Ausstellungsstücken vorbei kommt, ist es für das System wichtig zu wissen, vor welchem
Ausstellungsstück sich der Benutzer gerade befindet. Denn nur so ist es möglich,
im passenden Moment das richtige Wissen zu vermitteln. Das PEACH -Projekt
3
VERWANDTE ARBEITEN
53
Abbildung 17: Die PEACH-Präsentation auf einem PDA (links) und einem
Virtual Window“ (rechts). Quelle: [Kruppa]
”
benutzt zur Feststellung der Benutzerposition die in Kapitel 2.3.5 beschriebenen Infrarotbaken.
Auf diese Weise erkennt das System, zu welchem Kunstwerk es etwas vortragen soll. Um jedoch auf die spezifischen Wünsche des Benutzers eingehen zu
können, benötigt es ein entsprechendes Interessen-Profil. Dazu dokumentiert
das System ständig das Verhalten des Benutzers und erstellt aus den Beobachtungen ein Profil, wie es in Abbildung 18 dargestellt ist. Anhand dieses Profils
werden dann die Inhalte angeboten, die den Benutzer am meisten interessieren.
Sollten die Informationen nicht interessant sein, so kann der Benutzer sich eine
eigene Auswahl präsentieren lassen.
3.1.6
Resümee
In den Kapiteln 3.1.1 bis 3.1.5 wurden verschiedene Systeme präsentiert, die
Migrating Characters nutzen, um mit den Benutzern zu interagieren. Die vor-
3
VERWANDTE ARBEITEN
54
Abbildung 18: Eine Statistik über das Verhalten des Benutzers bei einem Rundgang. Quelle: [Kruppa]
gestellten Systeme nutzen dabei 3 verschiedene Ansätze, um die Interaktion mit
dem Benutzer zu realisieren.
Die Systeme STEVE , MAEVIF und WhizLow lassen ihre jeweiligen Avatare in virtuellen 3D-Welten umherlaufen. Die Benutzer begeben sich ebenfalls
in diese virtuellen Welten und erleben die Szene aus der Ich-Perspektive, wie
im STEVE - und MAEVIF -System, oder beobachten als Außenstehende das
Geschehen, wie beim WhizLow -System. In allen Fällen handelt es sich um Simulationen der realen Welt, die sich ausschließlich in der virtuellen Realität
abspielen. Die Systeme werden als Trainings- oder Lernprogramme genutzt, die
den Benutzern die reale Welt nur vorführen, aber von ihr vollkommen abgekoppelt funktionieren.
3
VERWANDTE ARBEITEN
55
Das Virtual Augsburg-Projekt aus Kapitel 3.1.4 macht den Spagat zwischen
virtueller 3D-Welt und der realen Welt. Einerseits kann der Benutzer mit dem
Avatar Ritchie einen Stadtrundgang in der virtuellen Realität machen, ähnlich
dem STEVE - und MAEVIF -Ansatz. Aber andererseits kann Ritchie auch aus
der virtuellen Welt herauskommen in die reale Welt und sich hier mit dem Benutzer zum Beispiel eine Szenerie anschauen, wie auf Abbildung 15 zu sehen
ist. Leider muss der Benutzer dazu verschiedene Geräte am Körper tragen, die
auf Dauer wohl eher als störend empfunden werden, da er durch sie in seiner
Bewegungsfreiheit eingeschränkt wird.
Beim PEACH -Projekt aus Kapitel 3.1.5 ging man einen völlig anderen Weg.
Der Avatar ist dank der Integration auf einem PDA so mobil, wie es der Benutzer ist. Außerdem ist es möglich, andere installierte Geräte, wie Bildschirme, als
Medium zu nutzen, indem der Avatar sich dorthin portiert. So ist der Benutzer
frei in seinen Bewegungen und kann die reale Welt erkunden und erhält vom
System dann am echten“ Objekt die Erläuterungen. Ein Nachteil an diesem
”
Ansatz ist das kleine Display eines PDAs, auf dem nur wenig dargestellt werden
kann. Die großen Bildschirme kompensieren diesen Nachteil zwar, jedoch sind
sie an einer Stelle fest installiert und folglich immobil. So kann der Benutzer nur
an bestimmten Stellen in der Umgebung alle Informationen optimal erhalten.
3.2
3.2.1
Raum- und Objektmodelle
CAD
In der Praxis gibt es eine Vielzahl von Anwendungsmöglichkeiten von Modellen, mit denen einzelne Objekte oder auch ganze Räume modelliert werden können. Eine der häufigsten Anwendungen sind Computer Added Design
(CAD)-Programme, wie etwa FactoryCAD der Firma UGS [FactoryCAD06],
mit dessen Hilfe Ingenieure Fabrikmodelle erstellen sowie Konstruktionspläne
3
VERWANDTE ARBEITEN
56
von Gebäuden, Schiffen und vielem mehr. Bei der Anwendung im Bauwesen werden Gebäude- und Raummodelle erstellt, um zum Beispiel Raumluftströmungen
zu simulieren (siehe [Treek]). Die CAD-Modelle sind äußerst genaue Modelle,
da sie als Vorlage für Konstruktionszeichnungen dienen oder auch selbige sind
(siehe Abbildung 19)
Abbildung 19: Links: ein CAD-Modell von einem Gebäude (Quelle:
[CADintern06]), Rechts: ein Raummodell eines Wohnraumes mit Schallsimulation (Quelle: [MCSquared06])
3.2.2
Akustik
Ein weiteres Anwendungsgebiet für Raummodelle ist die Akustik. Dort werden
die Modelle dazu benutzt, ein optimiertes Klangbild in Räumen zu erzeugen, wie
es etwa in Konzertsälen oder im Kino [MCSquared06] gefordert wird. In Abbildung 19 sieht man ein solches Modell eines Wohnraums, in dem das Klangbild
eines Soundsystems simuliert wird. Eine weitere Anwendung für Raummodelle
3
VERWANDTE ARBEITEN
57
im Bereich Akustik ist das in Kapitel 2.5 beschriebene räumliche Audiosystem
SAFIR“ [Schmitz]. In diesem Fall hat der modellierte Raum die vereinfachte
”
Form einer Kugel, um die Ausgabe der Klänge schneller berechnen zu können.
3.2.3
Computergraphik
Raum- und Objektmodelle werden natürlich besonders in der Computergrafik
benutzt, um Animationen oder virtuelle Welten zu erschaffen, wie zum Beispiel
in 3.1.1 und [Unreal06]. Es gibt verschiedene Programme, wie zum Beispiel 3D
”
Software Object Modeller Pro“ der Firma 3Dsom.com [3Dsom06], die dem Benutzer beim Erstellen der Modelle helfen. Im Fall von 3D Software Object
”
Modeller Pro“ werden die Modelle mit Hilfe von 2D-Fotos erstellt und anschließend vom Benutzer nachbearbeitet. Eine andere Möglichkeit ist die Erstellung
von 3D-Modellen mit Hilfe von Hochsprachen wie C# [CSharp06] oder Java 3D
[Java3D06]. Zum Beispiel wurde im Rahmen des Fluid Beam“-Systems, das
”
in Kapitel 2.4 beschrieben wurde, das 3D-Modell des instrumentierten Raums
mit Java 3D erstellt. Desweiteren kann auch die HTML-Erweiterung Virtual
”
Reality Modeling Language“ (VRML) [VRML06] genutzt werden, um dreidimensionale Szenen zu erstellen.
3.2.4
Virtual Augsburg
Das in Kapitel 3.1.4 vorgestellte System Virtual Augsburg“ benutzt ein ei”
gens erstelltes Raummodell [Kufner], welches mit VRML bearbeitet wurde. Datenbasis für das Raummodell der Augsburger Innenstadt sind die städtischen
Grundrisspläne, die nach der Digitalisierung in ein Koordinatensystem eingebettet wurden. Zur Vereinfachung wurde das 3D-Modell in ein 2D-Wegenetz
überführt, da die 2D-Informationen ausreichen, um einen Stadtrundgang zu
planen. Das so generierte 2D-Wegenetz wird in Kapitel 3.3.1 weiter erläutert.
In Abbildung 20 sieht man das 3D-Modell der Szene von oben, so dass im
nächsten Schritt die Sichtbarkeitspunkte eingetragen werden können.
3
VERWANDTE ARBEITEN
58
Abbildung 20: Das Raummodell des Virtual Augsburg Systems (Quelle:
[Kufner])
3.2.5
Resümee
Die hier vorgestellten Ansätze für Raummodelle gehen auf Grund der verschiedenen Ziele unterschiedliche Wege zur Modellierung. Die Computergraphik versucht möglichst detailgetreue Modelle zu erstellen und lässt so den Eindruck
von möglichst realistischen Umgebungen entstehen. Bei CAD-Modellen ist die
Genauigkeit ähnlich hoch, eventuell noch höher, wenn es sich um Konstruktionspläne handelt.
Im Gegensatz dazu sind die Modelle in der Akustik meist etwas vereinfacht, auch weil es nicht auf schönes Aussehen der Objekte im Raum ankommt,
als vielmehr auf die Schallausbreitung im Innenraum. Oft sind diese Modelle
nur Datenmodelle, da sie nur für Berechnungen benutzt werden. Dabei können
3
VERWANDTE ARBEITEN
59
kleine Abstriche in der Genauigkeit von einzelnen Objekten in Kauf genommen
werden, ohne dass das Modell an Aussagekraft verliert.
Das Raummodell des Virtual Augsburg“-Projekts ist kein echtes 3D-Modell.
”
Es wurde zuerst abstrahiert und anschließend in eine 2D-Sicht übertragen, was
im Rahmen des Projekts völlig ausreichend war.
3.3
Wegenetze und Wege
Um in einer fremden Umgebung einen Weg vom eigenen Standort zu einem
beliebigen Zielort finden zu können, braucht man Informationen über mögliche
Wege durch die Umgebung, in der man sich bewegt. Im Alltag bewegen wir
uns unter anderem auf Straßen, Bürgersteigen und in Fußgängerpassagen. Diese kann man als eine Ansammlung von Kreuzungen und Verbindungsstrecken
verstehen, die die Kreuzungen miteinander verbinden. Benennt man nun die
Kreuzungen als Knoten und die Verbindungsstrecken als Kanten, so erhält man
ein Wegenetz.
Wegenetze werden als Formalisierung der begehbaren Umgebung zur Grundlage für automatisierte Navigation eingesetzt. Das Problem, einen optimalen
Weg durch ein Netz aus möglichen Wegen zu finden, ist lange bekannt, und
es existieren verschiedene Lösungsansätze und Algorithmen. Der bekannteste
von allen ist wohl der Dijkstra-Algorithmus“, der in [Cormen] sehr ausführlich
”
erläutert wird. Die Applikationen in den folgenden Beispielen generieren Wegenetze, und suchen darauf mit unterschiedlichen Algorithmen nach möglichst
optimalen Wegen.
3.3.1
Virtual Augsburg
Das in Kapitel 3.1.4 vorgestellte System benutzt ein 3D-Modell (siehe 3.2.4)
zur Erstellung eines Wegenetzes [Kufner]. Das Wegenetz ist hier ein Sicht”
3
VERWANDTE ARBEITEN
60
barkeitsgraph“ bestehend aus Knoten, die hier Sichtbarkeitspunkte“ genannt
”
werden, und Kanten. Ein Sichtbarkeitspunkt“ hat die Eigenschaft, dass er
”
ein potentieller Wegpunkt ist und direkten Sichtkontakt zu wenigstens einem
anderen Sichtbarkeitspunkt“ hat. Der Sichtbarkeitsgraph“ wird nun erstellt,
”
”
indem von jedem Knoten aus zu jedem sichtbaren Nachbarknoten eine Kante
eingefügt wird.
Zur Vereinfachung wurde das 3D-Modell in ein 2D-Wegenetz überführt. Dies
ist für das Wegenetz nicht von Bedeutung, da sich die möglichen Wege im 3DModell nur in einer horizontalen Ebene befanden. Das Setzen der Sichtbar”
keitspunkte“ wird von Hand im 3D-Modell durchgeführt, da dies mit Hilfe des
Tools Cosmo Worlds“ [Cosmo06] sehr einfach ist und der Versuch eines auto”
matischen Setzens der Knoten scheiterte.
Auf dem generierten Wegenetz wird nun nach dem kürzesten Weg zwischen
zwei Knoten gesucht. Dazu wird der A∗-Algorithmus“ verwendet, der unter an”
derem in [AStern06] erklärt ist. Der so gefundene Weg ist leider sehr eckig, da
die Sichtbarkeitspunkte“ über gerade Kanten miteinander verbunden sind. Zur
”
Abrundung der Kanten werden Cardinal Splines [DeLoura] benutzt, beginnend
beim Startknoten, iterativ fortschreitend bis zum Zielknoten. Diese Abrundungen werden jedoch nicht in den Sichtbarkeitsgraphen“ übernommen, sondern
”
bei jedem neuen Pfad erneut berechnet. Die so entstandenen Wege sind einerseits möglichst kurz, und andererseits sind es schöne“ Wege, wie man sie auch
”
selbst in der Realität gehen würde.
3.3.2
Navigation in der Fußgängerzone
In den Arbeiten [Kolbe3D], [Kolbe], [Pressl] werden verschiedene Ansätze zur
Navigation in Fußgängerzonen gegeben. Allen drei Arbeiten liegt ein Wegenetz
zu Grunde, das aus Kanten und Knoten besteht. Die 2-dimensionalen Wegenetze werden nicht automatisch generiert, sondern von Hand aus einem Stadtplan
3
VERWANDTE ARBEITEN
61
einer topologischen Karte oder einem Gebäudeplan extrahiert.
In [Kolbe] werden Gebäude in die Navigation einbezogen. Dabei werden
Treppen und Aufzüge als einfache Kanten modelliert, die die jeweiligen Teilgraphen der betreffenden Stockwerke miteinander verbinden. Hierdurch bleibt das
Wegenetz 2-dimensional, obwohl 3-dimensionale Sachverhalte modelliert werden.
Zum Finden der kürzesten Wege in den Wegenetzen benutzen [Kolbe3D]
und [Kolbe] den in [Cormen] beschrieben Floyd(-Warshall)-Algorithmus“. In
”
[Pressl] wird hingegen der Dijkstra-Algorithmus“ zur Suche des kürzesten
”
Weges genutzt. Der Unterschied zwischen den beiden Algorithmen ist, dass der
Dijkstra-Algorithmus“ alle kürzesten Pfade von einem Startpunkt aus zu al”
len anderen Knoten berechnet, wohingegen der Floyd-Algorithmus“ von jedem
”
Knoten aus zu allen übrigen Knoten die kürzesten Pfade berechnet. Dadurch
verbraucht er deutlich mehr Speicherplatz und eignet sich nur für kleine Wegenetze.
Bei ihrem Lösungsansatz legen [Kolbe3D] und [Kolbe] den Fokus auf virtuelle Wegweiser, wie Videos oder Bilder. Diese werden den Benutzern auf einem
PDA angezeigt, um so den Weg effizient zu beschreiben. In [Pressl] dagegen
wird ein System für blinde Benutzer vorgestellt, bei dem zur Weitergabe von
Informationen über den weiteren Verlauf des Weges Sprachausgaben, Text (in
Blindenschrift), Vibrationsalarm und einfache Geräusche eingesetzt werden.
Bei [Pressl] ist noch zu erwähnen, dass eine Kostenfunktion zur Berechnung der sichersten Route implementiert wurde. Diese ist nur selten auch die
kürzeste Route, weswegen zur Länge der Kante noch zusätzliche Bewertungskriterien zur Gewichtung der Kanten genutzt wurden. So wirken sich zum Beispiel
Straßenübergänge und hohe Verkehrsdichte negativ auf die Gewichtung einer
Kante aus. Auf diese Weise muss am Algorithmus selbst nichts geändert wer-
3
VERWANDTE ARBEITEN
62
den, um die sicherste an Stelle der kürzesten Strecke zu finden.
3.3.3
Navigation mittels RFID
In [Tomberge] wird ein System vorgestellt, das mit Hilfe von RFID (siehe 2.3.5
und 2.6) Navigation für Fußgänger in einem Fußballstadion und in seiner unmittelbaren Nähe bereitstellt. Anwendung findet das System erstmals bei der
Fußball Weltmeisterschaft 2006 in Deutschland, da dann erstmals die Eintrittskarten mit RFID-Chips für die Eingangskontrolle versehen werden.
Für ein Anwendungsszenario wurde das Stadion Arena AufSchalke“ in
”
Gelsenkirchen ausgewählt, das mittlerweile den Namen Veltins-Arena“ trägt
”
[Schalke06]. Die Navigation wurde auf einem PDA realisiert, wodurch dem Benutzer auch andere ortsbasierte (Informations-) Dienste (Location Based Services, LBS) zur Verfügung gestellt werden können.
Dem Navigationssystem liegt ein Wegenetz zu Grunde, das sich von den
Parkplätzen bis zu den Sitzen in den verschiedenen Blöcken im Stadion erstreckt. Wie in 3.1.4 und 3.3.2 bereits beschrieben, besteht auch hier das Wegenetz aus Knoten und Kanten, wobei die Kanten verschiedene Gewichte haben.
Das Wegenetz wird aus dem Lage- bzw. Bauplan des Stadions gewonnen, und
die einzelnen Knoten und Kanten werden von Hand gesetzt. Ein 3D-Modell
wird nicht generiert.
Das Wegenetz besteht aus den folgenden Teilgraphen und den Verknüpfungen
zwischen ihnen:
• Wegenetz vor dem Stadion bis zu den Sicherheitsbereichen
• Wegenetz innerhalb der einzelnen Sicherheitsbereiche vor und im Stadion
• Wegenetz auf den einzelnen Ebenen und in den Blöcken des Stadions bis
zu den Sitzplätzen
3
VERWANDTE ARBEITEN
63
Abbildung 21: 3D-Wegenetz für das Fußballstadion in Gelsenkirchen (oben) und
das 2D-Wegenetz in das es überführt wurde. (Quelle: [Tomberge])
Das vollständige Wegenetz wird aus diesen Teilgraphen und den Verknüpfungen zusammengesetzt. Wie in Abbildung 21 zu sehen ist, spielt es dabei keine
Rolle, in welcher Position im 3D-Raum sich der jeweilige Punkt befindet, weshalb das Wegenetz 2-dimensional beschrieben wird, wie es auch in 3.3.1 und
3.3.2 gemacht wurde. Der Höhenunterschied zweier benachbarter Punkte wurde mit Hilfe der Kantengewichte modelliert. Der kürzeste Weg zwischen zwei
Knoten des Wegenetzes, zum Beispiel zwischen Parkplatz und Sitzplatz, wird
3
VERWANDTE ARBEITEN
64
mit Hilfe des Dijkstra-Algorithmus“ berechnet. Ein Glättungsverfahren für die
”
gefundenen Wege, wie in 3.3.1 beschrieben, wird nicht verwendet.
Das System kann problemlos in andere Fußballstadien übertragen werden,
es muss lediglich das Wegenetz für das jeweilige Stadion neu generiert werden,
was unter Umständen mit einigem Aufwand verbunden ist.
3.3.4
Resümee
Ein Wegenetz dient immer dem Finden von Wegen, egal wo diese Wege sind.
Die vorgestellten Ansätze haben alle gemeinsam, dass sie einen aus Knoten und
Kanten bestehenden Graphen als Grundlage nehmen. In allen Beispielen wurden die Knoten von Hand aus dem zu Grunde liegenden Modell extrahiert. Dies
ist je nach Größe des benutzten Modells ein großer Arbeitsaufwand, den nur
[Kufner] zu umgehen versuchte. Der dort versuchte Ansatz scheiterte jedoch an
der Komplexität des Problems der automatischen Positionierung der Knoten.
Die vorgestellten Systeme werden zur Navigation in unterschiedlichen Umgebungen verwendet, die auf ein ebenes Wegenetz vereinfacht wurden. Der scheinbare Informationsverlust dieser Vereinfachung wurde durch die entsprechende
Wahl von Kantengewichten kompensiert.
Um die gesuchten Wege im Wegenetz zu finden, benutzen alle Systeme
Shortest Path“-Algorithmen [Cormen]. Dabei verwenden [Kolbe3D] und [Kolbe]
”
den Floyd(-Warshall)-Algorithmus“, der für große Wegenetze aber auf Grund
”
seines hohen Speicherbedarfs nicht geeignet ist. [Pressl] und [Tomberge] nutzen
dagegen den Dijkstra-Algorithmus“, der sparsamer mit Speicher umgeht. In
”
[Kufner] wird der A∗-Algorithmus“ verwendet, welcher eine Erweiterung des
”
Dijkstra-Algorithmus“ ist. Alle drei Algorithmen liefern optimal kürzeste We”
ge als Ergebnis.
3
VERWANDTE ARBEITEN
3.4
65
Zusammenfassung
Im vergangenen Kapitel wurden verschiedene Systeme vorgestellt, die einen
Einblick in die Teilgebiete dieser Diplomarbeit geben.
In 3.1 wurden verschiedene Systeme vorgestellt die Avatare einsetzen, um
den Benutzer mit dem System interagieren zu lassen. Alle vorgestellten Lösungen benutzen zur Darstellung technische Geräte, die entweder komfortabel groß,
aber stationär sind ([Rickel1], [MAEVIF06], [Lester], [Andre], [PEACH06]),
oder zusätzlich mit mobilen Geräten erweitert wurden, die aber eingeschränkte
Darstellungsmöglichkeiten haben [PEACH06].
Diese Diplomarbeit nutzt den in 2.8 vorgestellten Ansatz eines projizierten
Displays, das auf beliebige Flächen positioniert werden kann. Dadurch ist es
möglich, den Avatar beim Benutzer zu positionieren, ohne auf fest installierte
Geräte angewiesen zu sein oder einen Kompromiss bei der Größe des Displays
eingehen zu müssen.
Die vorgestellten Raum- und Objektmodelle aus 3.2 zeigen verschiedene
Möglichkeiten der Modellierung auf. Die Modelle aus 3.2.1 und 3.2.3 sind sehr
detailliert und dementsprechend komplex und umfangreich. Das Modell in 3.2.2
konzentriert sich hauptsächlich auf die Inneneinrichtung eines Raums unter Beachtung von Objekten, die die Ausbreitung von Schallwellen beeinflussen. In
3.2.4 wird das Modell in den 2-dimensionalen Raum übertragen, und während
des Betriebs werden virtuelle 3D-Graphiken mit Hilfe des Head Mounted Dis”
plays“ eingefügt.
In Kapitel 3.3 wurden einige Ansätze für Wegenetze vorgestellt, welche man
aus unterschiedlichen Datenquellen generiert hat. Alle Wegenetze wurden jedoch von Hand erzeugt, nicht in einem automatisierten Prozess. Die Struktur
der Wegenetze ist bei allen Ansätzen ein ebener gewichteter Graph. Die gesuchten Wege wurden mittels Shortest Path“-Algorithmen berechnet.
”
3
VERWANDTE ARBEITEN
66
Im Rahmen dieser Diplomarbeit wird ein einfaches Raummodell vorgestellt,
das alle nötigen Informationen enthält, um ein Display auf einer freien Fläche
zu positionieren. Desweiteren wird mit dem Raummodell ein Wegenetz automatisch generiert, das noch die 3D-Informationen enthält.
4
LÖSUNGSANSATZ
4
67
Lösungsansatz
4.1
Allgemein
Der Avatar, und damit das projizierte Display, sollen sich frei auf den Oberflächen des Raums bewegen. Um dies gewährleisten zu können, muss das Display Informationen darüber besitzen, wie der Raum, in den es projiziert werden
soll, beschaffen ist. Nur wenn diese Informationen zur Verfügung stehen, kann
das Display in den gegebenen Grenzen der Oberflächen des Raums korrekt und
vollständig dargestellt werden. Die benötigten Informationen hierzu werden vom
Raummodell bereitgestellt. Somit ist es möglich zu entscheiden, wo das Display
dargestellt werden kann, jedoch noch nicht, wie es von einem Punkt des Raums
zu einem anderen gelangt.
Das Display kann sich nur von einem Punkt des Raums zu einem anderen
Punkt bewegen, wenn es Stück für Stück auf den Oberflächen entlang wandert.
Die Punkte, zu denen der Avatar gehen soll, stehen eventuell schon teilweise
fest. Es sind vielleicht besondere Punkte, an denen der Avatar stehen bleibt, um
dem Benutzer etwas erklären zu können. Damit die Bewegungen zwischen diesen Punkten einem gewissen Schema folgen und so zum einen für den Benutzer
nachvollziehbar, und zum anderen möglichst kurz sind, wird ihnen ein Wegenetz
zu Grunde gelegt. Mit Hilfe eines solchen Wegenetzes werden die Bewegungen
des Avatars systematisiert, er bewegt sich nun auf vorher berechneten Pfaden
über die Oberflächen im Raum. Des weiteren gibt es eine breite Auswahl an
Algorithmen zum Finden kürzester Wege in einem solchen Wegenetz, mit deren
Hilfe es möglich ist, diese Bewegungen zeitsparend und effizient zu optimieren.
Während einer solchen Bewegung sollte sich der Avatar der Verschiebung
des Displays entsprechend verhalten. Wenn das Display sich zum Beispiel horizontal bewegt, dann sollte der Avatar dieser Bewegung entsprechend, eine
Gehbewegung ausführen. Die Bewegungen des Avatars sind dabei aber nur ein
Teil des Eindrucks, den der Benutzer hat, die Reaktionen des Avatars auf den
4
LÖSUNGSANSATZ
68
Benutzer sind ein weiterer wichtiger Teil. Zur Interaktion mit dem Benutzer
muss der Avatar ständig auf das Verhalten des Benutzers reagieren, da dieser
unter Umständen den Avatar sonst nicht mehr beachtet. Um den schlimmsten
Fall zu vermeiden, das einseitige Beenden der Interaktion, beachtet das System
ständig die Aktionen des Benutzers und reagiert auf verschiedene Verhaltensweisen. Diese Reaktionen des Avatars folgen einer Logik, die dynamisch auf
die aktuellen Aktionen des Benutzers reagiert und das Verhalten des Avatars
steuert.
Die Logik berücksichtigt dabei zum einen das aktuelle Verhalten des Benutzers und zum anderen den aktuellen Zustand, in dem sich der Avatar befindet,
also was er gerade tut.
Im Weiteren wird nun genauer auf die einzelnen Bestandteile dieser Arbeit
eingegangen, beginnend mit dem Raummodell und dem darauf aufbauenden
Wegenetz, in dem sich der Avatar bewegen kann. Anschließend wird beschrieben, wie der Avatar seinen Weg durch den Raum findet, bevor dann mit dem
Konzept der Datensicherung dieses Kapitel abgeschlossen wird.
4.2
Raummodell
Das System muss Informationen über die Beschaffenheit des Raums haben,
damit es in der Lage ist, die projizierten Displays, und damit den Avatar, automatisch auf freie Flächen im instrumentierten Raum zu positionieren. Fehlen
diese Informationen, ist es dem System nicht möglich zu entscheiden, wo im
Raum eine freie Stelle ist, an der es ein Display positionieren kann. Das Fluid
”
Beam“-System benutzt zum Entzerren der Displays ein Raummodell, das aus
Ebenen besteht, die die Lage der Darstellungsflächen repräsentieren. Die Begrenzungen dieser Ebenen und eventuelle Hindernisse auf den Flächen sind in
diesem Modell nicht enthalten, da sie nicht relevant sind für den Prozess zum
Entzerren der projizierten Displays.
4
LÖSUNGSANSATZ
69
Durch das Fehlen der Informationen über den Raum ist es möglich, mit dem
Fluid Beam“-System ein Display an eine Stelle zu projizieren, an der eventuell
”
kein Platz für das Display ist. Auch ist es möglich, an eine Stelle zu projizieren, an der im virtuellen Raum eine Projektionsebene ist, aber im realen Raum
nicht. Dies kann passieren, wenn die Fläche im realen Raum dort schon begrenzt
ist und nicht genügend Platz für das Display ist oder dort keine reale Fläche
existiert. In beiden Fällen kommt es zu unschönen Effekten, die man vermeiden
möchte.
Um dieses Problem zu beheben wäre es möglich gewesen, entweder das
bestehende Modell des virtuellen Raums des Fluid Beam“-Systems um die
”
benötigten Informationen, wie zum Beispiel Position, Lage und Ausdehnung
von Objekten, Wänden, etc. zu erweitern oder ein neues Modell zu erzeugen,
das diese Informationen enthält.
Im Fall der Erweiterung des bestehenden Modells, wären das System zur
Entzerrung der dargestellten Displays und das System zur Steuerung des Avatars untrennbar miteinander verwoben. Eine klare Trennung zwischen Datenmodell und Darstellung wäre nicht mehr gegeben, welche aber in dem Systementwurf aus qualitativen Gründen des softwaretechnischen Designs einerseits
und der logischen Trennung zwischen Daten und Darstellung andererseits beibehalten werden sollte. Ein solcher modularer Aufbau hat den entscheidenden
Vorteil, dass man das System relativ leicht und komfortabel erweitern oder erneuern kann. Man muss in solch einem Fall nur ein Modul, zum Beispiel das
Datenmodell, verändern, kann aber die anderen Teile unberührt lassen. Ein weiterer Vorteil ist die Wiederverwendbarkeit, wenn zum Beispiel in einem anderen
Projekt nur ein Teil des Systems benötigt wird, kann dann nur der benötigte Teil
eingebunden werden, ohne den unnötigen Ballast anderer Module zu verwenden. Deshalb wurde ein neues Raummodell erzeugt, das nur die Informationen
über die Beschaffenheit des Raums beinhaltet und losgelöst von der Darstellung
4
LÖSUNGSANSATZ
70
der Displays ist.
Der Avatar benötigt auf Grund seiner Größe eine Fläche mit bestimmten
Ausmaßen, um gut erkennbar dargestellt werden zu können. Theoretisch ist es
möglich ein Display, und somit den Avatar, auf eine Kante, in eine Ecke oder
auf uneinheitliche Flächen zu projizieren. In einem derartigen Fall wäre es nicht
möglich das Bild so darzustellen, dass es aus allen möglichen Positionen und
Blickwinkeln verzerrungsfrei ist, was zu Irritationen führen würde. Diese Irritationen könnten sich in der Ablehnung des Systems niederschlagen. Schließlich
soll der Avatar mit dem Benutzer kommunizieren, was voraussetzt, dass der Benutzer auf den Avatar reagiert und diesen als Gesprächspartner“ akzeptiert.
”
Folglich sollte der Avatar auf einer einheitlichen Fläche projiziert werden mit
genügend Platz für das ganze Display.
Für das dem System zu Grunde liegende Raummodell bedeutet dies, dass
nur die Objekte eine wichtige Rolle spielen, die genügend Fläche für die Displays bieten. Ein absolut realitätsgetreues Raummodell, das alle Details, egal
wie klein sie auch sein mögen, beinhaltet, hat mehr Informationen als es eigentlich braucht. Des Weiteren ist die Erstellung eines derart genauen Modells eine
recht komplexe und zeitintensive Arbeit, die die Installation des Systems unkomfortabel und aufwendig gestaltet. Auch bei einer Veränderung des Raums,
wenn etwa ein Tisch oder ein anderes Objekt verstellt wird, werden die Korrekturen unter Umständen sehr aufwendig.
Unter Berücksichtigung dieser Aspekte wurde eruiert, was die entscheidenden Kriterien für das Gesamtsystem sind, also welche Objekte im Raum beim
Betrieb des Systems von Bedeutung und welche vernachlässigbar sein werden.
Die für das System wichtigen Objekte im Raum sind alle Oberflächen, die
genügend Platz bieten, um ein Display darauf zu projizieren. Aber nicht nur
die Fläche der Objekte ist relevant, sondern auch die Farbe (möglichst hell),
4
LÖSUNGSANSATZ
71
die Struktur (möglichst glatt) und die Form dieser Fläche. Projiziert man ein
Display zum Beispiel auf einen Wandteppich oder ein Bild, das an der Wand
hängt, kann der Benutzer das projizierte Bild nicht richtig oder nur sehr schwer
erkennen. Ist die Darstellungsfläche gekrümmt oder besteht aus einer anderen
nicht ebenen geometrischen Form, so ist das dargestellte Bild eher befremdlich
für den Benutzer. Da die projizierten Displays eine gewisse Größe haben, stellte
sich heraus, dass eine Approximation der Darstellungsflächen für die Anwendung ausreichend ist. Hieraus ergab sich, dass die ebenen Flächen im Raum,
das entscheidende Merkmal für das Raummodell sind. Ein wichtiges Kriterium
ist die Tatsache, ob auf einer solchen Fläche ein Bild so projiziert werden kann,
dass es für den Benutzer akzeptabel ist. Also ob die Fläche zum Darstellen
geeignet ist oder nicht; Farbe und Struktur der Fläche sind von Bedeutung.
So wurde das Raummodell nicht als exakte Abbildung der Wirklichkeit entworfen, sondern in einer vereinfachten Form, die die reale Welt abstrahiert darstellt.
Die für das Modell relevanten Objekte im Raum sind zum einen die Flächen,
durch die der Raum nach außen begrenzt ist, also überhaupt definiert wird. Im
Allgemeinen sind das die äußeren Wände und der Boden, welche auch in der
Realität fast immer plane Ebenen sind. Die Decke hingegen, ist von geringerer Bedeutung, da die Projektor-Kamera-Einheit im instrumentierten Raum so
aufgestellt ist, das die Decke nicht als Darstellungsfläche in Frage kommt. Die
Einheit hängt direkt unter der Decke, so dass der Winkel, in dem die Projektion
auf die Decke trifft, kein erkennbares Bild zulässt. Trotzdem wurde das Modell
so designt, dass die Decke eingebunden werden kann. In der Zukunft besteht
vielleicht die Möglichkeit, die Projektor-Kamera-Einheit so zu befestigen, dass
sie auch die Decke erreichen kann. Vielleicht wird das System auch in einem
Raum benutzt der hoch genug ist, so dass der Beamer in einer Höhe befestigt
wird, von der aus auf die Decke projiziert werden kann. Eine andere Möglichkeit wäre die Befestigung an einer Vorrichtung die während des Betriebs den
Beamer entsprechend vertikal verschieben kann.
4
LÖSUNGSANSATZ
72
Die im Raum platzierten Objekte sind die nächste wichtige Gruppe, da sie
den Raum im Inneren begrenzen. Diese Objekte können anders als die äußeren Wände und der Boden eine deutlich differenziertere Struktur aufweisen.
Ein Schreibtisch zum Beispiel ist je nach Bauart ein recht komplexes Gebilde mit vielen verschobenen Flächen, Rundungen, Löchern und ausstehenden
Wölbungen, wie etwa die Griffe an Schubladen. Für das System ist bei einem
Schreibtisch aber nur die Schreibplatte relevant, da sie der einzige Teil ist, der
genügend Fläche bietet, auf der das Display mit dem Avatar dargestellt werden
kann. Denn die Vorderseiten der Schubladen bieten ebenso zu wenig Fläche für
den Avatar wie die Tischbeine. Weiterhin wäre es unschön und auch unpraktisch, wenn ein Display unter den Schreibtisch projiziert werden würde. Folglich
genügt für das System die Information, dass an der Stelle, an der ein Schreibtisch steht, eine waagerechte Oberfläche ist, auf die projiziert werden kann. Da
alle weiteren Teile für eine Projektion des Bildes ungeeignet sind, können sie
weggelassen werden. Die Bereiche der Darstellungsflächen, die vom Schreibtisch
verdeckt werden (etwa ein Teil einer Wand, an der der Tisch steht), müssen als
Hindernisse modelliert werden. Analog hierzu sind die relevanten Informationen für die Repräsentation anderer Objekte im Raum ebenfalls Flächen, die
entweder als Darstellungsfläche dienen können oder Hindernisse darstellen.
Daraus ergibt sich die Schlussfolgerung, dass das Raummodell genügend Informationen für das System besitzt, wenn es die freien, darstellungstauglichen
und die nicht darstellungstauglichen Bereiche im Raum unterscheiden kann. Um
dies zu gewährleisten, genügt die Vereinfachung auf Flächen im Raum. Man
kann jedes Objekt im Raum approximativ darstellen, indem man es durch die
es umschließenden Flächen beschreibt. Das vom Projektor ausgesandte Licht
kann nicht durch ein Objekt hindurch, zum Beispiel in eine Schublade hinein.
Daraus ergibt sich eine weitere Vereinfachung. Da für den Projektor nur die
ihm zugewendeten Flächen relevant sind, genügen auch nur diese Flächen zur
Beschreibung des Raums. Alle Flächen, die auf der Rückseite oder im Inneren
eines Objekts liegen, sind unerreichbar und damit irrelevant.
4
LÖSUNGSANSATZ
73
Mit einfachen Flächen kann man also genügend Informationen abbilden, so
dass das System weiß, wo es ein Display, und damit den Avatar, platzieren
kann. Bleibt nun noch die Frage des Aussehens dieser Flächen zu klären. Die
einfachste ebene Fläche ist ein Rechteck. Mit einem einfachen Rechteck kann
man problemlos einen einfachen Tisch modellieren. Der Tisch besteht aus einer
Fläche oben, der Tischplatte, und darauf kann ein Display projiziert werden.
Die Vorderseite und gegebenenfalls die rechte und linke Seite des Tisches, wenn
diese vom Projektor aus sichtbar sind, sind ebenfalls Rechtecke, welche man
aber auch weglassen könnte, da man darauf nicht projizieren kann. Fertig ist
das Modell eines Tisches. Für einen einfachen Tisch mag dieses Modell völlig
ausreichen, aber betrachtet man einen modernen Schreibtisch, so erkennt man,
dass dieser unter Umständen nicht einfach ein Rechteck mit vier Ecken ist.
Viele Schreibtische können heute L-förmig sein oder haben Aussparungen an
einer oder mehreren Stellen. Dieses Modellierungsproblem könnte man beheben,
indem man mehrere Flächen aneinander modelliert. Ein Verfahren, das unter
Umständen recht aufwendig für denjenigen ist, der das Modell erstellen muss.
Eine weitaus komfortablere Lösung, als ein Objekt durch viele kleine Objekte
zu modellieren, ist die Form der modellierten Fläche dem Objekt anzunähern.
Denn Oberflächen in einem Raum sind nicht nur rechteckig, sie können ebenso
gut mehrere Ecken haben oder sogar rund sein. Solche Objekte zu modellieren,
kann dann eine sehr aufwendige Arbeit sein. Einfacher ginge es, wenn die modellierten Flächen sich approximativ an andere Flächen anpassen lassen, nicht
als Zusammenschluss vieler kleiner Flächen. Die Lösung hierzu war die Erweiterung des einfachen viereckigen Flächenmodells durch die Möglichkeit, eine
Fläche durch beliebig viele Kanten definieren zu können, die jeweils senkrecht
aufeinander stehen. Die Vereinfachung von senkrecht aufeinander stehenden
Begrenzungen der Flächen ist vollkommen ausreichend für die Genauigkeit des
Raummodells, da die projizierten Displays einfache viereckige Rechtecke sind.
Die Genauigkeit der modellierbaren Flächen im Vergleich zu den realen Objekten ist mehr als ausreichend für das System, selbst bei relativ hoher Abstraktion,
4
LÖSUNGSANSATZ
74
und kann je nach Belieben bei der Erstellung des Raummodells verfeinert werden. Eine zu genaue Abbildung der realen Welt ist jedoch nicht nötig für die
Darstellung des Avatars.
Die Darstellungsflächen werden in zwei Klassen eingeteilt, je nach der Möglichkeit ihrer Positionierung. Zum einen die Wände des Raums, welche den Raum
im gesamten begrenzen und jeden Raum definieren. Andere Flächen, wie zum
Beispiel ein Tisch oder eine Stellwand, können dagegen sehr leicht verschoben
werden. Auch müssen solche freien Flächen keinen direkten Bezug zu einer anderen Fläche haben. Eine Stellwand, wie auch ein Tisch zum Beispiel, kann
sowohl an einer Wand stehen als auch völlig frei irgendwo im Raum. Trotzdem
können beide, wie eine Wand, als Projektionsfläche für ein Display genutzt werden. Für eine Positionierung eines Displays spielt dieser Unterschied also keine
Rolle und benötigt auch keinerlei solche Unterscheidung. Das Ziel dieser Arbeit
ist jedoch eine freie und bewegliche Positionierung von Displays, mit dem Ziel
im Hintergrund, dass der Avatar sich möglichst ohne Unterbrechung durch den
Raum auf den vorhandenen Flächen bewegen kann. Da der Avatar sich seinen
Weg über die Flächen des Raums suchen muss, ist die Information darüber
nötig, welcher Art die Flächen sind, die er bevorzugt benutzt. Die Bewegungen
des Avatars sollen für den Benutzer nachvollziehbar und im besten Fall voraussehbar sein, so dass der Benutzer nicht unangenehm überrascht wird und
den Avatar aus den Augen verliert. Die logische Unterscheidung zwischen einer stationären Fläche und einer eventuell mobilen ist vom Gesichtspunkt der
Wegsuche also sinnvoll.
Im realen Leben, wie auch im instrumentierten Raum, besteht unsere Umgebung nicht nur aus freien Flächen. Es existieren in fast jeder Umgebung
Hindernisse unterschiedlichster Art, die der Positionierung und Bewegung von
projizierten Displays gewisse Grenzen setzen. Solche Hindernisse können die
verschiedensten Dinge sein, wie zum Beispiel Fenster, Türen, Regale, Lampen,
Bilder etc. Wird ein Display beispielsweise auf ein Fenster projiziert, so ist das
4
LÖSUNGSANSATZ
75
Bild für den Benutzer fast nicht sichtbar, folglich muss man wissen, wo sich ein
Fenster oder ein anderes Hindernis befindet, damit man nicht dorthin projiziert.
Neben Fenstern und Türen sind an Wänden aufgehängte Bilder die wahrscheinlichsten Hindernisse und teilen mit Fenstern und Türen die Eigenschaft, dass sie
meist rechteckig sind. Rechteckige Flächen als Hindernisse in das Raummodell
zu integrieren, erhöht nicht den Schwierigkeitsgrad der Raummodellierung.
Ein Hindernis muss nicht notwendigerweise ein viereckiges flaches Objekt
wie eine Tür oder ein Fenster sein, sondern kann auch ein Gegenstand auf einem Tisch oder ein Möbelstück im Raum sein. Das notwendige Kriterium für
die Klassifikation eines Objekts als Hindernis ist die Tatsache, dass sich das
Objekt nicht als Darstellungsfläche für ein Display eignet, egal welche Form
das Objekt hat. Mit anderen Worten: eine Computertastatur oder ein Globus
auf einem Schreibtisch sind ebenso Hindernisse wie ein Gemälde, das an der
Wand hängt. Nur ist ein Globus kein flaches Objekt, und ihn mit flachen Scheiben approximativ zu modellieren, birgt einen hohen und damit unkomfortablen
Arbeitsaufwand. Für die Positionierung eines Display ist die genaue Form des
Globus jedoch uninteressant, nur seine Größe und seine Position in Bezug zu
den ihn umgebenden Flächen auf denen ein Display projiziert werden kann sind
von Belang.
Das Raummodell soll so einfach und prägnant wie möglich sein, womit dann
auch die Hindernisse so einfach und übersichtlich wie möglich modelliert werden
sollten. Da von Hindernissen nur ihr Projektionsschatten, also der Bereich der
von dem Hindernis auf den Darstellungsflächen verdeckt wird, für das Modell
relevant ist, sollte auch nur dieser modelliert werden. Der Projektionsschatten
von Objekten ist eine von den Ausmaßen des Objekts begrenzte Teilfläche auf
einer Darstellungsfläche. Ein Hindernis als begrenzte Fläche ist mit der oben genannten Approximation von rechtwinklig aufeinander stehenden Kanten leicht
und genau zu modellieren und passt als solche logisch zu dem Konzept des aus
Flächen bestehenden Raummodells.
4
LÖSUNGSANSATZ
76
Ein kleiner Nachteil dieser Lösung ist der eher selten auftretende Fall, dass
ein Hindernis sich über verschiedene Darstellungsflächen erstreckt. Dann ist es
notwendig, das Hindernis als verschiedene Flächen zu modellieren, jeweils einmal auf jeder Darstellungsfläche. Da dieser Fall aber eher selten ist und die
Vorteile des einfachen und gut strukturierten Modells überwiegen, wurde dieser
Nachteil beim Entwurf des Raummodells in Kauf genommen.
4.3
Wegenetz
Im folgenden wird das Wegenetz näher erläutert, das den Bewegungen des Avatars zu Grunde liegt.
Der Avatar soll sich frei auf den Flächen des Raums bewegen können. Die
Informationen über die Beschaffenheit des Raums genügen, um feststellen zu
können, an welchen Stellen das Display, und damit der Avatar, positioniert werden kann. Punkte, an denen das Display positioniert werden kann, reichen aus,
um einen Weg zu generieren. Dieser Weg basiert dann nur auf den lose auf den
Flächen befindlichen Punkten und weicht höchstwahrscheinlich von einem optimalen Weg deutlich ab, wenn der Avatar zum Beispiel Hindernisse umlaufen
muss. Damit die Bewegungen des Avatars über die Darstellungsflächen nicht
chaotisch oder unnötig lang sind, müsste das System zusätzliche, strukturelle
Informationen über mögliche Wege besitzen.
Mit dem Wissen über mögliche Wege durch den Raum ist es möglich, aus
den sich stellenden Möglichkeiten eine intelligente“ Auswahl zu treffen. Ein
”
Wegenetz muss sich über den gesamten Raum erstrecken und alle Darstellungsflächen miteinander verbinden, egal ob sie Wände oder frei im Raum befindliche Flächen sind. Gleichzeitig müssen die Hindernisse berücksichtigt werden
sowie die verschiedenen Übergänge zwischen den Darstellungsflächen. Hindernisse müssen entsprechend ihrer Lage gemieden oder passiert werden können.
Die Strategie hierzu wird im nächsten Unterkapitel erläutert. Die unterschied-
4
LÖSUNGSANSATZ
77
lichen Darstellungsflächen und die Übergänge zwischen ihnen müssen ebenfalls
berücksichtigt werden, um eine möglichst homogene Bewegung zu gewährleisten. Werden die verschiedenen Übergänge gleich behandelt, also keine Unterschiede berücksichtigt, so verhält sich der Avatar beim Wechseln von einer
Wand zu einer anderen genauso wie beim Wechseln von einer Wand zu einer
freien Fläche. Die freie Fläche ist aber im Gegensatz zu einer benachbarten
Wand unter Umständen ohne direkten räumlichen Kontakt zu der Wand und
steht in einiger Entfernung dazu. Eine andere Möglichkeit wäre, dass die freie
Fläche waagerecht ist, also ganz anders im Raum liegt als eine Wand. In beiden
Fällen könnte der Benutzer durch das Verhalten des Avatars irritiert werden,
wenn dieser sich stets gleich verhält, egal wo er sich gerade befindet.
In der instrumentierten Umgebung gibt es einige besondere Punkte, zum
Beispiel in der Nähe von technischen Geräten, die der Avatar dem Benutzer
erklären soll, oder andere markante Stellen und Einrichtungsgegenstände. Diese Punkte im Raum sind durch die Einrichtung vorgegeben und bestimmen in
gewissem Maße die Bewegungen des Avatars. Um den Benutzer zielsicher und
direkt durch den Raum zu führen, braucht der Avatar ein strukturiertes Gerüst,
mit dessen Hilfe er navigieren kann.
Das Wegenetz, das dem Avatar als Gerüst für seine Gänge durch den Raum
dienen soll, besteht klassisch aus Knoten und Kanten. Die Knoten sind die
Punkte, an denen der Avatar stehen bleiben kann, wenn die Situation es erfordert. Die Kanten verbinden die Knoten miteinander und beschreiben folglich
den Weg oder zumindest die Teile, aus denen sich der Weg zusammensetzt. Ein
weiterer Vorteil eines derartigen Wegenetz ist die Vielzahl an Algorithmen, die
es zum Finden von Wegen in solchen Wegenetzen gibt.
Ein Wegenetz bestehend aus Knoten und Wegkanten, das alle Darstellungsflächen bedeckt und einfach nur miteinander verbindet, reicht jedoch nicht aus.
Es müssen weitere Informationen aus dem Raummodell übernommen werden,
4
LÖSUNGSANSATZ
78
um die genannten Probleme zu bewältigen. So enthalten die Knoten Informationen darüber, auf welcher der Darstellungsflächen des Raums sie liegen und ob
sie für eine bestimmte Aufgabe besonders geeignet sind, wie zum Beispiel das
Erläutern eines Einrichtungsgegenstandes, neben dem der Knoten liegt. So weiß
das System, wann der Avatar gut positioniert ist und was in der Nähe ist. Die
Kanten des Wegenetz sind gewichtet, so dass der Algorithmus zum Finden eines
Pfads von einem zu einem anderen Punkt den besten und nicht einen beliebigen Weg findet. Durch die Gewichtung beinhaltet das Wegenetz Informationen
über die Lage der einzelnen Knoten zueinander. So sind horizontal verlaufende
Kanten anders gewichtet als vertikal verlaufende. Weiterhin haben die Kanten
Informationen über ihre eigene Lage durch ihre Gewichtung. So haben Kanten,
die innerhalb einer Darstellungsfläche verlaufen, eine andere Gewichtung als jene, die zwei benachbarte Darstellungsflächen miteinander verbinden. Auch sind
die Gewichte von Kanten zwischen verschiedenen Übergängen von zwei Darstellungsflächen unterschiedlich. Zum Beispiel ist das Gewicht einer Kante, die
zwei benachbarte Wände verbindet, ein anderes als das einer Kante, die eine
Wand und eine freie Darstellungsfläche miteinander verbindet.
Auf diese Weise ist es gelungen, Informationen aus dem Raummodell in das
Wegenetz zu übertragen, mit deren Hilfe der Avatar optimal bewegt und die
Art der Bewegung gesteuert werden kann. Denn eine horizontale Bewegung des
Avatar ist für den Benutzer etwas völlig anderes als zum Beispiel eine vertikale.
Eine Gleichbehandlung der verschiedenen Bewegungsmöglichkeiten würde zu
einem unrealistischen Verhalten des Avatars führen und so eventuell zu einer
ablehnenden Haltung des Benutzers gegenüber dem System.
Die Entscheidung, ein Wegenetz als Grundlage der Bewegungen des Avatars
zu verwenden, wodurch diese dann strukturiert und optimiert werden können,
war naheliegend. Aber wie sollte das Wegenetz gestaltet werden? Wie sollen
sich die Knoten und Kanten über die Darstellungsflächen verteilen? Die Struktur legt schließlich die Bewegungen des Avatars fest. Der Avatar sollte sich
4
LÖSUNGSANSATZ
79
möglichst frei überallhin bewegen können. Eine Möglichkeit wäre, die Knoten
nur an den Rändern der Flächen und um die Hindernisse herum zu verteilen, wodurch die markanten Punkte im Raum identifiziert wären. Der Avatar
könnte dann zwischen ihnen frei herumspazieren. Dann käme es aber häufig
zu der Situation, dass der Avatar sich auf einer Diagonalen durch den Raum
bewegen würde, zum Beispiel von einem Punkt links unten zu einem anderen
Punkt rechts oben. Einerseits stand eine dazu passende Animation nicht zur
Verfügung, und andererseits wäre eine solche Bewegung nur äußerst schwer zu
synchronisieren. Das Resultat wäre ein Avatar der eckig und wackelnd eine imaginäre Treppe erklimmt. Die Diagonalbewegung als Idee ist gut, aber bei der
Umsetzung wären unschöne Nebeneffekte aufgetreten, die bei einem Benutzer
wohl auf Unverständnis gestoßen wären. Horizontale und vertikale Bewegungsabschnitte sind etwas einfacher mit der Animation zu realisieren und zu synchronisieren. Sie lassen den Avatar leicht voraussehbare Wege gehen, was dem
Benutzer und so der Akzeptanz des Systems entgegen kommt. So ergibt sich
die Struktur des Wegenetz als ein Netz von nebeneinander und übereinander
liegenden Knoten, von denen je zwei horizontal oder vertikal benachbarte Knoten mit einer Kante verbunden sind. Die Abstände zweier benachbarter Knoten
voneinander können sowohl in horizontaler wie auch in vertikaler Richtung voreingestellt werden, damit sich das Wegenetz an die Begebenheiten des Raums,
in dem es verwendet wird, anpassen lässt. Ein weitläufiger Raum, der aus großen
viereckigen freien Flächen mit wenigen Hindernissen besteht, benötigt ein weniger dichtes Wegenetz als ein Raum mit sehr verwinkelten Flächen, auf denen
sich viele Hindernisse befinden, die umlaufen werden müssen. Der horizontale
bzw. vertikale Abstand zwischen zwei benachbarten Knoten ist im gesamten
Wegenetz einheitlich. Dies schränkt die Freiheit der Platzierung der einzelnen
Knoten und damit der stationären Positionen des Avatars zwar etwas ein, da so
eine beliebige Position im Raum nicht mehr möglich ist. Dieser Nachteil kann
jedoch durch geeignetes Wählen der horizontalen und vertikalen Abstände der
Knoten so weit kompensiert werden, dass der Benutzer keinen Unterschied zwischen einem beliebig und einem auf dem Wegenetz platzierten Display merkt.
4
LÖSUNGSANSATZ
80
Falls es erwünscht ist, kann das Wegenetz so dicht gewählt werden, dass die
Knoten weniger weit voneinander entfernt sind als die Größe des Avatars auf
einer Darstellungsfläche.
Die recht starre Struktur des Wegenetzes dient also einerseits der besseren Synchronisation mit der Animation des Avatars, die der besseren Optik im
Betrieb und somit dem Benutzer entgegenkommt. Andererseits werden durch
diese Struktur die Wege des Avatars durch den Raum deutlicher strukturiert,
wodurch die Benutzbarkeit des Systems verbessert wird, was ebenfalls dem Benutzer entgegenkommt.
Abbildung 22: Wegenetz auf einer Wand mit Hindernissen. Rot: die Knoten,
Blau: die Kanten, Gelb: die Hindernisse (v.l.n.r.: eine Tür, ein Bild, ein Tisch
mit Lampe)
Unter anderem hat das Wegenetz die Aufgabe, den Avatar sicher um Hindernisse herum zu leiten, was bedeutet, dass beim Umgehen von Hindernissen der
4
LÖSUNGSANSATZ
81
Avatar nicht mit dem Hindernis zusammenstoßen darf. Dazu sind die Knoten
in der Nähe eines Hindernisses in einem genügend großen Abstand vom Hindernis platziert, so dass der Avatar problemlos herumgehen kann. Ebenso wird
am Rand von Darstellungsflächen verfahren, wodurch vermieden wird, dass ein
Teil des Avatars auf einer Wand ist und der Rest von ihm auf einer anderen
Wand. In Abbildung 22 ist eine Wand mit Hindernissen und einem Wegenetz
dargestellt.
Mit Hilfe des Wegenetz steht dem Avatar ein skalierbares System von Punkten zur Verfügung, an denen er mit dem Benutzer kommunizieren kann, und
eine Vielzahl an dynamisch auswählbaren möglichen Verbindungen zwischen
diesen Punkten. Wie das System eine Menge solcher Verbindungen auswählt,
um den Avatar von seinem Standort zu einem beliebigen Zielort zu bewegen,
wird im nächsten Kapitel erläutert.
4.4
Wege durch den Raum
Das im vorherigen Kapitel beschriebene Wegenetz stellt die Struktur, mit deren Hilfe der Avatar durch den Raum navigieren kann. Die Ausgangssituation
zum Finden eines Weges ist wie folgt: Der Avatar steht an einer bestimmten
Stelle, dem Startpunkt, dessen Koordinaten bekannt sind, und soll sich zu einem Ziel bewegen, dessen Koordinaten ebenfalls bekannt sind. Diese Start- und
Zielkoordinaten müssen nicht unbedingt deckungsgleich mit den Koordinaten
eines Knotens aus dem Wegenetz sein. Eventuell sind es sogar Koordinaten
eines Hindernisses im Raum, einem Einrichtungsstück vielleicht, zu dem der
Avatar gehen soll, damit er dem Benutzer etwas über dieses Einrichtungsstück
erzählen kann. Die erste Aufgabe beim Finden eines geeigneten Weges zu diesen
Koordinaten ist folglich die Identifizierung der nächstmöglichen freien Fläche
bei den Zielkoordinaten. An den Koordinaten dieser freien Fläche befindet sich
ein Knoten des Wegenetz, da sich das Wegenetz über die freien Flächen im
Raum erstreckt. Der Zielpunkt des gesuchten Weges ist im Allgemeinen also
4
LÖSUNGSANSATZ
82
der nächste Knoten bei den Zielkoordinaten. Einfacher ist es natürlich, wenn
der Avatar sich nicht zu einem beliebigen Punkt im Raum, sondern zu einem
bestimmten Punkt bewegen soll, von dem man weiß, dass dort ein Knoten liegt.
Damit sind Startknoten und Zielknoten des zu findenden Weges bekannt,
ein genau definiertes Wegenetz steht zur Verfügung, und alles was nun noch
fehlt ist der optimale Weg vom Start zum Ziel.
Das sich stellende Problem, einen möglichst optimalen Weg in einem Wegenetz zu finden, ist hinlänglich bekannt, und es existieren Algorithmen in den
verschiedensten Ausprägungen zur Lösung dieses Problems. Benannt wird das
Problem in der Fachliteratur als Single Source Shortest Paths Problem. Man
sucht von einem Punkt, der Quelle, ausgehend die kürzesten Wege zu den anderen Punkten. In [Cormen] wird weiter spezifiziert, so dass das Problem exakt
auf das hier zu lösende Problem zutrifft unter dem Namen Single Pair Shortest
Path Problem. Man sucht den kürzesten Pfad von einer Quelle zu einem Ziel.
Die Autoren in [Cormen] merken an, dass diese weitere Spezialisierung des Problems keine Verbesserung bei der Laufzeit der besten Algorithmen im Vergleich
mit dem allgemeineren Problem erreicht. Die Algorithmen lösen das Problem
des kürzesten Pfads auf einem Graphen bestehend aus Knoten und gewichteten
Kanten. Das Wegenetz ist ein eben solcher Graph mit Knoten und Kanten. Bei
dem verwendeten Wegenetz ergeben sich die Kantengewichte jedoch nicht aus
der Entfernung zwischen den Knoten, die die Kante verbindet, sondern aus der
Lage der Kante, was aber für den Algorithmus keine Rolle spielt. Wichtiger für
den Algorithmus ist die Frage nach der Größe der Kantengewichte, da manche
Algorithmen nur auf Graphen angewendet werden können, deren Kantengewichte nicht negativ sind.
Da die Kantengewichte im Wegenetz positiv gewählt wurden, kann man
zum Finden eines kürzesten Pfads einen Algorithmus für diesen speziellen Fall
wählen, der nur positive Kantengewichte zulässt. Der wohl bekannteste Algo-
4
LÖSUNGSANSATZ
83
rithmus zu diesem Problem ist wahrscheinlich Dijkstra’s Algorithmus“. Wie in
”
[Cormen] sehr schön erläutert, beginnt der Algorithmus vom Startknoten aus
und geht iterativ zu den jeweils aussichtsreichsten benachbarten Knoten weiter.
Bei jeder Iteration aktualisiert er die Kosten der bisher gefundenen Wege zu den
bisher besuchten Knoten so, dass er sich für jeden besuchten Knoten nur den bis
zu diesem Knoten kürzesten Weg merkt. Den jeweils aussichtsreichsten Knoten
den der Algorithmus bei jeder Iteration nimmt um fortzufahren, wählt er mit
Hilfe einer Priority Queue. In dieser Priority Queue sind die Knoten enthalten,
deren kürzester Pfad vom Startpunkt aus bislang noch nicht ermittelt ist. Auf
diese Weise ermittelt der Algorithmus den kürzesten Weg vom Startpunkt aus
zu jedem anderen Knoten im Netzwerk. Ist der kürzeste Weg zum Zielknoten
ermittelt, kann man den Algorithmus auch schon abbrechen, bevor er das ganze Wegenetz durchlaufen hat, da die Kosten für Wege zu allen anderen Knoten
nicht von Interesse sind.
Die so gefundenen Wege durch das Wegenetz sind bezogen auf die Kantengewichte die kürzesten Wege zwischen jeweils dem Startknoten und dem
Zielknoten. Wie diese Wege für den Benutzer in den Bewegungen des Avatars
aussehen, ist so noch nicht sicher. Es kann durchaus sein, dass der kürzeste Weg
zwischen zwei Punkten treppenförmig auf einer Wand entlang führt oder über
viele Kanten und Ecken im Raum geht. Diese unschönen Wege werden vom
Algorithmus nicht gewählt, da die Werte der Kantengewichte so gesetzt sind,
dass zum Beispiel horizontale Wege den vertikalen bevorzugt werden. Gleiches
gilt für andere unschöne Wegstücke, wie Kanten oder Ecken, die auf Grund der
hohen Kantengewichte, wenn möglich, gemieden werden.
4.5
Avatar Verhalten
Das Raummodell und das Wegenetz stellen sicher, dass das System weiß, wo
es den Avatar hinbewegen soll und wie es ihn dorthin führt. Aber wann er sich
bewegen oder stehenbleiben oder reden oder auch einfach nur warten soll, ist
4
LÖSUNGSANSATZ
84
nicht klar. Wenn der Avatar ein vorherbestimmtes Programm abspulen soll, ohne auf seine Umwelt zu reagieren, wie es der VRI (siehe 2.8) bisher tat, so muss
man dieses Programm einmal erstellen und kann es dann jederzeit abspielen.
Der Avatar wird jedesmal dem Programmablauf entsprechend so handeln wie
immer.
Ziel dieser Arbeit ist es, den Avatar aus seinem engen Korsett zu befreien,
also nicht einen bestimmten Ablauf immer stur befolgen zu lassen. Er soll in der
Lage sein, auf die Aktionen des Benutzers so zu reagieren, dass es zu einfachen
Interaktionen zwischen ihm und dem Benutzer kommen kann. Schließlich soll
der Avatar dem Benutzer die Umgebung erklären können und mit dem Benutzer zusammen durch den Raum wandern. Dabei ist es wenig hilfreich, wenn
der Avatar zum Beispiel auf der einen Wand ist und etwas erklärt, und der
Benutzer gerade vor der entgegengesetzten Wand steht und sich etwas anderes
anschaut.
Um auf den Benutzer reagieren zu können, muss der Avatar Informationen
über ihn und dessen Verhalten haben. Mit Hilfe der in Kapitel 2.3.5 beschriebenen Infrarotbaken wird die Position des Benutzers ermittelt. Die Position
des Avatars kennt das System und kann sie in Relation zu der Position des
Benutzers setzen, um auf dessen Bewegungen reagieren zu können. Wenn der
Benutzer sich zum Beispiel vom Standort des Avatars entfernt, so kann der
Avatar darauf reagieren, indem er dem Benutzer folgt.
Der in Kapitel 2.3.6 beschriebene digitale Kompass gibt die Blickrichtung
oder zumindest die Orientierung des Benutzers an. Blickt der Benutzter etwa
nicht in die Richtung des Avatars, so könnte der Avatar darauf reagieren und
den Benutzer auf sich aufmerksam machen. Mit den beiden Anhaltspunkten
Position“ und Blickrichtung des Benutzers“ kann der Avatar einfache Verhal”
”
tensweisen des Benutzers erkennen und entsprechend darauf reagieren.
4
LÖSUNGSANSATZ
85
Das Verhalten des Avatars ist durch seine eigene Tätigkeit und das Verhalten des Benutzers bestimmt. Er selbst kann verschiedene Tätigkeiten durchführen,
wie zum Beispiel reden. Diese Tätigkeiten werden durch Zustände beschrieben,
zwischen denen der Avatar wechseln kann. Auslöser für das Wechseln von einem
in einen anderen Zustand sind entweder Aktionen des Benutzers oder Aktionen
des Avatars selbst. Ein Beispiel hierfür wäre der Zustand Reden“, der been”
det wird, sobald der Avatar mit einer Äußerung fertig ist. Das Verhalten wird
in einem Modell bestehend aus Zuständen und Übergängen zwischen diesen
Zuständen beschrieben. Ein solches aus eindeutigen Zuständen und eindeutigen Übergängen bestehendes Modell lässt sich leicht als ein deterministischer
endlicher Automat (DEA) darstellen.
Ein DEA ist nach [Sipser] ein Fünftupel bestehend aus
• den Zuständen (endliche Menge),
• dem Alphabet (endliche Menge),
• der Übergangsfunktion (definiert Zustandswechsel),
• einem Startzustand,
• und einer Menge von akzeptierenden Zuständen, die auch Endzustände
genannt werden.
Der Avatar kann sich in endlich vielen verschiedenen Zuständen befinden. Das
Alphabet besteht in diesem Fall aus den möglichen Ereignissen, die eintreffen
können, wodurch von einem Zustand in einen anderen Zustand gewechselt werden kann. Die Übergangsfunktion beschreibt die möglichen Übergänge zwischen
je zwei Zuständen, d.h. von welchem Zustand in welchen anderen Zustand beim
Eintreffen eines Ereignis gewechselt wird. Der Startzustand ist der Zustand nach
der Initialisierung, und die Endzustände sind die Zustände, von denen aus das
Programm beendet werden darf. Was die einzelnen Elemente im Speziellen bezogen auf den Avatar sind, wird in Kapitel 5 erläutert.
Die Übergänge zwischen den einzelnen Zuständen werden durch Ereignisse
ausgelöst, die entweder vom Avatar oder vom Benutzer kommen. Dabei kann es
4
LÖSUNGSANSATZ
86
durchaus passieren, dass mehrere dieser Ereignisse gleichzeitig eintreten, wobei
das Problem aufkommt zu entscheiden, was der Avatar nun tun soll. Benötigt
wird also eine Entscheidungshilfe, die die auftretenden Ereignisse einordnet
und bestimmt, was als nächstes getan werden soll. In der Künstlichen Intelligenz existieren verschiedene Ansätze zum Treffen solcher Entscheidungen, die
im Verlauf der Zeit immer feiner und mit steigender Intelligenz“ auch immer
”
komplexer geworden sind. Da das Zustandsmodell recht überschaubar ist und
auch die Komplexität der Ereignisse nur eine begrenzte Anzahl an Möglichkeiten aufweist, genügt ein einfaches Entscheidungsmodell zum Auswählen der
nächsten Tätigkeit. Ein solches eher einfaches aber dennoch sehr robustes und
erfolgreiches Modell ist die in der Robotik benutzte Subsumption. Subsumption ist eine Strategie, mit der aus verschiedenen eintreffenden Ereignissen nur
das wichtigste herausgefiltert wird und dieses dann die nächste Handlung eines
Roboters beeinflusst. Dabei werden den möglichen Ereignisse Prioritäten zugeordnet, so dass ein wichtigeres Ereignis unwichtigere Ereignisse und damit das
von diesen ausgelöste Verhalten unterdrückt. So werden auch die Übergänge
zwischen den einzelnen Zuständen beim Verhalten des Avatars vollzogen, indem unwichtigere eingetroffene Ereignisse unterdrückt werden.
4.6
Datensicherung
Das Raummodell und das Wegenetz sind zwei essenzielle Teile des Systems,
die wichtige Informationen enthalten, ohne die der Avatar sich nicht bewegen
kann. Da ein System normalerweise nicht ununterbrochen läuft, sondern von
Zeit zu Zeit ausgeschaltet wird, ist es notwendig, diese Daten zu sichern. Es sei
denn, man möchte bei jedem Systemstart das Raummodell und das Wegenetz
neu modellieren und initialisieren, was aber irrational wäre. Um die Datensicherung möglichst effizient zu machen, werden nur die notwendigen Daten
gespeichert und alles was automatisch, also ohne Aufwand generiert werden
kann, wird weggelassen. Das Raummodell ist der zentrale Teil des Ganzen und
kann folglich nicht weggelassen werden, wohingegen das Wegenetz dynamisch
4
LÖSUNGSANSATZ
87
anhand der Daten des Raummodells erzeugt wird. Die Daten des Wegenetz sind
folglich redundant und müssen auch nicht gespeichert werden.
Das Raummodell besteht aus verschiedenen Objekten, die Informationen
enthalten und unterschiedliche Eigenschaften besitzen. Diese Informationen müssen
in einer strukturierten Form gespeichert werden, die robust ist gegen äußere
Einflüsse, wie etwa spätere Erweiterungen des Systems. Das Raummodell als
serialisiertes Java-Objekt zu speichern, wäre keine gute Idee, denn sobald etwas
an der Datenstruktur geändert wird, können ältere Raummodelle nicht mehr
gelesen werden. Eine Erweiterung des Systems wäre so nur schwer möglich.
In den letzten Jahren erfreut sich XML wachsender Beliebtheit, als eine
Möglichkeit, Daten strukturiert und vom Datenmodell unabhängig zu speichern. Ein Vorteil von XML ist die gute Lesbarkeit der XML-Dateien, die man
problemlos mit jedem Texteditor anpassen kann. So ergibt sich die Möglichkeit,
das Raummodell nicht nur zu speichern, sondern bei Bedarf auch einfach und
unkompliziert anzupassen, etwa wenn sich etwas an der Anordnung der Objekte
im Raum geändert hat.
5
IMPLEMENTIERUNG DES SYSTEMS
5
89
Implementierung des Systems
5.1
Sprache
Zum praktischen Erstellen des im letzten Kapitel vorgestellten Raummodells,
des Wegenetzes sowie des Verhaltens des Avatars habe ich mich für die Programmiersprache Java [JAVA] entschieden, die in Version 1.4.2 benutzt wurde.
Dies lag nahe, da die Systeme des Fluidum Projekts aus Kapitel 2, mit denen
das im Rahmen dieser Arbeit erstellte System interagiert, ebenfalls in Java geschrieben sind. Zur Integration des Systems wurde es in ein Java RMI-Interface
(Java Remote Method Invocation [RMI06]) eingebettet, so dass es auf einem
beliebigen Rechner gestartet werden und über ein Netzwerk auf die anderen
Komponenten, wie zum Beispiel die Fluid Beam-Applikation, zugreifen kann.
Die Daten des Raummodells werden in einer XML-Datei [XML06] gespeichert, die mit Hilfe des Apache Xerces XML Parsers [Apache06] erstellt, manipuliert und gelesen wird.
5.2
Portierbarkeit
Das System läuft in der Testumgebung im instrumentierten Raum auf einem
Athlon 2.0+ GHz Rechner mit Windows XP als Betriebssystem. Der Rechner
ist an das lokale Gbit-Netzwerk des Lehrstuhls für Künstliche Intelligenz von
Prof. Wahlster angeschlossen, worüber er mit den anderen Komponenten des
Fluidum-Projekts kommuniziert. Java-Bytecode ist auf allen Java Virtual Machines ausführbar, er muss jedoch in ein RMI-Interface integriert sein. XML ist
als ein (...) Standard zur Dokumentenauszeichnung“ [Harold] der auf einfachen
”
Textdokumenten basiert, problemlos portierbar.
5
5.3
90
Objektmodell
In Abbildung 23 ist das grobe Objektmodell des Systems auf der Klassenebene zu sehen. Das dargestellte Objektmodell erhebt keinesfalls den Anspruch
der Vollständigkeit, da aus Gründen der Übersicht nur die zentralen Klassen
dargestellt sind. Diese Darstellung soll einen Überblick über die wichtigsten
Klassen und deren Beziehungen zueinander geben, nicht über den Aufbau einzelner Klassen.
Abbildung 23: Das Klassenmodell mit den Hauptklassen des Systems
Die Klasse PositioningManager ist die ausführbare Hauptklasse des Systems. Sie benutzt alle relevanten Teile und fügt diese zu einem Ganzen zusammen. Alle Informationen zur Steuerung des Avatars, wie unter anderem seine
Position, die Position und Blickrichtung des Benutzers, das Wegenetz, etc. lau-
5
91
fen hier zusammen, werden entsprechend verteilt und genutzt. So kapselt die
Klasse PositionFinder die Funktionalität zur Bestimmung der Position und
Blickrichtung des Benutzers. In der Klasse Room wird das Raummodell gekapselt, von dem das System genau eines hat, eben das des Raums, in dem
es installiert ist. Ein Raum besteht aus beliebig vielen Wänden, die durch die
Wall-Klasse repräsentiert werden. In einem Raum können sich ebenfalls beliebig viele freie Darstellungsflächen befinden, die durch die Klasse Plane repräsentiert werden. Wände und freie Darstellungsflächen können jeweils beliebig
viele Hindernisse besitzen, instantiiert mit der Klasse Obstacle. Das Wegenetz,
bestehend aus beliebig vielen Knoten (PathNode) und beliebig vielen Kanten
(PathEdge), wird repräsentiert durch die PathNetwork-Klasse. Um einen
Weg durch das Wegenetz zu finden, benutzt die Hauptklasse den Single Source
Shortest Path-Algorithmus, der in der Klasse PathFinder gekapselt ist und
zur Pfadberechnung eine Instanz der PathNetwork-Klasse benötigt. Mit der
Klasse Behaviour wird das logische Verhalten des Avatars gesteuert, das dann
von der Klasse Movements in räumliche Bewegungen umgesetzt wird. Dazu
benutzt sie die Klasse DisplayHandler, welche die Verbindung zum VRI System kapselt.
5.4
5.4.1
Raummodell
Raum
Das Raummodell repräsentiert den Raum, in dem das System installiert ist und
in dem sich der Avatar bewegen soll. Da die exakte Abbildung des realen Raums
nicht nötig ist, wird der Raum abstrahiert modelliert. Ein Raum ist dreidimensional, besteht aus Wänden, freien Darstellungsflächen und Hindernissen, die
im Folgenden detailliert beschrieben werden.
Das Room-Objekt beschreibt den Raum, kennt alle Wände und freien Darstellungsflächen, und stellt Funktionen zur Verfügung, die ein Wegenetz auf den
5
92
Oberflächen des Raums erzeugen. Wie das Wegenetz explizit erzeugt wird, ist
im Kapitel 5.5.2 erläutert.
Die dreidimensionalen Koordinaten werden in der Form (X, Y, Z) angegeben. Da float-Werte nach einigen Rechenoperationen mitunter verhältnismäßig
grobe Ungenauigkeiten aufweisen, sind alle relevanten Zahlen vom Typ double, um so eine möglichst hohe Genauigkeit bei Berechnungen im Raummodell
gewährleisten zu können. Da bei Abfragen auf Gleichheit dennoch Fehler auftreten können, wird eine Abfrage auf Gleichheit mit einem Fehlerwert von 10−12
Meter durchgeführt.
5.4.2
Wand
Das Wall-Objekt beschreibt eine senkrecht stehende Wand, die den Raum, in
dem sie sich befindet, begrenzt. Eine Wand ist definiert durch ihre Eckpunkte.
Da die Kanten in jeder Ecke einen neunzig Grad Winkel bilden, wie in Kapitel 4.2 beschrieben, kann sie sehr viel mehr als nur vier Ecken haben. Um die
Definition eindeutig zu machen, werden die Eckpunkte im Uhrzeigersinn gespeichert, und die Wand hat eine Orientierung, die in Richtung des Benutzers
zeigt. Auf einer Wand können sich beliebig viele Hindernisse befinden, die die
freien Flächen, auf die ein Display projiziert werden kann, einschränken.
Wichtig für ein Objekt, ob Wand, freie Darstellungsfläche oder Hindernis,
ist die Möglichkeit, berechnen zu können, ob ein beliebiger Punkt Teil des Objekts ist oder nicht. Auf diese Weise kann entschieden werden, ob ein Punkt auf
einem Objekt liegt, und falls ja, auf welchem. Mit dieser Information kann dann
berechnet werden, ob man ein Display auf diese Koordinaten positionieren kann.
Eine Wand löst das Problem herauszufinden, ob ein Display an eine Stelle
projiziert werden kann, in zwei Schritten. Zum einen wird überprüft, ob die
Stelle, an die das Display projiziert werden soll, überhaupt auf der Wand liegt,
5
93
und zum anderen, ob sie eventuell in einem Hindernis liegt, das sich auf der
Wand befindet. Herauszufinden, ob ein Punkt auf einem Hindernis liegt, wird
dabei von den Hindernissen übernommen, die sich auf der Wand befinden, was
in Kapitel 5.4.4 beschrieben ist. Dagegen überprüft die Wand selbst, ob ein
Punkt überhaupt auf ihr liegt. Dies geschieht mit den Funktionen, die die Klasse Wall zur Verfügung stellt.
Die Überprüfung, ob ein Punkt auf einer Wand liegt, geschieht ebenfalls
in zwei Schritten, wobei der erste Schritt feststellt, ob der Punkt in der Ebene
liegt, in der die Wand steht, um dann im zweiten Schritt herauszufinden, ob der
Punkt innerhalb der Ränder liegt. Um das zweite Kriterium zu testen, werden
zuerst die Kanten gesucht, die am nächsten oberhalb, unterhalb, rechts und
links um den Punkt herum liegen, alle anderen sind für diesen Punkt nicht von
Bedeutung. Bei diesen vier Kanten wird nun getestet, ob der Punkt, bezogen
auf die jeweilige Kante, auf der Innenseite oder Außenseite liegt. Wenn er bei
allen vier Kanten auf der Innenseite liegt, ist das Kriterium erfüllt. Zusammen
mit dem ersten Kriterium, der Lage in der richtigen Ebene im Raum, was einfach zu überprüfen ist, wird geklärt, ob ein Punkt auf einer Wand liegt. Liegt
der Punkt auch in keinem Hindernis, dann liegt er auf einer freien Fläche der
Wand, auf die ein Display projiziert werden kann.
Um sicher zu stellen, dass an einer bestimmten Stelle auch genügend Platz
ist für ein Display, werden in spezifischen Abständen um den eigentlichen Punkt
herum noch weitere Punkte überprüft. Ausgehend vom Mittelpunkt des Displays werden horizontal und vertikal Punkte getestet, deren Abstand voneinander der Größe des kleinsten Hindernisses auf dem jeweiligen Objekt entspricht.
Nur wenn alle Punkte auf freier Fläche liegen, kann dort ein Display platziert
werden. Die Größe eines Hindernis ist dabei der maximale Abstand von je zwei
parallelen (horizontalen und vertikalen) Kanten des Hindernisses. So wird sichergestellt, dass an der überprüften Stelle kein Hindernis sein kann. Ist das
Display kleiner als das kleinste Hindernis, so werden nur der Mittelpunkt, die
5
94
Eckpunkte und die Mittelpunkte der Seiten des Displays überprüft.
5.4.3
Freie Darstellungsfläche
Das Plane-Objekt beschreibt eine ebene Fläche im Raum, auf die ein Display positioniert werden kann. Diese Fläche kann frei im Raum stehen oder
an eine andere Fläche oder Wand anschließen. Auch können sich auf ihr Hindernisse befinden. Genau wie eine Wand ist eine freie Darstellungsfläche durch
ihre Eckpunkte und deren Reihenfolge eindeutig beschrieben. Daraus berechnet sich die Orientierung zum Benutzer hin als Normalenvektor der Fläche.
Die Plane-Klasse stellt, wie die Wall-Klasse, Funktionen zur Verfügung mit
denen berechnet wird, ob ein Punkt auf ihr liegt oder nicht. Dies wird analog zum Verfahren bei der Wand berechnet. Bei einem Teil unterscheiden sich
die beiden Verfahren jedoch voneinander. Dort, wo geprüft wird, ob der Punkt
auf der Innenseite oder Außenseite der relevanten Ränder liegt, erschwert die
Möglichkeit der freien Lage des Plane-Objekts im Raum diesen Test. Ist es im
Fall der senkrecht stehenden Wand noch ausreichend zu testen, ob der Punkt
oberhalb oder unterhalb (Y-Koordinaten) einer horizontalen Kante bzw. rechts
oder links (Richtungsvektor der Ebene in der die Wand steht) einer vertikalen
Kante liegt, um bestimmen zu können, ob der Punkt auf der Wand ist oder
nicht, so geht dies bei der freien Darstellungsfläche nicht mehr. Liegt die Fläche
zum Beispiel schräg im Raum, so hat oben und unten keine Aussagekraft mehr
für einen Punkt in Bezug zu einer begrenzenden Kante.
Dieses Problem wurde gelöst, indem von dem zu testenden Punkt aus das
Lot auf die gerade zu testende Kante gefällt wurde. Die Richtung, die das Lot
hat, gibt an, auf welcher Seite der Kante der Punkt liegt. Da die Eckpunkte einer Darstellungsfläche im Uhrzeigersinn angegeben sind und daraus eine
Richtung der Kanten resultiert, folgt aus der Orientierung der Fläche, dass die
Innenseite der Kante immer die rechte Seite der Kante ist. Wenn also die Richtung des Lots von rechts nach links verläuft, bezogen auf die Richtung der zu
5
95
prüfenden Kante, ist der Punkt auf der Innenseite, andernfalls liegt er auf der
Außenseite.
Alle weiteren Aufgaben werden, wie oben bei der Wand beschrieben, gelöst.
5.4.4
Hindernis
Das Obstacle-Objekt beschreibt ein Hindernis, auf das kein Display projiziert
werden kann oder soll. Hindernisse liegen immer auf einem anderen Objekt,
entweder einer Wand oder einer freien Darstellungsfläche. Ein Hindernis ist eine Fläche, die durch senkrecht aufeinander stehende Kanten begrenzt wird. Zur
Definition genügen die Eckpunkte in einer festen Reihenfolge. Da Hindernisse
auf freien Darstellungsflächen liegen können, müssen sie ebenso frei im Raum
platziert werden können, weshalb ihre Definition analog ist. Ebenso wie die
Plane-Klasse stellt die Obstacle-Klasse Funktionen zur Verfügung, mit denen
berechnet werden kann, ob ein Punkt auf dem Hindernis liegt oder nicht. Dabei
gilt die Vereinfachung, dass auf einem Hindernis nicht andere Hindernisse liegen
können. Eine wichtige Eigenschaft von Hindernissen ist die Information, wie sie
überwunden oder umrundet werden können. Zum Beispiel wenn der Avatar ein
Hindernis umlaufen soll, muss er wissen, wo es passierbar ist und wo nicht. Ist
diese Information nicht bekannt, so könnte das Display an eine Stelle verschoben werden, an der es nicht vollständig darstellbar ist. In diesem Fall könnte
der Avatar unter einem Bild entlanggehen, während der Kopf des Avatars auf
das Bild projiziert wird. Die Information, wo ein Hindernis passierbar ist, wird
deshalb bei der Erstellung des Wegenetzes verwendet (siehe Kapitel 5.5.2).
5
5.5
5.5.1
96
Wegenetz
Struktur des Wegenetz
Das Wegenetz ist die Grundlage für die Bewegungen des Avatars durch den
Raum. Es besteht aus Knoten, die so auf den Flächen positioniert sind, dass an
jedem dieser Punkte der Mittelpunkt eines Displays positioniert werden kann
und dort eine genügend große freie Stelle für das Display mit dem Avatar vorhanden ist. Die Knoten beinhalten Informationen darüber, auf welchem Objekt
sie sich befinden und ob sie für den Avatar ein geeigneter Standort sind, an
dem er dem Benutzer etwas erklären kann. Definiert werden sie durch ihre Koordinaten im Raum. Die Abstände der Knoten zueinander sind in horizontaler
und vertikaler Richtung vordefiniert, wodurch das Wegenetz eine rechteckige
Netzstruktur erhält. Neben den Knoten besteht ein Wegenetz außerdem aus
Kanten, die durch zwei Knoten, die die Kante miteinander verbindet, definiert
sind. Kanten sind mit Gewichten versehen, die dem Algorithmus zum Finden
von Wegen durch das Wegenetz dienen. Mit diesen Gewichten kann man die
Lage der Kanten im Raum identifizieren und gleichzeitig den Algorithmus zum
Finden kürzester Pfade dahingehend manipulieren, schöne“ Wege zu wählen.
”
Horizontale Kanten haben das geringste Gewicht, dann kommen vertikale Kanten und anschließend Kanten die über eine Ecke verlaufen. Die teuersten Kanten
sind diese, die auf eine freie Darstellungsfläche führen oder durch Hindernisse
hindurch. Da der Algorithmus die teuren Kanten zu vermeiden versucht, sehen
die gefundenen Wege homogen aus.
5.5.2
Erzeugen des Wegenetzes
Das Erzeugen des Wegenetz ist aufgeteilt in mehrere Etappen. Jede Klasse, die
eine Fläche beschreibt, auf die ein Display projiziert werden kann, hat Funktionen, die ein eigenes lokales Wegenetz generieren. Diese lokalen Wegenetze
der Wände und freien Darstellungsflächen werden anschließend zu einem den
ganzen Raum bedeckenden Wegenetz zusammengefügt. Die Vorgehensweise zur
5
97
Erstellung der einzelnen kleinen Wegenetze ist auf jeder Fläche gleich, egal ob
es auf einer Wand oder einer freien Darstellungsfläche generiert wird.
Zu Beginn wird ein Punkt auf der jeweiligen Fläche gesucht, an dessen Stelle
der erste Knoten erzeugt wird. Dieser Knoten wird ausgehend von der linken
oberen Ecke der Fläche nach unten und rechts weiter suchend an der ersten freien Stelle gesetzt und kommt auf eine Warteliste. Natürlich hätte man auch ein
anderes Verfahren definieren können, mit dem der erste Knoten gesetzt wird,
aber da die linke obere Ecke an erster Stelle in der Aufzählung der Ecken einer
Fläche steht, wurde dieses Verfahren implementiert. Bei jedem Knoten auf der
Warteliste wird überprüft, ob in horizontaler oder vertikaler Richtung in gegebenem Abstand eine freie Stelle ist, an der ein neuer Knoten erzeugt werden
kann. Dabei wird überprüft, ob an dieser Stelle genügend Platz für ein Display
ist. Wenn ja und falls dort noch kein Knoten ist, wird ein neuer Knoten erzeugt.
In jedem Fall, wenn dort nun ein Knoten existiert, wird überprüft, ob es schon
eine Kante an dieser Stelle gibt, die dann gegebenenfalls mit entsprechender
Gewichtung generiert wird. Der Knoten wird anschließend von der Warteliste
gelöscht. So verbreitet sich das Wegenetz im Allgemeinen ausgehend von einer
Ecke aus über die ganze Fläche.
Interessant wird es, wenn man auf ein Hindernis stößt. In diesem Fall wird
unterschieden, ob man an einer Stelle das Hindernis umlaufen“ kann oder nicht.
”
Kann man dies, so wird nichts Spezielles getan, da das Wegenetz an anderer
Stelle am Hindernis vorbei kommt und so auch die Fläche dahinter erreicht. Ist
das Hindernis jedoch so groß, dass es nicht umlaufen werden kann, so wird ein
neuer Knoten auf der anderen Seite des Hindernisses erzeugt und eine speziell
gewichtete Kante generiert, die durch das Hindernis verläuft.
5
5.6
98
Wege durch den Raum
Der Avatar soll sich entlang des erzeugten Wegenetzes bewegen. Ein Weg besteht aus einer möglichst kurzen Abfolge von Knoten und Kanten mit möglichst
geringem Gewicht, deren erster Knoten der aktuelle Standpunkt des Avatars
ist und der letzte Knoten der gewünschte Zielpunkt.
5.6.1
Algorithmus
Der Algorithmus zum Finden des Weges, den der Avatar gehen soll, ist der
bekannte Dijkstra-Algorithmus“, der ein wenig erweitert wurde. Diese Erwei”
terung wird später an der entsprechenden Stelle erläutert.
Während der Algorithmus das Wegenetz durchsucht, speichert er in jedem
Knoten die Kosten des bis dahin gefundenen kürzesten Pfades von dem Startpunkt bis zu diesem Knoten und den Pfad selbst. Außerdem werden die von
bisher besuchten Knoten aus direkt erreichbaren Knoten, deren kürzester Pfad
noch nicht gefunden wurde, in einer Priority Queue gespeichert. Die Schlüssel
in der Priority Queue sind die Pfadkosten dieser Knoten.
Beim Start werden die Pfade der Knoten auf null gesetzt und ihre Pfadkosten auf unendlich. In der Priority Queue sind alle erreichbaren Knoten gespeichert und haben als Schlüssel die Kosten, die die Kante vom Startpunkt aus zu
ihnen hat. Nun durchläuft der Algorithmus eine Schleife, die solange ausgeführt
wird, bis die Priority Queue leer ist.
Sei A der Knoten mit dem niedrigsten Schlüssel und damit den niedrigsten
erwarteten Pfadkosten, dann wird A aus der Priority Queue genommen.
Anschließend nimmt man alle Knoten, die von A aus erreichbar sind, und aktualisiert deren Pfadkosten und die bisherigen kürzesten Pfade, aber nur, wenn
der neue Pfad günstiger (leichter) ist als der bisherige Pfad zu diesem Knoten.
Wenn der Algorithmus beendet ist, stehen in jedem Knoten des Wegenet-
5
99
zes der günstigste Pfad vom Startpunkt zu dem jeweiligen Knoten und seine
Kosten. An dieser Stelle wurde die oben erwähnte Erweiterung programmiert.
Da es unnötig ist, alle günstigsten Pfade zu kennen, wenn man nur den zwischen zwei bestimmten Knoten sucht, wurde eine weitere Abbruchbedingung
implementiert. Sobald ein Weg zum Zielknoten gefunden wurde, werden dessen Kosten mit den aktuellen Kosten des ersten Knotens in der Priority Queue
verglichen, denn dieser hat die geringsten bisherigen Pfadkosten in der Priority Queue. Sind die Kosten des Knotens in der Priority Queue höher, kann es
keinen kürzeren Pfad über die restlichen Knoten zum Ziel geben als den, der
bereits gefunden wurde. Folglich kann man an dieser Stelle schon abbrechen.
Die Worst-Case-Laufzeit des Algorithmus wird hierdurch nicht verbessert, aber
wenn Start- und Zielknoten nicht weit voneinander entfernt sind, müssen auch
nur solche Wege überprüft werden und nicht das gesamte Wegenetz. Je nach
Größe des Wegenetzes und Länge des gesuchten besten Weges werden so viele
Berechnungen gespart.
Das Ergebnis des Algorithmus ist ein Weg vom Start- zum Zielknoten mit
minimalen Kosten.
5.7
Avatar-Verhalten
Der Avatar kann in gewissem Maße auf den Benutzer reagieren, da er vom Benutzer die Position und Blickrichtung kennt. Eine einfache Verhaltenslogik wurde als deterministischer endlicher Automat implementiert, dessen Übergangsfunktion ereignisgesteuert ist. Mit Hilfe der Idee der Subsumption [Brooks] werden die Ereignisse gefiltert und so das Verhalten des Avatars geregelt.
5.7.1
Endlicher Automat
Der das Verhalten beschreibende deterministische endliche Automat hat folgende 5 Zustände:
5
100
• Stehen: Der Avatar steht an einer Stelle und wartet.
• Reden: Der Avatar spricht gerade, wenn er zum Beispiel etwas erklärt
oder den Benutzer begrüßt.
• Gehen: Der Avatar bewegt sich gerade in Menschengestalt oder als Ball
durch den Raum.
• Aufmerksam: Der Avatar macht auf sich aufmerksam, weil der Benutzer
gerade nicht auf ihn achtet.
Während des Betriebs überprüft das System permanent die Position und die
Blickrichtung des Benutzers. Diese Werte werden ständig auf dem Event Heap“
”
aktualisiert und dort vom System abgefragt. Ändert sich einer dieser Werte,
so wird ein entsprechendes Ereignis generiert. Die 4 möglichen Ereignisse, die
die Übergänge zwischen den einzelnen Zuständen auslösen, repräsentieren das
Verhalten des Benutzers wie folgt:
• BenutzerWeg : Der Benutzer ist gerade nicht in der Nähe des Avatars.
• BenutzerDa: Der Benutzer ist gerade in der Nähe des Avatars.
• BenutzerSchautHin: Der Benutzer schaut gerade auf den Avatar.
• BenutzerSchautWeg : Der Benutzer schaut gerade nicht auf den Avatar.
Die Übergangsfunktion ist in Abbildung 24 dargestellt. Dabei sind aus Gründen
der Übersicht die Übergänge weggelassen worden, bei denen sich der aktuelle
Zustand nicht ändert.
Zur Erklärung der Abbildung wird folgendes Beispiel angeführt: Der Aktuelle Zustand ist Reden. Nun tritt das Ereignis BenutzerSchautWeg ein, da
der Benutzer sich gerade in eine andere Richtung gedreht hat. Daraufhin wechselt der Avatar in den Zustand Aufmerksam, um auf sich aufmerksam zu
machen und zu erwirken, dass sich der Benutzer wieder ihm zuwendet. Genau
5
101
Abbildung 24: Die Übergangsfunktion der Verhaltenslogik des Avatars
das macht der Benutzer dann auch, wodurch das Ereignis BenutzerSchautHin ausgelöst wird, was den Avatar wieder in den Zustand Reden wechseln
lässt. Die Verhaltenslogik lässt sich mit geringem Aufwand um weitere mögliche Zustände und Übergänge, die in Zukunft vielleicht hinzukommen, erweitern.
5.7.2
Subsumptionsansatz
Den Ereignissen aus Kapitel 5.7.1 werden Prioritäten zugewiesen, die über ihre
Relevanz im Allgemeinen etwas aussagen, denn je höher dessen Priorität, desto
wichtiger ist das Ereignis. Für den Fall, dass mehrere Ereignisse gleichzeitig
eintreffen, bestimmen die Prioritäten der Ereignisse, welches das wichtigste ist
und somit Einfluss auf das Verhalten des Avatars hat.
Die Prioritäten sind wie folgt verteilt. Die höchste Priorität hat BenutzerWeg , da sonst der Avatar dem Benutzer nicht folgen würde, wenn dieser sich
entfernt. Der Benutzer wird vom Avatar durch die Umgebung geleitet, deshalb
ist es wichtig, dass er ständig in der Nähe des Benutzers ist. Als nächstes kommt
5
102
BenutzerSchautWeg , damit der Avatar stets auf sich aufmerksam machen
kann, es sei denn, er folgt dem Benutzer gerade. In diesem Fall ist es wichtiger,
überhaupt wieder in die Nähe des Benutzers zu kommen. Die beiden anderen
Ereignisse haben die gleiche und niedrigste Priorität, da sie den Avatar mit dem
fortfahren lassen, was er eigentlich machen möchte, denn der Benutzer ist dann
bei ihm und aufmerksam.
Man könnte nun sagen, dass es für vier Ereignisse, von denen jeweils nur
zwei gleichzeitig eintreffen können, etwas übertrieben ist, einen Auswahlmechanismus zu implementieren, wie gerade beschrieben. Aber bei einer späteren
Erweiterung des Systems um zusätzliche Funktionalität oder Sensorik und damit eventuell auch um weitere Ereignisse, können diese sehr einfach in die Logik
integriert werden.
5.8
Avatar-Bewegung
Die verschiedenen Bewegungen und Gestiken des Avatars, wie auch seine Sprachausgabe, werden durch das in Kapitel 2.8 beschriebene VRI -System zur Verfügung gestellt. Mit XML-Skripten wird das VRI -System angesteuert und manipuliert seinerseits die Flash-Animation und die Sprachausgabe. Die Ansteuerung des VRI -Systems ist in der Klasse Movements gekapselt. Unter anderem
sind die folgenden Bewegungen und Gesten implementiert, von denen einige
Screenshots in Abbildung 25 zu sehen sind:
• Warte-Gestik: Minnie steht und wischt sich über das Kleid (Abb. 25 oben
links),
• Uhrzeit-Gestik: Sie steht und schaut auf die Uhr (Abb. 25 oben 2te von
links),
• Zeige-Gestik: Sie steht und zeigt nach einer Seite, um etwas zu präsentieren (Abb. 25 oben 3te von links),
5
103
• Gehen-Gestik: Sie geht zu einer Seite, um etwas zu erreichen (Abb. 25
oben rechts),
• Swirl-Gestik: Sie verwandelt sich in einen Ball, um weite Strecken schneller
zurück legen zu können (Abb. 25 untere Reihe).
Abbildung 25: Einige Screenshots von Avatargestiken (Minnie)
Die XML-Skripte zur Steuerung der Avatar-Bewegungen bestehen aus zwei
Teilen und werden durch part“ als solche gekennzeichnet. Der erste Teil des
”
Skripts bestimmt, welche Gestik der Avatar machen soll, und der zweite Teil
5
104
bestimmt, welche Tondatei dabei abgespielt werden soll. So setzt sich zum Beispiel die Anweisung sich in einen Ball zu verwandeln“ aus den Teilen Swirl“
”
”
und Soundloop.mp3“ zusammen. Das fertige XML-Skript sieht dann wie folgt
”
aus:
<part gesture=“Swirl” sound=“Soundloop.mp3”/>
Wie man leicht erkennt, sind in den XML-Skripten keine Informationen enthalten, wie sich das Display bewegen soll. Die Bewegung des Displays wird mit
Hilfe der DisplyHandler-Klasse realisiert. Beide Teile einer Avatar-Bewegung
(Gestik mit Ton und Bewegung des Displays) werden von der Klasse Movements durch entsprechende Methoden bereitgestellt.
5.9
Datensicherung
Die Datensicherung betrifft nur die Daten des Raummodells, da alle anderen
Daten entweder aus dem Raummodell erzeugt werden können, wie das Wegenetz zum Beispiel, oder aber im Code als feste Größen implementiert sind. Um
ein Modell eines Raums zu speichern, muss man alle Bestandteile des Raums
speichern, wie Wände, freie Darstellungsflächen und Hindernisse. Jedes dieser
Objekte hat wiederum für sich spezifische Datenfelder, die ebenfalls gespeichert
werden müssen, so dass man zu einem beliebigen späteren Zeitpunkt das Modell
wieder rekonstruieren kann.
Gesichert werden die Daten des Raummodells in einem XML-Dokument, das
folgenden Aufbau besitzt:
<!ELEMENT Room (RoomFields, Wall*, Plane*)>
<!ELEMENT RoomFields (wegHoehe, mindestHoehe)>
<!ELEMENT Wall (WallFields, WallCorners, Obstacles)>
<!ELEMENT WallFields (WallID, RightWall, LeftWall, RechtsUnten)>
<!ELEMENT WallCorners (WallCorner 4+)>
<!ELEMENT WallCorner (X, Y, Z)>
<!ELEMENT Plane (PlaneFields, PlaneCorners, Obstacles)>
5
105
<!ELEMENT PlaneFields (PlaneID, RechtsUnten, Height, Width, Neighborwalls)>
<!ELEMENT Neighborwalls (NeighborWall*)>
<!ELEMENT PlaneCorners (PlaneCorner 4+)>
<!ELEMENT PlaneCorner (X, Y, Z)>
<!ELEMENT Obstacles (Obstacle*)>
<!ELEMENT Obstacle (ObstacleFields, ObstacleCorners)>
<!ELEMENT ObstacleFields (ObstacleID, Type, Passierbar)>
<!ELEMENT Passierbar (Hindurch, Darüber, Darunter, Rechts, Links)>
Ein Raum besteht aus beliebig vielen Wänden und freien Darstellungsflächen. Die Weghöhe gibt an, auf welcher Höhe sich ein Pfad bewegen soll, wenn
das Wegenetz nicht die ganze Wand bedecken soll, sondern nur einen einzigen
möglichen Pfad durch den Raum bereitstellt. Eine Variante des Wegenetzes, die
implementiert ist, aber normalerweise nicht benutzt werden sollte, da sie den
Avatar sehr einschränkt. Die Mindesthöhe beschränkt das Wegenetz eine gewisse Höhe nicht zu unterschreiten. Jede Wand, jede Darstellungsfläche und jedes
Hindernis besitzt eine eindeutige ID, über die das jeweilige Objekt identifiziert
werden kann. RightWall und LeftWall sind die IDs der rechten bzw. linken
Nachbarwand. Die Corner -Elemente sind die Eckpunkte des jeweiligen Objekts
und haben ihre Koordinaten in der Form (X,Y,Z ) als Kinder. Die Eckpunkte
sind jeweils im Uhrzeigersinn aufgezählt, beginnend bei der linken oberen Ecke
des Objekts. RechtsUnten gibt an, die wievielte Ecke die rechte untere Ecke des
jeweiligen Objekts ist, bei 0 beginnend mit Zählen. Daraus lassen sich dann die
Höhe und die Breite einer Fläche berechnen. Height und Width sind die Höhe
und die Breite einer Darstellungsfläche, d.h. die maximale Entfernung zweier
paralleler Kanten (horizontal bzw.vertikal), die die Fläche begrenzen. NeighborWall sind die IDs der Wände, von denen aus die Darstellungsfläche erreichbar
ist. Type gibt an, ob das Hindernis ein einfaches Hindernis ist oder ein spezielles
Objekt, zu dem der Avatar eventuell etwas sagen soll. Die Kind-Elemente von
Passierbar geben an, wo das Display bzw. der Avatar das Hindernis passieren
kann.
5
106
Abbildung 26: XML-Datei, in der ein Raummodell gespeichert ist
In Abbildung 26 sieht man ein Beispiel für eine XML-Datei, in der ein
Raummodell gespeichert ist. Der Raum hat 4 Wände und 1 freie Darstellungsfläche. Die erste Wand hat die ID 1, ihre rechte Nachbarwand hat die ID 2, und
ihre linke Nachbarwand hat die ID 4. Die erste Ecke der dieser Wand hat die
Koordinaten (0, 2.5, 0). Auf der Wand befinden sich 2 Hindernisse.
6
ZUSAMMENFASSUNG UND AUSBLICK
6
107
Zusammenfassung und Ausblick
6.1
Zusammenfassung
In dieser Diplomarbeit wurde ein System entwickelt, das es ermöglicht, projizierte Displays zur Laufzeit dynamisch zu positionieren. Die Displays werden
auf freie Oberflächen im instrumentierten Raum, möglichst in die Nähe des Benutzers projiziert, so dass sie zur Interaktion mit dem Benutzer genutzt werden
können. Dazu werden die Position und die Blickrichtung des Benutzers mit verschiedenen Sensoren und einem digitalen Kompass permanent überwacht. Zur
verzerrungsfreien Darstellung der projizierten Displays wird das Fluid Beam“”
System verwendet, das aus einem Projektor und einer Kamera besteht, die
in einer Dreheinheit an der Decke des instrumentierten Raums angebracht sind.
In das System wurde das bereits bestehende VRI -System integriert, mit dem
ein Avatar auf den projizierten Displays angezeigt wird, der über ein räumliches
Audiosystem mit dem Benutzer kommuniziert. Das Verhalten und die Position
des Avatars werden entsprechend dem Verhalten und der Position des Benutzers dynamisch angepasst.
Es wurde ein 3D-Raummodell entwickelt, das die Umgebung des Systems
approximativ erfasst. Es besteht aus Wänden, freien Darstellungsflächen, auf
denen Displays projiziert werden können, und Hindernissen, auf die nicht projiziert werden kann. Das 3D-Raummodell bildet die Grundlage des Systems,
es wird mit XML gespeichert und kann leicht von Hand erstellt und verändert
werden.
Ein 3D-Wegenetz wird von den Klassen des Raummodells automatisch generiert, auf dem sich die projizierten Displays so verschieben lassen, dass sie
während einer Bewegung mit keinem Hindernis im Raum kollidieren können.
Die Bewegungen werden dynamisch mit Hilfe des Dijkstra-Algorithmus“ für
”
kürzeste Pfade generiert. Dabei wurde durch eine geschickte Wahl der Kan-
6
108
tengewichte des Wegenetzes sichergestellt, dass die gefundenen Wege schön“
”
aussehen.
Das System ist in die Java-Architektur des instrumentierten Raums integriert, so dass es in Zukunft problemlos wiederverwendbar und erweiterbar ist.
6.2
Einsatzmöglichkeiten
Das hier vorgestellte System zum dynamischen Positionieren von projizierten
Displays bietet unterschiedliche Verwendungsmöglichkeiten. Wo immer etwas
angezeigt werden soll, kann das System etwas projizieren und das Display bei
Bedarf auf der Projektionsfläche verschieben. Drei mögliche Szenarien, in denen
das System angewendet werden könnte, werden im Folgenden kurz beschrieben.
In instrumentierten Umgebungen, die eine Vielzahl unterschiedlicher Geräte
beherbergen, kann das System dem Benutzer als Einweiser dienen und die Funktionen und die Handhabung der installierten Geräte erläutern und vorführen.
Bei einer solchen Vorführung könnte das System auf das Verhalten des Benutzers reagieren und zum Beispiel einen Rundgang durchführen, bei dem der Avatar das Gerät erläutert, zu dem sich der Benutzer gerade hinbewegt hat. Wenn
der Benutzer nun das Interesse an diesem Gerät verliert und zu einem anderen
Gerät geht, so könnte das System den Avatar dem Benutzer folgen und ihn anschließend das nächste Gerät vorstellen lassen. In diesem Zusammenhang sind
verschiedene Szenarien vorstellbar, die mit wenig Aufwand realisierbar sind.
Eine weitere Möglichkeit wäre ein Einsatz als Museumsführer, bei dem der
Avatar mit dem Benutzer zusammen einen Museumsrundgang macht. Auch
hierbei könnte das System auf die Bewegungen und die Blickrichtung des Benutzers reagieren und ihn so nur über die Kunstwerke informieren, die den
Benutzer wirklich interessieren. Wann immer der Benutzer vor einem Ausstellungsstück stehen bleibt, um es zu betrachten, kann der Avatar einen entspre-
6
109
chenden Vortrag über das Kunstwerk halten. Dabei wäre der Benutzer in seinen
Bewegungen und der Gestaltung des Museumsrundgangs völlig frei, da das System den Avatar mitlaufen lassen würde.
In der heutigen Zeit werden einige Dienstleistungen auf Grund von zu hohen Personalkosten nicht mehr oder nur noch sporadisch angeboten. Eine dieser
Dienstleistungen ist die Kaufberatung des Kunden in Warenhäusern. In diesem Fall könnte das System dazu genutzt werden, den Kunden Informationen
über die Produkte zu vermitteln, eventuell auch mit Querverweisen zu anderen
Produkten, wie in Abbildung 27 dargestellt. Anschließend könnte der Kunde
vom Avatar zu diesen anderen Produkten geführt werden oder als persönlicher
Verkäufer den Kunden während dessen Aufenthalts im Geschäft begleiten.
Abbildung 27: Der Avatar Cyberella“ assistiert einer Kundin beim Einkaufen,
”
Quelle: [Kruppa]
6
6.3
110
Erweiterung des Systems
Diese Diplomarbeit ist so konzipiert, dass sie als ganzes System oder aber auch
ein einzelner Teil des Systems, wie etwa das 3D-Raummodell, in andere Systeme integriert werden kann. Natürlich steht auch einer Weiterentwicklung des
Systems nichts im Wege, wodurch unter anderem eventuelle spezifische Probleme bei neuen Anwendungsfällen behoben werden können.
Das 3D-Raummodell besteht aus ebenen Flächen, die von aufeinander senkrecht stehenden Kanten begrenzt sind. Mit dieser Vereinfachung lassen sich
zwar die meisten Flächen approximativ modellieren, trotzdem stößt das System schnell an seine Grenzen, wenn zum Beispiel runde Flächen modelliert
werden sollen. Je nach gewünschter Genauigkeit des Modells kann die Modellierung einer runden Fläche eine Sisyphus-Arbeit werden. Es wäre ebenfalls
wünschenswert, runde Säulen zu integrieren, ebenso wie Flächen, die von Kanten begrenzt werden, die in beliebigen Winkeln aufeinander stehen.
Die Reaktion des Systems und damit des Avatars auf das Verhalten des Benutzers ist bisweilen noch rudimentär. An dieser Stelle könnte man eine umfangreichere Verhaltenslogik implementieren, die eventuell auch von zahlreicheren
Ereignissen beeinflusst wird, wodurch feinere Reaktionen auf das Benutzerverhalten verwirklicht werden könnten. In diesem Kontext wäre eine Erweiterung
des System um Benutzerprofile eine sinnvolle Investition, da sich nur so optimale Reaktionen und Äußerungen auswählen oder generieren lassen.
Im Rahmen von bereits bestehenden Systemen, wie zum Beispiel dem
PEACH“-System, könnte diese Arbeit eine gute Erweiterung des jeweiligen
”
Systems sein. Im Beispiel von PEACH“ könnte man die Kluft zwischen
”
dem kleinen mobilen Präsentationsmedium PDA und den großen stationären
Bildschirmen schließen, indem man dem Benutzer die Möglichkeit bietet, sich
an einer beliebigen Stelle Informationen anzeigen zu lassen. Die Größe und Position der projizierten Displays könnte dann entsprechend der darzustellenden
6
111
Informationen gewählt werden.
Bei der Interaktion mit einem Benutzer kann es vorkommen, dass der Benutzer oder andere Personen aus Versehen in den Projektionsstrahl geraten und
so die Darstellung behindern. Interessant wäre in diesem Zusammenhang die
Erweiterung des Systems um eine dynamische Erkennung von neuen oder sich
bewegenden Hindernissen, wie etwa Personen die sich im Raum befinden.
7
CODEAUSZÜGE
7
113
Codeauszüge
Im Folgenden werden verschiedene Klassen mit einigen Methodendeklarationen
und dazugehöriger Dokumentation aufgeführt.
/**
* Die Klasse repräsentiert einen Raum, in dem sich der Avatar
* bewegen soll.
* @author: Carsten Greiveldinger
*/
public class Room {
/**
* Standardkonstruktor für einen Raum
* @param WegHoehe: die Höhe, in der sich der Avatar
* normalerweise bewegen soll
* @param MindestHoehe: die Höhe, die der Avatar nicht
* unterschreiten soll
*/
public Room(double WegHoehe, double MindestHoehe) {}
/**
* Erzeugt ein komplettes Wegenetz für diesen Raum, so dass
* der Avatar sich frei im Raum bewegen kann, ohne in
* Hindernisse hinein zu laufen.
* @return Das Wegenetz in diesem Raum
*/
public PathNetwork createPathNetworkComplete()
{}
/**
* Verbindet die Wegenetze von zwei nebeneinander stehenden
* Wänden miteinander
* @param wand1: die linke Wand
* @param wand2: die rechte Wand
* @return das resultierende Wegenetz der beiden
* verbundenen Wände
*/
private PathNetwork connectWalls(Wall wand1, Wall wand2)
{}
7
CODEAUSZÜGE
114
/**
* Bindet eine freie Fläche in das Wegenetz ein
* @param plane: die einzubindende freie Fläche
* @param network Das bestehende Wegenetz des Raums
* @return das aktualisierte Wegenetz mit der
* integrierten Plane
*/
private PathNetwork connectPlane(Plane plane,
PathNetwork network)
{}
}
/**
* Die Klasse repräsentiert eine ebene, senkrecht stehende
* Wand in einem Raum
*/
public class Wall {
/**
* Konstruktor einer (senkrechten) Wand
* @param ID: die id der Wand
* @param Parent: der Raum, in dem die Wand steht
* @param RWall: die Wand, die rechts an diese Wand anschließt
* @param LWall: die Wand, die links an diese Wand anschließt
* @param Corners: die Eckpunkte dieser Wand (mindestens 4,
* beginnend oben links, dann im Uhrzeigersinn)
* @param RechtsUnten: der Index der rechten unteren
* Ecke in Corners
*/
public Wall(Room Parent, Wall RWall, Wall LWall,
ArrayList Corners, int RechtsUnten)
{}
/**
* Fügt ein neues Hindernis in die Wand ein
* @param newObstacle: das neue Hindernis auf dieser Wand
*/
public void addObstacle(Obstacle newObstacle)
{}
7
CODEAUSZÜGE
115
/**
* Testet, ob ein Display an dieser Stelle plaziert werden
* kann, ohne in ein Hindernis projiziert zu werden oder
* über die Wand hinaus zu ragen.
* @param centerPoint: der Mittelpunkt des Display
* @param Width: die Breite des Display in Metern
* @param Height: die Höhe des Display in Metern
* @return: true, wenn das Display dorthin projiziert
* werden kann, false sonst.
*/
public boolean displayCanBePlaced(double[] centerPoint,
double Width, double Heigth )
{}
/**
* Findet heraus, ob die Koordinaten frei sind, d.h. sie
* liegen auf der Wand und nicht in einem Hindernis
* @param point: der Punkt, der überprüft werden soll
* @return: true, wenn der Punkt frei ist und auf der Wand
* liegt, false sonst.
*/
public boolean isFreeBool(double[] point)
{}
/**
* Erzeugt ein komplettes Wegenetz für diese Wand, so dass
* der Avatar sich frei auf der Wand bewegen kann, ohne
* in Hindernisse hinein zu laufen.
* @return Das erzeugte Wegenetz für diese Wand
*/
public PathNetwork createPathNetworkComplete()
}
{}
7
CODEAUSZÜGE
116
/**
* Die Klasse repräsentiert ein ebenes Hindernis auf einer
* Fläche (Wall, Plane), auf der Displays erzeugt werden können.
*/
public class Obstacle {
/**
* Standardkonstruktor für ein rechteckiges Hindernis auf
* einer Fläche
* @param ID: die ID des Hindernisses
* @param ParentPlane: die Fläche, auf der das Hindernis ist
* @param Passierbar: gibt an, wie das Hindernis passiert
* werden kann
* @param Corners: eine Liste der Eckpunkte des Hindernisses.
* Der erste ist der obere linke Punkt, alle anderen folgen
* im Uhrzeigersinn. (Insgesamt mindestens 4 Punkte)
* @param Type: der Typ des Hindernisses: 0 = undefiniert,
* 1 = Ausstellungsstück
*/
public Obstacle( Plane ParentPlane, int [] Passierbar,
ArrayList Corners, int Type )
{}
/**
* Gibt an, ob der übergebene Punkt(X,Y,Z) innerhalb
* dieses Hindernisses ist
* @param X: die X-Koordinate des Punktes
* @param Y: die Y-Koordinate des Punktes
* @param Z: die Z-Koordinate des Punktes
* @return true, wenn der Punkt (X,Y,Z) innerhalb dieses
* Hindernisses liegt, sonst false
*/
public boolean isPart(double X, double Y, double Z)
}
{}
7
CODEAUSZÜGE
117
/**
* Die Hauptklasse zur Steuerung des Avatars im Raum
*/
public class PositioningManager {
/**
* Lässt den Avatar seinen Standort wechseln
* @param NewPosition der Punkt, zu dem der Avatar
* gehen soll
*/
private void goToPosition(double[] NewPosition)
{}
/**
* Lässt den Avatar einen Pfad entlang gehen
* in Menschengestalt
* @param Path: der Pfad, den der Avatar entlang
* gehen soll
*/
private void usePathAsHuman(LinkedList Path)
{}
/**
* Lässt den Avatar einen Pfad entlang gehen als Ball
* @param Path: der Pfad, den der Avatar entlang
* gehen soll
*/
private void usePathAsBall(LinkedList Path)
{}
/**
* Speichert den aktuellen Raum, in dem das System
* arbeitet, in einer XML-Datei
* @param Filename: der Name der XML-Datei, in der der
* Raum gespeichert werden soll (kompletter Pfad)
*/
private void saveRoom(String Filename)
{}
7
CODEAUSZÜGE
118
/**
* Lädt ein Room-Objekt aus einer XML-Datei und
* erzeugt anschließend das Wegenetz
* @param Filename: der Name der XML-Datei, in der
* der Raum gespeichert ist (kompletter Pfad)
*/
private void loadRoom(String Filename)
{}
/**
* Berechnet, ob der Benutzer gerade in Richtung
* des Avatars schaut oder nicht
* @return: true, wenn der Benutzer gerade in die
* Richtung des Avatars schaut, sonst false
*/
private boolean userWatchesAvatar(boolean watch)
{}
}
/**
* Diese Klasse enthält die verschiedenen Bewegungen
* des Avatars
*/
public class Movements {
/**
* Lässt den Avatar an einer Stelle still stehen
* und warten
* @param display: der DisplayHandler, der den Beamer
* ansteuert
* @param position: die Position an der der Avatar
* stehen soll
*/
public static void stand(DisplayHandler display,
double[] position)
{}
7
CODEAUSZÜGE
119
/**
* Lässt den Avatar an einer Stelle um
* Aufmerksamkeit bitten
* @param display: der DisplayHandler, der den
* Beamer ansteuert
* @param position: die Position, an der der Avatar
* stehen soll
*/
public static void callForAttention
(DisplayHandler display, double[] position)
{}
/**
* Lässt den Avatar nach links gehen
* Beamer ansteuert
* @param start: der Startpunkt[XS,YS,ZS] der Bewegung
* @param end: der Endpunkt[XE,YE,ZE] der Bewegung
*/
public static void GoLeft(DisplayHandler display,
double[] start, double[] end)
{}
/**
* Lässt den Avatar in Ballgestalt durch den Raum gleiten
* Beamer ansteuert
* @param start: der Startpunkt[XS,YS,ZS] der Bewegung
* @param end: der Endpunkt[XE,YE,ZE] der Bewegung
*/
public static void moveAsBall(DisplayHandler display,
double[] start, double[] end)
}
{}
7
CODEAUSZÜGE
120
/**
* Die Klasse steuert das Verhalten des Avatars
*/
public class Behaviour {
/**
* Die Übergangsfunktion von einem in den nächsten
* Zustand des Avatars. Anschließend muss man den
* neuen Zustand des Avatars noch setzen.
* @param Ereignis: das Ereignis, das gerade eingetreten
* ist, und das Verhalten des Avatars beeinflusst
* @return: die nächste Aktion, die der Avatar
* ausführen soll. Diese bestimmt den Zustand, in
* den er wechseln soll.
*/
public int nextAction(Vector Ereignisse)
{}
/**
* Die Methode entscheidet nach der Wichtigkeit der
* übergebenen Ereignisse, welches Ereignis das
* wichtigste ist und die nächste Aktion des
Avatars
* beeinflussen soll.
* @param Ereignisvektor: ein Vector, der die aktuellen
* Ereignisse beinhaltet
* @return: das relevante Ereignis, das den nächsten
* Schritt des Avatars beeinflusst
*/
private int useSubsumtion(Vector Ereignisvektor)
}
{}
Literatur
[3Dsom06] 3Dsom.com Homepage:
http://www.3dsom.com
(letzter Zugriff: 12. Juni 2006)
[Alice06] A.L.I.C.E. Artificial Intelligence Foundation Homepage:
http://www.alicebot.org
[Amptown06] Amptown Lichttechnik GmbH Homepage:
http://www.amptown-lichttechnik.de
(letzter Zugriff: 18. März 2006)
[Andre] E. André, K. Dorfmüller-Ulhaas, T. Rist:
Embodied Conversational Characters: Wandering Between the Digital
and the Physical World,
In W. Wahlster (Ed.), Special Journal Issue
Conversational User
”
Interfaces , IT - Information Technology (Vol. 46, p. 332-340). München,
”
Germany: Oldenburg, 2004
[Antonio1] A. de Antonio, J. Ramı́rez, R. Imbert, G. Méndez:
Intelligent Virtual Environments for Training: An Agent-Based Approach,
CEEMAS, pages 82-91. 2005
[Antonio2] A. de Antonio, J. Ramı́rez, R. Imbert, Ricardo et al.:
A Software Architecture for intelligent Virtual Environments applied to
education,
Revista de la Facultad de Ingenierı́a – Universidad de Tarapacá,
Vol.13(1), 47-55, Januar-April 2005, Chile
[Apache06] The Apache XML Project, Xerces Java XML Parser:
http://xerces.apache.org
(letzter Zugriff: 05. Februar 2006)
I
[AStern06] Uni-Protokolle.DE Homepage:
http://www.uni-protokolle.de/Lexikon/A-Stern-Algorithmus.
html
[ATT06] AT&T Natural Voices Homepage:
http://www.naturalvoices.att.com
[BeaMover06] Publitec Präsentationssysteme & Eventservice GmbH Homepage:
http://www.beamover.com
[BrandSch] B. Brandherm, T. Schwarz:
Geo Referenced Dynamic Bayesian Networks for User Positioning on
Mobile Systems,
In: Proceedings of the International Workshop on Location- and
Context-Awareness (LoCA 2005), Munich, Germany, 2005
[Brooks] R. A. Brooks:
A Robust Layered Control System for a Mobile Robot,
IEEE Journal of Robotics and Automation, 1986
[CADintern06] CAD intern GmbH Kassel Homepage:
http://cad-intern.de
[Cora] Cor@ im Portal der Deutsche Bank Homepage:
http://www.deutsche-bank.de/ui
(Seite nicht mehr aktiv)
[Cormen] T. H. Cormen, C. E. Leiserson, R. L. Rivest, C. Stein:
Introduction to Algorithms (Second Edition),
The MIT Press, 2001
II
[Cosmo06] Cosmo Worlds Homepage:
http://www.sgi.com/software/cosmo/worlds.html
[CSharp06] Online product documentation for Visual C# 2003:
http://msdn.microsoft.com/library/default.asp?url=/library/
en-us/vbcon/html/vboriManagedDevelopmentStartPage.asp
[DeLoura] Mark DeLoura:
Game Programming Gems (1-6),
Charles River Media 1996-2006
[DFKI06] Deutsches Forschungszentrum für Künstliche Intelligenz GmbH Saarbrücken Homepage:
http://www.dfki.de
[Dorfm] K. Dorfmüller-Ulhaas, E. Andre:
The Synthetic Character Ritchie: First Steps Towards a Virtual Companion for Mixed Reality,
In ISMAR 2005: Prococeedings of the IEEE Interational Symposium
on Mixed and Augmented Reality (p. 178-179). Vienna, Austria: IEEE
Computer Society Press, 2005
[Extemp06] Extempo Systems Inc. Homepage:
http://www.extempo.com/
[Eyeled06] Eyeled GmbH Homepage:
http://www.eyeled.de
(letzter Zugriff: 21. April 2006)
[FactoryCAD06] FactoryCAD Programm der Firma UGS:
http://www.ugsplm.de/produkte/tecnomatix/plant design/
III
factory cad.shtml
[Flash05] Macromedia Flash MX Homepage:
http://www.macromedia.com/software/flash
(letzter Zugriff: 11. August 2005)
[FLUIDUM06] FLUIDUM Homepage:
http://www.fluidum.org
(letzter Zugriff: 7. Mai 2006)
[Harold] E. R. Harold, W. S. Means:
XML in a Nutshell,
O’Reilly Verlag, 2003
[Identec06] Identec Solutions AG Homepage:
http://www.identecsolutions.com
[ITC06] The Center for Scientific and Technological Research Homepage:
http://www.itc.it
[JAVA] Java 2 Platform J2SE Version 1.4.2:
http://java.sun.com/j2se/1.4.2
[Java3D06] Java 3D API:
http://java.sun.com/products/javamedia/3D
[Johanson] B. Johanson, A. Fox:
The Event Heap: A Coordination Infrastructure for Interactive
Workspaces,
In: Proceedings of the Workshop on Mobile Computing Systems and
Applications, 2002
IV
[Klusch05] Vertiefungsvorlesung Intelligent Information Agents for Internet
”
and Web“ Homepage:
http://www.dfki.de/∼klusch/I2A-UDS-2005.html
[Kolbe] T.H.Kolbe:
Fußgängernavigation und Routenplanung in Innenstädten und Gebäuden
mit Videos und Panoramen,
Tagungsband Münsteraner GI-Tage 2002, IfGI Prints, Nr. 13, Uni
Münster, 2002
[Kolbe3D] T.H.Kolbe:
3D-Kartographie für die Fußgängernavigation: Virtuelle Wegweiser in
Panoramen,
In: Mitteilungen des Bundesamtes für Kartographie und Geodäsie, Band
31, September 2004, Verlag des Bundesamtes für Kartographie und
Geodäsie, 2004
[KrSpSc1] M. Kruppa, L. Spassova, M. Schmitz:
The Virtual Room Inhabitant,
2nd Workshop on Multi-User and Ubiquitous User Interfaces (MU3I),
2005
[KrSpSc2] M. Kruppa, L. Spassova, M. Schmitz:
The Virtual Room Inhabitant – Intuitive Interaction With Intelligent
Environments,
AI 2005 conference, 2005
[Kruppa] M. Kruppa:
Migrating Characters: Effective User Guidance in Instrumented Environments,
Dissertation, 2006
[Kufner] S. Kufner:
Integration und Steuerung von virtuellen Charakteren in einer AugmenV
ted Reality Szene,
Multimedia Praktikum, 2003 (unveröffentlicht)
[Lester] J.C. Lester, L. Zettlemoyer, J. Grégoire, W. Bares:
Explanatory Lifelike Avatars: Performing User-Centered Tasks in 3D
Learning Environments,
In AGENTS 1999: Proceedings of the Third International Conference
on Autonomous agents (p. 24-31). Seattle, United States: ACM Press,
1999
[MAEVIF06] The MAEVIF-Project Homepage:
http://decoroso.ls.fi.upm.es/paginas/proyectos/MAEVIF/
maevif\ e.html
[Marsella] S. Marsella, J. Gratch, J. Rickel:
Expressive Behaviours for Virtual Worlds,
In H. Prendinger & M. Ishizuka (Eds.), Life-Like Characters - Tools,
Affective Functions, and Applications (p. 317-360)
Berlin, Heidelberg, New York: Springer Cognitive Technologies, 2004
[Mattern] F. Mattern:
Allgegenwärtige Informationsverarbeitung – Technologietrends und Auswirkungen des Ubiquitous Computing,
To appear, 2006
[MCSquared06] MCSquared System Design Group, Inc. Homepage:
http://www.mcsquared.com/index.htm
[Mendez1] G. Méndez, P. Herrero, A. de Antonio:
Intelligent virtual environments for training in nuclear power plants,
In Proceedings of the 6th International Conference on Enterprise Information Systems (ICEIS 2004), Porto, Portugal, April 2004
VI
[Mendez2] G. Méndez, A. de Antonio:
Using Intelligent Agents to Support Collaborative Virtual Environments
for Training,
WSEAS Transactions on Computers Issue 10, Volume 4, pages 13651372, October 2005
[MultConc06] Gruppe Multimedia Concepts and their Applications Homepage:
http://mm-werkstatt.informatik.uni-augsburg.de
[PEACH06] PEACH: Personal Experience with Active Cultural Heritage Homepage:
http://peach.itc.it/home.html
[Pokemon06] Nintendo Pokémon Homepage:
http://pokemon.nintendo.de/deDE/
[Pressl] B. Pressl:
Fußgängernavigation - Navigationshilfe für Blinde,
Bakkalaureatsarbeit, 2003
[Pulkki] V. Pulkki:
Spatial Sound Generation and Perception by Amplitude Panning Techniques,
Dissertation, 2001
[Rickel1] J. Rickel, W. L. Johnson:
Animated Agents for Procedural Training in Virtual Reality: Perception,
Cognition, and Motor Control,
Applied Artificial Intelligence, 14(4-5), 343-382, 1999
[Rickel2] J. Rickel, W. L. Johnson:
Virtual humans for team training in virtual reality,
VII
In Proceedings of the Ninth International Conference on Artificial Intelligence in Education, pages 578–585. IOS Press, 1999
[RMI06] Java Remote Method Invocation (Java RMI):
http://java.sun.com/products/jdk/rmi
[SAFIR] M. Schmitz:
SAFIR: A Spatial Audio Framework for Instrumented Rooms,
in ITI04: Workshop on Invisible and Transparent Interfaces, held at
Advanced Visual Interfaces, Gallipoli, Italy, 2004
[Schalke06] Das Fußballstadion in Gelsenkirchen:
http://www.veltins-arena.de
[Schmitz] M. Schmitz:
Ein Framework für räumliches Audio in instrumentierten Umgebungen,
Diplomarbeit, 2003
[Sipser] M. Sipser:
Introduction to the Theory of Computation,
PWS Publishing Company Boston, 1997
[Spassova] L. Spassova:
Fluid Beam Konzeption und Realisierung eines Display-Kontinuums
mittels einer steuerbaren Projektor-Kamera-Einheit,
Diplomarbeit, 2004
[STEVE06] STEVE Homepage:
http://www.isi.edu/isd/VET/steve-demo.html
[Tomberge] P. Tomberge:
Navigation mittels RFID - Betrachtung der Navigationsmöglichkeiten
VIII
durch RFID-Eintrittskarten bei der WM 2006,
Diplomarbeit, 2004
[Treek] C. Alban van Treek:
Gebäudemodell-basierte Simulation von Raumluftströmungen,
Dissertation, 2004
[Trento06] Museo Castello del Buonconsiglio in Trento:
http://www.buonconsiglio.it
[Unreal06] Ego-Shooter Unreal Tournament Homepage:
http://www.unrealtournament.com
[Vectronics06] Vectronics AG Homepage:
http://www.vectronics.com
[VHuette06] Weltkulturerbe Völklinger Hütte:
http://www.voelklinger-huette.org
[VRML06] World Wide Web Consortium: VRML97:
http://www.web3d.org/x3d/specifications/vrml
[Wahlster05] Blockveranstaltung Einführung in die Methoden der Künstlichen
”
Intelligenz“ Homepage:
http://w5.cs.uni-sb.de/teaching/ws0506/KI/
[Weiser] M. Weiser:
The Computer for the 21st century,
Scientific American, 3(265):94-104,1991
IX
[Weiser06] Ubiquitous Computing Homepage:
http://www.ubiq.com/hypertext/weiser/UbiHome.html
[Wiki06] Wikipedia - Die freie Enzyklopädie:
http://de.wikipedia.org/wiki/Avatar\ \%28Internet\%29
[XML06] Extensible Markup Language (XML):
http://www.w3.org/XML
X
Abbildungsverzeichnis
1
Der instrumentierte Raum . . . . . . . . . . . . . . . . . . . . . . 15
2
Die Projektor-Kamera-Einheit an der Decke des instrumentierten Raums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3
Der PDA mit RFID-Kartenleser, eine Infrarotbake und ein RFIDTag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4
Der Vectronics DRC Kompass . . . . . . . . . . . . . . . . . . . . 23
5
Aufhebung von Projektionsverzerrung mit Kameraverzerrung . . 24
6
Ein Testweg durch die Räume des Lehrstuhls für Künstliche Intelligenz, zum Testen des Positinierungssystems . . . . . . . . . . 30
7
Beispiele für Avatare: Ein Pokémon, Chatterbot“ Alice und Cy”
berella . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8
Die Systemkomponenten des VRI-Systems . . . . . . . . . . . . . 35
9
Ein Beispiel für ein XML-Skript, das den Avatar den Benutzer
begrüßen lässt und dem Benutzer die Geräte im instrumentierten
Raum erklärt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10
Das alte und das neue Avatar-Modell im Vergleich . . . . . . . . 40
11
STEVE erklärt eine Schalttafel und spricht mit einem anderen
Avatar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
12
MAEVIF: Der Benutzer bewegt sich durch die virtuelle Welt und
trifft dabei auf andere Benutzer . . . . . . . . . . . . . . . . . . . 45
13
Whizlow bringt gerade ein Datenpaket zur CPU . . . . . . . . . 47
14
Rechts bewegt sich Ritchie dorthin, wo der Benutzer die Pyramide positioniert hat. Links sieht man einen Benutzer mit HeadMounted Display, der sich die Szene anschaut. . . . . . . . . . . . 48
15
Links folgt der Benutzer Ritchie durch die Stadt. Rechts ist Ritchie in der realen Welt und betrachtet das Stadtmodell. . . . . . 49
16
Die vier Avatare des PEACH-Projekts . . . . . . . . . . . . . . . 51
17
Die PEACH-Präsentation auf einem PDA und einem Virtual
”
Window“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
XI
18
Eine Statistik über das Verhalten des Benutzers bei einem Rundgang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
19
Ein CAD-Modell von einem Gebäude und ein Raummodell eines
Wohnraumes mit Schallsimulation . . . . . . . . . . . . . . . . . 56
20
Das Raummodell des Virtual Augsburg Systems . . . . . . . . . 58
21
3D-Wegenetz für das Fußballstadion in Gelsenkirchen und das
2D-Wegenetz in das es überführt wurde . . . . . . . . . . . . . . 63
22
Wegenetz auf einer Wand mit Hindernissen . . . . . . . . . . . . 80
23
Das Klassenmodell mit den Hauptklassen des Systems . . . . . . 90
24
Die Übergangsfunktion der Verhaltenslogik des Avatars . . . . . 101
25
Einige Screenshots von Avatargestiken (Minnie) . . . . . . . . . . 103
26
XML-Datei, in der ein Raummodell gespeichert ist . . . . . . . . 106
27
Der Avatar Cyberella“ assistiert einer Kundin beim Einkaufen . 109
”
XII
Index
A∗-Algorithmus, 64
Höhe, 105
Akustik, 56, 58
Datenmodell, 58, 69, 87
Automat
Device Manager, 34
endlich, 85
DFKI, 33
Avatar, 10, 11, 13, 29, 30, 32, 33, 35, Dijkstra-Algorithmus, 59, 64, 98
46, 50, 67, 81, 83, 102
Display, 16, 25, 96
projiziert, 13, 65, 68, 73, 107
BeaMover, 17
virtuell, 25
Behaviour, 91
DisplayHandler, 91
Bild entzerren, 23, 68, 69
DMX, 16, 17
Bildschirm, 9, 14, 31, 34, 52, 55, 110
Doppler Effekt, 27
C#, 57
Dreheinheit, 16, 17, 107
CAD, 55, 58
Ego-Shooter, 42, 44
Character, 11
Ereignis, 85, 86
Animation, 36
Event Heap, 38
Engine, 36
Engine Server, 36
Floyd-Algorithmus, 64
Lifelike, 31, 33
Fluid Beam, 18, 23, 35, 36, 68, 69, 107
Migrating, 41, 53
FLUIDUM, 14
Chat-Room, 31
Fußgänger, 62
Chatter-Bot, 32
Fußgängerzone, 60
Computergraphik, 57
Gestik, 13, 19, 34, 37–39, 102
Cor@, 32
CPU City, 46
Head Mounted Display, 48, 65
Cyberella, 33, 36, 39
Hindernis, 68, 72, 74–76, 80, 91, 92, 94–
96, 104, 105, 107
Darstellungsfläche, 10, 13, 18, 23, 68,
71, 74, 76, 77, 81, 91, 94, 95, Infrarotbaken, 16, 20, 22, 29, 53, 84
104
instrumentiert
Raum, 10, 13, 14, 29, 71
Breite, 105
XIII
Tisch, 9
Obstacle, 91, 93, 95
Umgebung, 9, 10, 14, 34, 77, 108
Online-Rollenspiel, 31
Interaktion, 13, 32, 34, 36, 54, 68, 84,
107, 111
PathEdge, 91
PathFinder, 91
System, 14
PathNetwork, 91
Technik, 14
PathNode, 91
Java, 13, 24, 36, 87, 89, 108
PEACH, 50, 52, 53, 55, 110
Java Remote Method Invocation (RMI), Personal Digital Assistant (PDA), 16,
25, 35, 36, 89
20, 22, 28, 38, 52, 61, 62, 110
Java3D, 57
Plane, 91, 94, 95
JBL Boxen, 19
Pokemon, 32
Kamera, 14, 16, 18, 19, 23, 24, 48, 107
Kanten, 59, 60, 62, 64, 77, 82, 91, 92,
PositionFinder, 91
Positionierung, 10, 13, 16, 18, 19, 25,
36, 48, 64, 65, 68, 92, 96, 107
94, 96
PositioningManager, 90
Gewicht, 61, 62, 78, 82, 83
Knoten, 59–62, 64, 77, 79–82, 91, 96–
Positionsbestimmung
egozentrischen, 28
98
exozentrisch, 28
Start, 82, 83, 99
Ziel, 82, 83, 99
Main Frame, 9
Presentation Planner, 34
Raummodell, 11, 26, 41, 55, 57, 66, 68,
70, 78, 86, 91, 107
Marker, 19, 48
speichern, 87, 89, 104
MEAVIF, 44, 46, 54
Minnie, 30, 39
Mixed Reality, 47
Movements, 91, 102, 104
RFID, 16, 20–22, 62
Ritchie, 47, 49, 55
Robotik, 86
Moving Yoke, 16, 17
SAFIR, 25, 26, 35, 57
Museumsführer, 50, 52, 108
Shortest Path, 64, 65
Museumsrundgang, 51, 108
Software-Architektur, 44
Natural Voice, 52
Stadion, 62
Navigation, 60, 62
STEVE, 41–43, 46, 47, 54
XIV
Subsumption, 86, 101
Dokument, 104
Sweet-Spot, 26
Parser, 89
Skript, 36–38, 102, 104
Ubiquitous Computing, 9, 14
Socket Verbindung, 36
Virtual Augsburg, 47, 55, 57, 59
Virtual Room Inhabitant (VRI), 34,
39, 84, 91, 102, 107
Yamaha Verstärker, 20
Zustand, 68, 85, 100
virtuell
End-, 85
Bewohner, 29, 30
Start-, 85
Character, 47
Kamera, 24
Layer, 25
Modell, 24
Objekt, 25, 41, 42
Person, 31
Raum, 25, 31, 69
Realität, 41, 47, 54
Schallquelle, 26
Taschenlampe, 25
Umgebung, 41, 42, 44, 49
Wegweiser, 61
Welt, 30, 42, 44, 46, 49, 54
Wall, 91–94
Wand, 38, 71, 72, 74, 77, 83, 92–95, 97
Wegenetz, 11, 13, 41, 57, 59, 60, 62–64,
66, 67, 76, 77, 79, 86, 91, 96
erzeugen, 96
Struktur, 96
WhizLow, 46, 47, 54
XML, 87, 89, 107
Datei, 106
XV

Thesis - AIDA - Universität des Saarlandes

Transcription

Similar documents

Hausordnung des PRL Parc Oasis Einleitung :

Seminar Reader - Mensch-Computer Interaktion

Photoshop Elements 13 – Der umfassende Ratgeber

FlowTwist - Prof. Eric Bodden, Ph.D.