Entwicklung eines dynamisch über Tools modifizierbaren

Transcrição

Systementwicklungsprojekt
Entwicklung eines dynamisch über Tools
modifizierbaren Filternetzwerkes
Nikolas Dörfler, Peter Hallama, Korbinian Schwinger,
Maximilian Schwinger
Aufgabensteller: Prof. Dr. Gudrun Klinker
Betreuer: Dipl. Inf. Christian Sandor
Abgabedatum: 10.04.2004
Hiermit versichern die Unterzeichnenden, dass sie die vorliegende Ausarbeitung
des Systementwicklungsprojektes ’Entwicklung eines dynamisch über Tools modifizierbaren Filternetzwerkes’ selbständig verfasst und nur die in der Bibliographie
eingeführten Quellen verwendet haben.
Nikolas Dörfler
Peter Hallama
Korbinian Schwinger
Maximilian Schwinger
Zusammenfassung
Im Rahmen eines Systementwicklungsprojektes wurde innerhalb des an der
TU München entwickelten DWARF ein Set von Applikationen erstellt, mit
dem es möglich ist die in einem solchen System notwendige kontinuierliche
Integration von Daten zu realisieren. Als Form wurde die eines Netzwerkes
von Filtern gewählt.
Dieses ist mit Hilfe des erstellten Toolsets konfigurierbar gestaltet. Seine
Konfiguration kann zur Laufzeit geändert werden. Ebenso ist seine Struktur zur Laufzeit mit Hilfe von zusätzlichen Tools änderbar.
INHALTSVERZEICHNIS
i
Inhaltsverzeichnis
1 Einleitung
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Struktur des Dokuments . . . . . . . . . . . . . . . . . . . . . . .
1
1
1
2 DWARF
2.1 Infrastruktur . . .
2.1.1 Services . .
2.1.2 Middleware
2.1.3 Architektur
.
.
.
.
3
3
6
6
7
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Anforderungsanalyse
3.1 Szenario . . . . . . . . . . . . . . . . .
3.2 Anforderungen . . . . . . . . . . . . .
3.2.1 Funktionale Anforderungen . .
3.2.2 Nichtfunktionale Anforderungen
3.2.3 Pseudoanforderungen . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
8
9
9
9
10
4 Verwandte Arbeiten
4.1 OpenTracker . . . . . . .
4.2 DART . . . . . . . . . .
4.3 VR-Juggler . . . . . . .
4.4 metaDESK . . . . . . .
4.5 DemoPaja . . . . . . . .
4.6 Unit . . . . . . . . . . .
4.7 Einordnung der Arbeiten
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
12
13
14
15
17
17
.
.
.
.
20
20
21
22
23
.
.
.
.
.
.
.
.
24
24
24
24
26
36
36
37
43
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 System-Design
5.1 Designziele . . . . . . . . . . . .
5.2 Dekomposition der Subsysteme
5.3 Hardware/Software - Zuordnung
5.4 Datenhaltung - und Speicherung
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6 Implementierung
6.1 Funktionalität - Filter . . . . . . . . .
6.1.1 Wahl der Programmiersprache:
6.1.2 Schnittstellen nach außen . . .
6.1.3 Klassendesign: . . . . . . . . .
6.2 Konfigurierbarkeit - CARMelion . . . .
6.2.1 Wahl der Programmiersprache .
6.2.2 Klassendesign . . . . . . . . . .
6.3 Evolution der Filter . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
INHALTSVERZEICHNIS
ii
7 Résumé
7.1 Ergebnis . . . . . . . . . . . . . . . . . . .
7.2 Probleme . . . . . . . . . . . . . . . . . .
7.2.1 Probleme speziell bei Filterservices
7.2.2 Probleme speziell bei CARmelion .
7.3 Future Work . . . . . . . . . . . . . . . . .
.
.
.
.
.
45
45
45
45
45
46
.
.
.
.
47
47
49
49
52
B Verwendete/Notwendige Hardware
B.1 Laboraufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
56
A Spinof - Entwicklungen
A.1 3D Audio . . . . . .
A.1.1 Future Work .
A.2 PoseRecorder . . . .
A.3 TUI . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ABBILDUNGSVERZEICHNIS
iii
Abbildungsverzeichnis
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
Mapping der realen Bewegung zunächst linear, dann exponentiell
Die virtuelle Hand der Testperson kann die Vase nur mit dem
GoGo-Gadget erreichen. . . . . . . . . . . . . . . . . . . . . . . .
DWARF-Typische Infrastruktur . . . . . . . . . . . . . . . . . . .
Servicedarstellung in UML . . . . . . . . . . . . . . . . . . . . . .
Beispiel einer Servicebeschreibung im XML-Format . . . . . . . .
Beispiel für DWARF-Architektur . . . . . . . . . . . . . . . . . .
DWARF - Architektur . . . . . . . . . . . . . . . . . . . . . . . .
OpenTracker - Anwendungsbeispiel . . . . . . . . . . . . . . . . .
DART, die Publisher-Erweiterung . . . . . . . . . . . . . . . . . .
VjControl - Control-Utility des VR-Jugglers . . . . . . . . . . . .
Benutzerinterface des DemoPaja . . . . . . . . . . . . . . . . . . .
Typisches Unit-Netzwerk . . . . . . . . . . . . . . . . . . . . . . .
Klassifizierung der Arbeiten . . . . . . . . . . . . . . . . . . . . .
Dekomposition in Subsysteme . . . . . . . . . . . . . . . . . . . .
Hardware/Software-Zuordung . . . . . . . . . . . . . . . . . . . .
Konfiguration eines Filter ber CARmelion . . . . . . . . . . . . .
Die Schnittstellen des Filters . . . . . . . . . . . . . . . . . . . .
Ein Filternetzwerk in DIVE . . . . . . . . . . . . . . . . . . . . .
Klassendiagramm eines Filters . . . . . . . . . . . . . . . . . . .
Debugoutput des DistanceFilters nach dem Starten. . . . . . . .
Empfang und Versand von Filterdaten. . . . . . . . . . . . . . . .
Interpolation zwischen den Stützwerten (Interpolator) . . . . . . .
Klassendiagramm des Parsephonefilters . . . . . . . . . . . . . . .
Registrierung der Variablen einer Formel . . . . . . . . . . . . . .
Abfrage der Variablenwerte . . . . . . . . . . . . . . . . . . . . .
Debugsausgaben Parsephone nach dem starten . . . . . . . . . . .
Parsephone: Ansicht in DIVE beim registrieren der Formel ADD(x,y)
Parsephone: Ansicht in DIVE nach dem registrieren der Formel
ADD(x,y) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Parsephone beim Addieren zweier Werte . . . . . . . . . . . . . .
DIVE-Bild eines von DIVE gestarteten CARmelion . . . . . . . .
Einfaches CARmelion-GUI zur Bedienung von 3 abilities . . .
Klassenhirarchie der CARmelion Implementierung . . . . . . . .
Konfigurieren eines Filters mit dem Grapheneditor . . . . . . . .
Endgültige Struktur des GenericFilters . . . . . . . . . . . . . . .
Prinzip räumlicher Klangdarstellung mit 2 Lautsprechern . . . . .
Prinzip räumlicher Klangdarstellung mit 4 Lautsprechern (quadrophonisch) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Klassenhierarchie der PoseRecorder-Imlementierung . . . . . . .
Beispiel einer TUI-Anwendung . . . . . . . . . . . . . . . . . . . .
1
2
4
5
6
7
8
12
13
14
16
17
18
21
22
25
25
26
27
28
29
32
33
34
34
35
35
35
35
36
38
40
41
44
47
48
51
52
ABBILDUNGSVERZEICHNIS
39
40
41
42
43
44
45
Apple Macintosh G4 dual . . . . . . . . . .
ART Kamera . . . . . . . . . . . . . . . . .
Apple Cinema-Display . . . . . . . . . . . .
3D Soundkarte Terratec Aureon Fun 5.1 . .
Dolby 5.1 System Terratec Home Arena 5.1
Die ’Basic Visualisation’ . . . . . . . . . . .
Das tangible Auto-Objekt . . . . . . . . . .
iv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
54
54
55
55
56
56
57
1 EINLEITUNG
1
1
Einleitung
Zunächst wollen wir zum besseren Verständnis des Dokumentes und des Projektes
dem Leser nahebringen, welches die Motivation für das vorliegende Projekt ist.
Des weiteren wollen wir auf Struktur und Aufbau des Dokumentes näher
eingehen.
1.1
Motivation
Häufig ist es in der Augmented Reality1 notwendig
nicht lineare Zusammenhänge
zwischen Benutzerinteraktion und Reaktion des AR-Systems
herzustellen. Beispiel dafür wäre
das, in [?] Eingeführte GoGo. Hierbei wird die Bewegung der Hand einer Testperson, wie in Abbildung 1
zu sehen ist, zunächst linear,
bei ’starker’ Bewegung jedoch
exponentiell auf ein virtuelles Objekt abgebildet (siehe
Abbildung 1: Mapping der realen Bewegung
auch Abbildung 2).
Um nun derartike nicht- zunächst linear, dann exponentiell
lineare Verknüpfungen herstellen zu können ist eine Bearbeitung der Daten,
welche die Bewegungen beschreiben, notwendig. Diese Berechnung soll von Filtern durchgeführt werden. Interessant wäre hier ebenso die nichtlinearen Zusammenhänge verändern zu können.
1.2
Struktur des Dokuments
Das vorliegende Dokument hält sich an den grundlegenden Aufbau, welcher laut
[?] den im Softwareengineering relevanten Strukturen entspricht.
• Im Kapitel zwei, der Anforderungsanalyse, werden Funktionale-, Nichtfunktionaleund Pseudoanforderungen welchen dieses SEP gerecht werden muss im Detail erörtert.
• Das dritte Kapitel beschäftigt sich mit verwandten Arbeiten und deren
besonderen Eigenschaften. Es wird näher darauf eingegangen, in wie weit
1
Unter Augmented Reality (Erweiterte Realität, Augmentierte Realität, kurz AR) versteht
man die (meist visuelle) Überlagerung (=Erweiterung) von virtueller Information mit der Realität in Echtzeit. Dabei soll die Information möglichst am richtigen geometrischen Ort dargestellt
werden.[?]
1 EINLEITUNG
2
Abbildung 2: Die virtuelle Hand der Testperson kann die Vase nur mit dem
GoGo-Gadget erreichen.
diese Arbeiten Anforderungen genügen, die denen des vorliegenden SEPs
ähneln.
• Im Abschnitt System-Design, dem vierten Kapitel, werden wir den Aufbau
des Gesamtsystems, seine Zergliederung in Subsysteme und die Rolle des
Systementwicklungsprojektes in diesem Gesamtsystem genauer betrachten.
• Im Kapitel fünf, welches die Implementation des Systementwicklungsprojektes zum Thema hat, wird beschrieben, wie die Realisierung des Projektes
als Schlussfolgerung aus den vorangegangenen Kapiteln bzw. Arbeitsschritten des Softwareengineering aussieht.
• Das Kabitel sechs, dem Résumé, werden die erreichten Ergebnisse, aufgetretene Probleme und mögliche Ansatzpunkte für die zukünftige Weiterentwicklung der erstellten Applikationen angeführt.
• Im Anhang findet sich sowohl eine kurze Beschreibung der bei der Erstellung
der notwendigen Applikationen entstandenen SpinOf-Produkte, namentlich
dem PoseRecorder, dem 3D-Audio-Service und der Anwendung von TUIObjekten. Des weiteren wird hier die von uns verwendete Hardware, sowie
der Laboraufbau beschrieben.
2 DWARF
2
3
DWARF
DWARF, das Distributed Wareable Augmented Reality Framework ist ein Forschungsprojekt der Technischen Universität München
welches, wie schon aus dem Namen zu erkennen ist, im Bereich der augmentierten Realität angesiedelt ist.
Das DWARF wurde entwickelt, um schnelle Prototypenerstellung durch mehrere Entwickler an unterschiedlichen Computeren zu
ermöglichen. Dadurch wurde der am Lehrstuhl für angewandtes Software Engineering
vorhandene Infrastruktur, bestehend aus Systemen auf PC-Basis mit den OS-Platformen
Linux und Windows, und Apple Macintosh Workstations, Rechnung getragen[?].
Es ist des weiteren möglich Hardwareomponenten, wie z.B. Tracking Systeme, die von Drittem hergestellt wurden, einzubinden. Im DWARF werden
AR-Anwendungen als verteilte Systeme modelliert, welche sich aus mobilen und
stationären Komponenten zusammensetzen können. Ein derartiges System kann
sich selbst zur Laufzeit durch Austausch oder Rekonfiguration von Komponenten
verändern.
2.1
Infrastruktur
Das DWARF - Framework kann auf vier Abstrakten Ebenen betrachtet werden[?]
(Abbildung 3).
• Auf der niedrigsten und damit Systemnächsten Ebene der Betrachtung
können wir das eigentliche System der PeerToPeer-Verbindung2 der einzelnen im System verwendeten Rechner sehen. Hier kann beispielsweise der
ServiceManager oder der CORBA3 -basierte Notificationservice angesiedelt
werden.
• Die nächsthöhere Ebene beinhaltet allgemeine Komponenten, die für Augmented Reality - Applikationen benötigt werden. Dazu gehören beispielsweise das Trackingsystem und die umgebungsspezifische Kontextgenerierung.
2
Bei einem PeerToPeer-Netzwerk sind, im Gegensatz zu einem ServerClient-Netzwerk, alle
teilnehmenden Rechner gleichberechtigt.
3
Die Common Object Request Broker Architecture kurz CORBA ist eine objektorientierte
Middleware, die plattformübergreifende Protokolle und Dienste definiert und von der Object
Management Group (OMG) entwickelt wird. CORBA ermöglicht das Erstellen verteilter Anwendungen in heterogenen Umgebungen.[?]
2 DWARF
4
Applikation 1
Applikation 2
...
Data Access
Navigation
Bluetooth
Communication
Service
service Access
Taskflow
Engine
AR
Wareable Computing
User
Interface
Engine
Tracking
Manager
Optical
Tracker
ID
Tracker
GPS
Tracker
World Modell
Attention
Management
CAP Router
Ubiquitous Computing
Computing
Context
Sensor
Actuator
Dynamisches Peer-to-Peer-System
Service
Manager
Service
Lokation
Protokoll
CORBA
Notification
Service
Abbildung 3: DWARF-Typische Infrastruktur
2 DWARF
5
• Die dritte Ebene wird als die allgemeine Applikationsebene beschrieben.
Komponenten, die auf den allgemeinen Aufgaben der darunterliegenden
Schichten aufbauen sind hier angesiedelt.
• Die oberste Ebene ist die der konkreten Applikation, welche für den Benutzer des Systems sichtbar ist.
Ein Framework für den Bereich der Augmented Reality wie das DWARF
muss einigen Ansprüchen genügen. Zum einen sollte es eine robuste Middleware
bieten, welche für Verbindung zwischen den einzelnen Komponenten Sorge trägt.
Zum anderen ein allgemein gehaltenes Konzept zur Erstellung von Applikationen,
welches auch wiederverwendet werden kann.
Die vorgenannten Komponenten bzw. Konzepte sind der Garant für Wiederbenutzbarkeit einzelner Systemteile in unterschiedlichen Applikationen. Um auf
die konzeptionelle Gestaltung des DWARF näher einzugehen stellen wollen wir
einen Blick auf die folgednen Punkte werfen:
• Service: Ein Service ist eine Komponente, die andere Services oder der Benutzer durch seine abilities mit Daten versorgt, die von dem genannten
Service bearbeitet, verändert oder gefiltert wurden. Durch die needs des
Service erhält der Service Daten (Abbildung 4).
• Middleware: Die Middleware konfiguriert und verbindet die Services dynamisch zur Laufzeit miteinander. Dabei werden die individuellen needs bzw.
abilities berücksichtigt.
• Architektur: Die Architektur soll die grundlegenden Strukturen des ARSystems und seine Fähigkeiten beschreiben. Dazu ist es notwendig, dass
unterschieldiche Entwickler sich an vorgegebene Konventionen bezüglich der
rolle ihrer Services und der zur Verbindung notwendigen Interfaces halten.
Die Kernkomponente des DWARF<<DWARFService>>
Frameworks ist der service
ability
Beispielservice
need
manager, der sich um Start,
ability
Verschaltung und Handhabung
need
der einzelnen DWARF-Services
ability
kümmert. Dies ist in unserem Falle auf unterschiedliAbbildung 4: Servicedarstellung in UML
chen Systemen innerhalb eines Netzwerkes möglich. Somit ist die Möglichkeit gegeben, ubiquitäre4 Applikationen zu implementieren.
Auf die oben genannten Punkte soll nun in den folgenden Abschnitten etwas
genauer eingegangen werden.
4
Unter dem 1988 von Mark Weiser geprägten Begriff ’Ubiquitous Computing’ wird die Allgegenwärtigkeit von Informationstechnik und Computerleistung verstanden, die in beliebige
Alltagsgegenstände eindringt[?].
2 DWARF
6
<service name="TestStringSender" startOnDemand="false"
stopOnNoUse="true" startCommand="TestStringSender"
isTemplate="true">
<attribute name="subsystem" value="testing"/>
<attribute name="serviceclass" value="testserver"/>
<ability name="status" type="Status">
<connector protocol="ObjrefExporter"/>
</ability>
<ability name="sendstrings" type="StringData">
<attribute name="foo" value="I send events"/>
<connector protocol="PushSupplier"/>
</ability>
<ability name="writestrings" type="StringData">
<attribute name="foo" value="I write data"/>
<connector protocol="Shmem"/>
</ability>
</service>
Abbildung 5: Beispiel einer Servicebeschreibung im XML-Format
2.1.1
Services
Ein DWARF-Service implementiert, neben der eigentlichen Funktionalität, die
Interfaces, welche zur Kommunikation innerhalb der gegebenen Infrastruktor von
Nöten sind. Repräsentiert werden diese innerhalb der Infrastruktur zum einen
durch sogenannte needs und abilities. Hierbei stehen die needs für InputInterfaces, die abilities für Output-Interfaces.
Beschrieben werden die vorgenannten Interfaces in der sogenannten service
description. Somit ist in diesen die Verbindungsstruktur der verschiedenen Services festgelegt. Servicebeschreibungen können in Form von XML-Dateine gespeichert werden (Abbildung 5).
2.1.2
Middleware
Im Falle von DWARF wird die Middleware vom sogenannten service manager
repräsentiert. Eine Instanz des service managers wird auf jedem teilnehmenden
Rechner gestartet. Jeder service managers trägt die ihm bekannten service
descriptions dem Gesamtpool derservice descriptions bei und sorgt dafür,
dass korrespondierende needs und abilities verbunden werden.
2 DWARF
7
<<DwarfService>>
Tracking
Pose
Data
Pose
Data
PoseData
<<DwarfService>>
Filter2
<<DwarfService>>
Filter1
Configuration
<<DwarfService>>
Filter3
Configuration
Configuration
<<DwarfService>>
CARmelion
Input
Data
Analog
Unlimited
<<DwarfService>>
UIC
PoseData
Viewer
Command
PoseData
<<DwarfService>>
Viewer
Abbildung 6: Beispiel für DWARF-Architektur
2.1.3
Architektur
Die konzeptionelle Architektur definiert die grundlegende Struktur eines ARSystems. Basis dafür sind Konventionen unter den beteiligten Entwicklern. Ein
Beispiel für ein im DWARF-Framework aufgebautes System und dessen Architektur kann in Abbildung 6 betrachtet werden. Hier ist ein Filternetzwerk, wie
es Ziel dieses SEPS ist und in den folgenden Kapiteln beschrieben wird, und sein
Zusammenspiel mit anderen DWARF-Komponenten in einem UML-Diagram abgebildet. Eine allgemeinere Beschreibung wird mit Abbildung 7 gegeben
3 ANFORDERUNGSANALYSE
8
Input
Trackingadapter
diskrete Ereignisse
...
kontinuierliche Ereignisse
<<Tokens>>
Interaktionsmanagement
continuous
Integration
User Interface
Controller
...
<<Tokens>>
<<Commands>>
Output
3D-Viewer
...
Abbildung 7: DWARF - Architektur
3
Anforderungsanalyse
Um die an dieses Projekt zu stellenden Anforderungen deutlich herausarbeiten
zu können ist es von großer Wichtigkeit, sich zunächst mit der vorhandenen Umgebung zur Entwicklung und Anwendung des Ergebnisses auseinanderzusetzen,
was Thema des vorangegangenen Kapitels war.
Ein weiterer Bezugspunkt der Anforderungsanalyse ist natürlich die Beschreibung des Szenarios, in welchem die Ergebnisse dieses SEPs verwendet werden
soll.
3.1
Szenario
Das CAR-Projekt soll, wie schon in der Einführung beschrieben, als Kollaborationsbasis für Ingenieure und Nichtingenieure dienen. Dabei wird der Laboraufbau
in eine Simulation der Fahrzeugumgebung, die zur Generierung von Situationen,
auf den das Fahrzeug durch Änderung von Darstellungen, Repräsentationen und
Verhaltensweisen im zweiten Teil der Simulation, der Simulation des Fahrzeuginneren, reagieren soll. Eine genauere Beschreibung des Aufbaus findet sich im
Abschnitt B.1
Aufgabe der in diesem SEP zu erstellenden Komponenten ist es nun, die
dynamischen Änderungen, die mit einfachen Zusammenhängen beschreibbar sind,
durch konfigurierbare Komponenten zur Filterung von Daten zu realisieren.
3.2
9
Anforderungen
Aus den oben beschriebenen Faktoren, der Umgebung und dem Szenario, zusammen mit den Vorstellungen des Betreuers und der Aufgabenstellerin ergeben sich
die Anforderungen an das Systementwicklungsprojekt. Die Anforderungen lassen
sich in drei Gruppen unterteilen.
3.2.1
Funktionale Anforderungen
Funktionale Anforderungen an ein System sind diejenigen Anforderungen, welche
die Interaktion zwischen System und Umwelt beschreiben und unabhängig von
der Art der Implementierung sind[?].
• Es sind Filter zur Verarbeitung von Daten zu erstellen, die verschiedene
einfache mathematische Zusammenhänge implementieren. So wären als Beispiele Filter denkbar, die in Orientierungsdaten, welche sie erhalten Rotationsachsen vertauschen.
• Mit dem in einem anderen SEP entwickelten Service DWARF Interactive
Visualisation Environment, kurz DIVE5 , welcher in einem parallel zu dem
vorliegenden SEP laufenden Systementwicklungsprojekt weiterentwickelt
wurde soll es möglich sein, Filterservices zu starten.
• Die Services sollen die Möglichkeit bieten, Veränderungen der Konfiguration
durchzuführen.
• Die Konfiguration der Filter soll über ein Interface erfolgen, dass für alle
Filter einheitlich ist.
• Die oben genannten Veränderungen der Konfiguration sollen zur Laufzeit
durchführbar sein.
• Die Struktur und das Zusammenspiel von mehreren Filtern bzw. Filternetzwerken soll zur Laufzeit veränderbar sein.
• Die Filter sollen zur Hilfe bei Integrationstests verwendet werden können.
3.2.2
Nichtfunktionale Anforderungen
Nichtfunktionale Anforderungen sind Anforderungen, welche das von einem Benutzer erkennbare Verhalten des Systems betreffen.
Sie stehen nicht in direkter Beziehung zur funktionalen Verhaltensweise des
Systems[?].
5
DIVE wurde als Visualisierungstool im DWARF entwickelt. Es hat unter anderem die
Fähigkeit, die Verbindungsstati der verschiedenen Services im Netzwerk zu zeigen und auch die
Eigenschaften der Verbindungen zu editieren.
10
• Die Ausgabe der verarbeiteten Daten soll in Echtzeit6 erfolgen. Diese Anforderung ist für AR-Anwendungen, die direkte Auswirkung auf die Augmentierung haben stets erforderlich.
• Um die oben beschriebenen Anwendungen mit den zu erstellenden Filtern
realisieren zu können ist eine gewisse Mindeststabilität des Filternetzwerkes
unerlässlich.
3.2.3
Pseudoanforderungen
Pseudoanforderungen sind diejenigen Anforderungen, welche nicht durch die Projektziele selbst, sondern durch Kunden oder in diesem Falle durch den Aufgabensteller gegeben werden.
• Die wichtigste Anforderung des Aufgabenstellers ist die Verwendung des
DWARF als Basis der Entwicklungen.
• Die zu erstellenden Filter sollen mit den in anderen Arbeiten implementierten Komponenten des Projektes CAR innerhalb des Projektes CAR
verwendbar sein.
• Die filternden Funktionen sollen nicht in einem einzigen ’Multifunktionsfilter’, sondern in separaten Filtern, welche sich untereinander verschalten
implementiert werden.
6
Die Definition von Echtzeit ist umstritten. Die breiteste Zustimmung findet folgende Definition: Ein Echtzeit-System ist ein System, bei dem das Ergebnis der Berechnung innerhalb eines
gewissen Zeitraumes garantiert vorliegt. Verletzt das System diese Zeitschranke, hat das System
versagt. Um die Echtzeit-Fähigkeit eines Echtzeit-Systems theoretisch nachweisen zu können,
müssen die Häufigkeit der externen Ereignisse, die Laufzeit der einzelnen Programmteile und
die Zeitschranken bekannt sein[?].
4 VERWANDTE ARBEITEN
4
11
Verwandte Arbeiten
Auf dem relativ aktuellen Forschungsgebiet der Augmented Reality gibt es viele
Arbeiten die zumindest ähnliche Ziele verfolgen. Ein Blick über den Tellerrand
der eigenen Entwicklungen hinaus ist daher zumindest lohnenswert, wenn nicht
gar unverzichtbar. Auch eine Untersuchung der verwandten Entwicklungen der
Virtuellen Realität7 soll hier durchgeführt werden.
4.1
OpenTracker
Kurzbeschreibung
OpenTracker ist ein als ’OpenSource8 ’ verfügbares
Projekt, das es sich zum Ziel gesetzt hat eine Software zu entwickeln, die Lösungen für unterschiedlichste
Anforderungen, welche Verarbeitung von Trackingdaten betreffen, bietet.
Hierbei wird versucht das System so modular wie
möglich aufzubauen. Die Konfiguration erfolgt über
XML. Dieses Projekt wurde an der Technischen Universität Wien initiiert[?].
Besonderheiten
Motivation für das OpenTracker-Projekt war die Beobachtung, dass derzeit das
Hauptaugenmerk bei den Entwicklungen im Bereich Tracking auf der Erstellung
des Trackers selbst, nicht aber auf einem soliden Ansatz für die Software zur Verarbeitung der Trackingdaten liegt. Als Folge davon sind die meisten kommerziell
erhältlichen Systeme mit wenig modularer, schwer konfigurierbarer und meist gar
nicht anpassbarer Software ausgestattet. Genau diese Beobachtung führt uns zu
den Besonderheiten des OpenTracker-Projektes.
Das Hauptkonzept des Open Tracker ist es, den Trackingdatenfluss in VR
und AR- Umgebungen, welcher typischerwiese aus Generierung der Trackingdaten durch die Trackinghardware, einlesen der Daten durch Gerätetreiber, Transformation der Trackingdaten in die benötigte Form und senden der Daten über
das Netzwerk besteht, aufzubrechen und ein ’Data-Flow’ - Netzwerk aus den einzelnen Komponenten zu erstellen. Grund für dieses Vorgehen ist die Tatsache,
dass all die vorgenannten Schritte in jedem AR oder VR - Setup vorhanden sind,
allerdings in eventuell anderen Ausprägungen und Anordnungen.
Die Anordnung und Ausführung der einzelnen Schritte wird, ähnlich einem
Szenengraph, organisiert. Aufbau und Konfiguration dieses die Arbeitsschritte
bestimmenden Graphen werden durch das Editieren einer XML-Datei relativ einfach. ermöglicht.[?]
7
Als Virtuelle Realität (VR) wird die Darstellung der Wirklichkeit und ihrer physikalischen
Eigenschaften in einer in Echtzeit computergenerierten Umgebung bezeichnet[?].
8
Der englische Ausdruck Open Source steht einerseits für ’quelloffen’ (in dem Sinne, dass der
Quelltext eines Programms frei erhältlich ist), andererseits für ’offene Quelle’ (in dem Sinne,
dass ein Werk frei zur Verfgung steht). Software gilt als Open Source, wenn sie bestimmte
Kriterien erfüllt, die in ihrer Open-Source-Lizenz geregelt sind[?].
12
Abbildung 8: OpenTracker - Anwendungsbeispiel
4.2
DART
Kurzbeschreibung
Das Designer’s Augmented Reality Toolkit, kurz DART, ist eine
Entwicklung des Georgia Institute
of Technology in Atlanta. Mit ihm ist eine Prototypenerstellung von Augmented
Reality-Applikationen mit Hilfe von Tangible User Interfaces möglich. DART
wurde zur Unterstützung von AR-Experten, speziell beim ’rapid prototyping9 ’
entwickelt. DART ist eine Erweiterung des Macromedia Directors, welcher einer
der wohl am meisten verbreiteten Multimediadesigner ist[?].
Besonderheiten
Die größte Besonderheit des Projektes DART ist wohl das Konzept der Bedienung durch Tangible User Interfaces10 . Für die Benutzung ist eine Umgebung,
9
Das (Rapid) Prototyping ist eine Methode der Softwareentwicklung, die zu schnellen Ergebnissen führen soll. Diese Ergebnisse werden z.B. in der Machbarkeitsphase benötigt, um
ein Software-Projekt vom Aufwand und von den Kosten einzuschätzen und um überhaupt die
Machbarkeit einer Lösung zu demonstrieren[?].
10
Als Tangible User Interface oder kurz TUI bezeichnet man metaphorische Objekte, mit
denen der Benutzer in der realen Welt interagieren kann. Eine Manipulation des Objektes in
vorher festgelegter Art hat Auswirkungen auf die zugehörige Applikation.
13
ausgestattet mit multiplen Tracking-Sensoren und Displays in verschiedensten
Konfigurationen, notwendig. Somit hat der Designer die Möglichkeit seine ARAnwendung in der selben Umgebung zu entwickeln, in der sie später benutzt
werden soll.
Durch die Bedienung via
metaphorischer Objekte wird
als Zielgruppe neben der der
technischen Designer auch
diejenige der nichttechnischen
erschlossen.
Die Integration in den
Macromedia Director erfolgt
durch hinzufügen von sogenannten ’behaviors’, also Verhaltensweisen, die dem Director als Erweiterungen, welche in LINGO11 erstellt wurden bzw. durch erstellen sogenannter Director Xtras12 ,
Abbildung 9: DART, die Publisher-Erweiterung
die in C++ implementiert
werden.
Beispielsweise kann nun durch das Hinzufügen von Actor-Verhaltensweisen
ein Objekt in der AR-Szene mit einem realen Objekt verbunden oder Verhaltensweisen nach dem Muster ’Wenn X eintritt führe Y aus’ definiert werden.
4.3
VR-Juggler
Kurzbeschreibung
Der VR-Juggler ist, wie schon aus dem Namen
erkennbar, ein Tool, welches speziell für die Anforderungen von VR-Szenarien entwickelt wurde.
Er agiert als Bindeglied zwischen der eigentlichen
VR-Anwendungen und der Hardware.
Somit muss der Entwickler der Software auf
der höchsten Applikationsebene sich bespielsweise nicht mehr um die Hardware und Hardwaretreiberspezifischen Trackingdaten und deren Importierung und Konvertierung
kümmern sondern erhält unabhängig vom verwendeten Trackingsystem die Positionsdaten in standardisierter Form direkt vom VR-Juggler [?].
11
LINGO ist eine Scriptsprache, die im Macromedia Director zur Erstellung von multimedialem Content verwendet wird.
12
Macromedia Director Xtras sind Erweiterungen, die in Form von Bibliotheken hinzugefügt
werden.
14
Abbildung 10: VjControl - Control-Utility des VR-Jugglers
Besonderheiten
Der VR-Juggler agiert, wie in der Kurzbeschreibung erwähnt, als ’Middleware’ zwischen den verschiedenen VR-Anwendungen. Das System besteht einerseits
aus dem Mikrokernel, der als Bindeglied zwischen den verschiedenen Managern
dient, andererseits aus den Managern selbst. Die Aufgabe der Manager sind beispielsweise die Verwaltung der Anzeigegeräte, aller Eingaben und ähnlichem.
Durch das Design des VR-Jugglers ist es möglich platformunabhängig Systeme
zu entwickeln und zu benutzen.
Um nun eine VR-Application erstellen zu können ist es zunächst notwendig,
den VR-Juggler an die vorhandene Hardware anzupassen. Zur Vereinfachung der
Konfiguration und der Erstellung von Applikationen wurde ein Java-Frontend,
der VjControl erstellt, welches in Abbildung 10 betrachtet werden kann.
4.4
metaDESK
Kurzbeschreibung
Das metaDESK - Projekt beschäftigt sich mit der Erstellung von Benutzerinterfaces, die näher an den dem Menschen aus seiner natürlichen Umgebung ge-
15
wohnten Interaktionsformen liegen, als das GUI13 . Zu diesem Zweck wurde schon
1997 eine augmentierte Umgebung entwickelt, in der Versuche mit neuen Bedienungsmetaphern möglich waren[?].
Besonderheiten
Das metaDESK-System
besteht aus folgenden Komponenten: Das Zentrale Objekt des Systems ist der
’desk’. Wie der Name vermuten lässt ist er tischähnlich. Er ist mit einer berührungssensitiven Oberfläche und
zur Bildwiedergabe mit einem Rückprojektor ausgestattet. Weitere Komponenten sind die ’active lens’,
ein Flatscreen der an einem schwenkbaren Arm befestigt wird und die ’passive lens’, eine optisch transparente Oberfläche durch die
der ’desk’ projezieren kann.
In der beschriebenen Umgebung nun werden die von der GUI bekannten Bedienungsobjekte wie ’icons’, ’menues’ und ’handles’ in Tangible User InterfaceObjekte, nämlich phicons (physical icons), trays und phandles(physical handles)
übersetzt.
4.5
DemoPaja
Kurzbeschreibung
Der DemoPaja ist ein Authoring Tool, das zu den klassischen MultimediaDesignern gezählt werden kann. Eine ’Demo’ kann in diesem Zusammenhang als
Demonstration oder Komposition verschiedener multimedialer Inhalte allein
als Kunstwerk oder Beispiel der Fähigkeiten des Authors und der zur Verfügung
stehenden Hardware beschrieben werden. Zu diesem Zweck bietet der DemoPaja ein einfach und nahezu intuitiv
16
Abbildung 11: Benutzerinterface des DemoPaja
bedienbares Benutzerinterface. Die Bedienungsparadigmen des DemoPaja sind
vergleichbar mit den allgemein in der Welt der klassischen Multimediadesigner
üblichen Ausprägungen. Beispiele dafür wären etwa das Macromedia-Flash Designertool oder ’After Effects’, welches von Adobe vertrieben wird.
Besonderheiten
Im Gegensatz zu den vorgenannten Arbeiten ist der Demopaja eher für eine weniger versierte Zielgruppe ausgelegt. Auch die Ziele des Multimediadesigns sind
wesentlich niedriger gesteckt, als z.B. die Ziele eines Frameworks zur Erstellung
von AR-Applikationen.
Die Erstellung von Animationen erfolgt als Komposition von Animationen,
Videospuren, Audiospuren u.s.w. die entsprechend ihrer Position in der Timeline
zu einem fest bestimmten Zeitpunkt der Demo wiedergegeben werden. Das Interface zur Erstellung dieser Demos ist, wie in Abbildung 11 erkennbar, intuitiv
verständliches und verwendet, ähnlich einem Zeitplanungsdiagramm, an der Timeline ausgerichtete Ereignisse.
13
GUI ist eine Abkürzung aus dem IT-Bereich für ’Graphical User Interface’, was wörtlich
übersetzt ’Grafische Benutzerschnittstelle’ bedeutet, in der Softwareergonomie jedoch in der
Regel treffender als Grafische Benutzungsschnittstelle bzw. Mensch-Maschine-Schnittstelle bezeichnet wird. Ein GUI stellt dem Benutzer somit eine grafische Schnittstelle zur Bedienung
des Rechners zur Verfügung[?].
4.6
17
Unit
Kurzbeschreibung
Die Idee hinter Unit ist die eines Frameworks zum Zwecke der Entwicklung des
Designs und der Implentierung interaktiver Technologien. Als potentielle Anwendungsgebiete werden vom Author sowohl Augmented, als auch Virtual Reality Szenarien gesehen.
Um diese Idee zu verwirklichen wird bei Unit eine abstrakte Ebene der Benutzerinteraktion geschaffen, die zwischen der Ebene der Benutzereingaben und
der Ebene der eigentlichen Applikation liegt[?].
Besonderheiten
Der Name Unit leitet sich aus den
verwendeten Bezeichnungen innerhalb
der Systemarchitektur ab. Die Units
sind hier einzelne abstracte Entitäten.
Sie bestehen aus Methoden, die die Informationsverarbeitung innerhalb der
Unit repräsentieren und Verbindungen,
die einseitige Informationskanäle nach
außen darstellen. Die wahre Stärke des
Systems Unit liegt in der Zusammenschaltung mehrerer Unit-Entitäten zu
einem Netzwerk. Somit kann die Informationsverarbeitung stufenartig bis
zur endgültigen Ausgabe aufgebaut werden.
Die Entwicklungsarbeit neuer Applikationen erfolgt bei diesem Framework durch instanziieren und manipu- Abbildung 12: Typisches Unit-Netzwerk
lieren verschiedener Units.
4.7
Einordnung der Arbeiten
Um nun eine Vergleichsmöglichkeit zur Einordnung der vorgestellten Arbeiten
zu haben müssen wir uns zunächst ein Bezugssystem definieren, in das wir die
Arbeiten und ihre speziellen Ausprägungen einordnen können. Als Bezugsgrößen
bietet sich z.B. an:
• Zielgruppe: Ist die vorgestellt Arbeit eher für den Entwickler oder für einen
potentiellen Enduser, soweit man in dieser Domäne eher versiertere Personen von Enduser sprechen kann, gedacht?
AR
DART
18
metaDESK
OpenTracker
Unit
VRJuggler
VR
DemoPaja
multimedial
ubiquitär
Abbildung 13: Klassifizierung der Arbeiten
• VR - oder AR-Applikation: Kann die Arbeit eher zur Erstellung von Szenarien der virtuellen oder der augmentierten Realität verwendet werden?
• Klassischer oder ubiquitärer Multimediadesigner: Werden eher klassische
Konzepte zur Erstellung der Applikationen verwendet oder ubiquitäre?
Der Einfachheit halber werden wir die Arbeiten nur mit Hilfe der letztgenannten beiden Bezugsgrößen einordnen. Somit ist eine Darstellung ähnlich einer
Portfolioanalyse möglich(Abbildung 13).
Viele Konzepte der vorgestellten Arbeiten eignen sich gut um Anstoß und Ideen für unser eigenes Projekt zu sammeln. Um nun aus den verwandten Arbeiten
etwas für die unsrige schlussfolgern zu können bietet es sich an auch unsere Arbeit in das vorgegebene Portfolio einzuordnen. Dies fällt dank der Anforderungsanalyse relativ leicht. Unsere Arbeit ist eindeutig der augmentierten Realität
zuzuordnen. Die Methoden, welche verwendet werden sind wiederum eindeutig
ubiquitär.
Somit ist die Arbeit, die der unsrigen in dieser Beziehung am ähnlichsten
ist ohne Zweifel das Projekt metaDESK. Wenn wir nun die Zielsetzungen dieses
Projektes in Relation zu den unsrigen sehen erkennen wir wieder starke Parallelen: Auch metaDESK versuchte neue Konzepte, in seinem Falle nur auf die
Verwendung von TUI-Objekten als Ersatz für die klassische GUI beschränkt, zu
untersuchen.
Viele Konzepte und Ideen des metaDESK-Projektes werden sicher in das unsrige miteinfließen. Auch die anderen angeführten Arbeiten spiegeln interessante
19
Ideen der Entwickler wieder, die wir, soweit für uns von Nutzen, mit in unserer
Arbeit berücksichtigen werden.
5 SYSTEM-DESIGN
5
20
System-Design
Beim Design des Systems werden die in den vorgenannten Abschnitten aufgeführten relevanten Punkte, nämlich die Anforderungen an das System und die Konzeptideen, die uns aus verwandten Arbeiten brauchbar erscheinen zu einem Modell überführt, welches eine Dekomposition des Projektes in seine Subsysteme
möglich macht.
5.1
Designziele
Die Designziele geben die Qualität der Ansprüche wieder, denen das Gesamtsystem genügen muss. Wichtige Punkte, die zu dieser Kathegorie zählen, auf die
während der Realisierung des Projektes stets geachtet werden muss, sind in unserem Falle:
• Geschwindigkeit: Da für das Projekt CAR relativ viele Daten gefiltert und
bearbeitet werden müssen ist eine gewisse Mindestgeschwindigkeit jedes
einzelnen Filters durch die Echtzeitrelevanz der AR-Anwendung CAR notwendig. Zusätzlich zu der Datenmenge, welche jeder einzelne Filter bearbeiten muss macht die Notwendigkeit vieler Filter die Geschwindigkeit der
Einzelfilter zu einem sehr wichtigen Designziel.
• Erweiterbarkeit: Das Netzwerk von Filtern soll ohne großen Aufwand um
weitere Filter erweiterbar sein. Dieses Ziel ist durch das Verbindungskonzept
des DWARF relativ leicht zu verwirklichen.
• Modifizierbarkeit: die Filternetze sollen in ihren Verbindungen, welche die
Abhängigkeiten untereinander ausdrücken, leicht veränderbar sein.
• einfache Anwendbarkeit: Nach der Entwicklungsphase soll die Verwendung
und evtl. auch die Weitertentwicklung der zu erstellenden Applikationen
relativ einfach realisierbar sein.
• Konfigurierbarkeit: Die Filterservices sollen, auch zur Laufzeit, die Möglichkeit bieten, Änderungen an ihrer Konfiguration, also der Behandlung der zu
verarbeitenden Daten, durchzuführen. Diese Konfigurierbarkeit soll auch in
weiteren Filtern einfach integrierbar sein.
• Wiederverwendbarkeit: auch nach Abschluss des Systementwicklungsprojektes und des Projektes CAR sollen die entwickelten Services weiter für
andere Szenarien verwendbar sein.
5 SYSTEM-DESIGN
21
continuus Integration
CARmelion
Filter
Filter1
Filter2
DIVE
Abbildung 14: Dekomposition in Subsysteme
5.2
Dekomposition der Subsysteme
Die Dekompositions des Systems hat zum Zweck, die funktionalen Anforderungen an das Gesamtsystem in eine Aufteilung dieses in Subsysteme zu überführen.
Eine rudimentäre Dekomposition kann in Abbildung 14 betrachtet werden. Hier
wird die kontinuierliche Integration, welche im Kapitel ’DWARF’ eingeführt wurde genauer aufgegliedert. In unserem Fall kann die kontinuierliche Integration in
mehrere Komponenten aufgespalten werden. Namentlich dem CARmelion, weches für die Konfiguration des eigentlichen datenbearbeitenden Partes, der Filter,
zuständig ist und die Userinteraktion mit der Filterkonfiguration ermöglichen soll
und den Filtern selbst.
Das DIVE, welches im Rahmen eines früheren SEP’s[?] erstellt und in einem
parallel zu diesem SEP laufenden Projekt weiterentwickelt wurde, steht ausserhalb der erstellten Ordnung. Das hat als Grund die vielfältigen Einsatzmöglichkeiten des DIVE, welche es zu mehr als einer Gruppe zugehörig machen.
Die im Kapitel ’Designziele’ eingeführten Kriterien bewogen uns zur vorgenannten Aufteilung. Die Komponenten, welche für die eigentliche kontinuierliche Datenverarbeitung verantwortlich sind und als DWARF-Komponenten zu
erstellen sind, werden als Basis für schnellere Entwicklung von Komponenten der
kontinuierlichen Integration erstellt. Um denjenigen, welche derartige Komponenten benötigen, das Leben zusätzlich zu vereinfachen wurde die Konfiguration
der Komponenten und das Graphical User Interface in einer eigenen Komponente implementiert. Aufteilung und Zweck der einzelnen Komponenten sollen hier
nocheinmal genau voneinander abgegrenzt werden:
• Filter: Die Filterkomponenten erhalten Daten, verarbeiten diese und geben
verarbeitete Daten aus. Die Art der Verarbeitung wird über das Senden
eines Konfigurations-Events an ein DWARF-Need vom Benutzer oder anderen DWARF-Services bestimmt.
5 SYSTEM-DESIGN
22
• CARmelion: Die Benutzerinteraktion mit den Filtern ist durch die graphische Oberfläche des CARmelion möglich. Von DIVE gestartet soll das
CARmelion die beim Start übergebene und zur Konfiguration des in DIVE beim Start ausgewählten Filters nötigen, Abilities ausbilden. Zu diesem
Zweck soll das CARmelion beliebige Datenquellen simulieren können.
5.3
Hardware/Software - Zuordnung
Das Kapitel Hardware/Software - ZuordPentium, 500 MHz, Matrox
G550, 256 MB
nung beschäftigt sich
mit der Zuordnung der,
im vorangegangenen Kapitel eingeführten, SubFilter
Audio
systeme zu vorhandeAthlon 2400+, GeForce FX
Athlon 2400+, GeForce FX
5600, 512 MB
5600, 512 MB
ner Hardware. Hierbei
wird Leistungsbedarf und
Bedarf anfordungsspezifischer Hardware berücksichtigt und gegebenenfalls genauer erläutert.
ART-Tracking
Visualisierung
In Abbildung 15 werAthlon XP 1600
Apple Macintosh PowerPC
dual G4
den die in der folgenden Tabelle begründeten Hardwarezuordnungen, sowie weitere in
Abbildung 15: Hardware/Software-Zuordung
unserem System vorhandene Software und deren Zuordnung zu Hardware grafisch dargestellt.
CARmelion
• Filter: die Filter sollten, wenn möglich, separat auf einem Rechner gestartet
werden. Der Grund dafür ist die Echtzeitrelevanz des mit Filtern zu verarbeitenden Datenstroms und die Unberechenbarkeit der Leistungsforderung
anderer Applkikationen auf dem verwendeten System. Das von uns verwendete System der Anwendung CAR ist ein Athlon 2400+ mit GeForce FX
5600 Grafikkarte und 512 MB RAM. Es läuft unter SuSe Linux.
• CARmelion: da die Hauptaufgabe des CARmelion das senden von diskreten
Daten ist und keine Verarbeitungsaufgaben anfallen ist der zu erwartende
Rechenaufwand relativ gering und beschränkt sich zum größten Teil auf die
einmalige GUI-Generierung. Der von uns für das CARmelion verwendete
Rechner ist daher nur ein Pentium mit 500 MHz, Matrox G550 Grafikkarte
und 256 MB RAM. Ebenfalls unter SuSe Linux.
5 SYSTEM-DESIGN
5.4
23
Datenhaltung - und Speicherung
Die hier benötigte Art der Datenhaltung und Speicherung kann von der Art der
Daten und dem Zweck derer Verarbeitung hergeleitet werden. Zunächst haben wir
die kontinuierlichen Daten, die z.B. vom ART-Tracking-System kommen können
und uns mit Positions- und Orientierungsdaten von Objekten versorgen. Sie geben
die aktuellen Verhältnisse wieder. Es besteht daher eigentlich keine Notwendigket
sie aufzuzeichnen. Um allerding z.B. Demonstrationen, bei denen Bewegungen
vorher festgelegt werden sollen, realisieren zu können kann es notwendig sein
Trackingdaten zu speichern. Zu diesem Zweck wurde der PoseRecorder, welcher
in Kapitel A.2 eingeführt wird, implementiert.
Die zweite Art von Daten, mit denen wir zu tun haben, sind Konfigurationsdaten, welche vom CARmelion generiert werden. Eine einmal getestete Konfiguration zu speichern ist durchaus sinnvoll und soll im CARmelion möglich sein.
Das Speichermodell kann in diesem Falle durchaus einfach gehalten werden,
da es sich nicht um sehr komplexe Datenstrukturen und keine groen Datenmengen
handelt. Beispielsweise wäre die Speicherung in einer relationalen Datenbank aus
den vorgenannten Gründen bestenfalls ineffizient.
6 IMPLEMENTIERUNG
6
24
Implementierung
6.1
Funktionalität - Filter
In diesem Abschnitt soll nun näher auf die Implementierung der Filter als Teil der
kontinuierlichen Integration eingegangen werden. Insbesondere die Wahl der Programmmiersprache, die Schnittstellen des Filters nach außen, sowie der genaue
Aufbau der verschiedenen Klassen sollen hier ausführlicher erläutert werden.
6.1.1
Wahl der Programmiersprache:
Als Programmiersprache fr die Filter wurde C++ gewhlt. Dies hat verschiedene
Grnde:
Geschwindigkeit Da die Filter dafr entworfen wurden in Echtzeit relevante
Daten zu verarbeiten war Geschwindigkeit ein wesentliches Kriterium. Deshalb wurde die Möglichkeit ausgeschlossen die Filter in einer Scriptsprache
wie Python zu schreiben. C++ dagegen bietet hohe Geschwindigkeit sowie
alle Mglichkeiten einer modernen Hochsprache.
Vorhandenes Template Zu Begin unseres Projekt lag bereits ein sog. TemplateService14 vor, der die grundstzlichen DWARF Service Funktionen wie z.B.
das Anmelden des Services beim Servicemanager, bereitstellte. Dies machte
es einfach bei unserem geringen Wissenstand zu Beginn des Projekts schnell
einen lauffähigen Service zu schreiben.
Bekanntheit der Sprache Ein weiteres Kriterium war, dass fast alle Teilnehmer bereits Erfahrungen mit C++ gesammelt hatten und es somit nahelag
diese Sprache zu verwenden.
6.1.2
Schnittstellen nach außen
Ein Filter benötigt drei verschiedene Verbindungen nach außen. (Siehe auch Bild
6.1.2)
• Er empfängt Daten: Zu diesem Zweck besitzt er DWARF Needs.
• Er versendet Daten: Hierzu besitzt er DWARF Abilities.
• Er ist konfigurierbar: Zu diesem Zweck besitzt er DWARF Needs. Diese
sind jedoch in seiner Servicebeschreibung speziell als Konfigurationsneed
gekennzeichnet15 Diese Konfigurationsneeds können beispielsweise mit dem
14
geschrieben von Martin Wagner
Um beim ServiceManager ein Need als Konfigurationsneed zu kennzeichnen muss es in
der XML-Servicebeschreibung das Attribut ConfigurationNeed besitzen. Dies dient auch dazu, dass der Filter selbst erkennt, welche seiner Eingänge zu seiner Konfigurationsschnittstelle
zählen.
15
6 IMPLEMENTIERUNG
25
Konfigurationsprogramm CARmelion angesteuert werden. Dieses Vorgehen
wird in Bild 6.1.2 dargestellt.
Abbildung 16: Konfiguration eines Filter ber CARmelion
Ein Filter besitzt mindestens ein Need
und eine Ability. Er muss allerdings nicht
zwingend ein Konfigurationsneed besitzen. Wie andere DWARF Services auch
müssen Filter diese zunächst beim Servicemanager anmelden. Dies geschieht
normalerweiser automatisch durch die
XML Beschreibung des Filters, die dem
ServiceManager vorliegt, aber der Filter besitzt auch Funktionen um selbstständig
Abbildung 17: Die Schnittstellen des seine Beschreibung verändern zu können
und neue Needs und Abilities einzufügen.
Filters
Um Daten verschicken zu können bedient sich das DWARF Framework des Notification Services des CORBA-ORBs(siehe
hierzu [?]). Alle Daten werden als strukturiertes Ereignis verschickt. Um nun solche Ereignisse empfangen und senden zu können wird jedem Need ein Empfänger
(Receiver) -Objekt, und jedem Ability ein Sender Objekt, zugeordnet. Vergleiche
hierzu Bild 6.1.2
Filter können über diese Schnittstellen miteinander und mit anderen Services
zu einem Netzwerk verschaltet.6.1.2 zeigt zum Beispiel ein Netzwerk von Filtern,
visualisiert mit DIVE.
6 IMPLEMENTIERUNG
26
Abbildung 18: Ein Filternetzwerk in DIVE
6.1.3
Klassendesign:
Receiver Diese Klasse erweitert die SvcProtPushConsumer Klasse. Sie benötigt
einen Zeiger auf das instantiierende Objekt, um später die empfangenen Daten weiterreichen zu können. Außerdem wird jeweils das letzte empfangene
Event zwischengespeichert. Da jeder Receiver direkt einem Need zugeordnet ist wird auch gleich der Name (in m name ) sowie der Typ des Needs (
Normales Need oder Konfigurationsneed ) gespeichert. Eine entscheidende
Stelle des Receivers ist die Methode push structuredEvent. Diese Methode wird vom CORBA NotificationService aufgerufen, wobei das Event als
Parameter übergeben wird. Sie speichert das Event zusammen mit der Zeit
des Eintreffens im Receiver ab, und ruft dann die gotEventMethode des Filterobjekts auf. Dabei wird wieder ein Zeiger auf das Receiverobjekt (this)
übergeben, damit die Filterklasse später einfach auf das empfangene Event
zugreifen kann.
void Receiver::push_structured_event(const CosNotification::
StructuredEvent& event)
{
above->lockMutex();
if (lastEvent.sevnt!=NULL) {delete lastEvent.sevnt;}
6 IMPLEMENTIERUNG
27
Abbildung 19: Klassendiagramm eines Filters
lastEvent.name = m_name;
lastEvent.received = true;
lastEvent.sevnt = new CosNotification::StructuredEvent(event);
gettimeofday(&lastEvent.timeStamp, 0);
above->unlockMutex();
above->gotEvent(this);
// Aufruf der Filtermethode
zur Eventbehandlung
}
Sender Die Senderklasse erweitert die SvcProtPushSupplier Klasse. Beim
Senden von Events ist zu beachten, dass zuerst eine Verbindung zu einem
empfangenden Service (Consumer ) aufgebaut sein muss. Wenn dies der Fall
ist ruft der ServiceManager die Methode setConsumer des Senders auf. Nun
können mit der Methode sendoutEvent Events über den Notificationservice
verschickt werden.
CommonList Da ein Filter eine, sich möglicherweise zu Laufzeit ändernde, Anzahl vpn Needs und Abilities besitzen kann bietet es sich an, die zughörigen
Objekte in einer verketteten Liste zu speichern, um den Filter möglichst
flexibel zu halten. Eine solche Liste implementiert CommonList. Durch die
Verwendung der Templateklasse T wird erreicht, dass diese Liste für beliebige Objekte verwendet werden kann. Der Filter verwendet jeweils eine Liste
für Sender (sndList) , Empfänger (recList) und Konfiguration (cfgList
).
6 IMPLEMENTIERUNG
28
Filter Diese Klasse ist abgeleitet von TemplateService der von Martin Wagner geschrieben wurde. TemplateService stellt die wichtigen Funktionen eines einfachen DWARF Services bereit. Es wird das einfachste Interface
BasicService implementiert. BasicService implementiert wiederum das
DWARF Service-Interface sowie das DWARF SvcStartup-Interface. Dadurch ist eine DWARF Service Funktionalität bis auf die die Methoden
run(),createNeedObject() und createAbilityObject() bereits gegeben.
Diese mussten neu implementiert werden.
Filter besitzt nun folgende Methoden.
• createAbilityObject(), createNeedObject(),addAbility(),addNeed(),removeAbi
removeNeeds().
Beim Start eines Filters werden createAbilityObject bzw. createNeedObject
für jedes Need bzw. Ability, welches in der XML Beschreibung eingetragen ist, automatisch vom Servicemanager aufgerufen. Dadurch wird
jeweils ein neues Sender- oder Receiverobjekt erzeugt und an die jeweilige Liste gehängt. Zur Laufzeit können neue Needs bzw. Abilities
und ihre zugehörigen Objekte mit den Funktionen addAbility und
addNeed erzeugt werden. removeNeeds bzw removeAbilites entfernen alle Needs/Abilities und melden diese auch beim Servicemanager
ab.
Abbildung 20: Debugoutput des DistanceFilters nach dem Starten.
• gotEvent()
Diese Methode wird vom Receiver aufgerufen wenn er ein neues Event
empfangen hat. Bei diesem Aufruf wird ein Zeiger auf das Receiverobject mitgeliefert, welches das Event erhalten hat. So kann im folgenden
schneller darauf zugegriffen werden. Die gotEvent Methode liest nun
6 IMPLEMENTIERUNG
29
den Typ des zugeordneten Needs aus (Normal oder Konfiguration ).
Bei einem normalen Need ruft sie anschließend die Calculate Methode auf. Ansonsten, wenn es sich um Konfigurationsdaten handelt,
wird Configure aufgerufen. Bild 21 zeigt den Ablauf beim Empfang
eines Events als Aktivitätsdiagramm. gotEvent übergibt dabei nicht
das Event selbst, sondern leitet einfach den Zeiger weiter. Dies sorgt
für größere Geschwindigkeit.
Abbildung 21: Empfang und Versand von Filterdaten.
Die folgenden Methoden sind für jeden Filter jeweils neu zu implementieren:
• run()
Diese Methode wird ausgeführt und sollte eigentlich die Hauptschleife
eines Services enthalten. Da ein Filter aber nur auf Events von außen reagieren muss dient die run-Methode eigentlich nur dazu, den
Hauptthread des Programms solange zu blockieren bis der Filter beendet werden soll.
• Calculate()
Hier werden alle Berechnungen des Filters gemacht und dem Filter
somit seine Funktionalität verliehen. Da diese Methode in der Filterklasse virtuell ist, bzw. aus einer leeren Methode besteht, muss sie für
jeden neuen Filter auch neu implementiert werden. Daher ist die folgenden Beschreibung nur eine bei allen Filtern bis jetzt verwendete
Möglichkeit.
6 IMPLEMENTIERUNG
30
Calculate bekommt als Übergabewert einen Zeiger auf das Receiver - Objekt, das das letzte Event empfangen hat. Dies ermöglicht
eine schnelle Abfrage des Events, da direkt über diesen Zeiger und die
Methode getEvent darauf zugegriffen werden kann. Wenn der Filter
allerdings mehrere Eingänge besitzt und diese jeweils für die Berechnung benötigt werden, kann man auch die recList - Liste durchlaufen
und so für alle Empfänger die Werte abfragen, da Calculate immer
nur dann aufgerufen wird, wenn ein neues Event empfangen wurde.
Man könnte aber z.B. die Calculate Methode auch von run aus in regelmäßigem Zeitabständen aufrufen und so garantieren, dass der Filter
kontinuierlich Daten berechnet und verschickt. Im Rahmen des Projekts CAR war das aber nicht nötig.
Nach der Berechnung muss Calculate die Daten in strukturierte Events
verpacken und diese an die Sender weiterreichen. Dies könnte folgendermaßen aussehen:
Zusammenstellen des Headers des Events
sevnt.header.fixed\_header.event\_type.type\_name="TestTyp\";
sevnt.header.fixed\_header.event\_type.domain\_name = "Dwarf\";
std::string event\_name = \"Output\";
sevnt.header.fixed\_header.event\_name = CORBA::string\_dup(event\_name.c\_str());
sevnt.header.variable\_header.length(0);
"Ubergabe der Daten in den Eventbody
sevnt.remainder\_of\_body <<= data;
Verschicken des Events "uber Ability 0
SndList.getNode(0)->sendOutEvent(sevnt);
Zuerst werden Datentyp (z.B. PoseData ), Domänenname sowie der
Name der Ability in den festen Header des Events geschrieben und
noch die Länge des möglichen variablen Headers auf null gesetzt. Dann
wird die sendOutEvent Methode des ersten Abilityobjekts aufgerufen
und das Event verschickt. Dies kann jedoch nur so erfolgen, wenn sichergestellt ist ,dass das ausgewählte Abilityobjekt als erstes in der
Liste steht. Bei mehreren Abilities muss man eventuell die Liste durchgehen und über getName der Senderklasse den Namen überprüfen.
Auch eine festgelegte Reihenfolge der Abilitydefinitionen in der XML
Datei des Filters sagt nämlich noch nichts darüber aus in welcher Reihenfolge die Abilities beim Servicemanager angemeldet werden. Daher
bekommen Abilityobjekte auch nicht mit Sicherheit einen festen Platz
in der Senderliste.
• Configure()
Mit Hilfe von Configure kann die Funktion der Filter von außen
6 IMPLEMENTIERUNG
31
zur Laufzeit weitgehend angepasst werden. Diese Methode ist, genau
wie Calculate, virtuell und sollte in einem neuen Filter auch neu
implementiert werden. Sie wird immer dann von gotEvent aus aufgerufen, wenn ein Event zur Konfigurationsänderung des Filters ankommt. Wie auch bei Calculate bekommt Configure einen Zeiger auf
das Empfängerobjekt das das letzte Event empfangen hat. Configure
muss sich anschließend über diesen Zeiger das Event holen und auslesen. Die Daten des Events können nun z.B. dazu dienen Berechnungsfaktoren neu zu setzten. In Configure könnten aber auch neue Needs
oder Abilities abhängig vom jeweiligen Wert eines Konfigurationsneeds
erzeugt werden. Dies wird z.B. im Filter Parsephone benutzt.(Näheres
dazu im nächsten Abschnitt)
Hinweis: Da die grundsätzliche Struktur der Klasse Filter und damit der Filterservices allgemein erst im Laufe dieser Arbeit entwickelt wurde liegt bei älteren
Filtern zum Teil eine etwas andere Struktur vor. Insbesondere sind Benennungen
von Methoden und Variablen abweichend oder es gibt noch keine Configure Methode. Der grundsätzliche Aufbau ist aber jeweils ähnlich. Siehe hierzu auch
Kapitel 6.3 Evolution der Filter.
Implementierung Spezieller Filter (Parsephone /Interpolator) Da
wir nun die Implementierung der Klasse Filter behandelt haben werde ich kurz
auf den Aufbau einiger ausgewählter Filter eingehen. Besonders interessant als
konfigurierbare Filter sind hierbei Parsephone und Interpolator. Alle hier behandelten Filter sind abgeleitet von der Klasse Filter die oben besprochen wurde.
Interpolator:
Der Interpolatorfilter bildet die Eingangswerte gemäß einer durch diskrete
Werte gegebenen Funktion ab. Alle Zwischenwerte werden hierbei durch lineare Interpolation erzeugt. Dieser Filter verarbeitet Daten vom Typ InputDataAnalogUnlimited. Über das Need GraphValues kann man dem Filter
Daten vom Typ FilterConfig schicken. Dieser Datentyp besteht aus einem
Feld mit 100 Wertepaaren. Diese werden dann als Koordinaten der Stützstellen der Funktion betrachtet und müssen von der kleinsten x-Koordinate
an aufsteigend geordnet sein. In der Methode Configure werden diese
Werte ausgelesen. Zunächst wird der kleinste und größte x-Wert gespeichert. Nun wird einfach der durchschnittliche Abstand der Stützpunkte,
hier Schrittweite genannt, berechnet und davon ausgegangen, dass die Werte äquidistant waren. Wenn der eingegebene X-Wert kleiner als der Minimalwert oder größer als der Maximalwert der Stützwerte ist so gibt der
Filter den zugehörigen y-Wert des Minimal bzw Maximal X-Werts aus. Dazwischen wird nach folgenden Formeln interpoliert:
6 IMPLEMENTIERUNG
32
valuelow = f loor((Input − M inimumV alue)/Schrittweite)
(1)
out = y(valuelow ) + (Input/Schrittweite − valuelow ) ∗ (y(valuelow ) − y(valuelow + 1))
(2)
valuelow ist dabei der Index des Werts der als nächstes links neben dem
Eingabewert liegt. Die Funktion floor bedeutet Abrunden auf die nächste
ganze Zahl.
Abbildung 22: Interpolation zwischen den Stützwerten (Interpolator)
Parsephone:
Der Parsephonefilter bedient sich der Formelinterpreterklasse von Korbinian Schwinger. Diese Klasse wertet mathematische Formeln aus und gibt
dann deren Ergebnis zurück. Jedes Formelinterpreterobjekt kann dabei eine
Formel interpretieren. Standardmäßig wird nur ein Formelinterpreterobjekt
sowie ein zugehöriges Need FormulaInput0 erzeugt. An dieses schickt man
nun als String eine Formel. Der Formelinterpreter durchsucht diese dann
und ruft für jede Variable die er findet eine über einen Zeiger bereitgestellte Methode von Parsephone registerVars auf, um ein Need dafür zu
registrieren. Wenn alle Needs registriert sind wird der Zeiger neu auf die
Methode zum Auslesen der Empfangenen Variablenwerte getVarValues
gesetzt und der Filter ist fertig konfiguriert .
Es ist allerdings auch möglich gleich mehrere Parser in einem Parsephonefilter laufen zu lassen. Hierzu kann man über das Konfigurationsneed
NumberOfInterpreters einfach eine Zahl (≥1) einstellen und der Filter erzeugt automatisch neue Formelinterpreter und zugehörige Formeleingänge.
6 IMPLEMENTIERUNG
33
Abbildung 23: Klassendiagramm des Parsephonefilters
An diese können dann wieder Formeln geschickt und neue Variablenneeds
registriert werden.
Die folgende Tabelle liefert einen Überblick über alle Funktionen die im
Interpreter implementiert sind.
Null- und Einstellige Operatoren
Konstanten
alle reelen Zahlen
Variablen
alle Buchstabenkombinationen
ABS
Betrag
ACO
Arcuscosinus
ASI
Arcussinus
ATA
Arcustangens
COS
Cosinus
EXP
Exponentialfunktion ex
LGN
Logarithmus Naturalis
LOG
Logarithmus zur basis 10
NEG
Negation
SIN
Sinus
SQR
Wurzel
TAN
Tangens
Zweistellige Operatoren
ADD
Addition
SUB
Subtraktion
DIV
Division
MUL
Multiplikation
POW
xy
ROO
y-te Wurzel von x
Der Aufbau der Formeln in BNF-Notation:
Formel := Konstante | Variable | Einstelliger Operator ( Formel) | Zweistellig
6 IMPLEMENTIERUNG
Abbildung 24: Registrierung der Variablen einer Formel
Abbildung 25: Abfrage der Variablenwerte
34
6 IMPLEMENTIERUNG
35
Abbildung 26: Debugsausgaben Parsephone nach dem starten
Abbildung 27: Parsephone: Ansicht in
DIVE beim registrieren der Formel
ADD(x,y)
Abbildung 28: Parsephone: Ansicht in
DIVE nach dem registrieren der Formel
ADD(x,y)
Abbildung 29: Parsephone beim Addieren zweier Werte
6 IMPLEMENTIERUNG
36
Abbildung 30: DIVE-Bild eines von DIVE gestarteten CARmelion
6.2
Konfigurierbarkeit - CARMelion
Das CARmelion hat als primäre Aufgabe die im vorangegangenen Abschnitt
erläuterten Filterservices zu konfigurieren. Dieser Abschnitt geht genauer auf die
Implementierung des CARmelion ein. Im ersten Unterbaschnitt wird die Wahl
der Programmiersprache gerechtfärtigt. Der darauf folgende Unterabschnitt geht
näher auf das gewählte Klassendesign ein und spricht die wichtigsten Funktionen
kurz an.
6.2.1
Wahl der Programmiersprache
Zur Implementierung musste zunächst eine Entscheidung über die zur Verwundung kommende Programmiersprache getroffen werden. Mögliche Programmiersprachen, für die mit DWARF auch schon Services und Erfahrungen existieren
sind:
• C++: Die Objektorientierte Programmiersprache C++ kann sicher als
hoch performant eingeschätzt werden. Ihr primärer Verwendungszweck liegt
in statischen, echtzeitrelevanten Anwendungen. Der ORB16 für C++ ist,
16
Der Object Request Broker, kurz ORB, ist das zentrale Bindeglied eines CORBA-Systems.
Der ORB stellt Methoden zur Verfügung, mit welchen man sowohl auf lokale, wie auch auf im
CORBA-Netz verteilt Objekte zugreifen kann.
6 IMPLEMENTIERUNG
37
wegen der weiten Verbreitung von C++, einer der am besten beträuten.
• Java: Java ist, wie auch C++, objektorientiert. Mit den neu verfügbaren
Compilern ist ebenfalls das früher latent vorhandene Performanzproblem
beseitigt. Somit liegen seine vorwiegenden Einsatzgebiete, wie die von C++,
in statischen, echtzeitrelevanten Anwendungen.
• Python: Python ist eine Skriptsprache, in der objektorientierte Programmierung möglich, aber nicht zwingend notwendig, ist. Ein ORB ist vorhanden.
Die Implementierung des CARmelion erfolgte nach der Analyse aller zu Verfügung
stehenden Programmiersprachen in der Scriptsprache Python. Die Gründe für
diese Entscheidung sind wie folgt:
• Für den geforderte dynamischen Charakter des CARmelion ist es unbedingt
notwendig, Code dynamisch zu generieren und einzubinden. Dies ist ohne
Kompilierung nur bei Scriptsprachen möglich.
• Da das gesamte Projekt innerhalb und mit Hilfe des DWARF zu erstellen
ist muss in der Sprache der Wahl eine ausgereifte CORBA-Implementierung
vorhanden sein.
• Das CARmelion hat weder rechenintensive Aufgaben zu leisten, noch ist
die Konfiguration von Services, was ja seine Hauptaufgabe ist, Echtzeitrelevant. Somit ist Performanz der Programmiersprache ein untergeordnetes
Kriterium
6.2.2
Klassendesign
Im folgenden sollen die Klassen des CARmelion detailiert beschrieben werden. Die
Klassen des CARmelion sind:initcon, GUI, Manctxt, manctxtimpl, CARmelion,
EventSenderThread, EventSender, Configuration, graphenEditorUI und Painting.
Klasse initcon: initcon ist die initialisierende Klasse des CARmelion. Sie
übernimmt einen Großteil der Umsetzung des dynamischen Grundkonzeptes. Dazu erzeugt sie aus der vom service manager übergebenen service description
die notwendigen need und ability-Objekte. Ebenso wird hier eine CARmelion-,
sowie eine GUI-Instanz erzeugt, die von initcon Informationen über die vom CARmelion zu unterstützenden abilities erhält. Das generieren dieser Informationen bereitet unter Python wegen der unvollständigen CORBA-Implementierung
größeren Aufwand (Kapitel 7.2.2).
6 IMPLEMENTIERUNG
Abbildung 31: Einfaches CARmelion-GUI zur Bedienung von 3 abilities
38
6 IMPLEMENTIERUNG
39
Klasse GUI: Die GUI-Klasse implementiert die dynamische Generierung der
eigentlichen Oberfläche aus den bei der Initialisierung erhaltenen Daten, die auf
die jeweiligen, in der service description beschriebenen, Angaben beruht.
Die einzelnen Funktionen der Klasse generieren jeweils ein bestimmtes Element
des GUI, z.B. fügt addItem der zu generierenden Oberfläche ein neues Element
hinzu. Mit der Funktion Berechnen wird, nachdem alle zu generierenden Oberflächenelemente der GUI-Instanz übergeben wurden, die Position der einzelnen,
nun dynamisch angeordneten, Oberflächenelemente, berechnet. Mit der Funktion
makeguifile wird anschließend der eigentliche Qt-Python-Code erzeugt und in
der Datei newGUI.py gesichert.
Klasse Manctxt: Die Datei newGUI.py beinhaltet nun die Oberfläche des
Python-Programms, welche auf die mit der service description übergebenen
Anforderungen abgestimmt ist. Ebenso beinhaltet sie schon alle später notwendigen Oberflächenstandardfunktionalitäten und Verbindungen, um von mancontxtimpl
eingebunden zu werden.
Klasse manctxtimpl: mancontxtimpl wird von der Klasse Manctxt abgeleitet. Sie erweitert diese um die Funktionalitäten des Sendens von structured
events als kontinuierlicher und als diskreter Sender für jede ability des CARmelion und um das korrespondierende Oberflächenelemente. Auch die für das
Speichern und Laden von Konfigurationen notwendigen Funktionen, fileSave,
fileLoad und newFile sind hier implementiert. Sie greifen auf Funktionen der
Instanz von CARmelion zu.
Klasse CARmelion: Die von initcon erzeugte Instanz von CARmelion übernimmt die Hauptaufgaben des CARmelion zur Laufzeit. Beispielsweise implementiert sie die eigentliche Durchführung des Ladens und Speicherns von Konfigurationen, die von mancontxtimpl aufgerufen werden. Die Datensicherung erfolgt im
denkbar einfachen Format CSV17 im Verzeichnis des CARmelion. Dabei wird der
Name vom service manager in der service description übergebene Name
als Dateiname verwendet. Beim Zurückladen der Konfiguration wird, um Fehlern durch eventuelle veränderte service descriptions vorzubeugen, nur die in
Name und Art in der gespeicherten Datei und im laufenden CARmelion exakt
übereinstimmenden Werte geladen.
In CARmelion befinden sich des weiteren die Methoden addSender, welche ein
neues Senderobjekt instanziiert und im lokalen Datenfeld senderArray verwaltet.
Auch die Methoden zur Registrierung der needs und abilities sind hier zu finden. Dies sind Standardmethoden die in jedem Fall implementiert werden müssen.
17
CSV steht für Character Separated Value. CSV wird als Synonym für einfach Datenstrukturen bei der Speicherung verwendet, bei denen die einzelnen Werte durch ein vorher festgelegtes
Zeichen voneinander getrennt werden.
6 IMPLEMENTIERUNG
40
initcon
Configuration
parent
__init__
push_structured_event
*
EventSenderTread
service
i
*
delay
__init__
run
1
1
1
CARmelion
parent
SenderArray
StructArray
TypeArray
nEventData
data
event
cont
__init__
saveconfig
loadconfig
resetconfig
addSender
StartThread
stopallThread
startService
stopService
getStatus
getHeaderData
getStructData
makeSendEvent
1
theGUI
argc
myOrbConnec
tion
cmdLineProps
smgr
newstruct
NameStruct
StructList
abi
nee
sender
app
w
__init__
parseEvents
GUI
init
body
header
itemCounter
currentGroupX
currentGroupY
currentGroupWidth
maxHeightProSeite
Spaltenbreite
bisherigeGesHoehe
1 currentItemX
currentItemY
itemHoehe
itemLabel
row
elementPos
elementPostmp
__init__
addItem
Berechnen
makeGui
initend
makeguifile
*
EventSender
consumer
hasConsumer
parent
__init__
setConsumer
disconnect_structured_push_suplier
sendEvent
generisch
manctxtimpl
parent
__init__
continiousSender
eventSender
fileSave
fileOpen
fileNew
1
Manctxt
generisch
__init__
generisch
1
Painting
height
buffer
werte
__init__
1
initList
paintEvent
cleanIt
mouseMoveEvent
mousePressEvent
resizeEvent
Abbildung 32: Klassenhirarchie der CARmelion Implementierung
*
graphenEditorUI
outputList
gesLabel
painting
array
__init__
setSize
listToString
makeFormula
6 IMPLEMENTIERUNG
41
Abbildung 33: Konfigurieren eines Filters mit dem Grapheneditor
Zur Klasse der Standardmethoden zählt auch die Methode startservice, die von
anderen Services aufgerufen werden kann.
Die Methoden startThread und stopallThread die einen Senderthread instanziieren, starten und alle Senderthreads beenden können ist ebendfalls Bestandteil der Klasse codeCARmelion. Die eigentliche Steuerung, das ’start’ und
’stop’ wird über das Setzen von Flags gesteuert, die, je nachdem ob ein einzelnes Event oder ein kontinuierlicher Strom von Events gesendet werden oder das
Senden gestoppt werden soll gesetzt werden.
Die Hilfsmethoden getStructData und getHeaderData zur Übernahme der
in der grafischen Benutzeroberfläche eingestellten Werte sind hier zu finden.
Klasse EventSenderThread: Hier wird die Methode send event aus der Instanz der Klasse EventSender wiederholt gestartet solange die Flags entsprechend gesetzt sind. Die threadgestützte Implementierung dieser Funktion erlaubt
es, das CARmelion zu jedem Zeitpunkt bedienbar zu halten. Nur durch diese Art
der Implementierung ist die Bedienbarkeit der Oberfläche, welche das starten,
stoppen u.ä. für jedes mit einer ability korrelierende Bedienungsobjekt einzeln
möglich.
Klasse EventSender: Der EventSender ist die Implementierung des eigentlichen DWARF-spezifischen Output - Kommunikationsinterfaces. Hier sind die
vorgesehenen Standardmethoden zu finden.
6 IMPLEMENTIERUNG
42
Klasse Configuration: Mit der Klasse Configuration steht ein Input-Interface
zur Verfügung. In der Methode push structured event muss zu diesem Zwecke
lediglich noch entsprechende Funktionalität, beispielsweise zur Auswertung von
ankommenden Daten, eingefügt werden.
Klasse Painting: Um eine für den Benutzer intuitive Konfigurierbarkeit von
Filtern, dem Hauptzweck des CARmelion, zu garantieren, wurde die hier implementierte Oberfläche dem CARmelion hinzugefügt (Abbildung 33). Die Klasse
Painting ist für die Darstellung der Eingabe und deren Übersetzung in ein Datenfeld, welches die generierte Eingabe beschreibt, zuständig. Von ihr wird die
Klasse graphenEditorUI abgeleitet.
Klasse graphenEditorUI: Um die Benutzereingaben und die Umwandlung
der Daten, die in der Instanz der Klasse Painting generiert wurden kümmert
sich das graphenEditorUI. Hier werden aus den Rohdaten, durch Anpassen der
Grenzen an die Benutzereinstellungen, mit Hilfe der Methode makeFormula Konfigurationsdaten in der Form eines Datenfeldes erzeugt.
6 IMPLEMENTIERUNG
6.3
43
Evolution der Filter
Die Idee der Filterimplementierung war es, dass jeder einzelne Filter auf einem
gemeinsamen Modell, dem GenericFilter, basiert, welches die grundlegende Kommunikation zwischen den DWARF-Services regeln sollte. Die spezielleren Filter
sollten eigentlich nur noch eine einzige Methode der Basisklasse überschreiben,
was den Vorteil hat, dass eine Weiterentwicklung des GenericFilters nicht dazu
führen würde, dass alle Filter neu geschrieben werden mussten.
Die erste Idee zur Implementierung des GenericFilter war, ein eigenes Datenformat zu entwickeln, das eine beliebige Anzahl beliebiger Datentypen speichern
konnte und dann erst nach Empfang der Daten ausgewertet und für die im speziellen Filter zu überschreibende Methode aufbereiten werden sollte. Diese Idee
würde zwar zu einem sehr allgemeinen Filter führen, aber schnell wurde klar, dass
es keinen Sinn hatte, die Daten auf eine so abstrakte Weise zu speichern, wenn
es in den einzelnen speziellen Filtern dann sowieso klar war, welche Datentypen
empfangen bzw. auch gesendet werden mussten - außerdem wäre die Auswertung
der Daten sehr aufwendig geworden, was zu relativ langsamen Filtern geführt
hätte.
Da permanent neue spezielle Filter entwickelt werden sollten und auch der
GenericFilter währenddessen noch stark geändert wurde, mussten die Filter mit
der entsprechenden Version des GenericFilter zusammen gespeichert werden und
sind damit nicht repräsentativ für die Filter, die mit dem entgültigen GenericFilter entwickelt werden können.
Die erste Version des GenericFilters konnte nur mit PoseData umgehen, was
wiederum zu einer zu starken Einschränkung führte, aber für die ersten speziellen
Filter, die zu schreiben waren, völlig ausreichte.
Die zweite Version des GenericFilters arbeitete schon eher, wie sie sollte : alle
Needs wurden in eigenen Instanzen der Need-Klasse in einer Liste gespeichert. Um
die Bearbeitung der empfangenen Daten möglich zu machen, wurden auch eine
Kopie der empfangenen Datenpackete zwischengespeichert. Dies war nötig, da
der Datentyp der Eingangskanäle für die späteren Filter beliebig sein sollte, und
damit dem Filter zu diesem Zeitpunkt noch unbekannt sein konnte. Die eigentliche
Arbeit sollte in der zu überschreibenden Methode calculate() ausgeführt werden.
Der Programmierer sollte nur noch den Namen der Eingangskanäle überprüfen
und das dazugehörige Datenpacket entsprechend interpretieren.
Die weiteren Versionen des GenericFilters beinhalten kleinere Erweiterungen der zweiten. Anfangs wurde die Liste nicht durch eine ’mutual exclusion’
geschützt, was zu Speicherschutzverletzungen führte, dieser Fehler wurde in der
dritten Version behoben. Obwohl rein logisch in der dritten Version des GenericFilters keine Speicherschutzverletzungen mehr auftreten konnten, stürzte eine
Corba-Funktion in einem spezielllen Filter, dem MergeFilter mit eben dieser ab.
Dies lag an der Tatsache, dass ein wiederholtes entpacken eines StructuredEvents
dazu führte, dass ein interner Zeiger des Objekts auf einen falschen Speicherbe-
6 IMPLEMENTIERUNG
44
Abbildung 34: Endgültige Struktur des GenericFilters
reich wies - dies wurde behoben, indem dieser Fall einfach ausgeschlossen wurde.
Die letzte Änderung an dem Funktionsumfang des GenericFilters ergab sich
daraus, dass der Parsephone Filter seinen need zur Laufzeit ändern musste, der
GenericFilter musste also in der Lage sein, needs und abilities dynamisch hinzuzufügen bzw. auch wieder zu löschen.
Nachdem die Filter für ein Leistungsproblem verantwortlich gemacht wurden,
wurden noch mehrere kleinere Optimierungen zu Lasten der Einfachheit in der
Erstellung neuer Filter und zu Gunsten der Geschwindigkeit gemacht.
7 RÉSUMÉ
7
45
Résumé
7.1
Ergebnis
Als Ergebnis des Projektes CAR und damit auch des hier vorliegenden SEP’s lässt
sich eine Umgebung zur Entwicklung von einfachen AR-Szenarien vorstellen, die,
im Verhältnis zu ihrer einfachen Konfigurier- und Modifizierbarkeit sehr mächtig
ist. Beispiel für eine Anwendung dieser Umgebung ist das CAR-Szenario.
7.2
Probleme
Während der Entwicklung traten einige unerwartete Probleme auf. Unter anderem sind hier anzuführen:
• Probleme mit der Kalibrierung des ART-Tracking-Systems standen bei jedem Test auf der Tagesordnung. Ursache war jedoch meist nur der von den
Teilnehmern gescheute Zeitaufwand der neukalibrierung.
• Durch das Ausführen von zu vielen Services auf einem Rechner ging die
Echtzeitfähigkeit des Systems verloren
• Ein schwerwiegendes Problem war folgender bei größeren Filternetzwerken
sehr unangenehme Effekt: War ein Filternetzwerk aufgebaut und konfiguriert verschalteten die Services nach dem Neustarte eines einzelnen Filterservices häufig nicht mehr
7.2.1
Probleme speziell bei Filterservices
Bei der Integration stellte sich heraus, dass 2 der programmierten Filter falsche
Ergebnisse lieferten. Nach mehreren verschiedenen gescheiterten Ansätzen, diese
korrekt zu implementieren, stellte sich haraus, dass eine grundlegende mathematische Sammlung von Hilfsfunktionen der Quaternionenmathematik einen Fehler
aufwies. Nachdem niemand in der Lage war diesen Fehler während des Projekts
zu beheben, lief die Implementierung auf Ausprobieren und Raten heraus, und
kostete deswegen weit mehr Zeit, als dafür vorgesehen war.
7.2.2
Probleme speziell bei CARmelion
Während der Implementierungsphase des CARmelion erfuhren wir Schwierigkeiten im Zusammenhang mit der dynamischen Erzeugung von Code. Als Lösung
wurde der Weg über die Generierung einer, zur Laufzeit festen, Datei zur Beschreibung des GUI und seiner Funktionalität gewählt.
Ein weiteres Problem hatte die nicht voll funktionsfähige CORBA-Portierung
unter Python zur Ursache: Durch das Fehlen eines Interface-Repository entstand
7 RÉSUMÉ
46
erheblicher Mehraufwand. Alternativer Weg war es, die fertige Beschreibung einer bereits instanziierten Datenstruktur mit der dir() - Funktion18 des PythonInterpreters zu analysieren. Dadurch erhalten wir ein Datenfeld, welches in verschlüsselter Form die Datenstruktur beschreibt.
7.3
Future Work
Ein so weitläufig und flexibel angelegtes Projekt ist natürlich niemals wirklich
abgeschlossen. Es wird stets den Bedarf an neuen Anpassungen und Weiterentwicklungen geben. In diesem Kapitel nun sollen mögliche Ansatzpunkte für die
zukünftige Arbeit mit den Ergebnissen dieses Systementwicklungsprojektes gegeben werden.
• Im Bereich der Filterservices, die für möglichst einfache Implementierung
von neuen Services gestaltet wurden kann ein weiterer Schritt in Richtung
Benutserfreundlichkeit getan werden, indem man versucht einen ähnlichen
Weg der GUI-gestützten Codegenerierung zu beschreiten, wie sie in [?]
gewählt wurde.
• Natürlich wird es stets den Bedarf für neue Filterservices mit neuen Funktionen geben. Somit wird es stets notwendig sein neue Funktionalitäten in
die Filter zu integrieren.
• Das CARmelion könnte als Fortführung der bestehenden Implementierung
noch mit einer Auswertungsfunktion für empfangene Daten ausgestattet
werden.
• Stets sollte an der Steigerung der Performanz des generischen Filtermodells
gearbeitet werden.
• Die Funktionalität der Positionsdatenaufzeichnung könnte, in verallgemeinerter Form, als Zusatzfunktion in das CARmelion integriert werden.
18
Die Funktion dir() des Pythoninterpreters gibt die in einem Modul definierten Namen als
geordnete Liste von Strings zurück. Dazu zählen Module, Funktionen, Variablen u.s.w..
A SPINOF - ENTWICKLUNGEN
47
Abbildung 35: Prinzip räumlicher Klangdarstellung mit 2 Lautsprechern
A
A.1
Spinof - Entwicklungen
3D Audio
Um im Simulator Klänge in 3 Dimensionen wiedergeben zu können wurde der
3DAudioService entwickelt. Der angedachte Einsatzzweck für diesen war eine
Wiedergabe von Warnsignalen im Simulator, wenn das Fahrzeug sich in der Situation des Einparkens einem Hindernis zu stark annähert. Hierbei war wichtig, dass
für die Testpersonen erkennbar ist, dass der Ton aus der Richtung des Hindernisses zu kommen scheint, und mit sinkender Entfernung lauter wird. Ursprünglich
sollte diese Aufgabe von dem bereits vorhandenen Viewer erledigt werden, der
auf Coin3D basiert, welches diese Funktionalität bereits bietet. Allerdings erwies
sich die Implementierung unter Linux als nicht funktionsfähig, darauf weisen aber
auch die Entwickler hin, die sie, zumindest unter Linux, noch als sehr experimentell bezeichnen. Deswegen war eigentlich nicht zu erwarten, daß sie problemlos
laufen würde.
Um eine Klangquelle im 3 dimensionalen Raum zu platzieren, gibt es verschiedene Ansätze. Einer der prinzipiell einfachsten ist es, den Hörer von allen
Seiten mit Lautsprechern einzuschließen, und die Position des Tons dadurch zu
beeinflussen, dass die jeweils zur Klangquelle nächsten Lautsprecher - je nach Entfernung zur Klangquelle - den Ton mehr oder weniger laut abspielen. Dieses Verfahren kann durch verschiedene Techniken noch weiter verbessert werden, so dass
48
Abbildung 36: Prinzip räumlicher Klangdarstellung mit 4 Lautsprechern (quadrophonisch)
ein noch akkuraterer Klangeindruck entsteht. Aus Mangel an dazu fähigen Treibern unter Linux, blieb es bei erstgenannten Modell. Im Prinzip ist es technisch
möglich, auch nur mit 2 Audiokanälen einen 3 dimensionalen Klang zu erzeugen,
was an der Tatsache liegt, dass der Mensch nur 2 Ohren besitzt, was bereits die
Firma Aureal, die für die Nasa Audiochips für Shuttlesimulatoren herstellte, ausnutzte, allerdings ist dazu ein entsprechender Treibermodus notwendig, der unter
Linux nicht vorhanden war. Bei dieser Technik ist es notwendig, zu wissen, wo
sich der Hörer relativ zu den Lautsprechern befindet, damit die beiden Kanäle
entsprechend beeinflusst werden können. Da der dreidimensionale Höreindruck
aber nicht angeboren, sondern erst erlernt wird, stellt er eine extrem individuelle
Sache dar. Es ist z.B. möglich, dass eine Person bei diesem Ansatz den Klang
tatsächlich sehr gut im Raum erkennen kann, wobei einer zweiten Testperson
jegliche räumliche Tiefe bei ihrem Klangeindruck fehlt. Dies ist auch der Grund,
warum sich die einfache Methode mehrerer Lautsprecher durchgesetzt hat, da
hierbei der Raumklang sehr viel näher an der tatsächlichen Situation simuliert
werden kann.
Für den 3DAudioService wurde die API OpenAL verwendet, die entwickelt
wurde, um eine platformunabhängige Unterstützung von Soundkarten zu bieten, was auch den Namen erklärt, der nicht ohne Grund an OpenGL erinnert.
Im Gegensatz zu anderen APIs wie DirectSound, Aureal3D und der WaveOut-
49
API unter Windows oder auch ALSA oder das OSS unter Linux handelt es sich
nicht um eine Schnittstelle, die tatsächlich direkt auf die vorhandene Hardware
zugreift, sondern um ein Programm, das auf die bereits im System vorhandenen
Schnittstellen benutzt. Dies hat den Vorteil, dass viele Eigenheiten der APIs nicht
durch die Vereinheitlichung verloren gehen, da man im Grunde auch nach dem
Prinzip des kleinsten gemeinsamen Nenners hätte vorgehen können. Programme
dieser Funktionalität werden im allgemeinen auch als Wrapper bezeichner, da sie
tatsächlich nur eine einheitliche Kommunikationsebene zu den im System vorhandenen Schnittstellen bieten und Funktionsaufrufe nur umleiten. Dies hat den
kleinen Nachteil, dass durch dieses Umleiten Systemleistung verloren geht, die
man als quasi ungenutzt bezeichnen kann, da nur dem Programmierer und nicht
dem Endanwender Vorteile entstehen.
Bei dem Test des 3DAudioService unter Linux stellte sich heraus, dass der
Treiber der im Versuchsaufbau verwendeten 3D Soundkarte entgegen der Freigabe von SuSe und auch dem Controlpanel des Treibers noch keine Wiedergabe
von Klängen über mehr als 2 Kanäle beherrschte. Zwar wurden alle 4 Kanäle
angesprochen, wobei allerdings das hintere Boxenpaar das Signal der vorderen
Lautsprecher abspielte. Das Resultat war, dass es logischerweise sehr einfach entschieden werden konnte, ob sich ein Ton links oder rechts vom Hörer befindet,
allerdings nicht, ob er sich hinten oder vorne befand.
A.1.1
Future Work
Sobald der neue Treiber für die 3DSoundkarte entwickelt wurde, der auch quadrophonische Audioausgabe beherrscht, ist auch der 3DAudiosevice voll funktionsfähig. Wenn sich dieses Problem nicht sowieso mit einer neueren Version von
SuSe Linux erledigt, muss der Treiber für den CMI8738 Chipsatz installiert werden. Hierbei ist zu beachten, dass bereits der jetzige Treiber von SuSe als voll
funktionsfähig deklariert ist. Dieses Trugbild wird noch durch eine entsprechende
Option im Control-Panel unterstrichen, diese ließ sich aber nicht aktivieren.
A.2
PoseRecorder
Der PoseRecorder wurde als SpinnOff für allgemeine Anwendungen in CAR
und DWARF entwickelt. Er ist Rekorder und zugleich Sender, steuerbar über
eine einfache Tk-GUI. Er hat einen PoseData-Eingang der über DIVE mit der
aufzunehmenden Komponente verschaltet werden muss. Aufgenommen werden
kann immer nur ein Datenfluß je Rekorder. Ist die Aufnahme über den StartRecord Button begonnen, so wird jedes Event in CSV Form in eine temporäre
Datei geschrieben. Wird die Aufnahme beendet muss noch ein Speicherort für
die endgültige Datei angegeben werden, welche einen beliebigen Namen tragen
kann.
50
Aufgrund der einfachen Struktur der Aufgezeichneten Daten ist eine beliebige
Auswertung auf Basis dieser Daten sehr einfach und wurde auch im Laufe des
Projektes CAR bereits durchgeführt.
Um eine Aufnahme abzuspielen muss zuerst eine entsprechende Datei ausgewählt und geöffnet werden. Beginnt man mit dem Playback wird ein Playerthread
gestartet, welcher die Datei im rekursiven Loop abspielt. Zwar ist bekannt, dass
einmal ein mögliches Threadproblem aufgetreten ist, jedoch konnte dies nicht reproduziert werden und ist wahrscheinlich nicht auf diese Implementation zurückzuführen. Das Playback kann jederzeit beendet werden.
Ein weiterer Vorteil der einfachen Datenstruktur ist es, dass auch die Positionsdateien einfach maschinell erzeugt werden können. Dies ist ein großer Vorteil
für Viewer- oder sonstige Benchmarktests, da die Daten so mit gleichmäßiger
Frequenz und Änderung gesendet werden können.
Auch zur Erzeugung schöner Datensimulationen als Brücke zur VR oder bei
der Sendung vorher festgelegter Daten zu Forführzwecken ist dieser Service wegen
seiner einfachen Verwendbarkeit die Methode der Wahl.
Die Struktur des PoseRecorders laesst sich wie folgt darstellen:
Pose2Pose
need
ability
nPose
aPose
Bar
__init__
IncrememtProgress
playfile
testopen
startService
stopService
getStatus
handleEvent
startrecord
stoprecord
saveAs
51
Pose2PoseObject
parent
1
counte
__init__
push_structured_event
1
Pose2PosePose
count
fh
usrEventtype
parent
consumer
hasconsumer
playthread
__init__
setopenfilename
setConsumer
disconnect_structured_push_supplier
playfile
sendEvent
1
ProgressBar
Height
Width
BarCanvas
__init__
SetProgressPercent
DrawProgress
GetProgressPercent
1
PlayerThread
service
consumer
Threadrun
__init__
run
process
Abbildung 37: Klassenhierarchie der PoseRecorder-Imlementierung
A.3
52
TUI
Während des Implementierungsprozesses wurde uns
klar, dass Tangible User Interfaces nicht nur sehr wünschenswert für eine Entwicklung im
Bereich der augmentierten Realität sind, sondern mit den
von uns realisierten Applikationen auch ohne weiteres generiert werden kann. Als kleine Demonstration banden wir
in die CAR-Applikation ein
tangibles Objekt zur Steuerung einer Übersichtsichtskarte ein.
Durch die Mächtigkeit der Abbildung 38: Beispiel einer TUI-Anwendung
Funktionalität und Konfigurierbarkeit des Projektes ist es jedoch möglich auch wesentlich kompliziertere
Zusammenhänge zwischen tangiblen Objekten und Reaktion der AR-Umgebung
herzustellen.
B VERWENDETE/NOTWENDIGE HARDWARE
B
53
Verwendete/Notwendige Hardware
Um die ganze Mächtigkeit des vorgestellten Projektes erkennen zu können ist es
leider notwendig einiges an, teilweise sehr teuerer, Hardware einzusetzen. Diese
Hardware soll hier in aller Kürze vorgestellt werden.
• 2 Laptops: Die Laptops werden nicht direkt für in diesem Projekt eingeführten Applikationen benötigt. Sie sind für das automatische Labeling
(in seiner Implementation für DWARF, welche in [?] eingeführt wird) und
das Central Information Display und seine Ansteuerung mit dem Attentiv
User Interface, welches von Vinko Novak in [?] eingeführt wurde, nötig.
• 2 Beamer: Die Beamer werden für die ’basic Visualisation’, die grundlegenden Visualisierungen, benötigt. Diese wird genauer im Kapitel ’Laboraufbau’ beschrieben.
• 4 PCs (x86): Die Rechner werden für verschiedene DWARF-Services benutzt
• 1 Apple Macintosh dualG4 mit 3D Grafikkarte: Er wird zur Ansteuerung
eines der Beamer benötigt(Abbildung 39).
• 3 ART-Kameras: Das Trackingsystem ist von Wichtigkeit für jedes Detail
der CAR-Applikation. Es versorgt uns mit Positions- und Orientierungsdaten(Abbildung 40).
• 1 Apple Cinema-Display: Das Cinema-Display wird zur Simulation des
HUD(Siehe Kapitel Laboraufbau) benötigt(Abbildung 41).
• 3D Soundkarte Terratec Aureon Fun 5.1: Sie ist Ausstattungsteil eines der
x86-PC’s und für den 3D-Audio-Service von Nöten(Abbildung 42).
• 1 Dolby 5.1 System Terratec Home Arena 5.1: Das Lautsprechersystem ist
ebenfalls für die Anwendung des 3D-Audio-Services nötig(Abbildung 43).
Abbildung 39: Apple Macintosh G4 dual
Abbildung 40: ART Kamera
54
Abbildung 41: Apple Cinema-Display
Abbildung 42: 3D Soundkarte Terratec Aureon Fun 5.1
55
56
Abbildung 43: Dolby 5.1 System Terratec Home Arena 5.1
B.1
Laboraufbau
Der Laboraufbau für das Projekt CAR ist, wie zu Anfang dieses Dokumentes
kurz beschrieben, zweigeteilt. Zum einen wäre da die Simulation der Fahrzeugumgebung zu nennen, welche in Abbildung 45 betrachtet werden kann.
Sie wird erstellt durch die
Projektion eines 3D-Modells
der Umgebung auf einen Tisch.
Auf dem Tisch wird ein Automodell als tangibles Eingabeinstrument zur Generierung von Situationen, auf die
die Simulation des Fahrzeuginneren reagieren soll, benutzt.
Das Innere des Fahrzeuges wird minimalistisch dargestellt. Nämlich ausschließlich durch die Erweiterungen,
Abbildung 44: Die ’Basic Visualisation’
die im Fahrzeug durch Augmentierungen unter anderem im HUD19 , hervorgerufen werden. Diese Beschränkung
19
Ein Head Up Display oder HUD ist eine halbdurchlässig spiegelnde Oberfläche, auf die
Informationen projeziert werden können. Die projezierten Informationen werden als Effekt der
gespiegelten Fokussierung des zur Projektion verwendeten Gerätes nicht in der Ebene der halb-
57
erlegten wir uns auf, da die Zielsetzung für die Applikation CAR nicht eine exakte
Simulation eines Fahrzeuges, sondern nur eine Simulation der mit Augmentierungen erweiterbaren Anzeigeelemente ist.
In der nebenstehenden Abbildung ist die Umgebung für
das tangible Objekt, welches
das Auto symbolisiert zu erkennen. Des weiteren ist zu
sehen das, durch ein Apple
Studio-Display dargestellte,
HUD und die, durch eine Projektion an die Wand dargestellte, Umgebung des Autos.
Das Zusammenspiel der
Komponenten, also des tangiblen Interfaces und der verAbbildung 45: Das tangible Auto-Objekt
schiedenen Visualisierungskomponenten wird erst ermöglicht durch den Einsatz von Trackingtechnologien. In
unserem Fall gehört ein Trackingsystem der Firma ART zu unserem Laboraufbau,
welches im vorangegangenen Kapitel genauer beschrieben wurde.
durchlässig spiegelnden Oberfläche wahrgenommen, sondern dahinter.
LITERATUR
58
Literatur
[1] R. Azuma. A survey of augmented reality, 1995.
[2] Martin Bauer, Bernd Bruegge, Gudrun Klinker, Asa MacWilliams, Thomas
Reicher, Stefan Riss, Christian Sandor, and Martin Wagner. Design of a
componentbased augmented reality framework. In Proceedings of The Second IEEE and ACM International Symposium onAugmented Reality (ISAR
2001), 2001.
[3] Allen Bierbaum. Vr juggler: A virtual platform for virtual reality application
development. Master’s thesis, Iowa State University, 2000.
[4] Bernd Bruegge and Allen H. Dutoit. Object-Oriented Software Engineering
Using UML, Patterns, and Java. Prentice Hall, Englewood Cliffs, NJ, second
edition, September 2003.
[5] Gerhard Reitmayr Dieter. A platform for location based augmented reality
applications, 2002.
[6] Markus Geipel. Run-time development and configuration of dynamic service
networks, 2004.
[7] Otmar Hilliges. A control component for adaptive augmented reality user
interfaces, 2004.
[8] Poupyrev I. and Billinghurst. Go-go interaction technique: Non-linear mapping for direct manipulation in vr. In Proceedings of UIST’96, pages 79–80,
1996.
[9] Christian Kulas. Usability engineering for ubiquitous computing, 2003.
[10] Steven Dow Maribeth Gandy and Blair MacIntyre. Prototyping applications
with tangible user interfaces in dart,the designer’s augmented reality toolkit.,
2004.
[11] Friedemann Mattern. www.smart-environment.de, März 2004.
[12] Vinko Novak. Attentive user interfaces for dwarf, 2004.
[13] Alex Olwal. Unita modular framework for interaction technique design, development and implementation. Master’s thesis, Royal Institute of Technology
(KTH), Stockholm, Sweden, Mai 2002.
[14] Gerhard Reitmayr and Dieter Schmalstieg. Opentracker-an open software
architecture for reconfigurable tracking based on XML. In VR, pages 285–
286, 2001.
LITERATUR
59
[15] Lothar Richter. Design and practical giudeline to a corba-based communication framework, Aug 2002.
[16] Fabian Sturm. Issues in view management for 3d objects on multiple displays, 2004.
[17] Brygg Ullmer and Hiroshi Ishii. The metadesk: Models and prototypes for
tangible user interfaces. In ACM Symposium on User Interface Software and
Technology, pages 223–232, 1997.
[18] unbekannter Author. CORBA, from wikipedia, the free encyclopedia, März
2004.
[19] unbekannter Author. Echtzeit, from wikipedia, the free encyclopedia, März
2004.
[20] unbekannter Author. GUI, from wikipedia, the free encyclopedia, März 2004.
[21] unbekannter Author. Opensource, from wikipedia, the free encyclopedia,
März 2004.
[22] unbekannter Author. Rapid Prototyping, from wikipedia, the free encyclopedia, März 2004.
[23] unbekannter Author. Virtuelle Realität, from wikipedia, the free encyclopedia, März 2004.

Entwicklung eines dynamisch über Tools modifizierbaren

Transcrição

Documentos relacionados

"Der Filter des Heiligen Geistes" oder

unser faszinierender betrieb altesse der region fürstenfeld

Wasserfilter WAF 01 ohne Druckminderer, rückspülbar

DP3-PBLPCBPFEX 10µm Eisenwasserfilter

788 ECK-VENTIL mit integriertem Filter

Frage: Wenn ich meinen Aussenfilter reinige, (Eheim Classic 2211

nik multimedia, Inc. | Color Efex Pro http://www.nikmultimedia.com

acuraLine® - Fuhr GmbH

Übersicht Wasserfilter

Faserband, Garne und Zwirne können als