Embed Size (px)
Citation preview
Einbinden von Eingabegeräten zur Manipulation visualisierter 2D- und 3D- Daten, sowie die Integration
von Funktionen zum Austausch der Daten, in das OfuturO- Projekt
Von
Lino Sanfilippo
Zur Erlangung des akademischen Grades Diplom-Informatiker (FH)
Fachhochschule Köln University of Applied Sciences Cologne
Abteilung Gummersbach
Erstprüfer: Prof. Dr. Horst Stenzel Zweitprüfer: Dr. Gernot Goebbels
Oktober 2003
2
Einführung Der praktische Teil dieser Diplomarbeit besteht in der Verwirklichung der
Eingabeverarbeitung innerhalb der OfuturO-Umgebung. OfuturO stellt eine
Realisierung des Office Of The Future-Konzeptes dar, bei der eine
herkömmliche Büroumgebung mit virtuellen Komponenten angereichert wird.
OfuturO ist somit ein Projekt aus dem Bereich der Mixed Reality.
Das Ziel von OfuturO besteht darin, eine tischbasierte, multimediale
Arbeitsumgebung zur Verfügung zu stellen, die als Plattform für verschiedene
Konferenzszenarien dienen kann. Erreicht wird dies, indem während einer
Konferenz virtuelle Komponenten in die Arbeitsumgebung integriert werden.
Diese Komponenten werden mittels eines Visualisierungsservers verwaltet und
können sowohl in zweidimensionaler, als auch in dreidimensionaler Form
dargestellt werden. Zur Darstellung beider Formen kommt ein Projektionssystem
zum Einsatz, das in den Arbeitstisch der OfuturO-Plattform integriert ist.
Um die Projektionsfläche herum sind die Teilnehmer der Konferenz angeordnet.
Die Teilnehmer schließen sich mit ihren Laptops, auf denen sie die in der
Konferenz zu behandelnden Daten mitbringen, an das OfuturO-Netzwerk an.
Über eine grafische Oberfläche haben sie die Möglichkeit, eigene Daten zu
visualisieren. Durch spezielle Eingabegeräte, können sie die dargestellten
Objekte manipulieren, indem sie diese in verschiedene Richtungen bewegen und,
soweit es sich um räumlich dargestellte Daten handelt, um ihre Raumachsen
drehen können. Die visualisierten Daten befinden sich dabei in einem als Shared
Workspace bezeichneten Arbeitsbereich auf dem Visualisierungsserver.
Da sowohl zwei- als auch dreidimensionale Daten über die Eingabegeräte
manipuliert werden sollen, kommen zwei verschiedene Arten von Eingabegeräte
zum Einsatz, die so genannte Spacemaus und ein herkömmliches Touchpad.
Jeder Teilnehmer hat dabei die Kontrolle über ein solches Gerätepaar. Eine
Spacemaus ist ein speziell zur Eingabeverarbeitung im Raum entwickeltes
Eingabegerät, während ein Touchpad zur Eingabeverarbeitung in der Ebene
3
eingesetzt wird. Spacemaus und Touchpad werden in Kapitel 4 ausführlich
vorgestellt.
Neben der Möglichkeit die visualisierten Daten über die Eingabegeräte zu
steuern, können die Teilnehmer die Daten auch über Gesten, die auf dem
Touchpad ausgeführt werden, an anderen Konferenzteilnehmer verschicken.
Die Aufgabestellung, die in dieser Diplomarbeit gelöst werden soll, lässt sich in
drei Teilaufgaben unterteilen.
1. Teilaufgabe:
Einbinden von Spacemaus und Touchpad zur Interaktion des Benutzers mit
visualisierten 2D- und 3D-Daten sowie Fokussierung der
Eingabemöglichkeit und Wechsel des Eingabefokus’.
Um den Benutzern die Möglichkeit zu geben mit den vom Visualisierungsserver
dargestellten zweidimensionalen und dreidimensionalen Grafiken interagieren
bzw. diese manipulieren zu können, müssen die Eingabegeräte, die allesamt am
Visualisierungsserver angeschlossen werden sollen, softwaremäßig in die
OfuturO-Umgebung integriert werden. Insgesamt handelt es sich dabei um sechs
Geräte (je drei Spacemäuse und drei Touchpads), die über zwei 4-Port-USB-
Hubs am USB-Port des Servers angeschlossen werden.
Eingaben dürfen nicht von mehreren Benutzern gleichzeitig gemacht werden,
sondern sind zu einer Zeit nur einem bestimmten Benutzer erlaubt. Die
Eingabeverarbeitung erfolgt also über einen Eingabefokus. Der Fokus wird
immer nur einem Konferenzteilnehmer zugewiesen und berechtigt diesen zur
Steuerung der visualisierten Daten über Touchpad und Spacemaus. Durch einen
Wechsel des Fokus’ wird die Steuerberechtigung auf einen anderen
Konferenzteilnehmer übertragen. Dies macht Sinn, da die Perspektive für die
räumlich dargestellten Objekte auch immer nur für einen Konferenzteilnehmer
zu einem Zeitpunkt korrekt dargestellt werden kann. Die perspektivisch richtige
Betrachtung 3-dimensionaler Objekte erfolgt also ebenfalls über einen Fokus,
den Sichtfokus. Geplant ist, Eingabe- und Sichtfokus später einmal so zu
synchronisieren, dass derjenige Konferenzteilnehmer, der den Sichtfokus besitzt,
4
auch automatisch den Eingabefokus besitzt. Dazu muss auch die Möglichkeit
bestehen, den Eingabefokus an einen anderen Konferenzteilnehmer
weiterzugeben. Eine Übergabe muss dabei explizit (durch eine Geste,
Buttondruck etc.) von demjenigen Teilnehmer erfolgen, der momentan die
Eingabeberechtigung hat.
2. Teilaufgabe:
Implementieren von Funktionen zur Übertragung von Dateien die sich im
Shared Workspace befinden, an die am OfuturO-Netzwerk angeschlossenen
Workstations über eine geeignete Geste auf dem Touchpad.
Die OfuturO-Umgebung soll den Teilnehmern einer Konferenz außer der
Möglichkeit eine Reihe von Aktionen über die GUI der Workstationsoftware
durchführen zu können, auch die Möglichkeit bieten, bestimmte Aktionen über
Gesten auf den Touchpads auszuführen. Unter einer Geste wird eine nonverbale
Ausdrucksform verstanden, mit der eine bestimmte Absicht angedeutet wird.
Da die Touchpads in erster Linie zum Steuern von visualisierten Dokumenten
auf der Projektionsfläche eingesetzt werden, sollen sich die mit der
Gestenerkennung verbundenen Aktionen auch lediglich auf Datensätze
beschränken, die sich im Shared Workspace befinden. Dazu sollen exemplarisch
verschiedene Gesten und die damit verbundenen Aktionen implementiert
werden. Die Gesten, die letztendlich in OfuturO eingesetzt werden, hängen von
der jeweiligen Zielsetzung ab, die durch den Einsatz der OfuturO-Plattform
erreicht werden soll.
Aktionen, die über Gesten auf den Touchpads ausgeführt werden sollen sind:
1. Das Versenden von Datensätzen im Shared Workspace an den rechten
Sitznachbarn1.
1 Da die Konferenzteilnehmer am OfuturO Tisch nicht kreisförmig sondern hufeisenförmig angeordnet sind, hat genau genommen nur der mittlere Teilnehmer einen rechten und einen linken Nachbarn. Für die Funktion des Dokumentenversendens wird allerdings darüber hinweggesehen und eine kreisförmig Anordnung der Konferenzteilnehmer angenommen.
5
2. Das Versenden von Datensätzen im Shared Workspace an den linken
Sitznachbarn.
3. Das Versenden von Daten im Shared Workspace an alle Konferenz-
teilnehmer.
3. Teilaufgabe:
Implementieren einer Beispielapplikation an der die Funktionalität der
Lösungen zu den obigen Aufgaben demonstriert wird.
Da die OfuturO Softwareumgebung mit ihren Schnittstellen, die
Voraussetzungen für die Lösungen der Aufgaben dieser Diplomarbeit darstellen,
bis zum Fertigstellen der Diplomarbeit voraussichtlich noch nicht voll
einsatzbereit sein wird, soll die Funktionalität der gefundenen Lösungen an einer
Beispielapplikation gezeigt werden. Die Beispielapplikation soll dabei die
Funktionalität der noch nicht implementierten Softwarekomponenten der
OfuturO-Umgebung simulieren.
Ein Problem, das bei der Realisierung der Teilaufgaben gelöst werden muss,
besteht darin, dass die Eingabegeräte allesamt am Visualisierungsserver und
nicht an den einzelnen Workstations der Konferenzteilnehmer angeschlossen
sind. Die Eingabegeräte sind fester Bestandteil von OfuturO, während die
Workstations beliebig an- und abgeschlossen werden können. Dadurch muss
eine Möglichkeit gefunden werden, die Geräte den gerade vorhandenen
Workstations zuzuordnen.
Im folgenden Kapitel wird zunächst ein Überblick über das Gebiet der Mixed
Reality und ihrer Beziehung zur Virtual Reality gegeben. Dabei werden sowohl
die Hardwarekomponenten, die in der Mixed Reality zum Einsatz kommen, als
auch Interaktionsmöglichkeiten, mit den virtuell dargestellten Objekten,
beschrieben. Zum Schluss werden einige Anwendungsgebiete vorgestellt, in
denen Projekte der Mixed Reality heute schon erfolgreich angewandt werden.
6
Dazu gehören auch das Office Of The Future Konzept, und das OfuturO-Projekt,
als mögliche Realisierung dieses Konzeptes. Sowohl Office Of The Future, als
auch OfuturO, werden in den darauf folgenden Kapiteln vorgestellt. Nachdem
die theoretischen Grundlagen zum Verständnis der in dieser Diplomarbeit
behandelten Problematik erarbeitet wurden, erfolgt eine genaue Analyse der
Problemstellung, mit ersten Lösungsansätzen. Die zu den einzelnen
Teilaufgaben gefundenen Lösungen, werden jeweils anschließend vorgestellt.
Zum Schluss dieser Ausarbeitung wird schließlich ein kritischer Blick auf die
Ergebnisse geworfen, um zu ermitteln, inwieweit die Lösungen den gestellten
Anforderungen gerecht werden.
7
Inhaltverzeichnis
Abbildungsverzeichnis........................................................................................ 9
1 Virtual Reality ................................................................................................ 10
1.1 Einführung................................................................................................. 10
1.2 Arten von Virtual Reality Systemen ......................................................... 14
1.2.1 Immersive Reality .............................................................................. 14
1.2.2 Mixed Reality..................................................................................... 15
1.3 Hardwarekomponenten eines Mixed Reality Systems............................. 16
1.3.1 Stereoprojektoren und Projektionsflächen ........................................ 17
1.3.2 Tracker .............................................................................................. 18
1.3.3 Shutterbrillen und Polarisationsbrillen.............................................. 18
1.3.4 Eingabegeräte eines Mixed Reality Systems .................................... 19
1.4 Interaktion in der Mixed Reality ............................................................... 20
1.5 Anwendungsgebiete von Mixed Reality Systemen................................... 22
2 Office Of The Future...................................................................................... 24
2.1 Motivation ................................................................................................. 24
2.2 Virtuelle Hilfsmittel .................................................................................. 25
2.2.1 Definition ........................................................................................... 25
2.2.2 Arten................................................................................................... 25
2.2.3 Integrationsmethoden......................................................................... 26
2.3 Projekte...................................................................................................... 28
2.3.1 Roomware for Cooperative Buildings................................................ 28
2.3.2 The Office of the Future..................................................................... 30
3 Die OfuturO Plattform .................................................................................. 32
3.1 Vorstellung ................................................................................................ 32
3.2 Aufbau....................................................................................................... 33
3.2.1 Tisch ................................................................................................... 34
3.2.2 Display ............................................................................................... 35
3.2.3 Eingabegeräte ..................................................................................... 37
3.3 Software .................................................................................................... 38
3.4 Anwendungen............................................................................................ 40
8
3.5 Der Mixed Reality Conferencing Prototyp ............................................... 41
3.5.1 Beschreibung eines Konferenzszenarios........................................... 45
3.5.2 Entwicklungsstand ............................................................................. 49
4 Die Eingabegeräte.......................................................................................... 50
4.1 Grundlagen ............................................................................................... 50
4.2 Vorgaben ................................................................................................... 53
4.2.1 Das Cirque USB Easy Cat Touchpad................................................. 54
4.2.2 Die Magellan Spacemaus Plus........................................................... 56
5 Die Integration der Eingabegeräte in OfuturO........................................... 61
5.1 Analyse der Problemstellung .................................................................... 61
5.2 Der SMTP-Treiber als Realisierung der Lösung...................................... 63
5.3 USB-Kerneltreiber unter Linux................................................................. 65
5.4 Die SMTP-Treiberroutinen........................................................................ 67
5.4.1 Die Moduleeinsprungspunkte ModulInit und ModulExit................... 67
5.4.2 Die USB-Gerätespezifischen Operationen......................................... 69
5.4.3 Die File-Operationen.......................................................................... 72
5.5 Probleme bei der Implementierung.......................................................... 77
6 Das Versenden visualisierter Daten durch Gesten..................................... 84
6.1 Analyse der Aufgabenstellung zur Gestenerkennung .............................. 84
6.2 Realisierung der Gestenerkennung............................................................ 88
6.3 Analyse der Aufgabenstellung zur Zuordnung von Eingabegeräten zu
Workstations.................................................................................................... 93
6.4 Realisierung der Zuordnung von Eingabegeräten zu Workstations.......... 95
6.5 Die Klassen fpTouchpadNode und fpSpacemouseNode............................ 96
7 Ergebnis......................................................................................................... 100
7.1 Die Beispielapplikation zur Demonstration der erzielten Ergebnisse..... 100
7.2 Betrachtung der Lösung zum Einbinden der Eingabegeräte in OfuturO 102
7.3 Betrachtung der Lösung zum Versenden visualisierter Daten über die
Gesten........................................................................................................... 106
7.3.1 Die Gestenerkennung auf den Touchpads........................................ 106
7.3.2 Die Zuordnung der Workstations zu den Gerätepaaren ................... 107
Literaturverzeichnis ........................................................................................ 109
Anhang ............................................................................................................. 112
Erklärung ......................................................................................................... 114
9
Abbildungsverzeichnis
1.1 Milgram Diagramm aus [MC99] 10
1.2 Cubic Mouse der GMD 20
1.3 Space Ball 4000 20
1.4 Magellan Spacemaus Plus 20
2.1 Office Of The Future Vision aus [RWC+98] 24
2.2 Roomware Komponente CommChair aus [SGH98] 29
3.1 OfuruO Tisch 32
3.2 Konzeptionelle Skizze von OfururO 34
3.3 Arbeitsplatz mit Laptop 35
3.4 Display Vorrichtungen 35
3.5 Eingabegeräte 38
3.5 Avango Entwicklungsumgebung 39
3.7 Vergleich von Konferenzszenarien 42
3.8 Verbindung von Datenbankarchiven und Projektionssystem 43
3.9 Vernetzung der Softwarekomponenten 46
3.10 Visualisierung von Präsentationsinhalten 47
3.11 Download von Präsentationsinhalten 48
3.12 Direkter Transfer von Informationen 48
4.1 Deskriptorhyrarchie [Lin03] 53
4.2 Easy Cat Touchpad von Cirque 56
4.3 Magellan Spacemaus Plus mit ihren 6 Freiheitsgraden 60
5.1 Auszug aus /proc/bus/devices 70
5.2 Schematische Darstellung der Race Conditions Problematik 80
5.3 Schematische Darstellung der Race Conditions Problematik II 83
6.1 Funktionsweise der GlidePoint Technologie 86
6.2 Gestenausführung auf einem Touchpad 87
6.3 Gestenverlauf innerhalb des Toleranzintervalls 90
6.4 Vorzeichenwechsel bei einer Kreisgeste auf dem Touchpad 92
6.5 Platznummernvergabe am OfuturO-Tisch 96
10
Kapitel 1
Virtual Reality
1.1 Einführung
Da die Aufgabenstellung dieser Diplomarbeit Teil eines Projektes aus dem
Bereich der Virtual Reality (genauer der Mixed Reality) ist, soll vorab erstmal
eine Erläuterung dessen erfolgen, was im Folgenden als Virtual Reality (VR)
bezeichnet wird und welche Teilgebiete von dem Thema der Virtual Reality
abgedeckt werden. Insbesondere wird dabei auf den Bereich der Mixed Reality
eingegangen, in dem das OfuturO Projekt anzusiedeln ist.
Der Begriff Virtual Reality wurde 1989 von Jaron Lanier geprägt. Im Grunde
genommen beinhaltet er zwei an sich gegensätzliche Bezeichnungen: Virtual
bedeutet übersetzt soviel wie nicht real, nicht wirklich existent. Reality
bezeichnet die uns umgebende Wirklichkeit. Zusammengesetzt bedeutet Virtual
Reality also erst einmal nichts weiter als nicht real existente Wirklichkeit. Das
untenstehende Diagramm nach Milgram (Abbildung 1.1) zeigt eine mögliche
Definition der Virtual Reality und ihre Beziehung zur realen Welt auf.
Abb.1.1: Beziehung zwischen wirklicher und virtueller Realität nach Milgram aus [MC99]
In dieser Definition stehen sich die uns bekannte reale Wirklichkeit am linken
Ende, sowie eine vollkommen nicht existente Wirklichkeit am rechten Ende,
gegenüber. Die Umgebung der Realen Wirklichkeit (Real Environment) steht
dabei für eine Umwelt, in der keinerlei Simulationen stattfinden. Sämtliche
Sinneseindrücke werden von physikalisch real existierenden Gegebenheiten
11
erzeugt. Mit der Zunahme von virtuellen Komponenten die in die wirkliche
Realität integriert werden, bewegt man sich in Richtung des rechten Endes auf
dem Milgram Diagramm fort. Der Übergang zwischen den Extremformen an
beiden Enden auf dem Milgram Diagramm wird als Mixed Reality bezeichnet. In
der Mixed Reality befindet sich der Mensch in einer Umgebung in der beides
existiert, sowohl reale, als auch nicht reale Komponenten. Je nach Anteil von
Realem und Nichtrealem wird im Milgram Diagramm noch zwischen
Augmented Reality (AR) und Augmented Virtuality (AV) unterschieden. In der
Augmented Reality stellen simulierte Umgebungskomponenten Anreicherungen
der Realen Welt dar. In der Augmented Virtuality wird eine simulierte Welt
durch reale Komponenten angereichert. Denkbar sind auch Modelle in denen
noch feinere Unterscheidungen gemacht werden. Am äußersten rechten Rand
des Diagramms schließlich steht die virtuelle Umgebung (Virtual Environment).
Sämtliche Sinneseindrücke sind hier Folgen von durch nicht real existierende
Gegebenheiten ausgelösten Simulationen. Für eine solche Umgebung wurde in
dem 1984 erschienen Roman Neuromancer von W.Gibson auch die
Bezeichnung Cyberspace geprägt. Fälschlicherweise wird Cyberspace oft als
Synonym für Virtuelle Realität benutzt. In Wirklichkeit stellt der Cyberspace
aber nur den Sonderfall aller möglichen virtuellen Realitäten dar, die sich
ausgenommen vom äußerst linken Ende über das gesamte Milgram Diagramm
verteilen, nämlich eine vollkommen von der Außenwelt abgeschnittene,
interaktionsfähige, frei begehbare, simulierte Wirklichkeit. Der Begriff
Wirklichkeit steht dabei für das, was wir als real existent empfinden. Somit
genügt es zum Erzeugen einer virtuellen Realität nicht, die reale Umgebung
einfach mit virtuellen Elementen anzureichern. Vielmehr müssen diese Elemente
auch vollkommen in die reale Umgebung integriert werden. Nur dadurch kann
aus realen und virtuellen Elementen eine zur realen Wirklichkeit gleichwertige
virtuelle Realität erzeugt werden.
Um den Übergang von der wirklichen Welt in eine virtuelle Welt zu erleben ist
ein bestimmter Vorgang notwendig, nämlich das subjektive Verlassen der realen
und gleichzeitige Eintauchen in die virtuelle Welt. Dieser Vorgang wird auch als
Immersion bezeichnet. Immersion kann genauso beim Ansehen eines
spannenden Filmes erfolgen, wie auch beim Kontakt mit computergenerierten
Welten durch Verwendung der verschiedenen Darstellungskomponenten in der
12
VR. Die Immersion ist ein Vorgang, der schleichend erfolgt und verschiedene
Stärken aufweisen kann. Der Grad an Immersion der erreicht wird, hängt in
hohem Maße von der Fähigkeit des verwendeten Systems ab, eine realistische
Darstellung der künstlichen Wirklichkeit zu erzeugen. Auf dem Milgram
Diagramm sind keine Informationen über den Grad einer Immersion zu
entnehmen. Eine Immersion wird hier schon vorausgesetzt. Ziel eines Virtual
Reality Systems ist es immer, ein möglichst hohes Maß an Immersion zu
erreichen. Was aber erzeugt das Empfinden von Realität überhaupt? Der Mensch
nimmt seine Umwelt über die fünf Sinne fühlen, hören, schmecken, sehen und
riechen wahr. Aufgrund der Informationen, die über diese Sinne aufgenommen
werden, generiert der Mensch ein inneres Abbild seiner Umgebung. Dieses
Abbild stellt die ganz persönliche Realität dar. Um nun für den Menschen eine
andere Realität zu erzeugen, sollte es genügen die Sinneseinflüsse entsprechend
zu verändern. Diese an sich simple Bedingung bereitet in der Praxis jedoch
gravierende Probleme. Grund dafür ist, dass die Informationen
(Sinneseindrücke) einer virtuellen Welt in geeigneter Weise an die Sinne
weitergeleitet werden müssen. Dazu sind spezielle Schnittstellen unerlässlich.
Diese Hardwareschnittstellen werden weiter unten noch genauer betrachtet. Das
Problem liegt nun darin diese Schnittstellen so zu konstruieren, dass die
Übertragung der gewünschten Informationen als möglichst natürlich empfunden
wird. Dazu müssen sie Funktionen bieten, die zum einen Informationen in
geeigneter Weise wiedergeben und zum anderen ihren Einsatz möglichst nicht
wahrnehmen lassen.
Geeignete Voraussetzungen für eine im oben beschriebenen Sinne optimale
Informationsübertragung zu schaffen ist jedoch nur eine von zwei Teilaufgaben
der Darstellungskomponenten eines Virtual Reality Systems. Die andere besteht
darin diese Informationen überhaupt erst zu erzeugen. Dazu muss es gelingen die
zu übermittelnden Eindrücke so gut wie möglich nach dem Vorbild aus der
realen Welt zu simulieren.
Somit muss bei der Darstellung von Grafiken und Änderungen der Perspektive
ein Bildaufbau immer in Echtzeit erfolgen, was bedeutet, dass
Verzögerungszeiten immer in einem Bereich von weniger als einigen hundertstel
Sekunden liegen. Fehlt diese Echtzeitfähigkeit, kommt es zu verzögertem
Bildaufbau, der in Nichtsynchronität von Bewegung und Bildwiedergabe
13
resultiert. Das Echtzeitverhalten eines Systems für Virtual Reality nimmt mit der
Zunahme an zu verarbeitenden Polygonen und somit der Prozessorlast ab.
Derzeit können z.B. einige tausend Polygone noch verzögerungsfrei dargestellt
werden, bei höheren Anzahlen kommt es dann aber bereits zu Bildauslassungen
und anderen Qualitätseinbußen. Einige Darstellungskomponenten von heutigen
Systemen für Virtual Reality werden im nächsten Abschnitt vorgestellt.
Eine gewisse Immersion kann bereits durch das geeignete Darstellen und
Übermitteln simulierter Sinneseindrücke erzielt werden, sie lässt sich jedoch
durch eine Interaktionsfähigkeit des VR-Systems noch verstärken: In der Realität
können wir unsere Umwelt nicht nur wahrnehmen, wir können auch mit ihr in
Kontakt treten, indem wir sie manipulieren. Viele Systeme für Virtual Reality
machen erst dadurch Sinn, dass sie Interaktionen zulassen. Die
Interaktionsfähigkeit, sowie auch die Darstellungsfähigkeit eines Systems für
Virtual Reality, werden immer durch den Einsatz von Computerhardware
erreicht.
Die theoretischen Grundlagen für den Einsatz von Datenverarbeitungs-
technologien zur Erzeugung interaktiver virtueller Realitäten wurden 1965 von
dem Wissenschaftler Ivan Sutherland unter dem Titel "The Ultimate Display"
[Sut65] veröffentlicht. Bereits 1963 entwickelte Sutherland am Massachusetts
Institute of Technique (MIT) ein Zeichenprogramm, das dem Benutzer
ermöglichte mit Hilfe eines Fadenkreuzes auf dem Bildschirm Linien zu
zeichnen und wieder zu löschen. Das Programm mit dem Namen “Sketchpad“
erlaubte erstmals die direkte Interaktion des Benutzers mit dem Computer. Einen
weiteren Meilenstein in der Entwicklungsgeschichte der Virtual Reality stellt das
um 1970 ebenfalls von Sutherland entwickelte Head Mounted Display (HMD)2
dar. Etwa zur selben Zeit arbeitete das Militär daran Flugverhalten und
Steuerung von Flugzeugen mit Hilfe von Software zu simulieren. Die
Flugsimulatoren bestanden aus einem frei gelagerten Cockpitnachbau, das auf
Bewegungen des Steuerknüppels mit Kipp- und Drehbewegungen zur Seite,
nach vorne oder nach hinten reagierte. Die Simulatoren sollten vor allem den
auszubildenden Piloten ein Training ermöglichen, das billiger und gefahrloser
war als das herkömmliche Flugtraining in echten Flugzeugen. Bevor
Computergrafiken in den Simulatoren eingesetzt wurden, nutzte man für die
2 Beschrieben in [Sut68]
14
visuellen Eindrücke noch Videoaufnahmen. Der Einsatz der Computergrafik
erlaubte im Gegensatz zu den Videoaufnahmen jedoch visuelle Reaktionen in
Echtzeit, auch wenn die Grafik zu dieser Zeit noch primitiv und weit entfernt
davon war, eine realistische Darstellung zu bieten. Flugsimulationen, in die das
Militär Millionen von Dollar investierte, brachten die Entwicklungen auf dem
Gebiet der VR entscheidend voran. Obwohl militärische Forschungen für
Simulationen zeitweise aus Kostengründen abgebrochen wurden, stellen
Simulationsprogramme aller Art heute noch immer einen großen Anteil des
Einsatzbereiches von Datenverarbeitungsanlagen und speziell der VR dar. In 1.4
wird das Thema der Interaktion im Zusammenhang mit der Mixed Reality noch
einmal genauer erläutert.
1.2 Arten von Virtual Reality Systemen
Je nachdem welche Hardware eingesetzt wird, welche Ziele verfolgt werden und
wie der Einsatz der verschiedenen Komponenten eines Systems für Virtual
Reality erfolgt, werden verschiedene Kategorien der VR unterschieden. Im
Folgenden werden die beiden wichtigsten Bereiche der VR, die Immersive
Reality und die Mixed Reality vorgestellt. Je nach Definition von Virtual Reality
finden sich auch andere Unterteilungen.3
1.2.1 Immersive Reality
Anwendungen der Immersive Reality (IR) stehen ganz rechts im Milgram
Diagramm und bemühen sich den Benutzer vollkommen in simulierte,
interaktive Welten eintauchen und damit interagieren zu lassen. Das auch als
Immersion (Definition siehe oben) bekannte Eintaucherlebnis (der Effekt, wenn
sich der Benutzer psychisch in der virtuellen Welt befindet) kann hier aber erst
dann erfolgen, wenn die Sinne des Anwenders von der Außenwelt abgeschirmt
3 Siehe auch [Vie03] in denen die VR in sechs Teilbereiche unterteilt wird.
15
werden. Gleichzeitig müssen anstelle der Einflussfaktoren aus der Außenwelt
ausreichende und als real empfundene virtuelle Informationen aus dem VR-
System geliefert werden. Obwohl die Immersion selbst nicht erfordert, dass alle
Sinne von der Simulation angesprochen werden, kann sie dadurch jedoch
verstärkt werden. So hat sich gezeigt, dass die visuelle Wahrnehmung verbessert
werden kann, indem sie mit einer akustischen Ausgabe gekoppelt wird. Die
Systeme der Immersive Reality unterstützen daher neben einer visuellen
Darstellung so gut wie immer auch die auditive Wahrnehmung, indem der
Anwender Klangeindrücke über Kopfhörer bzw. Soundanlagen zugespielt
bekommt, während die Geräusche der Außenwelt gleichzeitig abgeschirmt
werden. Je nach Anwendung sind dem Benutzer mehr oder weniger
Interaktionen mit der virtuellen Welt möglich. Dazu werden in der Regel
spezielle Eingabegeräte verwendet. Diese unterstützen teilweise auch haptische
Feedbacks, so dass auf bestimmte Handlungen in der IR im besten Fall visuelle,
akustische sowie sensorische Rückmeldungen des Systems erfolgen. Die beiden
verbleibenden Sinne für die olfaktorische sowie gustatorische Wahrnehmung
werden heutzutage von der IR noch vernachlässigt.
Derzeit gibt es noch keine Richtlinien für die Immersionsfähigkeit eines IR-
Systems. Eine Methode besteht im so genannten Ducktest: Dabei wird dem
Benutzer ein virtuelles Objekt entgegen geworfen- erfolgt eine
Ausweichreaktion, so kann davon ausgegangen werden, dass der Benutzer die
virtuelle Welt als Alternative zur Realität anerkennt. Zur Bilddarstellung wird in
der Immersive Reality vorzugsweise das HMD eingesetzt, da es den Blick des
Anwenders auf die reale Umgebung abschirmt und somit die nötigen
Voraussetzungen für ein Eintauchen in eine vollkommen vom Computer
generierte Welt erfüllt. Alternativ zum HMD werden in der Immersive Reality
auch Projektionsräume eingesetzt, wie die CAVE oder die iCone.
1.2.2 Mixed Reality
Während bei der Immersive Reality der Versuch unternommen wird den
Menschen in eine nicht reale, vom Computer geschaffene Umgebung eintauchen
zu lassen, hat die Mixed Reality (MR) sich zum Ziel gesetzt, den Menschen in
16
seiner gewohnten Umgebung zu belassen und stattdessen die
computergenerierten Objekte darin zu integrieren. Um dies zu erreichen dürfen
die Sinne des Anwenders in der Mixed Reality nicht wie bei der Immersive
Reality von der Umgebung abgeschirmt werden. Die Visualisierung findet daher
auch nicht wie beim gewöhnlichen Head Mounted Display unter Ausschluss der
Umgebung statt. Stattdessen werden spezielle Projektionsflächen in Form von
Großbildwänden, einer Workbench, oder einer ganz gewöhnlichen Wand die als
Bildwand dient, verwendet.
Die MR hat gegenüber der IR den Vorteil, dass keine komplett neue Umgebung
berechnet und dargestellt werden muss. Die Computerdarstellung kann sich auf
die nur wirklich relevanten Objekte beschränken. Die hierfür nötige
Rechenleistung ist somit um ein Vielfaches geringer als bei der Virtual Reality.
Dies kommt vor allem dann zum Tragen wenn die getrackten4 Bewegungen des
Anwenders eine Neukalkulation der visualisierten Daten und ein anschließendes
Neudarstellen in Echtzeit erfordern.
1.3 Hardwarekomponenten eines Mixed Reality Systems
Je nach Anforderungen an ein MR-System und den mit ihrem Einsatz
verbundenen Zielen, können den Computerdarstellungen bzw. dem
Interaktionsverhalten eines MR-Systems eine nebensächliche oder eine
vorherrschende Rolle zukommen. Für die verschiedenen MR- Systeme kommen
daher unterschiedlichste Hardwarekomponenten zum Einsatz. Die gebräuch-
lichsten Hardwarekomponenten, die in der VR-Forschung auf dem Gebiet der
Mixed Reality eingesetzt werden, werden hier kurz vorgestellt:
4 Das Tracking wird weiter unten unter 1.3.2 beschrieben.
17
1.3.1 Stereoprojektoren und Projektionsflächen
Sinn der Stereoprojektion ist das Erreichen einer räumlichen Darstellung des
anzuzeigenden Bildes. Dazu macht man sich die natürliche Fähigkeit des
Gehirns zunutze, zwei voneinander versetzte Bilder automatisch zu einem
räumlichen Bild verarbeiten zu können. Dies geschieht nämlich immer dann,
wenn wir eine bestimmte Szene mit den Augen betrachten: Aufgrund des
Abstandes der Augen zueinander wird auf die Netzhaut der Augen nicht jedes
Mal das gleiche, sondern zwei leicht voneinander versetzte Bilder projeziert.
Nähere Objekte scheinen dabei stärker, weiter entfernte Objekte weniger stark
versetzt. Hauptsächlich anhand dieses Versatzes bekommt der Mensch
Entfernungsdaten übermittelt. Ein räumliches Sehen wird möglich, indem das
Gehirn die beiden Einzelbilder zu einem räumlichen Bild zusammensetzt. Um
den gleichen Effekt bei einer Projektion zu erreichen, erfolgt diese über eine
Doppelprojektion, wobei beide Bilder gleichzeitig, aber der Perspektive
entsprechend leicht versetzt voneinander projeziert werden. Die Räumlichkeit
wird erreicht, indem für jedes Auge nur jeweils eines der beiden Bilder angezeigt
wird. Dazu müssen jedoch zuerst beide Projektionen voneinander getrennt
werden. Die Trennung wird in der Regel durch spezielle Brillen (Shutterbrillen)
erreicht, die dafür Sorge tragen, dass immer nur das für das jeweilige Auge
bestimmte Bild durchgelassen wird. Da es verschiedene Projektionsverfahren
gibt, arbeiten auch die zum Einsatz kommenden Brillen unterschiedlich: Bei der
Anaglyphenmethode wird für jedes der Bilder zur Darstellung eine andere Farbe
gewählt (rot, grün). Die Brillen die in Zusammenarbeit mit dieser Projektionsart
eingesetzt werden erreichen die Trennung der beiden Bilder voneinander indem
auch die Brillengläser jeweils eine der beiden Farben aufweisen und auf diese
Weise nur das nicht der Glasfarbe entsprechende Bild zum Auge durchlassen.
Das der Glasfarbe entsprechende Bild wird vom Brillenglas überdeckt.
Bei der Polarisationsprojektion sind auch mehrfarbige Bilder möglich. Hierbei
werden beide Bilder in Originaleinfärbung, dafür aber mit unterschiedlicher
Lichtpolarität projeziert. Die hier eingesetzten Brillen erreichen die
Bildtrennung, indem sie gleichfalls polarisierte Gläser einsetzen. Jedes
Brillenglas lässt dabei nur die seiner Polarisation entsprechende Projektion zum
Auge durch (siehe Abschnitt 1.3.3).
18
1.3.2 Tracker
Einige Eingabegeräte in der VR weisen Tracker auf, die ständig Position und
Orientierung des Gerätes aufzeichnet. Ein Tracker besteht dabei prinzipiell aus
einem Transmitter und einem Receiver, wobei eine Steuereinheit abhängig von
Winkel und Lageveränderung des Senders und Empfängers zueinander, die
neuen Koordinaten für den Computer berechnet. Sinn des Trackings ist die
Möglichkeit eines VR-Systems, angemessen auf Bewegungen des Anwenders
reagieren zu können. So wird auch durch das Tracking wieder ein zusätzliches
Maß an Realitätsempfinden erzeugt, indem das VR-System beispielsweise dafür
sorgt, dass Eigenbewegungen des Benutzers einen Perspektivenwechsel gemäß
der Bewegungsparallaxe5 nach sich ziehen.
Es existieren verschiedene Trackingverfahren, darunter das mechanische
Tracking, das optische Tracking und das Ultraschalltracking. Eine Beschreibung
der Arbeitsweise dieser Trackingarten findet sich in [KR98].
1.3.3 Shutterbrillen und Polarisationsbrillen
Shutterbrillen setzen das Verfahren der aktiven, Polarisationsbrillen das
Verfahren der passiven Stereoprojektion ein.
Bei den Gläsern der Shutterbrille handelt es sich um 2 LCD Gläser, die
abwechselnd verdunkelt werden können. Das wechselseitige Verdunkeln der
Bilder ist dabei mit dem Stereobildprojektor über Kabel oder Infrarotemitter
synchronisiert, und erfolgt in einer so hohen Geschwindigkeit (mindestens 50
Hz), dass es für das menschliche Auge nicht mehr wahrnehmbar ist. Als Resultat
wird jeweils immer nur eines der beiden Bilder die vom Projektor erzeugt
werden von einem Brillenglas zum Auge durchgelassen, während das andere
blockiert wird. Da das Verdunkeln der Brillengläser mit der Projektion der
Bilder koordiniert werden muss, sind Shutterbrillen über ein Kabel mit dem
Projektor verbunden. Polarisationsbrillen wurden bereits 1928 von Edwin Land
entwickelt und arbeiten dagegen ohne eine solche Synchronisation. Stattdessen
5 Die Bewegungsparallaxe ist für das Phänomen verantwortlich, dass sich bei einer Bewegung nahe stehende Objekte für den Beobachter stärker verschieben als weiter entfernte. Dieses Phänomen muss für die realistische Darstellung innerhalb einer virtuellen Umgebung nachgeahmt werden.
19
sind die Gläser der Brille unterschiedlich polarisiert. Die Bildtrennung kommt
dadurch zustande, dass die Stereoprojektion ebenfalls mit verschiedener Polarität
für die einzelnen Bilder stattfindet und die Brillengläser somit das Bild mit der
jeweils anderen Polarisierung blockieren.
1.3.4 Eingabegeräte eines Mixed Reality Systems
Für die Interaktion innerhalb einer Mixed Reality Umgebung kommen
verschiedene Eingabegeräte, wie beispielsweise die Cubic Mouse, der Space Ball
oder die Spacemaus zum Einsatz. Bei der Cubic Mouse handelt es sich um ein
von der GMD (Gesellschaft für Mathematik und Datenverarbeitung)
entwickeltes Eingabegerät. Sie besteht aus einem würfelförmigen Gehäuse, bei
dem durch jede der drei Achsen ein Stab gezogen ist (Abbildung 1.2). Die Enden
eines Stabes ragen dabei zu beiden Seiten aus dem Gehäuse. Durch Verschieben
der Stäbe lassen sich bei der Cubic Mouse Translationsbewegungen auf, und
durch das Drehen an den Stäben Rotationsbewegungen um alle drei Achsen
erzeugen. Bei der Spacemaus lässt sich eine Kappe, beim Space Ball ein kleiner
Gummiball in alle erdenklichen Richtungen drücken, ziehen oder drehen
(Abbildungen 1.3 und 1.4). Dabei werden die Bewegungsdaten nicht nur ihrer
Richtung entsprechend übertragen, sondern variieren auch je nach Druckstärke
in die entsprechende Richtung. Dadurch lässt sich mit der Spacemaus bzw. dem
Space Ball neben der eigentlichen Bewegung auch die Geschwindigkeit der
Bewegungsabläufe kontrollieren. Unter anderem ist das Einbinden von
Spacemäusen für die Eingabeverarbeitung innerhalb der OfuturO-Umgebung
Teil dieser Diplomarbeit. Die Spacemaus wird daher in Kapitel 4 noch genauer
betrachtet.
20
Abb.1.2: Die Cubic Mouse der GMD (links), Abb. 1.3: Der Space Ball 4000 (mitte),
Abb.1.4:Magellan Spacemaus Plus (rechts) der Firma 3DConnexions
1.4 Interaktion in der Mixed Reality
Im Folgenden sollen einige Aspekte der Interaktion in einem MR-System
aufgezeigt werden, sowohl einige Möglichkeiten als auch die damit verbundenen
Problemstellungen. Die Problematik bei der Interaktion mit virtuellen
Gegenständen ähnelt der ihrer Darstellung. Bei der Darstellung in der MR
müssen spezielle (Hardware-) Schnittstellen vor die natürlichen
Eingabeschnittstellen (Augen, Ohren, Nase, Haut) geschaltet werden um die
Darstellung überhaupt zu ermöglichen. Diese dienen quasi als Bindeglieder
zwischen dem Menschen und der virtuellen Realität. Da virtuelle Objekte keine
physikalische Gegenständlichkeit besitzen, bedarf es auch zur Interaktion mit
ihnen spezieller Werkzeuge. Diese stellen Bindeglieder zwischen der virtuellen
Realität und den natürlichen Ausgabeschnittstellen (Finger, Hand, Sprache,
Gesten, Mimik etc.) dar. Auch bei den Eingabeschnittstellen eines MR-Systems
liegt die Problematik darin, dass eine Immersion erschwert wird, wenn sich der
Anwender zu sehr der Tatsache bewusst ist, dass er nicht unmittelbar, sondern
über Schnittstellen mit der virtuellen Umgebung kommuniziert. Wie bei den
Ausgabekomponenten der MR besteht deshalb auch bei den Eingabemedien
eines der primärem Ziele darin, die Handhabung so intuitiv wie möglich zu
gestalten und das Medium selbst in den Hintergrund treten zu lassen. Die
Eingabeschnittstellen bestehen immer aus Hardware. In den meisten Fällen wird
diese Hardware über direkten Kontakt mit dem Benutzer durch diesen
manipuliert. Beispiele hierfür sind die Maus, die Spacemaus, die Cubic Mouse
usw. Solche Eingabegeräte weisen spezielle zur Manipulation vorgesehene
Vorrichtungen auf, sei es eine Kappe, ein Ball oder Stäbe die sich in
21
verschiedene Richtungen bewegen lassen. In jedem Fall aber führen
Manipulationen am Eingabegerät schließlich zu einer Manipulation am
Zielobjekt. Bei der Entwicklung solcher Eingabegeräte liegt die Schwierigkeit
beim auch als Mapping genannten Verfahren liegt darin, festzulegen welche Art
von Manipulation auf dem Eingabegerät zu welcher Art von Manipulation auf
dem (virtuellen) Zielobjekt führt. Die oben genannten Eingabegeräte erlauben
alle die gleichen Arten von Manipulationen auf Objekten, verlangen dafür aber
teilweise sehr unterschiedliche Arten von Manipulationen auf den Geräten
selbst.
Die verschiedenen Bedienungsmöglichkeiten der Geräte, sowie deren
Auswirkungen müssen vom Benutzer erst erlernt und verstanden werden. Daraus
ergibt sich das Problem, dass ein Interaktionsprozess mittels solcher
Eingabegeräte einer Immersion immer etwas hinderlich ist. Eine andere
Möglichkeit besteht daher darin, auf direkten Kontakt mit der
Eingabeschnittstelle zu verzichten. Im Bereich der Gesten- und
Spracherkennung wird versucht bestimmte Reaktionen des MR-Systems auf
Gestik, Mimik bzw. Sprache des Benutzers hervorzurufen, indem Kameras oder
Mikrofone Bewegungen bzw. Sprache des Anwenders erfassen und auf
bestimmte Gesten oder Laute hin analysieren. Anstatt ein virtuelles Objekt
mittels eines Eingabegerätes das mit der Hand gesteuert wird beispielsweise zu
greifen und durch den Raum zu führen, kann hier die reine Geste des Greifens
und Führens eines Gegenstandes ausreichend sein um die gewünschte Aktion zu
bewirken. Nachteil ist hier wiederum fehlendes haptisches Feedback, das ohne
direkten Kontakt mit entsprechender Hardware nicht realisiert werden kann. In
vielen Fällen müssen allerdings Aktionen durchgeführt werden, denen keine
eindeutige Geste zugeordnet werden kann, wie beispielsweise ein
Moduswechsel. Hier müssen dann wieder Gesten oder Sprache auf bestimmte
Funktionen gemappt werden, wodurch sich bei der Gestenerkennung wieder die
gleiche Problematik ergibt wie bei der Verwendung von Eingabegeräten wie
Space Ball oder Cubic Mouse.
Allerdings hat die Interaktion mittels Gestik einen entscheidenden Vorteil
gegenüber einer Interaktion mittels herkömmlicher Eingabegeräte: Da es eine
nahezu unbegrenzte Anzahl an möglichen Gesten gibt, die allein mit der Hand
ausgeführt werden können, können Gesten so gewählt werden, dass sie den
22
Charakter der durchzuführenden Aktion bereits widerspiegeln. Dies erlaubt eine
intuitivere Eingabemöglichkeit, was wiederum den gesamten Interaktionsprozess
erleichtert.
Eine weitere Möglichkeit besteht in der Kombination aus Gestenerkennung und
dem Verwenden von herkömmlichen Eingabegärten wie einer Maus oder einem
Touchpad. Hier stellen die Eingabegeräte eine natürliche Begrenzung von
möglichen Gesten dar, indem sie beispielsweise die Gestenerkennung zur
Manipulation zweidimensionaler Objekte auch nur auf eine Gestenausführung in
der Ebene beschränken (Ein Beispiel dazu ist die Realisierung der zu dieser
Diplomarbeit gehörenden Aufgabenstellung des Versendens von Dokumenten
mittels einer Geste auf einem Touchpad innerhalb eines Netzwerkes. Näheres
dazu in 4.2 und Kapitel 6).
1.5 Anwendungsgebiete von Mixed Reality Systemen
Die Anwendungsmöglichkeiten von Systemen der Mixed Reality sind schon
heute äußerst zahlreich. Es ist zu erwarten, dass virtuelle Welten in der Zukunft
eine immer größere Rolle spielen werden. Das stete Ansteigen der
Leistungsfähigkeit von Mikroprozessoren und Grafikbausteinen wie
Grafikkarten und Displaysysteme, wird die Kosten für ein MR-System in
Zukunft auch für kleinere Firmen und Privatanwender erschwinglich werden
lassen. In den letzten Jahren wurde die MR immer sehr stark von großen
Unternehmenszweigen wie zum Beispiel der Automobilindustrie vorangetrieben.
Hier können Fahrzeuge bevor sie gebaut werden erst modelliert und
anschließend in einer Windkanalsimulation auf ihre aerodynamischen
Eigenschaften überprüft werden. Die Modelle werden dann solange getestet und
verbessert, bis ein optimales Ergebnis vorliegt.
Ein weiteres Feld in dem die MR bereits erfolgreich Anwendung findet ist die
Medizin: Das ARSyS Tricorder Projekt des Instituts für Medienkommunikation
(IMK) der Fraunhofer Gesellschaft in Sankt Augustin6 beispielsweise, stellt die
Realisierung eines Augmented Reality Systems zum Einsatz in der Mund-Kiefer-
Gesichtschirurgie dar. Hier sollen operative Eingriffe unterstützt werden. Solche
6 Beschrieben in [GTB+02]
23
Eingriffe bestehen in der Mund-Kiefer-Gesichtschirurgie oftmals aus zwei
Schritten: dem Entfernen eines Tumors in Schädelbereich, sowie der
Knochenentnahme im Hüftbereich zur anschließenden Rekonstruktion des vom
Tumor zerstörten Schädelknochens. Das Augmented Reality System des ARSyS
Tricorder Projektes unterstützt den Chirurgen in beiden Schritten. Beim
Entfernen des Tumors kann dieser über eine durchsichtige Projektionsfläche die
sich über dem Patienten befindet visualisiert werden. Der Chirurg trägt dabei
eine Stereobrille, die die räumliche Darstellung des Tumors ermöglicht. Position
und Skalierung des virtuellen Tumorgewebes stimmen dabei mit der des echten
Tumors überein. Durch das Hervorheben des Tumors wird der Eingriff
erleichtert und die Risiken der Operation minimiert. Beim zweiten Schritt, der
Entnahme des Knochens aus der Hüftregion, kann das zu entnehmende
Knochenteil schon vor dem Eingriff in Größe und Ausrichtung in die
Entnahmestelle projeziert werden, so dass ein überflüssiges Maß an Entnahme
von Knochenmaterial durch den Chirurgen verhindert werden kann.
Mehr Informationen rund um die Thematik der Virtual Reality sind auch unter
[Phi03] und [Boh99] erhältlich.
24
Kapitel 2
Office Of The Future
Abb. 2.1: Vision eines Office Of The Future aus [RWC+98]
Das vorliegende Kapitel, sowie das darauf folgende, wurden im Wesentlichen
aus [Gal03] übernommen. Um einen Bruch zum übrigen Text dieser
Ausarbeitung zu vermeiden, wurde der Originaltext an einigen Stellen
geringfügig geändert. Außerdem wurden Kürzungen vorgenommen, um
Wiederholungen zu vermeiden.
2.1 Motivation
Die Motivation für dieses Kapitel liegt darin, Wege zur Schaffung einer Office
Of The Future- Landschaft zu beleuchten. Da sich ein Office Of The Future
durch die Erweiterung durch virtuelle Hilfsmittel auszeichnet, ist zunächst eine
25
Klärung der Bedeutung des Begriffs “virtuelles Hilfsmittel” nötig, um danach
aufzuzeigen, auf welche Weise solche in eine Büroumgebung integriert werden
können. Außerdem werden Techniken zur Interaktion mit virtuell erweiterten
Büroumgebungen besprochen und Projekte vorgestellt, welche die Zielsetzung
der Integration von virtuellen Hilfsmitteln haben.
2.2 Virtuelle Hilfsmittel
2.2.1 Definition
Mit virtuellen Hilfsmitteln sind computergenerierte Modelle gemeint, die
Arbeitsumgebungen zugeordnet sind und verschiedenste digitale Informationen
repräsentieren können. Die Integration als virtuelle Ergänzung einer
Arbeitsumgebung wird mittels geeigneter Ausgabe- und Interaktionstechniken
durch die Überlagerung der physikalischen Umgebung erreicht. Der Benutzer
erhält auf diesem Wege Informationen, die für ihn anderenfalls nicht über die
reale Umgebung erreichbar wären. Daten zur Beschreibung der virtuellen
Hilfsmittel werden in Datenbankarchiven verwaltet, die mit den Steuer- und
Grafiksystemen der virtuellen Umgebung gekoppelt sind. Eine Integration
solcher Hilfsmittel ist an vielen Orten, an denen Menschen ihre Arbeit verrichten
sinnvoll, um z. B. Informationen darzustellen, die das Arbeiten vereinfachen und
effektiver gestalten können.
2.2.2 Arten
Virtuelle Elemente, die als ergänzende Komponenten zur Hilfestellung in eine
Büroumgebung integriert werden, können sowohl in zwei- als auch in
dreidimensionaler Darstellungsform in die physikalische Umgebung eingebettet
werden. Bei der Erscheinungsform des virtuellen Hilfsmittels besteht lediglich
eine jeweilige Abhängigkeit von der zu erfüllenden Aufgabe in der Umgebung,
der es zugeordnet ist und den Anforderungen, die an die Interaktion mit dem
26
Hilfsmittel gestellt sind. Die Verwendung einer zweidimensionalen
Darstellungsform bietet sich an, wenn die digitalen Informationen Daten
repräsentieren, die in der realen menschlichen Erfahrungswelt ebenso
zweidimensional wiedergegeben würden, also auf Oberflächen darstellbar sind.
Solche Daten sind z. B. Textdokumente oder Bilder, bei denen eine Darstellung
in zwei Raumdimensionen oft vollkommen ausreichend und etwas anderes auch
nicht sinnvoll ist.
Zur dreidimensionalen Repräsentation, die für den Menschen der realen
visuellen Wahrnehmungserfahrung der physikalischen Umwelt entspricht, eignet
sich im Prinzip jede Information. Im Fall der digitalen Erweiterung einer
Büroumgebung beschränkt sich dies auf dreidimensionale virtuelle Modelle von
Objekten oder Personen, die einem Arbeitsprozess zugeordnet werden können.
So kann der physikalischen Umgebung z. B. bei einem System für
Telekollaboration eine entfernte Person oder bei einem Konstruktionssystem ein
in der Entwicklung befindliches Objekt als dreidimensionales Modell
hinzugefügt werden.
2.2.3 Integrationsmethoden
Der Aufwand zur Integration virtueller Hilfsmittel in ein Büroszenario ist je nach
Art der digitalen Informationen unterschiedlich. So reicht bei einer Information,
die lediglich zweidimensional dargestellt werden soll, eine brauchbare
Oberfläche im Raum für Projektionen oder ein Bildschirm aus. Bei
dreidimensionalen Informationen ist die Verwendung einer geeigneten AR-
Display-Technologie notwendig, um die virtuellen Objekte in die physikalische
Umgebung einzubinden. Die zusätzlich eingeblendeten Informationen sind dabei
den Arbeitsprozessen der Benutzer angepasst und dienen zur Unterstützung der
jeweiligen Tätigkeiten. Zur Generierung und Wahrnehmung einer in drei
Raumdimensionen virtuell erweiterten Arbeitsumgebung gibt es verschiedene
Ansätze, die ihre Vor- und Nachteile haben.
Ein Weg ist die Implementierung einer virtuellen Umgebung, die sich auf das
visuelle Feld des Benutzers beschränkt und durch ein See-Through-HMD
27
dargestellt wird. Ein solches am Kopf befestigtes Anzeigegerät, bei dem
durchsichtige Bildschirme direkt vor den Augen des Trägers angebracht sind, hat
durch die überlagernde Einblendung digitaler Informationen in die physikalische
Umgebung die Eignung als klassisches AR-Display. Ein wichtiger Vorteil dieser
Alternative ist, dass die virtuellen Objekte für jeden Benutzer aus einer korrekten
Perspektive dargestellt werden, was bei anderen Lösungen zum Problem werden
kann. Allerdings besteht der Nachteil, dass der Tragekomfort von HMDs eher
schlecht ist, wodurch die Interaktionsmöglichkeiten mit Personen und Objekten
der Umgebung begrenzt werden.
Eine Alternative ist die Integration der virtuellen Hilfsmittel durch ein
Projektionssystem, bei dem zur Wahrnehmung von Stereobildern das Tragen
von aktiven Shutterbrillen oder passiven Polarisationsbrillen nötig ist. Im
Unterschied zu der HMD Lösung werden die virtuellen Objekte hier direkt in die
Umgebung des Benutzers integriert und nicht nur in dessen visuellem Feld
angezeigt. Die ideale Eignung von Projektionssystemen zur Erzeugung
lebensgroßer Bilder kann als Vorteil betrachtet werden. Besteht die Motivation
darin, virtuelle Objekte auf die Fläche einer kompletten Büroumgebung zu
verteilen, die sich gewöhnlich über einen Raum erstreckt, bietet sich dafür ein
Spatially Immersive Display (SID), wie z. B. die CAVE, an. Ein SID hat
normalerweise Raumgröße und eignet sich dazu, sämtliche im Raum
befindlichen Oberflächen durch Front- oder Rückprojektionen als
Anzeigeflächen zu nutzen.
Ein Beispiel für den Einsatz eines SID ist das in Abschnitt 2.3.2 vorgestellte
Telekollaborations-Projekt The Office of the Future. In [RL01] werden
Projektionssysteme, die zur virtuellen Erweiterung der physikalischen
Umgebung genutzt werden, als Spatially Augmented Reality bezeichnet.
Zur Umsetzung von Collaborative Virtual Environments (CVE), also virtuellen
Umgebungen die durch mehrere Personen genutzt werden können, eignen sich
sowohl See-Through-HMDs als auch Projektionssysteme. Das ist im Fall von
Büroumgebungen vorteilhaft, da dort in verschiedenen Situationen der Fall
auftreten kann, dass mehrere Personen an einem Arbeitsprozess teilnehmen
möchten. Allerdings besteht bei Projektionssystemen im Gegensatz zur
Verwendung von HMDs der Nachteil, dass nur für einen Beobachterpunkt im
Raum eine korrekte perspektivische Sicht geliefert werden kann. Dieser Nachteil
28
kann abgeschwächt werden, indem das System eine Umschaltung der
Perspektive implementiert, die Benutzer verwenden können um selbst die
richtige Ansicht der virtuellen Szene zu erhalten. Doch auch so kann das System
zur gleichen Zeit nur einem Benutzer die richtige Perspektive liefern. Sollen nur
bestimmte Raumkomponenten der Umgebung virtuell erweitert werden, kann
dies durch direkten Einbau von Displaytechnologien in die Raumkomponenten
gelöst werden. Beispiele für die virtuelle Erweiterung von Raumkomponenten
sind die in Abschnitt 2.3.1 vorgestellte Roomware oder der OfuturO Tisch
(Kapitel 3). Aufgrund der Verwendung von Rückprojektionen zählt OfuturO zu
den Projektionssystemen.
2.3 Projekte
Im folgenden Teil werden Ansätze präsentiert, die mit jeweils verschiedenen
Zielsetzungen Büroumgebungen durch die Integration von virtuellen
Komponenten funktionell aufwerten. Zu Projekten dieser Art ist neben den hier
vorgestellten auch das in Kapitel 3 behandelte Mixed Reality Conferencing
System zu zählen.
2.3.1 Roomware for Cooperative Buildings
Roomware for Cooperative Buildings ist ein Projekt am Integrated Publication
and Information Systems Institute der Fraunhofer Gesellschaft. In [SGH98]
werden die Konzepte Cooperative Building und Roomware vorgestellt, die die
Integration von realen, physikalischen architektonischen Räumen und virtuellen,
digitalen Informationsräumen verfolgen.
Der Antrieb des Projekts liegt in der Annahme, dass die Anforderungen an
Arbeit und Kooperation in Firmen zukünftig steigen werden, da zwar
Arbeitsinhalte und -prozesse bereits signifikant von der Informations- und
29
Kommunikationstechnologie verändert wurden, aber das Design von
Arbeitsumgebungen sich nicht dementsprechend weiterentwickelt hat.
“In the future, work and cooperation in organizations will be characterized by a
degree of dynamics, flexibility and mobility that will go far beyond many of
today’s developments and examples.” [SGH98]
Das Ziel ist also die Entwicklung gleichwertig dynamischer, flexibler und
mobiler Arbeitsumgebungen. Das Konzept Cooperative Building kombiniert
reale mit virtuellen Welten und bietet so kooperative Arbeitsplätze, die die
Erweiterung von menschlicher Kommunikation und Zusammenarbeit
unterstützen. Personen sollen in einem kooperativen Gebäude miteinander
kommunizieren, Informationen teilen und unabhängig von der physikalischen
Position zusammen arbeiten können. Das Gebäude selbst soll dazu in der Lage
sein zu (re)agieren, sobald es bestimmte Bedingungen identifiziert hat. Es kann
Probleme analysieren, Verbindungen zwischen Personen herstellen und Hilfe
anbieten sowie kontextabhängige Informationen, die auf dem Wissen von
vergangenen und derzeitigen Zuständen und Aktionen basieren, zur Verfügung
stellen.
Abb. 2.2: Roomware Komponente CommChair aus [SGH98]
Mit Roomware sind durch Computer erweiterte Gegenstände in Räumen
gemeint. Stühle, Tische und die Wand sollen interaktive Geräte sein, die
Unterstützung für Kooperation und Interaktion durch eingebettete
Informationstechnologie bieten und die Erstellung, Bearbeitung und Präsentation
30
von Informationen ermöglichen. Durch Team- oder Projekträume,
Präsentationseinrichtungen oder Informationshallen, in denen Roomware
Komponenten integriert sind, sollen flexible und dynamische Räume geschaffen
werden, die auch als cooperative landscapes bezeichnet werden.
Ein Beispiel für eine Roomware Komponente ist der in Abbildung 2.2 zu
sehende CommChair. In der gezeigten Variante dieses Armstuhls ist ein
Computer integriert (in einer zweiten Variante wird über eine Docking-Station
ein Laptop angeschlossen), durch den der Benutzer aufgrund der Vernetzung von
Roomware Komponenten Zugang zu einem geteilten virtuellen Arbeitsraum
erhält, in dem er vom CommChair aus Daten manipulieren kann.
2.3.2 The Office of the Future
Die in Abbildung 2.1 gezeigte Vision eines Office Of The Future ist eine
konzeptionelle Skizze, die im Rahmen eines Projekts an der University of North
Carolina entstanden ist, das den Namen The Office of the Future trägt und in
[RWC+98] beschrieben wurde. Die Motivation besteht in der Entwicklung eines
3D-Systems zur Telekollaboration, durch das mit Hilfe von Darstellungs- und
Interaktionsmöglichkeiten, die der menschlichen Erfahrungswelt entsprechen,
ein verbesserter Immersionseindruck im Vergleich zu bereits verfügbaren 2D-
Systemen erreicht werden soll.
Die Problematik bei der zweidimensionalen Telekollaboration liegt darin, dass
den über ein solches System miteinander arbeitenden Personen oft nicht die
Interaktionsmöglichkeiten zur Verfügung stehen, die sie hätten, wenn sie sich im
selben Raum befänden. Außerdem ist es problematisch, dass Benutzer eines
solchen Systems dazu gezwungen sind, zwei so genannte separate Egocenter7
beizubehalten; eines in der lokalen Umgebung und ein anderes in der entfernten
Büroumgebung der Mitarbeiter.
Zur Umsetzung der 3D-Telekollaboration wird ein auf CAVE basierendes
Spatially Immersive Display (SID) in ein Büro eingebaut. Um eine nahezu
“natürliche” Arbeitsform (als ob man sich im gleichen Raum befände) zu
7 In [RWC+98] bezeichnet das Egocenter die Vorstellung davon, wo man sich und mit wem man sich an diesem Ort befindet.
31
gewährleisten, ist die Darstellung von und die Interaktion mit entfernten
Mitarbeitern dreidimensional. Das lokale und das entfernte Büro werden
zusammengefügt, indem mittels Echtzeit-Bilderkennungstechniken
Informationen über die sichtbaren Oberflächen der Umgebungen (Wände,
Möbel, Personen) extrahiert und diese als 3D-Szene am entfernten Ort
rekonstruiert werden. Als SID wird dafür nahezu alles, das sich in der lokalen
Büroumgebung befindet, genutzt und die dreidimensionale Interaktion wird über
das Tracking der Hände der handelnden Personen umgesetzt.
32
Kapitel 3
Die OfuturO Plattform
Abb. 3.1: OfuturO Tisch
3.1 Vorstellung
Bei der Betrachtung von Möglichkeiten zur Einbettung von virtuellen
Hilfsmitteln in Büroumgebungen wird in Abschnitt 2.2.3 unter anderem der
Ansatz zur virtuellen Erweiterung von Raumkomponenten beschrieben. Diese
bietet sich an, wenn Arbeitsprozesse, die sich nicht auf die Verwendung des
33
gesamten Büroraums, sondern nur auf bestimmte Komponenten der Umgebung
beziehen, durch den Zugang zu digitalen Informationen unterstützt werden
sollen.
Zu diesem Zweck müssen Systeme geschaffen werden, die geeignete
Technologien zur virtuellen Erweiterung direkt in Raumkomponenten
integrieren. Ein solches System ist das in der Abteilung Virtual Environments
des Fraunhofer Instituts für Medienkommunikation (IMK.VE) in der
Entwicklung befindliche OfuturO8, das in Zukunft mittels integrierter MR/AR-
Displaytechnologie die Plattform für verschiedene tischbasierte Anwendungen
der Mixed Reality in Büroszenarien bieten soll.
3.2 Aufbau
Abb. 3.2: Konzeptionelle Skizze von OfuturO
8 Der Name OfuturO bezieht sich auf das Office Of The Future-Konzept und leitet sich von dem portugiesischen “O Futuro” ab, was übersetzt “Die Zukunft” bedeutet.
34
Die OfuturO Plattform verfügt über geeignete Aus- und Eingabeschnittstellen,
die es bis zu drei Personen erlauben sowohl zwei- als auch dreidimensionale
digitale Daten zu betrachten und zu bearbeiten. Des Weiteren können
physikalisch entfernte Personen per Videoconferencing mit der Arbeitsgruppe
am OfuturO Tisch in Kontakt treten und so trotz der Entfernung an einer Sitzung
teilnehmen.
In Abbildung 3.2 wird der Großteil der Geräte dargestellt, die bei OfuturO zum
Einsatz kommen, um die gewünschte Arbeitsumgebung zu erzeugen und mit ihr
zu interagieren. Weitere Komponenten, welche dort zum Teil aufgrund der
gewählten Perspektive nicht dargestellt werden konnten, sind ein Spiegel und
Projektoren unterhalb des Tisches sowie eine RGB-Kamera9.
3.2.1 Tisch
Abbildung 3.1 zeigt den OfuturO Tisch kurz nach dem Bau, in einer Phase der
Entwicklung, in der noch keinerlei Display- oder Eingabevorrichtungen
integriert waren. Die Abmessungen des Tisches sind inklusive der seitlich
herausragenden Arbeitsflächen ca. 2,50 m x 3,50 m. Der Tisch ist mit vier
Plätzen ausgestattet, wovon einer als passiver Arbeitsplatz ausgelegt ist.
Die drei verbleibenden Plätze geben ebenso vielen Personen den vollen Umfang
an Interaktionsmöglichkeiten, um an einer OfuturO Sitzung teilzunehmen. Die
Teilnehmer können dort ihre tragbaren Computer anschließen und des Weiteren
über permanent am Arbeitsplatz installierte Eingabegeräte mit dem OfuturO-
System interagieren. Ein solcher Arbeitsplatz ist in Abbildung 3.3 dargestellt.
9 Die auf Abbildung 3.2 nicht dargestellten Komponenten sind in Abbildung 3.4 bzw. Abbildung 3.5 zu sehen.
35
Abb. 3.3: Arbeitsplatz mit Laptop und weiteren Eingabegeräten
3.2.2 Display
Die bei OfuturO verwendeten Vorrichtungen zur Anzeige sind von den
Anforderungen an das System bestimmt. Zum einen soll die Möglichkeit
bestehen zwei- und dreidimensionale Daten darzustellen und mit ihnen zu
arbeiten und zum anderen sollen auch entfernte Personen mittels
Videoconferencing an einer Arbeitssitzung teilnehmen können. Sämtliche in
Abbildung 3.4 aufgezeichneten Anzeigegeräte sowie weitere zur Anzeige
benötigte Vorrichtungen sind mit dem Grafikcomputer verbunden, der die
zentrale Systemkomponente für die Verarbeitung von Aus- und Eingaben ist.
Abb. 3.4: Display Vorrichtungen
36
Videoconferencing Display
Der zum Videoconferencing genutzte Plasmabildschirm hat eine
Bildschirmdiagonale von ca. 1,25 m. Er wird zur Darstellung von Videobildern
entfernter, auf diese Weise an einer Arbeitssitzung teilnehmender Personen
eingesetzt, wobei durch eine in das OfuturO System integrierte Kamera10 das
Videobild der Arbeitsgruppe am OfuturO Tisch aufgenommen wird. Die auf
beiden Seiten durch die Videoaufnahme anfallenden Datenströme werden über
das Internet ausgetauscht, wodurch nahezu eine Live-Präsenz möglich ist.
MR Display
Die über OfuturO dargestellten Daten können entweder zwei- (Dokumente,
Bilder) oder dreidimensional (3D-Objekte) sein. Die Ausgabe der Daten erfolgt
mit bis zu vier Projektoren, die unterhalb des Tisches platziert sind. Dabei
werden zweidimensionale Daten durch Monoprojektionen und dreidimensionale
Daten durch Stereoprojektionen visualisiert. Um eine höhere Auflösung zu
erreichen wird das Projektionsbild aus Halbbildern zusammengesetzt, wobei
jeweils zwei Projektoren die Darstellung eines Halbbildes übernehmen11. Die
höhere Auflösung ist speziell bei Dokumenten notwendig, da diese
hochaufgelöst dargestellt werden müssen um noch lesbar zu sein. Die
Projektoren sind an einem beweglichen Metallgestell befestigt und daher frei
justierbar. Sie zeigen auf einen 1,45 m x 1,30 m großen, schräg ausgerichteten
Spiegel, über den das ausgesendete Licht von unten auf die Projektionsfläche
umgeleitet wird. Dies geschieht um den Projektionsweg zu verlängern, der so
vom Projektor bis zur Projektionsfläche ca. 1,30 m beträgt.
Die Projektionsfläche ist eine in den Tisch eingelassene Platte, die aus einem
speziellen lichtdurchlässigen Material (PVC) besteht und deren Abmessungen 10 Die Videoconferencing-Kamera ist in der Konzeptions-Skizze in Abbildung 3.2 eingezeichnet. 11 Bei Monoprojektionen werden zwei Projektoren genutzt (einer pro Halbbild), bei Stereoprojektionen sind es vier (zwei pro Halbbild).
37
1,48 m x 1,12 m sind. Durch die Verwendung dieser Spezialplatte können
virtuelle Objekte mit einer guten Farbgenauigkeit oberhalb der Platte dargestellt
werden. Im Falle der Anzeige dreidimensionaler Objekte auf der
Projektionsfläche benötigt der Betrachter zur räumlichen Wahrnehmung des
bereits von den Projektoren polarisierten Bildes eine Polarisationsbrille. Die
Darstellung der Perspektive muss dabei auf einen bestimmten
Konferenzteilnehmer ausgerichtet sein. Das bedeutet, dass jeweils nur einem
Teilnehmer zu einer Zeit eine korrekte Perspektive bei einer dreidimensionalen
Darstellung geboten wird.
3.2.3 Eingabegeräte
Jedes zur Interaktion mit dem OfuturO-System genutzte Gerät verfügt über eine
Verbindung zum Grafikcomputer12 (siehe Abbildung 3.5). Die Verbindung zu
den von den Benutzern verwendeten Laptops wird durch den Anschluss an einen
Netzwerk Switch hergestellt, der die Laptops in ein Netzwerk mit dem
Grafikcomputer integriert. Im Gegensatz zu den nicht fest installierten Laptops,
die bei jeder Sitzung neu angeschlossen werden, sind die weiteren Eingabegeräte
permanent mit dem System verbunden. Pro Arbeitsplatz sind jeweils eine
Spacemaus sowie ein Touchpad angebracht, deren Verbindung zum
Grafikcomputer durch einen USB Hub realisiert ist. Außerdem ist eine RGB-
Kamera angeschlossen, die zur Erkennung von Mustern und Gesten eingesetzt
wird.
12 In Abbildung 3.5 wird der Grafikcomputer als Visualisation Server bezeichnet.
38
Abb. 3.5: Eingabegeräte
Die Spacemaus kann aufgrund von sechs Freiheitsgraden zur räumlichen
Steuerung verwendet werden. Somit lassen sich Objekte im Raum platzieren und
in ihm ausrichten, d. h. es können Translationen auf den und Rotationen um die
drei Raumachsen ausgeführt werden. Das Touchpad wird verwendet um
visualisierte zweidimensionale Daten auf der Projektionsfläche zu bewegen.
Darüber hinaus können auf dem Touchpad Gesten ausgeführt werden mit deren
Hilfe visualisierte Daten zwischen den einzelnen Konferenzteilnehmern
verschickt werden können. Die Eingabeverarbeitung mit Hilfe von Spacemaus
und Touchpad innerhalb der OfuturO-Umgebung, wird in Kapitel 4 ausführlich
vorgestellt.
3.3 Software
Um die in die OfuturO Plattform integrierte Hardware zur Erzeugung einer MR-
Umgebung nutzen zu können, ist die Verwendung eines Software-Systems
notwendig, das speziell auf die Erstellung interaktiver virtueller Umgebungen
ausgerichtet ist. Dazu wird Avango, ein Entwicklungssystem für virtuelle
Umgebungen eingesetzt, das im folgenden Abschnitt vorgestellt wird.
39
Avango
Das Software Framework Avango wird seit 1996 in der Abteilung Virtual
Environments des Fraunhofer Instituts für Medienkommunikation (IMK.VE)
entwickelt [IMK03] und dient zur Erstellung verteilter, interaktiver VE
Anwendungen. Es unterstützt eine Vielzahl von Displaykonfigurationen und
Eingabegeräten, zu denen z. B. unterschiedliche Trackingsysteme oder 3D
Interaktionsgeräte zählen. Um so viele menschliche Sinne wie möglich
anzusprechen, kann zur Ausgabe Spezialhardware, wie Vibrationsböden,
Duftzerstäubungssysteme oder 3D-Soundsysteme, verwendet werden. Die in
[Goe01] aufgezählten Anforderungen an ein solches Entwicklungssystem für
virtuelle Umgebungen sind: Performance, Flexibilität, schnelle
Anwendungsentwicklung, Erweiterbarkeit und Portierbarkeit.
Als Basis dient das OpenGL Performer Toolkit der Firma SGI. Darauf baut das
objektorientierte Avango Framework auf, das eine Programmierschnittstelle
(API) in der Sprache C++ zur Verfügung stellt und die Erstellung von
anwendungsspezifischen Klassen erlaubt. Zusätzlich zur C++ API bietet Avango
eine vollständige Anbindung der Interpretersprache Scheme, von der aus alle
high-level Avango Objekte erstellt und manipuliert werden können. Komplexe
und performance-kritische Funktionalitäten werden durch Ableitungen und
Erweiterungen bestehender Avangoklassen in C++ implementiert, während die
typische Avango Anwendung selbst aus einer Sammlung von Schemeskripten
besteht, die Avango-Objekte instanziieren, ihre Methoden anwenden, Werte von
Feldern setzen und die Beziehungen zwischen Objekten definieren. Die
Komponenten der Avango Entwicklungsumgebung werden in Abbildung 3.6
dargestellt.
Abb. 3.6: Avango Entwicklungsumgebung
40
Das auf dem Scene Graph13 Konzept aufbauende Programmiermodell von
Avango wird in [Tra98] beschrieben. Die C++ API erlaubt die Definition zweier
verschiedener Kategorien von Objektklassen; Nodes bieten eine objektorientierte
Scene Graph API, die die Repräsentation und die Darstellung komplexer
Geometrien ermöglicht, während Sensors Avango’s Schnittstellen zur realen
Welt sind und benutzt werden, um externe Gerätedaten in eine Anwendung zu
importieren. Alle Avango-Objekte werden als so genannte Fieldcontainer
bezeichnet, welche den Status von Objekten als eine Sammlung von Feldern
repräsentieren.
3.4 Anwendungen
In Zukunft soll die OfuturO Plattform als Grundlage für diverse tischbasierte
MR-Anwendungen dienen. Die noch in der Entwicklung befindliche Prototyp-
Anwendung ist das in nächsten Abschnitt vorgestellte MR Conferencing System.
Noch in der Planungsphase befindet sich als weitere Anwendung eine
Mindmapping14 Software, die als Tangible User Interface (TUI) realisiert
werden soll. Dabei werden die Ideen der Teilnehmer eines Brainstormings von
diesen auf digitalen Karten notiert, um danach in eine globale Darstellung
eingegliedert zu werden, die über die Projektionsfläche von OfuturO angezeigt
und für eine Gruppendiskussion freigegeben wird. Die Gruppenbewertung der
Ideen wird durch TUI phicons15 markiert, die neben der Projektion der Idee zu
platzieren sind und mit Hilfe einer Mustererkennungssoftware vom OfuturO-
System interpretiert werden können. Als Beispiel kann ein auf das phicon
gezeichnetes “Mülleimer”-Symbol für eine nicht akzeptierte, zu verwerfende
Idee stehen, ein “Daumen nach oben”-Symbol wäre ein Beispiel für eine
beizubehaltende Idee.
Im nächsten Schritt werden die Bewertungen vom System eingelesen und je
nach dem, wie sie ausgefallen sind, verworfen oder beibehalten. Eine
tiefergehende Beschreibung der Mindmapping Anwendung für OfuturO findet 13Der Scene Graph ist eine baumartige Struktur welche die Beschreibung eines virtuellen Universums enthält. Dieses Modell wird auch bei anderen stand-alone APIs wie z.B. Java 3D [Mic03] verwendet 14 Eine Mindmapping Software assistiert bei der Sammlung und Gliederung von Ideen und Gedanken. 15 phicon = physical icon. In diesem Fall entspricht ein phicon einem Kärtchen auf dem ein der Bewertung entsprechendes Piktogramm aufgezeichnet ist.
41
sich in [GKG+03]. Verwandte Projekte sind der DigitalDesk [Wel 93], der
KoKoBel [Fit 03] sowie der metaDESK [IU97a], [IU97b]
3.5 Der Mixed Reality Conferencing Prototyp
Durch die erweiterten Visualisierungs- und Interaktionsmöglichkeiten im
Bereich Mixed Reality ergeben sich für die als tischbasiertes System konzipierte
OfuturO Plattform zahlreiche Anwendungsmöglichkeiten zur Unterstützung von
Arbeitsprozessen im Bürobereich. Die Motivation für die Entwicklung der
Prototyp-Anwendung für OfuturO, einem Mixed Reality Conferencing System,
ist die Nutzung der angebotenen erweiterten Darstellungs- und
Interaktionsmöglichkeiten zur Schaffung eines verbesserten multimedialen
Konferenzszenarios.
An einer Konferenz nehmen Mitarbeiter im Rahmen von Firmenprojekten teil,
denen es um die Besprechung von Arbeitsergebnissen oder die Vorstellung von
Ideen und Konzepten geht. Durch ein traditionelles Konferenzszenario wird in
der Regel ein ganzer Meetingraum belegt, in dem neben einem Konferenztisch,
um den sich die Teilnehmer versammeln, ein Projektor enthalten ist, der sich für
die Präsentation von Folien oder elektronischen Dokumenten eignet, die auf eine
Wandfläche projeziert werden. Präsentationen finden in der Form eines Vortrags
statt, den die vortragende Person zunächst zu Ende führt, bevor im Anschluss
eine Besprechung mit den Zuhörern folgt, in der Fragen gestellt und
Verbesserungsvorschläge angebracht werden. Sollten aufgrund der Diskussion
Änderungen an digitalen Inhalten der Präsentation notwendig werden, so fehlen
oft die Mittel diese unmittelbar innerhalb der Konferenz umzusetzen.
Die Änderungsvorstellungen werden stattdessen an den zuständigen Mitarbeiter
weitergegeben, der diese zu einem späteren Zeitpunkt an seinem gewöhnlichen
Arbeitsplatz implementiert. Damit die Zuhörer die Auswirkungen von
Änderungen begutachten können, ist auf diese Weise eine weitere Präsentation
nötig, in der der aktualisierte Inhalt vorgestellt wird. Die Nachteile der
traditionellen Konferenzumgebung sind:
42
- Die Darstellungsmöglichkeiten sind auf zweidimensionale Informationen
beschränkt und eignen sich daher für Dokumente und Bilder, aber nicht für
dreidimensionale Objektmodelle.
- Durch das eingesetzte Projektionssystem besteht ein hoher Platzbedarf, in der
Regel wird ein ganzer Meetingraum belegt. Aufgrund fehlender
Interaktionsmöglichkeiten können Änderungsvorstellungen an digitalen
Präsentationsinhalten oft nicht unmittelbar umgesetzt werden.
Der Anspruch des Mixed Reality Conferencing Prototypen ist die Entwicklung
eines Konferenzkonzepts, das keinen der aufgezählten Nachteile enthält. Die
Reduzierung des Platzbedarfs wird durch die Basierung auf der OfuturO
Plattform erreicht, da das direkt integrierte Rückprojektionssystem keinen
zusätzlichen Raum benötigt und so lediglich die Fläche eines großen
Arbeitstisches (2,5 m x 3,5 m) beansprucht wird. Daher kann eine solche
Konferenzumgebung anstatt einen separaten Raum zu belegen in einem
gewöhnlichen Büroraum untergebracht werden, der für weitere Aufgaben
nutzbar bleibt.
Abb. 3.7: Vergleich von Konferenzszenarien
Durch das zur Wiedergabe von zwei- als auch dreidimensionalen Informationen
geeignete Rückprojektionssystem werden die Darstellungsmöglichkeiten um die
Anzeige entsprechender Präsentationsdaten als dreidimensionale Objekte
erweitert. Die Darstellung von Präsentationsinhalten erfolgt im für alle
Teilnehmer gut einsehbaren Zentrum des OfuturO Tisches auf der dort
angebrachten Projektionsfläche.
43
Die für Präsentationen bestimmten Daten bringen die Teilnehmer mit ihren
eigenen portablen Computern zur Konferenz mit, auf denen die
Präsentationsinhalte in Datenbankarchiven organisiert sind. Diese Laptops
werden an den OfuturO Arbeitsplätzen angeschlossen und damit untereinander
und mit einem Rechner, der das Visualisierungssystem steuert, vernetzt. Zur
Wiedergabe der Präsentationsdaten wird das OfuturO Projektionssystem mit den
Datenbankarchiven der Laptops kombiniert, indem die zur Präsentation
bestimmten Informationen an den Visualisierungsrechner weitergegeben werden.
Durch die Vernetzung der Laptops können Daten unter den Teilnehmern
ausgetauscht werden.
Abb. 3.8: Verbindung von Datenbankarchiven und Projektionssystem
Werden Präsentationsinhalte durch das OfuturO System visualisiert, so bestehen
verschiedene Möglichkeiten mit diesen zu interagieren und sie zu manipulieren.
Dabei werden die Laptop Computer der Teilnehmer als Interaktionskonsolen
verwendet, weitere Interaktionsmöglichkeiten bestehen durch die fest an den
OfuturO Arbeitsplätzen installierten Eingabegeräte, wie dem Touchpad zur
Interaktion mit zweidimensionalen und der Spacemaus zur Interaktion mit
dreidimensionalen Inhalten. Mit diesen Interaktionsmöglichkeiten können die
Teilnehmer die Darstellungsart der präsentierten Informationen beeinflussen,
44
indem sie z. B. in Echtzeit die perspektivische Ansicht von einem
dreidimensionalen Modell ändern, um das Modell von allen Seiten zu
betrachten. Sollen Änderungen an den digitalen Inhalten vorgenommen werden,
können Präsentationsdaten auf Laptops transferiert werden, um sie dort mit einer
geeigneten Anwendung den Vorstellungen anzupassen und die angepasste
Version anschließend wieder dem Visualisierungssystem zu übergeben. Damit
besteht die Möglichkeit der direkten Manipulation von digitalen Daten
unmittelbar im Rahmen einer Konferenz. Des Weiteren vereinfacht das MR
Conferencing System die Aufbewahrung von Präsentationsinhalten, da die Daten
problemlos auf Wunsch in das eigene Datenbankarchiv integriert werden
können.
Zur Interaktion und zum Datenaustausch sollen auch Gesten genutzt werden,
denen das System entsprechende Befehle zuordnet. Diese Gesten können
entweder über die Eingabegeräte oder durch körperbezogene Aktionen der
Teilnehmer (in der Regel Handgesten) ausgeführt werden. Handgesten werden
dabei von einer RGB-Kamera aufgenommen und durch ein
Bildverarbeitungssystem interpretiert.
Um externe Partner mit einzubeziehen, die nicht lokal an der Konferenz
teilnehmen können, wird das OfuturO Videoconferencing Display verwendet.
Den externen Konferenzpartnern sollen dabei durch die Integration in das
Konferenznetzwerk die gleichen Möglichkeiten zur Interaktion und zur
Manipulation von Präsentationsinhalten zur Verfügung stehen.
Ein Nachteil des MR Conferencing Systems ist die Beschränkung auf drei
Arbeitsplätze durch die Vorgaben der OfuturO Plattform, da nur ebenso viele
Personen (abgesehen von externen Konferenzpartnern) an einer Konferenz
teilnehmen können. Aufgrund dieser Beschränkung eignet sich das System am
Besten zu einer Besprechung unter Spezialisten, die auch in einem kleinen
Personenkreis in der Lage sind zu einem guten Ergebnis zu kommen.
Die Entwicklung der Softwarebasis für das MR Conferencing System, durch die
die beschriebenen Möglichkeiten zur Visualisierung von Präsentationsinhalten
und zum Austausch der Daten realisiert werden, wird in [Gal03] ausführlich
dargelegt.
45
3.5.1 Beschreibung eines Konferenzszenarios
Bei dem Ablauf einer Konferenz auf der Basis der MR Conferencing Prototyp-
Anwendung bestehen diverse Möglichkeiten für die Teilnehmer, um Daten zu
präsentieren oder untereinander auszutauschen. Die Mittel und Wege zur
Vorstellung und zum Austausch von Präsentationsinhalten werden in dem nun
folgenden Abschnitt beschrieben.
Zunächst verteilen sich die Konferenzteilnehmer auf die Arbeitsplätze von
OfuturO und schließen dort ihre Laptop Computer an ein Netzwerkkabel an.
Dies verbindet die Laptops sowohl untereinander als auch mit dem
Grafikcomputer der OfuturO Plattform, an dem das Projektionssystem
angeschlossen ist. Nun besteht eine Verbindung zwischen den
Datenbankarchiven, in denen auf den Laptops die Präsentationsinhalte verwaltet
werden und dem Visualisierungssystem von OfuturO (siehe Abbildung 3.8).
Diese Verbindung wird von der in [Gal03] beschriebenen Softwarebasis des MR
Conferencing Prototypen, der Visualisierungs- und Kommunikationsschnitt-
stelle, zur Weitergabe von digitalen Präsentationsinhalten an das
Projektionssystem genutzt. Die Software verfügt neben einer Schnittstelle zu
dem Datenbankarchiv auch über mehrere Schnittstellen zum Netzwerk und bietet
so die benötigten Transportwege für die Daten. Mit Hilfe der Software können
die Laptops nun als Interaktionskonsolen bei einer Konferenz verwendet werden,
da sämtliche den Teilnehmern zur Verfügung stehenden Optionen, um in eine
Präsentation einzugreifen, in der Software implementiert sind. Als weitere
Interaktionsgeräte befinden sich an jedem Arbeitsplatz eine Spacemaus sowie
ein Touchpad, die den Teilnehmern alternativ zur Verfügung stehen, um
Aktionen der Software auszulösen und so mit dem MR Conferencing System zu
interagieren.
Die Visualisierungs- und Kommunikationsschnittstelle besteht aus
verschiedenen Komponenten, die über alle Rechner des Netzwerks verteilt sind,
sowohl auf die Laptops als auch auf den Visualisierungsrechner. Auf den
Laptops steht den Teilnehmern eine grafische Benutzeroberfläche (GUI) zur
Verfügung, mit der sie sich am Konferenzsystem anmelden und über die sie
sämtliche Conferencing Funktionen abrufen können. Da in der GUI die
Schnittstelle zur Datenbank integriert ist, hat der Benutzer Zugriff auf
46
Präsentationsdaten enthaltende Datensätze und kann so über die GUI die
gewünschten Informationen selektieren. Gewählte Daten kann er dann entweder
zur Präsentation freigeben oder mit anderen Teilnehmern austauschen; beides
geschieht, indem die Daten zu einer an die GUI angegliederten
Netzwerkschnittstelle weitergegeben werden. Die Software besteht neben der
GUI-Netzwerkschnittstelle aus einer weiteren Netzwerkkomponente, die in
einen Programmteil integriert ist, der auf dem Visualisierungsrechner ausgeführt
und als GVM Server bezeichnet wird. Die Abkürzung GVM steht für Global
View Manager, ein Oberbegriff für die Programmkomponenten, die über einen
Zugang zum Visualisierungssystem verfügen, worunter neben dem GVM Server
auch die GUI-Netzwerkschnittstelle fällt, welche den Namen GVM Interface
trägt. Dem auf der Seite des Visualisierungsrechners angesiedelten Programmteil
GVM Server sind einige wichtige Aufgaben des Konferenzsystems zugewiesen.
Er nimmt Präsentationsinhalte von dem GVM Interface entgegen, die visualisiert
werden können, indem der GVM Server eine geeignete Anwendung zur
Darstellung von Dokumenten, Bildern oder dreidimensionalen Daten startet, die
mit Hilfe des Projektionssystems wiedergegeben wird. Des Weiteren verwaltet
der GVM Server Informationen, die zur Koordination des Systems benötigt
werden, z.B. welche Präsentationsinhalte gerade dargestellt werden oder welche
Teilnehmer am System angemeldet sind. Abbildung 3.9 zeigt die Vernetzung der
Softwarekomponenten untereinander auf.
Abb. 3.9: Vernetzung der Softwarekomponenten
Im Rahmen einer Konferenz stehen den Teilnehmern verschiedene
Möglichkeiten zur Verfügung, Präsentationsinhalte weiterzugeben. Dazu finden
47
Datentransfers zwischen den an das System angeschlossenen Rechnern statt, die
in drei Arten von Datenströmen unterteilt werden können:
- Zur Visualisierung von Präsentationsinhalten / Upload von Laptop zu
Visualisierungsrechner
- Übernahme und lokale Sicherung von Präsentationsinhalten!Download von
Visualisierungsrechner zu Laptop
- Zur direkten Datenweitergabe von Teilnehmer zu Teilnehmer ! Transfer von
Laptop zu Laptop
Wenn ein Teilnehmer die Absicht hat, der Gruppe Informationen aus seinem
Datenbankarchiv zu präsentieren, kann er diese unter Verwendung der GUI
selektieren und zur globalen Anzeige durch das Projektionssystem freigeben.
Die Daten werden nun in einen so genannten “Shared Workspace” (geteilten
Arbeitsraum) kopiert, in dem sich alle gerade zur globalen Anzeige freigegeben
Daten befinden. Dieser geteilte Arbeitsraum wird vom GVM Server verwaltet,
der in der Lage ist, den Typ (Dokument, Bild oder 3D Objekt) der über die
Netzwerkschnittstelle entgegen genommenen Daten zu identifizieren.
Zur Darstellung der Daten startet der GVM Server eine geeignete Anwendung,
die der Visualisierungsrechner über das Projektionssystem, global und für die
ganze Konferenzgruppe sichtbar, wiedergibt (Abbildung 3.10).
Abbildung 3.10: Visualisierung von Präsentationsinhalten
Der Zugriff auf gerade angezeigte Präsentationsinhalte ist den Teilnehmern
entweder möglich, indem sie deren Darstellung für zweidimensionale Daten mit
Hilfe des Touchpads oder für dreidimensionale Daten mit Hilfe der Spacemaus
beeinflussen (durch Translationen, Rotationen oder Skalierungen der
48
dargestellten Informationen) oder, indem sie die Daten auf ihren Laptop
kopieren, um diese dort mit erweiterten Manipulationsmöglichkeiten bearbeiten
zu können.
Das Erstellen einer solchen Kopie erfordert den Download der Daten vom
Visualisierungsrechner auf den Laptop, der durch einen Datentransfer zwischen
dem GVM Server und dem GVM Interface erreicht wird (Abbildung 3.11).
Abb. 3.11: Download von Präsentationsinhalten
Wenn Informationen weitergegeben, aber nicht visualisiert werden sollen, weil
sie lediglich als “Präsentationsbeilage” verteilt werden oder weil sie eventuell
nicht für die Sichtung durch die gesamte Gruppe bestimmt sind, haben die
Teilnehmer die Möglichkeit, Daten direkt untereinander auszutauschen.
Ein solcher direkter Datentransfer findet zwischen zwei Laptops statt, genauer
gesagt werden die Daten von GVM Interface zu GVM Interface übertragen
(Abbildung 3.12).
Abb. 3.12: Direkter Transfer von Informationen
Die beschriebenen Operationen zum Austausch und zur Visualisierung von
Präsentationsinhalten werden entweder durch die Anwahl entsprechender GUI
Optionen mit dem Laptop oder über die Gestenerkennung auf dem Touchpad
realisiert. Zur Eingabe mit Hilfe des Touchpads werden bestimmte Gesten
interpretiert, denen bestimmte Aktionen zugeordnet sind.
Abgesehen von der am OfuturO Tisch arbeitenden Konferenzgruppe können
weitere Personen teilnehmen, die durch das OfuturO Videoconferencing Display
einbezogen und deren Workstations über das Internet mit dem System
verbunden werden. In Bezug auf die Austauschmöglichkeiten von Daten sind
Videoconferencing Teilnehmer gleichgestellt.
49
3.5.2 Entwicklungsstand
Der MR Conferencing Prototyp ist nur zum Teil fertig gestellt und befindet sich
somit noch in der Entwicklungsphase. Die Softwarebasis, die Visualisierungs-
und Kommunikationsschnittstelle, ist zu einem großen Teil implementiert.
Dadurch können bereits Daten auf den zuvor beschriebenen Wegen unter
vernetzten Rechnern ausgetauscht und zur Wiedergabe an den
Visualisierungsrechner weitergegeben werden.
Die Hardwaregrundlage OfuturO befindet sich noch im Aufbau, eine große
Lücke lässt das zurzeit noch fehlende Projektionssystem offen. Aufgrund dessen
können die Präsentationsinhalte bis jetzt lediglich auf einem zweidimensionalen
Display wiedergegeben werden und die Möglichkeit der Darstellung
dreidimensionaler Objekte auf der Projektionsfläche ist noch nicht vorhanden.
Die Wiedergabe von Präsentationsinhalten geschieht derzeit durch das Öffnen
der Daten in einer jeweils dazu geeigneten Anwendung und der gleichzeitigen,
aber voneinander getrennten Darstellung. Dies ist nur eine Übergangslösung, da
die Daten nicht in verschiedenen separaten Anwendungen angezeigt werden
sollen, sondern in einer Anwendung, die alle Daten in einer virtuellen
Umgebung integriert. Dieses Vorhaben wird mit dem Software Framework
Avango realisiert werden.
50
Kapitel 4
Die Eingabegeräte
In diesem Kapitel werden die Eingabegeräte beschrieben, die im Rahmen dieser
Diplomarbeit eingesetzt wurden. Dazu wird zunächst auf die Grundlagen
eingegangen, auf denen ein Einbinden von Interaktionsgeräten in die OfuturO-
Umgebung aufbaut. Anschließend werden die Vorgaben, die für die Auswahl der
Geräte aufgrund der Anforderungen an sie vorlagen, erläutert. Im Anschluss
daran, werden die Eingabegeräte selbst vorgestellt.
4.1 Grundlagen
Avango
Als Softwaregerüst zur Entwicklung virtueller Welten unterstützt Avango
selbstverständlich auch die Eingabe über Hardwaregeräte. Zu diesem Zweck
stehen Klassen bereit, die bereits grundlegende Voraussetzungen zum Auslesen
von Geräten und dem Weiterleiten ihrer Daten an die instanziierten Zielobjekte
erfüllen. Um vordefinierte Fähigkeiten für ein eigenes Eingabegerät zu nutzen
leitet der Entwickler seine Klasse von einer bereits bestehenden Avango-
Geräteklasse ab, beispielsweise die Klasse fpSerialDevice wenn es sich bei dem
anzusprechenden Gerät um ein serielles Gerät handelt, und erweitert diese
Klasse seinen Wünschen entsprechend.
Das Übertragen der von den Avango-Geräteklassen ausgelesenen Daten erfolgt
über einen speziellen Hintergrundprozess, den av-daemon. Zu diesem Zweck
muss der av-daemon separat gestartet und ihm die Instanzen der entsprechenden
Geräteklasse übergeben werden. Die Daten, die diese Klassen dann auslesen,
werden vom Dämon in ein spezielles Speichersegment übertragen, welches von
Objekten einer Avango-Applikation abgerufen werden kann. Der av-daemon
51
dient somit quasi als Übermittler zwischen Geräten und der eigentlichen
Avango-Applikation.
Geräte unter Linux
Sowohl der av-daemon, als auch die Avango-Applikation, die bei Fertigstellung
der OfuturO-Umgebung zur Darstellung der virtuellen Objekte eingesetzt wird,
laufen auf dem Visualisierungsserver. Da auf diesem das Betriebssystem Linux
zum Einsatz kommt, müssen die Gerätedaten von den Avango-Geräteklassen aus
so genannten Gerätedateien ausgelesen werden. Gemäß der Linux/ Unix
Paradigmen wird sämtliche Hardware als Datei abstrahiert. Eine detaillierte
Darstellung, wie Gerätedateien programmiertechnisch behandelt werden können
findet sich unter anderem in [Her03].
Die Aufgabe des Datenübermittlers vom Gerät in die zugehörige Gerätdatei
übernimmt dabei ein so genannter Gerätetreiber, eine Softwareimplementation,
die den Übergang von der reinen Hardwarefunktionalität des Gerätes auf seine
Abstraktion als Datei darstellt. Eine genauere Erläuterung zur Rolle und
Funktionsweise von Gerätetreibern erfolgt im nächsten Kapitel.
Der Universal Serial Bus
Bei den einzubindenden Spacemäusen und Touchpads handelt es sich
ausnahmslos um USB-Geräte. Die Datenübertragung beim USBus findet über
eine Kommunikation des Geräts mit dem so genannten Host-Controller statt.
Der Host-Controller verwaltet die gesamte Kommunikation auf dem USBus,
wie das Senden und Empfangen von Daten, das Bereitstellen der benötigten
Bandbreite für die Übertragung und das Registrieren eines neuen Gerätes.
Hat der Host ein neues Gerät registriert, so wird eine Anfrage an das Gerät
versandt, die eine Datenstruktur Namens Gerätedeskriptor vom Gerät erfragt.
Die Datenstruktur enthält gerätespezifische Informationen, unter anderem die
Hersteller- und Produktnummer und die Information über die Anzahl der
Konfigurationen, die das Gerät zur Verfügung stellt. Jedes Gerät kann dabei eine
52
bis mehrere mögliche Konfigurationen aufweisen. Mehrere Konfigurationen
können beispielsweise nötig sein wenn ein Gerät in verschiedenen Modi oder auf
unterschiedliche Arten betrieben werden kann. Die Konfigurations-
informationen16 sind in den Konfigurationsdeskriptoren enthalten, die der Reihe
nach für jede Konfiguration vom Host angefordert werden. Jede Konfiguration
kann ein bis mehre Interfaces enthalten. Jedes Interface kann ein spezielles
Feature innerhalb einer möglichen Gerätekonfiguration darstellen. Auch hier
werden die Informationen über das Interface wieder über einen Deskriptor, den
Interfacedeskriptor vom Host angefordert. Innerhalb eines Interfaces schließlich
können ein bis mehrere Kommunikationsendpunkte, auch endpoints genannt
enthalten sein. Ein endpoint ist der Speicherbereich in der Gerätehardware, in
den zu versendende oder empfangene Daten abgelegt werden und jede
Kommunikation des Hosts mit einem USB- Gerät findet letztlich über einen
endpoint statt.
Ein endpoint ist normalerweise nur entweder für die Datenübertragung vom Host
zum Gerät (Out- endpoint) oder vom Gerät zum Host (In- endpoint) ausgelegt.
Die Ausnahme bildet der endpoint mit der Nummer 0 über den jedes Interface
verfügen muss und der bidirektional arbeitet. Über diesen endpoint werden beim
Anschluss eines USB- Gerätes Daten mit dem Host ausgetauscht: Einerseits
kann der Host darüber die Information über das Gerät in Form der einzelnen
Deskriptoren beschaffen. Andererseits kann der Host aber auch selbst Daten an
das Gerät senden und dieses mit Hilfe dieser Daten konfigurieren. Auch die
endpoint-Informationen sind wieder in einem Deskriptor hinterlegt, so dass sich
insgesamt die in Abbildung 4.1 gezeigte Deskriptorhyrarchie ergibt.
16 Darunter befindet sich beispielsweise die Information ob es sich beim Gerät um ein selbst mit Strom versorgendes oder vom Bus mit Strom versorgtes Gerät handelt.
53
Abb. 4.1: Deskriptorhyrarchie zur Beschreibung eines USB- Gerätes aus [Lin03]
Die Kommunikation zwischen Host und endpoint findet über Pipes17 statt. Dabei
werden vier verschiedene Arten von Nachrichtentransfers vom USB-Protokoll
unterstützt. Genaueres dazu, findet sich im Rahmen einer detaillierten
Beschreibung der USB-Technologie unter [Axe99].
Sämtliche Transfers werden programmiertechnisch mittels nur einer speziellen
Datenstruktur realisiert, dem USB Request Block, auch URB genannt. In dieser
Datenstruktur werden alle für eine Datenübertragung relevanten Informationen
abgelegt und anschließend dem USB-Subsystem bekannt gemacht. Nachdem der
URB dem USB-Subsystem übergeben wurde, kümmert sich dieses selbstständig
um alle damit verbundenen Datentransfers. Informationen zur Arbeit mit URBs
finden sich unter [Gui03], Informationen zu USB unter Linux erhält man unter
[Lin03].
4.2 Vorgaben
An erster Stelle der Überlegungen zur Einbindung der Eingabegeräte in die
OfuturO-Umgebung stand die Auswahl der geeigneten Eingabegeräte. Dabei
waren folgende Vorgaben für geeignete Eingabegeräte zum Ermöglichen von
Interaktionen in der OfuturO- Umgebung gegeben:
17 Eine Pipe ist ein logischer Datenkanal, der zur Datenübermittlung genutzt werden kann.
54
• Zwei verschiedene Eingabegeräte, von denen eines in Form eines
Touchpads der Navigation in der Ebene und das andere in Form einer
Spacemaus der Navigation im Raum dienen soll.
• Auf den Touchpads sollen unterschiedliche Gesten ausgeführt werden
können, denen die bereits beschriebenen Aktionen des Versendens von
Dokumenten von einer Workstation zur anderen, sowie des Versendens
von zu visualisierenden Daten an den Visualisierungsserver zugewiesen
werden können.
• Um Unterscheidungen zwischen den Aktionen zur Bewegung von
visualisierten Daten und den speziellen Gesten machen zu können muss
das Touchpad mindestens einen Button aufweisen, um zwischen beiden
Kommandoarten umschalten zu können.
• Die Spacemaus soll zusätzlich mindestens zwei Buttons aufweisen um
den Eingabe- und Visualisierungsfokus einer der maximal zwei weiteren
Workstations zuweisen zu können.
• Beide Geräte sollen noch voll funktionsfähig sein, nachdem sie in den
Konferenztisch der OfuturO-Hardwareumgebung eingearbeitet worden
sind.
• Schließlich müssen sämtliche Geräte über einen USB-Stecker verfügen
damit sie über einen Hub am USB-Port des Visualisierungsservers
angeschlossen werden können.
4.2.1 Das Cirque USB Easy Cat Touchpad
Für das Touchpad wurde das USB Easy Cat Touchpad der Firma Cirque
gewählt. Das USB Easy Cat Touchpad von Cirque misst etwa 8,5 cm x 7 cm.
Die Sensorfläche bietet mit Dimensionen von 6 cm x 4.5 cm eine
55
Bewegungsfläche von 27 cm2. Die Bewegungsfläche überschneidet sich dabei
mit einem schmalen Scrollfunktionsbereich entlang der rechten Seitenlinie,
sowie einem kleinen dreieckigen Bereich in der oberen linken Ecke. Dieser
Bereich schneidet sich zugleich auch mit dem Scrollfunktionsbereich.
Die Funktionen aller Bereiche sind bereits hardwaremäßig in die
Touchpadkonstruktion integriert. Neben der Sensorfläche weist das Touchpad
noch zwei Buttons auf, die sich unterhalb der Sensorfläche befinden. Beide
Buttons lassen sich leicht auch während einer Bewegungsausführung auf der
Sensorfläche mit dem Daumen bzw. kleinen Finger erreichen und bedienen.
Bei jeder Aktivierung einer Funktion sendet das Touchpad ein Datenpaket von 8
Bytes. Leichtes Berühren der Sensorfläche verändert die Werte für die X- und Y-
Koordinaten, die im 2. und 3. Byte angezeigt werden. Die Werte die dabei
übertragen werden stellen keine Absolutwerte dar, sondern zeigen die
Geschwindigkeit, mit der eine Geste über die Fläche geführt worden ist auf,
indem die Zeitintervalle interpretiert werden, innerhalb derer die Berührung
eines Sensorpunktes zum nächsten ausgeführt wurde. Bei den Werten handelt es
sich um vorzeichenbehaftete ganze Zahlen. Der Wertebereich liegt zwischen -
128 für sehr schnelle Bewegungen in Richtung des negativen Bereiches im
Koordinatensystem und +127 für sehr schnelle Bewegungen in Richtung des
positiven Bereiches im Koordinatensystem. Zweimaliges kurz hintereinander
erfolgendes Antippen der Touchpadoberfläche zeigt das Ausführen eines
Buttondruckes im 1. Byte des Datenpakets an, ebenso wie bei Betätigen eines
der beiden Buttons. Bei Betätigen des linken Buttons wird dabei eine 9
übertragen, Betätigen des rechten Buttons hat die Übertragung einer 10 zur
Folge. Wurden beide Buttons gleichzeitig gedrückt, zeigt das erste Byte dies mit
einer 11, wurde kein Button betätigt mit einer 8 als Wert an. Bei einer Imitation
eines Buttondruckes durch zweimaliges Tippen auf die Sensoroberfläche
entscheidet der Bereich in dem die Geste erfolgte darüber welcher Button als
gedrückt interpretiert wird:
Für den rechten Button steht die obere dreieckige Fläche, für den linken Button
die gesamte restliche Fläche zur Verfügung.
Das vierte Byte ist für die Scrollfunktion des Touchpads reserviert, der Wert
dieses Bytes beträgt 1 wenn nach oben gescrollt und -1 wenn nach unten
gescrollt wurde. Wird nicht gescrollt beträgt der Wert 0.
56
Abb. 4.2: Easy Cat Touchpad von Cirque
4.2.2 Die Magellan Spacemaus Plus
Für die Spacemaus wurde die Magellan Spacemaus Plus der Firma LogiCad3D
GmbH gewählt. Die Magellan Spacemaus Plus ist eine Entwicklung des
Deutschen Zentrums für Luft- und Raumfahrt und besteht aus einer ergonomisch
geformten Auflagefläche für die Hand und einer darauf angebrachten ca. 2,5 cm
hohen Kappe mit einem Durchmesser von etwa 6 cm. Die Kappe ersetzt dabei
den Control Ball, einen kleinen Gummiball der zur Steuerung bei den
Vorgängern der Spacemaus Plus eingesetzt wurde. Den Grund für das
Bevorzugen einer Kappe anstelle eines Balles zur Steuerung von virtuellen
Objekten im Raum gibt der Vertreiber der Spacemaus Plus, die LogiCad3D
GmbH selbst wie folgt an18:
“As Magellan/ SPACE MOUSE is the legal successor of DLR’s (German
Aerospace Research Establishment) former, worldwide patented control ball, the
question arises occasionally, why a cap has replaced the original ball form. The
answer is based on extensive ergonomic studies. We found out that for optimally
operating a ball, the palm area is not used either, but preferably only the finger
tips. So it is no disadvantage that the flat cap design makes it impossible to
enclose the cap firmly with the hand’s inner surface; on the contrary the flat cap
allows the human hand to rest on the table in a natural and non-fatiguing,
relaxed way, and to use three or four finger tips spread around the cap to
18 Siehe auch [Log99], Seite 5.
57
slightly shift and twist it. Of course it does not matter wheather the right or left
hand is used, and of course no wrist or even shoulder movements are needed.”
Tatsächlich lässt sich die Kappe sehr leicht nur mit den Fingerspitzen dirigieren.
Sie ist dazu an der Oberseite abgeflacht und besitzt Ausbuchtungen an der
rechten und linken Vorderseite, die einen verbesserten Halt für die führenden
Finger ermöglichen. Rechts und links von der Kappe befindet sich außerdem
jeweils ein abgeflachter länglicher Button. Diese Buttons sind so platziert, dass
sie vom Daumen bzw. kleinem Finger der Hand benutzt werden können,
während diese gerade die Kappe führt. Sie sind daher möglicherweise
prädestiniert für die Funktion eines Moduswechsels, der während einer
Bewegungsausführung erfolgen soll ohne den Arbeitsablauf zu unterbrechen.
Oberhalb der Kappe befinden sich auf der Auflagefläche noch neun weitere
Buttons die in zwei Querreihen angeordnet sind. Von den neun Buttons sind acht
von eins beginnend durchnummeriert, der neunte trägt ein Sternsymbol und ist
somit als Sonderbutton ausgezeichnet. Alle Buttons sind sowohl abrufbar (die
Funktion der Buttons ist also frei programmierbar) haben aber bereits auch eine
hardwaremäßig implementierte Funktion. Jede dieser Funktionen wird dabei
durch Kombination des Drucks auf den Sonderbutton mit einem der acht
Auswahlbuttons aktiviert. Die Funktionen die in der Hardware der Spacemaus
Plus implementiert sind, werden im Folgenden kurz aufgezeigt19:
Sonderbutton kombiniert mit erstem Auswahlbutton:
Die Datenübermittlung für die Translationen wird unterdrückt bzw. eingeschaltet
(Voreinstellung ist eine eingeschaltete Translationsdatenübermittlung).
Sonderbutton kombiniert mit zweitem Auswahlbutton:
Die Datenübermittlung für die Rotationen wird unterdrückt bzw. eingeschaltet
(Voreinstellung ist eine eingeschaltete Rotationsdatenübermittlung).
19 Siehe auch [Log99], Seite 14
58
Sonderbutton kombiniert mit drittem Auswahlbutton:
Der Dominant Modus wird aktiviert bzw. deaktiviert. Im Dominant Modus
werden feine Bewegungen an der Kappe ignoriert. (Voreinstellung ist ein
deaktivierter Dominant Modus).
Sonderbutton kombiniert mit viertem Auswahlbutton:
Die Translations- und Rotationswerte werden auf Null gesetzt.
Sonderbutton kombiniert mit fünftem Auswahlbutton:
Der Sensibilitätswert für die Translationsbewegungen wird jedes Mal beim
Drücken dieser Kombination um eins erhöht. Der Wert kann 7 nicht
überschreiten. Ein weiterer Versuch den Wert zu erhöhen wenn er bereits auf 7
gesetzt ist lässt ihn wieder auf 0 zurückfallen (Voreinstellung ist ein
Sensibilitätswert von 0).
Sonderbutton kombiniert mit sechstem Auswahlbutton:
Der Sensibilitätswert für die Rotationsbewegungen wird jedes Mal beim
Drücken dieser Kombination um eins erhöht. Der Wert kann 7 nicht
überschreiten. Ein weiterer Versuch den Wert zu erhöhen wenn er bereits auf 7
gesetzt ist lässt ihn wieder auf 0 zurückfallen (Voreinstellung ist ein
Sensibilitätswert von 0).
Sonderbutton kombiniert mit siebtem Auswahlbutton:
Der Sensibilitätswert für die Rotationsbewegungen (Nullradiuswert) wird jedes
Mal um eins erhöht. Erreicht der Wert 15 fällt er bei weiterem
Erhöhungsversuch zurück auf 0 (Voreinstellung ist ein Nullradiuswert von 8).
Sonderbutton kombiniert mit achtem Auswahlbutton:
Die Sensibilitätswerte für die Rotationen und Translationen werden auf ihre
voreingestellten Werte zurückgesetzt, was bedeutet, dass der
Translationssensibilitätswert auf 0 und der Rotationssensibilitätwert auf 8 gesetzt
werden.
59
Jede aktivierte Funktion wird von der Spacemaus Plus durch einen Doppelten
Signalton rückgemeldet. Das Ausschalten einer Funktion wird dagegen durch ein
einfaches Signal bestätigt. Die Sensibilitätswerte bestimmten das Maß in dem
sich eine Bewegung der Kappe auf die Bewegungsdaten auswirkt. Ein
Sensibilitätswert von 0 bewirkt lineares Ansteigen der Werte mit Druck auf die
Kappe. Bei Erhöhen des Sensibilitätswertes verschiebt sich dieses Verhältnis bis
zu einem quadratischen Ansteigen der generierten Bewegungswerte.
Die Kappe der Spacemaus erlaubt Bewegungen in sechs Freiheitsgraden, indem
sie sich um jeweils drei Achsen drücken, ziehen und drehen lässt. Dabei ist nur
ein ganz leichtes Führen der Kappe in die entsprechende Richtung nötig. Druck
nach rechts generiert positive X-Werte, deren Höhe der Stärke des Druckes
entsprechen. Druck nach links generiert negative X-Werte. Druck nach vorne
erzeugt negative Z-Werte, Druck nach hinten positive. Die Y-Werte werden
durch Niederdrücken der Kappe (negative Werte) bzw. durch hochziehen
(positive Werte) generiert. Rotationswerte werden erzeugt, sobald die Kappe um
eine der Achsen gedreht wird. Ein Drehen der Kappe im Uhrzeigersinn um eine
der Koordinatenachsen erzeugt positive Werte, ein Drehen der Kappe entgegen
dem Uhrzeigersinn, um eine der Koordinatenachsen, erzeugt negative Werte.
Der Drehsinn wird dabei relativ zur positiven Ausrichtung der
Koordinatenachsen bestimmt. Die Abbildung 4.3 unten zeigt die Spacemaus mit
ihren drei Bewegungsachsen auf. Die Pfeile zeigen dabei immer in die positive
Richtung der jeweiligen Achse.
Durch die große Beweglichkeit der Kappe sind gleichzeitige Bewegungen aus
mehreren Translationen, Rotationen oder Kombinationen aus beiden, möglich.
Nach jeder Aktion kehrt die Kappe wieder in ihre Ausgangsposition zurück.
Damit die Spacemaus Plus mit einer Hand bedient werden kann und bei
stärkeren Bewegungen an der Kappe nicht selbst mit verschoben wird, wurde
mit Hilfe einer Metallplatte auf ihrer Unterseite für ein ausreichendes Gewicht
gesorgt.
Die USB-Version der Spacemaus Plus verschickt bei jeder Aktion, unabhängig
davon ob es sich um einen Buttondruck oder eine Kappenbewegung handelt,
eine Datenfolge von 14 Bytes. Die 14 Bytes werden zu zwei Paketen verschickt,
von denen das erste 8 und das zweite die restlichen 6 Bytes enthält20. Die
60
Bedeutung der Bytes teilt sich wie folgt auf: Die ersten beiden Bytes
identifizieren den Button der gedrückt wurde. Für die acht Auswahlbuttons sind
dies die Werte 1, 2, 4, 8, 16, 32, 64, 128. Die Zuordnung erfolgt von 1 für den
ersten, bis zu 128 für den achten Auswahlbutton. Der Wert 256 ist dem
Sonderbutton und die Werte 512 und 1024 sind den links und rechts neben der
Kappe befindlichen Buttons zugeordnet. Ein Wert von 0 hingegen zeigt an, dass
kein Button betätigt wurde. Die nächsten drei Bytepaare geben die Werte für die
X-, Y- und Z-Translationen an. Die letzten drei Bytepaare stehen für die
Rotationen um die X-, Y- und die Z-Achse. Alle Bytepaare müssen dabei immer
als vorzeichenbehaftete ganze Zahlen interpretiert werden. Der Wertebereich der
Zahlen für die Rotationen und Translationen liegt zwischen -500 und +500.
Abb. 4.3: Magellan Spacemaus Plus mit ihren 6 Freiheitsgraden
20 Die Spacemaus Plus kann über ihren endpoint, nur 8 Byte Daten auf einmal schicken.
61
Kapitel 5
Die Integration der Eingabegeräte in
OfuturO
Im Folgenden wird beschrieben, wie die in der Einleitung erläuterte, erste
Teilaufgabe gelöst wurde. Dabei werden zuerst die Überlegungen beschrieben,
die zu der Lösung führten. Die Lösung, die in Form eines Kerneltreibers erfolgt,
wird im Anschluss an eine kurze Einführung in die Thematik der USB-
Kerneltreiber unter Linux vorgestellt. Dabei werden sowohl die
programmiertechnische Umsetzung, als auch die Probleme beschrieben, die
diese mit sich führt.
5.1 Analyse der Problemstellung
Bei den Überlegungen zur Realisierung einer Lösung für die erste Teilaufgabe,
die das Einbinden der Eingabegeräte Spacemaus und Touchpad in die
Umgebung von OfuturO vorsieht, tat sich zunächst das Problem auf, dass bis
zum heutigen Zeitpunkt (September 2003) noch kein Linuxtreiber für die USB-
Version der Spacemaus vorliegt. Das Cirque Easy Cat Touchpad läuft dagegen
auch mit dem gewöhnlichen USB-Maustreiber usbmouse.
Die LogiCad3D GmbH von der die Spacemäuse für das OfuturO-Projekt
bezogen wurden, bietet Linuxtreiber derzeit nur für die serielle Version der
Spacemaus bzw. für ihre USB-Version unter Windows an. Ein passender
Gerätetreiber ist aber eine Grundvoraussetzung dafür, dass Daten die die
Hardware an den Computer schickt, überhaupt abgefragt werden können, da es
Aufgabe eines Gerätetreibers ist, den Datenfluss von der Hardware zur
Gerätedatei bzw. von der Gerätedatei zur Hardware zu steuern.
An erster Stelle stand also das Programmieren eines Kerneltreibermoduls für die
Spacemaus, den SpacemausPlus-Treiber. Der Treiber übernimmt die Aufgabe,
62
Daten die von der Spacemaus geschickt werden über eine Gerätedatei zugänglich
zu machen. Die Gerätedaten werden dabei in eine Gerätedatei umgeleitet, deren
Minornummerierung das jeweilige Gerät identifiziert. Zu jeder Spacemaus muss
daher eine eigene Gerätedatei angelegt und ausgelesen werden.
Nachdem der SpacemausPlus-Treiber vorlag, führten die Überlegungen zu einer
Realisierung der Eingabe mit Hilfe von Spacemaus und Touchpad über einen
Eingabefokus, zu einer grundlegenden Designentscheidung bei der
Implementation der endgültigen Lösung:
Spacemaus- und Touchpadgeräte sollten paarweise logisch miteinander
verknüpft werden. Da sich der Eingabefokus stets auf ein Gerätepaar und nie auf
ein einzelnes Gerät bezieht, soll die Behandlung von Gerätepaaren anstelle von
einzelnen Geräten, die Implementierung und den Wechsel des Eingabefokus’
erleichtern. Zudem kann ein unnötiger Datenfluss verhindert werden, indem vom
Treiber nur die Daten der Geräte an die Gerätedateien übertragen werden, die
derzeit den Eingabefokus besitzen. Alle anderen Gerätedaten sind für die
auslesende Avango-Applikation ohne Bedeutung.
Zu diesem Zweck wurde der SpacemausPlus-Treiber soweit erweitert, dass er
neben der Datenübertragung der Spacemäuse auch die der Touchpads
übernimmt. Dadurch, dass der daraus resultierende SMTP21-Treiber beide
Gerätearten innerhalb eines Treibers behandelt, tat sich die Möglichkeit auf,
treiberintern Zuweisungen zwischen den einzelnen Geräten zu machen und diese
zu Paaren zu vereinen. Ein Paar besteht dabei immer aus einer Spacemaus und
einem Touchpad, so wie sie einem Benutzer schließlich als Eingabegeräte zur
Verfügung stehen sollen.
Dabei kam die Frage auf, nach welchen Kriterien die Zuordnung der einzelnen
Geräte erfolgen sollte: Eine Möglichkeit wäre gewesen festzulegen, dass zuerst
alle Spacemäuse angeschlossen werden müssen. Die nachfolgenden Touchpads
wären dann der Reihe nach den zuvor angeschlossenen Spacemäusen
zugeordnet worden. Das gleiche Verfahren wäre auch umgekehrt möglich
gewesen. Eine andere Möglichkeit hätte in der Vorgabe bestehen können
Touchpads und Spacemäuse immer abwechselnd anschließen zu müssen und
dadurch die Paare zu bilden. Was wäre aber passiert sobald sich der Anwender
21 SMTP steht dabei für die beiden gekoppelten Eingabegeräte Spacemaus und Touchpad.
63
einmal nicht an die Vorgaben für die Anschlussreihenfolge hält? Oder ein Gerät
kurzerhand wieder abschließt? Die USB-Technologie wurde hauptsächlich unter
den Gesichtspunkten entwickelt, den Einsatz von Hardwaregeräten möglichst
unkompliziert zur Verfügung zu stellen. Diesem Gedanken folgend sollte der
SMTP-Treiber nach Möglichkeit auch keine Vorschriften darüber machen, in
welcher Reihenfolge die einzelnen Geräte anzuschließen sind, um ein korrektes
Arbeiten zu gewährleisten. Stattdessen sollte er unabhängig von der
Anschlussreihenfolge die Fähigkeit besitzen, selbständig Spacemaus-Touchpad-
Paarungen zu bilden sobald die Möglichkeit dazu gegeben ist. Außerdem sollte
er auch noch arbeiten können, nachdem Geräte mehrfach ein- und abgesteckt
worden sind, solange dabei noch die Voraussetzungen für die Bildung eines
gültigen Paares gegeben sind.
5.2 Der SMTP-Treiber als Realisierung der Lösung
In der Implementation des SMTP-Kerneltreibers sollen die in der ersten
Teilaufgabe gestellten Ansprüche erfüllt werden, indem Applikationen die
Gerätedaten der Eingabegeräte in Gerätedateien zur Verfügung gestellt werden.
Die Eingabe wird dabei über einen zuweisbaren Fokus gesteuert, der die Eingabe
auf nur jeweils eines aller angeschlossenen Spacemaus- und Touchpadgeräte
beschränkt. Im folgenden werden Fähigkeiten und Arbeitsweise des SMTP-
Treibers beschrieben.
Der SMTP-Treiber ist so implementiert, dass sowohl Spacemäuse als auch
Touchpads in beliebiger Reihenfolge an- und wieder abgeschlossen werden
können. Sobald ein Gerät angeschlossen wird, prüft der Treiber, ob bereits ein
freies Gerät vom anderen Typ angeschlossen ist, das sich noch nicht in einer
Paarung befindet. Wenn dies der Fall ist, wird das neue Gerät mit dem freien
Gerät verknüpft. Handelte es sich um das erste Paar, wird diesem Paar
automatisch der Eingabefokus zugewiesen. Jedem Paar wird treiberintern
außerdem eine laufende Nummer zugewiesen, die von der Reihenfolge abhängt
in der die Paare entstanden sind. Die Nummerierung startet bei 1 und geht bis 8,
was die maximale Anzahl von möglichen Gerätepaaren die vom SMTP-Treiber
64
behandelt werden, darstellt. Die Anzahl der möglichen Gerätepaare ist auf acht
limitiert, da die Magellan Spacemaus Plus acht nummerierte Auswahlbuttons
aufweist. Weitere Geräte werden vom Treiber ignoriert.
Bei mehreren Spacemaus-Touchpad-Paaren kann der Fokus durch Drücken des
Buttons mit der entsprechenden Nummer auf der Spacemaus die derzeit den
Eingabefokus besitzt, weitergegeben werden.
Wird ein Gerät abgeschlossen, das sich in einer Paarung befand, so ist dieses
Paar zerstört. Für das verbleibende Gerät wird sofort wieder versucht eine
Paarung zu bilden, indem nach einem freien Gerät am USBus vom anderen Typ
gesucht wird. Wurde beim Abschließen eines oder mehrerer Geräte ein Paar
zerstört, das zu der Zeit den Eingabefokus hatte, wird der Eingabefokus
automatisch auf das nächste gültige Gerätepaar übertragen. Existieren keine
gültigen Paarungen mehr, sind keinerlei Eingaben mehr möglich. Dies ist dann
der Fall, wenn am USBus nur Geräte vom Typ Spacemaus oder vom Typ
Touchpad angeschlossen sind.
Eine weitere Frage stellt sich bezüglich der Gerätedateien in die der Treiber die
Gerätedaten überträgt. USB- Treiber verhalten sich normalerweise so, dass sie
jedem Gerät das angeschlossen wird eine eigene Gerätedatei zuordnen. Eine
Anwendung die auf sechs Geräte zugreift, was der Anzahl der in OfuturO
einzubindenden Eingabegeräte entspricht, muss daher sechs verschiedene
Dateien auslesen. Der zuerst implementierte SpacemausPlus- Treiber verfährt,
indem er jedem Gerät eine Gerätedatei zuordnet. Der SMTP- Treiber übernimmt
intern jedoch bereits eine Zuordnung zwischen den einzelnen Spacemäusen und
Touchpads, sowie ein Zuweisen des Eingabefokus’. Es wäre daher inkonsequent
jedem Gerät eine eigene Datei zuzuordnen. Dadurch müsste die Logik zum
Auslesen der jeweils richtigen, daher den momentan den Eingabefokus
besitzenden Gerätedatei, die Applikation implementieren die darauf zugreift.
Ohnehin dürfen immer nur jeweils eine Spacemaus und ein Touchpad zu einem
Zeitpunkt Daten übertragen.
Daher werden zur Datenübertragung im SMTP-Treiber auch lediglich zwei
URBs22 verwendet. Ein URB ist dabei mit der den Eingabefokus besitzenden
Spacemaus und der andere mit dem den Eingabefokus besitzenden Touchpad
22 Definition von URBs siehe 4.1.
65
verknüpft. Der SMTP-Treiber lenkt seine Ausgabe in nur zwei Gerätedateien,
unabhängig davon wie viele Geräte tatsächlich angeschlossen sind. In die eine
Gerätedatei werden die Bewegungsdaten des Touchpads, in die andere die
Bewegungsdaten der Spacemaus geleitet.
Die beiden Gerätedateien, in die der SMTP- Treiber seine Ausgabe schreibt,
werden von den beiden Avango- Geräteklassen fpSpacemausNode und
fpTouchpadNode ausgelesen. Durch Bilden von Instanzen dieser Klassen und
ihrem Einbinden in den av-daemon werden Spacemaus- und Touchpadgeräte in
eine Avango-Applikation integriert. Die Arbeitsweise der Klassen
fpSpacemausNode und insbesondere fpTouchpadNode werden im nächsten
Kapitel beschrieben. fpTouchpadNode implementiert auch die Funktionen der
Gestenerkennung aus der 2.Teilaufgabe der Diplomarbeitsaufgabenstellung. Die
Beschreibung dieser Funktionen erfolgt ebenfalls im nächsten Kapitel.
5.3 USB-Kerneltreiber unter Linux
Die Aufgabe von Kerneltreibern ist es, Daten die von der Hardware zum
Linuxkernel geschickt werden in die Gerätedateien zu übertragen, bzw. Daten
aus den Gerätedateien zur Hardware zu vermitteln, um so Anwendungs-
programmen den Zugriff auf die Hardwaregeräte zu ermöglichen. Daten die
zwischen Geräten und Gerätedateien ausgetauscht werden, werden vom Treiber
vermittelt.
Kerneltreiber sind unter Linux als so genannte Module realisiert. Modulcode
kann dynamisch, das heißt im laufenden System ge- und entladen werden. Damit
Module so flexibel agieren können weisen sie bestimmte Einsprungspunkte auf,
die jedes Mal aufgerufen werden sobald ein Modul geladen oder entladen wird.
Die Einsprungspunkte dienen in erster Linie dem An- und Abmelden der
Fähigkeiten am System, über die das Modul verfügt und müssen vom
Modulprogrammierer implementiert werden. Treibermodule arbeiten immer mit
Gerätedateien zusammen, aus diesem Grund arbeiten sie intern mit einer
Struktur, die eine Datei unter Linux repräsentiert, der file-Struktur. Jede file-
Struktur verfügt über eine Liste von Funktionszeigern, die auf die
66
Systemfunktionen verweisen, die auf der Datei ausgeführt werden können. Es
gibt eine ganze Reihe solcher möglicher Fileoperationen, wobei es dem
Programmierer überlassen ist zu entscheiden, welche davon implementiert
werden und welche nicht. Der SMTP-Treiber implementiert folgende
Fileoperationen:
Open: Das Öffnen der Gerätedatei
Read: Das Lesen aus der Gerätedatei
Release: Das Schließen der Gerätedatei
Da es sich beim SMTP-Treiber um einen USB-Treiber handelt, verwendet er
zusätzlich noch eine Struktur vom Typ usb_driver. Diese Struktur ist Bestandteil
einer Softwareschicht, die sich zwischen der Host-Controller-Implementierung
und dem USB-Gerätetreiber befindet, dem USB-Subsystem oder auch USB-
Framework. Sie stellt USB-Treibern eine API zur Verfügung und wird daher
auch als usbcore bezeichnet. Ähnlich wie die file-Struktur verfügt auch die
usb_driver-Struktur über eine bestimmte Anzahl von Funktionszeigern. Die
Funktionen beziehen sich dabei auf USB-gerätespezifische Eigenschaften. Der
SMTP-Treiber implementiert folgende USB-Operationen:
Probe: Das Anschließen eines Gerätes an den USB
Disconnect: Das Abschließen eines Gerätes vom USB
Innerhalb der usb_driver-Struktur werden außerdem auch die Geräte bestimmt,
die von der Struktur übernommen werden sollen. Dies erfolgt durch die Produkt-
und Vendor-Identifikationsnummer, die ein Gerät eindeutig identifiziert.
Die USB-Geräte selbst werden von einer weiteren Struktur vom Typ
usb_InputDevice dargestellt. Hier werden alle geräterelevanten Informationen
67
abgelegt. Statische Instanzen dieser Struktur werden im SMTP-Treiber sowohl
für die Spacemäuse als auch für die Touchpads verwendet.
Mehr Informationen zum Thema Treiberprogrammierung finden sich in [RC02].
Treiberprogrammierung für USB unter Linux wird in [Fli00] behandelt.
5.4 Die SMTP-Treiberroutinen
Im vorliegenden Abschnitt wird die Bedeutung der einzelnen SMTP-
Treiberroutinen erläutert. Die Implementation des Treibers erfolgt dabei in der
Programmiersprache C, der unter Linux üblichen Programmiersprache für
Kernelmodule. Bei der Beschreibung der einzelnen Treiberroutinen wird von
implementierungsspezifischen Details abgesehen. Stattdessen soll hier nur eine
vereinfachte Darstellung der Funktionsweise dieser Routinen erfolgen. Zu jeder
Funktion wird sowohl der allgemeine Aufgabenbereich als auch die speziell im
SMTP-Treiber implementierte Funktionalität erläutert.
5.4.1 Die Moduleeinsprungspunkte ModulInit und ModulExit
Diese Funktionen werden jedes Mal aufgerufen, wenn vom System oder vom
Anwender das entsprechende Modul geladen bzw. entladen wird. Dem System
werden dadurch beim Laden des Moduls seine Dienstleistungen bekannt
gegeben. Beim Entladen wird das System darüber informiert, dass diese
Dienstleistungen nun nicht mehr zur Verfügung stehen. Die Init-Routine
informiert das System unter anderem darüber, welche Gerätedateien mit dem
vom Treiber geregelten Datenfluss verknüpft sind. Die dem Treiber zugewiesene
Gerätedatei wird dabei nicht über einen Namen identifiziert, sondern über eine
Nummer, der so genannten Majornummer. Die Majornummer ist eine positive 8-
Bit ganze Zahl und umfasst somit einen Wertebereich von 0 bis 255, was
theoretisch den Einsatz von nur 256 Geräten ermöglicht23. Da es jedoch weitaus
mehr Peripheriegeräte gibt, existiert noch eine weitere 8-Bit Nummer, die so
23 Vor Kernelversion 2.2 war dieser Wert sogar auf nur 128 Geräte beschränkt.
68
genannte Minornummer. Zur vollständigen Beschreibung eines Gerätes sind
daher Major- und Minornummer nötig.
Minornummern werden vom Betriebssystem bei der Zuweisung des
verantwortlichen Gerätetreibers ignoriert. Hat ein Treiber sich für eine
bestimmte Majornummer beim Betriebssystem angemeldet, so wird er jedes Mal
aufgerufen sobald ein Zugriff auf eine Gerätedatei stattfindet, die diese
Majornummer aufweist, unabhängig davon wie die Minornummer der Datei
lautet. Der Treiber kann dann intern entscheiden, ob er auf bestimmte
Minornummern reagieren will oder nicht.
Bei experimentellen Treibern, wie dem SMTP-Treiber, kann eine der für
experimentelle Zwecke vorgesehenen Majornummern (Nummern 60-63,120-
127,240-254) verwendet werden, oder der Treiber kann sich dynamisch vom
System eine Nummer zuweisen lassen.
Der SMTP-Treiber verwendet die Methode der dynamischen Zuweisung einer
geeigneten Majornummer vom Betriebssystem. Nach dem Laden des SMTP-
Treibermoduls ist diese Nummer unter /proc/devices einsehbar.
Da es sich beim SMTP-Treiber um einen USB-Treiber handelt, übernimmt hier
die Init-Funktion auch das Anmelden der usb_driver Struktur am USB-
Subsystem. Außerdem werden die im Treiber verwendeten, globalen Objekte
initialisiert.
Es handelt es dabei um zwei Felder von Strukturen, wobei das eine Strukturfeld
die Menge der Touchpadgeräte und das andere Strukturfeld die Menge der
Spacemausgeräte repräsentiert. Beide Strukturfelder sind als statische Felder
implementiert. Die Feldgröße entspricht dabei der maximal möglichen Anzahl
von 8 Gerätepaaren.
Die ModulExit-Methode übernimmt die genau entgegen gesetzten Aufgaben,
indem Sie die Verbindung des Treibers mit der zuvor zugewiesenen
Majornummer wieder auflöst. Da es sich beim SMTP-Treiber um einen USB-
Treiber handelt, meldet ModulExit darüber hinaus auch noch die usb_driver
Struktur vom USB-Subsystem ab.
69
5.4.2 Die USB-Gerätespezifischen Operationen
Die Probe-Funktion
Wird ein neues Gerät am USBus angeschlossen oder wird ein neuer Treiber
geladen und es sind bereits USB-Geräte am USBus angeschlossen denen bisher
noch kein Treiber zugeordnet werden konnte, ruft das USB-Framework
nacheinander die Probe-Funktionen der geladenen Treiber auf.
Die erste Aufgabe welche Probe dabei im Allgemeinen direkt nach dem Aufruf
übernimmt, ist das Testen des eingesteckten Gerätes auf die Kompatibilität zum
Treiber. Dazu wird Probe der Zeiger einer usb_device-Struktur übergeben, die
das angeschlossene Gerät repräsentiert. Die Vendor- und ProduktID-Nummern
des Gerätes können nun aus der Struktur entnommen und mit denen der vom
Treiber zu behandelnden Geräte verglichen werden. Verläuft dieser Vergleich
negativ, d.h. kommt die Probe-Routine zu dem Ergebnis, dass es sich beim
vorliegenden Gerät nicht um ein zum Treiber kompatibles Gerät handelt oder
stellt sich heraus, dass die maximal vom Treiber zu verarbeitende Anzahl an
Geräten bereits erreicht ist, wird die Probe-Funktion vorzeitig verlassen.
Ansonsten werden alle Informationen24, die für eine spätere Verwendung noch
benötigt werden vor einem Verlassen der Probe Funktion in der treiberinternen
usb_InputDevice Struktur gesichert, indem nacheinander der device descriptor,
der configuration descriptor, der interface descriptor und der endpoint
descriptor ausgewertet werden. Diese Informationen sind auch in der Datei
/proc/bus/usb/devices zu finden, siehe Abbildung 5.1.
24 Zu diesen Informationen gehören beispielsweise Informationen über die Schreib/Lese-endpoints des Gerätes, die maximal zu verarbeitenden Daten, sowie Anzahl an Interfaces und Konfigurationen usw.
70
Abb. 5.1: Auszug aus /proc/bus/usb/devices in dem die Geräteinformationen zu
Spacemaus und Touchpad dargestellt sind.
Unter anderem ist hier zu erkennen, dass sowohl Spacemaus als auch Touchpad
über lediglich ein Interface und eine mögliche Konfiguration verfügen. (Zeile I).
Des Weiteren existiert bei beiden Geräten lediglich ein endpoint vom Typ
Interrupt, der ein Datenpaket mit einer Maximalgröße von 8 Byte unterstützt.
(Zeile E). Neben diesen Aufgaben, die die Probe-Funktion eines jeden USB-
Treibers implementieren, erfüllt die Probe-Routine des SMTP-Treibers noch
einige spezielle Aufgaben:
Da vom SMTP-Treiber sowohl Touchpad als auch Spacemaus übernommen
werden, muss der Treiber zuerst feststellen, um welchen der beiden Gerätetypen
es sich bei dem aktuellen Gerät handelt. Teil der Gerätedatenstruktur die eine
Spacemaus bzw. ein Touchpad repräsentiert ist ein URB, der an dieser Stelle mit
den nötigen Gerätedaten initialisiert wird. Im Gegensatz zu herkömmlichen
USB-Treibern, die lediglich ein Gerät behandeln, wird der URB jedoch noch
nicht an das USB-Subsystem geleitet. Stattdessen versucht der Treiber bereits
das angeschlossene Geräte einem eventuell zuvor schon angeschlossenen Gerät
vom anderen Typen zuzuordnen. Gelingt die Zuordnung und handelte es sich
dabei um das erste gültige Gerätepaar das zugeordnet werden konnte, wird
diesem Paar der Eingabefokus zugewiesen. Erst jetzt werden die URBs beider
Geräte dem USB-Subsystem bekannt gegeben. Ein URB übernimmt dabei die
Kommunikation des USB-Subsystems mit der Spacemaus, der andere die
Kommunikation des USB-Subsystems mit dem Touchpad.
71
Die Disconnect-Funktion
Die Disconnect-Routine stellt das Gegenstück zur zuvor beschriebenen Probe-
Funktion dar. Disconnect wird jedes Mal aufgerufen wenn ein vom Treiber
übernommenes Gerät vom USBus abgesteckt wird. Aufgabe der Disconnect-
Funktion ist es dann, das entsprechende Gerät in der treiberinternen
usb_InputDevice-Struktur als nicht mehr am Bus angeschlossen zu
kennzeichnen. Ist keine Gerätedatei mehr geöffnet die auf das Gerät zugreift,
wird die interne usb_InputDevice-Struktur vollständig gelöscht. Ansonsten wird
mit dem Löschen bis zum Schließen der Gerätedatei gewartet, da noch immer
Lese- oder Schreibzugriffe auf diese Datei erfolgen könnten und dabei dann auf
eine nicht mehr vorhandene Struktur zuzugreifen versuchten. Beim SMTP-
Treiber wird die Löschung der Struktur in jedem Fall in der Disconnect-Funktion
vorgenommen, unabhängig davon ob die SMTP-Gerätedatei noch geöffnet ist
oder nicht. Das liegt daran, dass beim SMTP-Treiber das Abstecken eines
Gerätes nicht unbedingt zur Folge hat, dass ein Lesezugriff nicht mehr möglich
ist. Das ist erst der Fall wenn auch das letzte gültige Gerätepaar durch Abstecken
eines Gerätes zerstört worden ist. Dies aber wird bei einem anschließenden
Lesezugriff registriert und der Lesevorgang dann als gescheitert übermittelt. Der
Aufruf der Disconnect-Funktion im SMTP-Treiber beinhaltet auch das
Überprüfen darauf, ob das zu löschende Gerät bis zu diesem Zeitpunkt Teil eines
Gerätepaares war. Wenn dies der Fall ist, hat das zur Folge, dass beim Löschen
des Gerätes das andere Gerät nun frei geworden ist. Aus diesem Grund prüft
Disconnect ob sich noch ein Gerät des anderen Typs am USB-Bus befindet,
welches bisher noch keiner Paarung zugeordnet werden konnten. Wenn dem so
ist, wird das frei gewordene Gerät mit dem bisher nicht zugeordneten Gerät zu
einer neuen Paarung verknüpft.
Falls der Eingabefokus auf das nächste gültige Gerätepaar übergehen muss, weil
das Abschließen des Gerätes zur Folge hat, dass ein Gerätepaar zerstört wird,
werden die URBs von Touchpad und Spacemaus vom USB-Subsystem
abgemeldet. An ihrer Stelle werden die URBs des neuen Gerätepaares an das
USB-Subsystem übermittelt.
72
Die URB-Completion-Routine
Hierbei handelt es sich um eine optionale Routine, die einem URB bei der
Initialisierung mit übergeben werden kann und die jedes Mal im Anschluss eines
Datentransfers über diesen URB aufgerufen wird. In erster Linie bietet diese
Routine die Möglichkeit auf das Auftreten eventueller Fehler während einer
Datenübertragung reagieren zu können. Es ist aber auch möglich andere
Aufgaben in diese Routine zu verlegen, wie beispielsweise das Aufwecken zuvor
schlafen gelegter Prozesse oder aber das Anstoßen weiterer URBs.
Der SMTP-Treiber überprüft hier den Status der erfolgten URB Übertragung. Ist
der URB mit einer Spacemaus verlinkt wird ein mit der Spacemausgerätedatei
verbundener Read-Prozess reaktiviert. Ist der URB mit einem Touchpad verlinkt,
wird ein mit der Touchpadgerätedatei verbundener Read-Prozess reaktiviert
(siehe Die Read-Funktion weiter unten).
5.4.3 Die File-Operationen
Die Open-Funktion
Die Open-Funktion eines Gerätetreibers wird jedes Mal aufgerufen wenn eine
Gerätedatei mit der Majornummer der vom Treiber behandelten Geräte
übereinstimmt. Die entsprechende Majornummer muss dem Betriebssystem
zuvor in der ModulInit-Routine bekannt gegeben worden sein. Aufgabe der
Open-Funktion ist in erster Linie Initialisierungen interner Treiberdaten-
strukturen vorzunehmen. Darüber hinaus erhöht ein Aufruf von Open den so
genannten Modulverwendungszähler. Dieser Zähler ist eine moduleigene
Datenstruktur, die dem Betriebssystem das die Module verwaltet, Auskunft
darüber gibt, ob und wie oft ein bestimmtes Modul gerade beansprucht wird. Das
Betriebssystem verhindert das Entladen eines Moduls das gerade verwendet
wird. Für ein Gerätetreibermodul bedeutet dies, dass ein erfolgreiches Entladen
durch das Betriebssystem oder eine explizite rmmod-Anweisung des Benutzers
erst erfolgen kann, wenn alle Dateien wieder geschlossen wurden, die in den
Aufgabenbereich des Treibers fallen und zuvor geöffnet worden sind. Erst das
73
Schließen einer Datei ruft die mit dieser Datei verbundene Release-Funktion auf,
in der normalerweise das Dekrementieren des Modulzählers implementiert ist.
Treiber die unterschiedliche Geräte behandeln. ermitteln in der Open-Funktion
außerdem den Gerätetyp, indem sie die Minornummer der geöffneten
Gerätedatei abfragen. Der Zugriff auf jegliche Informationen über die mit dem
jeweiligen Open-Aufruf assoziierte Datei wird der Open-Funktion in einer
Inode- und einer File-Struktur ermöglicht. Die File-Struktur bietet dabei neben
den dateirelevanten Informationen die Möglichkeit ein Datum beliebigen Typs in
einer speziell dafür vorgesehenen Strukturkomponente zu speichern. Auf diese
Weise können entscheidende Informationen über die Datei, die in Open ermittelt
wurden, abgespeichert und bei kommenden Fileoperationen wieder abgefragt
werden.
Da der SMTP-Treiber seine Ausgabe in zwei verschiedene Gerätedateien lenkt,
ist auch hier die Minornummerabfrage implementiert. Eine SMTP-Gerätedatei
mit der Minornummer 0 erlaubt den Zugriff auf die von der Spacemaus
übertragenen Daten, während eine Gerätedatei mit der Minornummer 1 den
Zugriff auf die vom Touchpad übertragenen Daten erlaubt. Gerätedateien mit
anderen Minornummern werden vom SMTP-Treiber zwar geöffnet, jedoch nicht
weiter behandelt. Das Inkrementieren des Verwendungszählers wird in diesem
Fall wieder rückgängig gemacht.
Der ermittelte Dateityp wird im SMTP-Treiber innerhalb der oben beschriebenen
Filestrukturkomponente abgespeichert und ist somit in späteren Aufrufen von
Dateioperationen wieder abrufbar. Dies ist insbesondere im Read-Aufruf
wichtig, da Read je nachdem ob es sich um eine Touchpad- oder eine
Spacemausgerätedatei handelt, die Gerätedaten unterschiedlich handhabt.
Die Release-Funktion
Die Release-Funktion stellt das Gegenstück zu Open dar. Ihr Aufruf erfolgt jedes
Mal wenn eine zuvor geöffnete Datei wieder geschlossen wird. Alle zuvor in
Open reservierten Speicherbereiche werden hier wieder freigegeben.
Insbesondere wird der Verwendungszähler der zuvor in Open erhöht worden ist,
wieder dekrementiert. Da nur Gerätedateien mit den Minornummern 0 und 1
74
vom SMTP-Treiber behandelt werden, wird hier der Verwendungszähler nur
dekrementiert, wenn die zu schließende Datei eine dieser beiden Minornummern
aufweist.
Die Read-Funktion
Die Read-Funktion wird jedes Mal aufgerufen wenn aus einer Gerätedatei, die
vom Treiber behandelt wird, gelesen wird. Die Hauptarbeit der Read-Funktion
ist dabei das Übertragen der Daten vom Gerät in den Ausgabepuffer der
Gerätedatei. Das Betriebssystem erhält zwar die Übertragungsdaten vom Gerät,
das Weiterleiten muss allerdings der Gerätetreiber übernehmen. Zu diesem
Zweck werden zuerst die Daten des auszulesenden Gerätes abgefragt und
anschließend in den von der Gerätedatei bereitgestellten Puffer geschrieben.
Dadurch werden die übertragenen Gerätedaten vom Kernel-Space des
Betriebssystems in den User-Space übertragen. Im User-Space kann die
Gerätedatei dann auf dem üblichen Wege mit der Read-Betriebssystemfunktion
ausgelesen werden. Das Auslesen aus Dateien kann dabei auf verschiedene
Arten erfolgen: blockierend oder nicht blockierend. Beim blockierenden
Auslesen wird der Prozess von dem aus die Read-Systemfunktion aufgerufen
wurde, solange schlafen gelegt, bis Daten vorliegen die ausgelesen werden
können. Erst dann wird der Prozess fortgesetzt. Beim nicht blockierenden
Auslesen aus einer Datei wird der Prozess nicht schlafen gelegt, stattdessen
erhält er die Information darüber ob Daten ausgelesen werden konnten oder nicht
über den Rückgabewert der Read-Systemfunktion. Beim nicht blockierenden
Auslesen muss die Gerätedatei ständig auf das Vorhandensein von vorliegenden
Daten überprüft werden. Ob blockierend oder nicht blockierend aus einer Datei
gelesen wird, kann von einer Applikation, die auf diese Datei zugreift, beim
Öffnen mittels des Flags O_NONBLOCK angegeben werden. Damit eine
Gerätedatei sowohl blockierendes als auch nicht blockierendes Auslesen
unterstützt, müssen beide Methoden in der Read-Funktion der Gerätedatei
implementiert werden.
75
Um blockierendes Lesen zu implementieren, muss Read bei jedem Aufruf zuerst
einmal suspendiert werden. Erst wenn der Fall eintritt, dass Gerätedaten
vorliegen, wird Read reaktiviert um die Datenübermittlung durchführen. Im
SMTP- Treiber wird das blockierende Lesen durch ein Zusammenspiel von Read
und der URB-Callbackfunktion (siehe Die URB-Completion-Routine oben)
realisiert. Die URB-Callbackfunktion wird jedes Mal aufgerufen wenn das mit
dem URB assoziierte Gerät Daten sendet.
Zum Zweck des blockierenden Lesens werden in der SMTP-Treiberinternen
Read-Funktion zwei Warteschlangen25 verwendet, eine für die Touchpadgeräte,
die andere für die Spacemausgeräte. Eine der ersten Aufgaben die Read hier
übernimmt ist das Suspendieren des eigenen Prozesses mit Hilfe einer der beiden
Warteschlangen, je nachdem um welchen Gerätedateityp es sich handelt auf den
ein Read ausgeführt wird. Der Einsatz von zwei Warteschlangen statt einer ist
nötig, um zu verhindern das Spacemausgerätedaten weitergeleitet werden,
obwohl nur das Touchpad Daten zu übermitteln hat und umgekehrt.
Das Aufwecken des Prozesses erfolgt durch Zugriff auf die entsprechende
Warteschlange innerhalb der URB-Callbackfunktion, sobald Daten von einem
Gerät bereitgestellt werden.
Findet eine Datenübermittlung statt und wird der Read-Prozess reaktiviert,
werden die Gerätedaten mittels der in Probe angelegten URBs vom Gerät
gelesen und in einen treiberinternen Puffer geschrieben. Die Pufferdaten werden
schließlich in den dateieigenen Puffer kopiert. Das Kopieren der Daten über den
treiberinternen Puffer im SMTP-Treiber erfolgt, da beim Übertragen von
Touchpaddaten neben den 8 Datenbytes die vom Touchpad bei Berühren der
Sensorfläche oder Betätigen eines Buttons, übermittelt werden, vom Treiber
noch ein neuntes Byte hinzugefügt wird. Der Grund für das Hinzufügen dieses
zusätzlichen Byte wird im nächsten Kapitel erläutert.
Bei blockierendem Lesen verbringen die Leseprozesse den größten Teil der Zeit
in schlafendem Zustand. Bei einem Entfernen des auszulesenden Gerätes vom
25 Warteschlange oder auch wait queues genannt, sind Strukturen auf die im Wesentlichen die Operationen Sleep und WakeUp ausgeführt werden können. Ein Sleep reiht den aufrufenden Prozess in die Warteschlange ein und legt diesen damit schlafen. Ein WakeUp weckt sämtliche bis zu diesem Zeitpunkt in der Warteschlange eingereihten Prozesse wieder auf.
76
USBus während eines laufenden Leseprozesses, ist die Wahrscheinlichkeit daher
groß, dass dies passiert während der Prozess gerade suspendiert ist. Registriert
das USB-Subsystem das Abschließen eines Gerätes, wird wie bei der
Datenübermittlung durch ein Gerät automatisch die URB-Callback-Funktion
aufgerufen. Beim SMTP-Treiber wird innerhalb dieser Funktion somit auch
immer überprüft, ob der Aufruf deshalb geschah, weil Daten übermittelt wurden,
oder weil die Daten fehlerhaft übermittelt, bzw. das Gerät abgeschlossen wurde.
Trifft letzteres zu, wird wie bei einer Datenübermittlung, der durch die
Warteschlange des jeweiligen Gerätes schlafende Prozess geweckt. Dadurch ist
gewährleistet, dass ein suspendierter Leseprozess nicht in einen Zustand
kommen kann, in dem keine Möglichkeit zur Reaktivierung mehr gegeben ist,
weil das auszulesende Gerät nicht mehr vorhanden ist.
Beim SMTP-Treiber wird vor dem Anfordern der Gerätedaten mit Hilfe der File-
Informationen, die beim Aufruf der Read-Funktion mit übergeben wurden,
zuerst anhand der Minornummer geprüft, ob es sich um die Touchpad- oder die
Spacemausgerätedatei handelt, damit die Read-Funktion das Anfordern der
Gerätedaten für den richtige Gerätetyp durchführt. Da der SMTP-Treiber nicht
nur die beiden Gerätetypen Spacemaus und Touchpad, sondern auch mehrere
Geräte jeden Typs behandelt, erfolgt das Anfordern der Gerätedaten nur für das
Gerät, welches sich in der Gerätepaarung befindet die aktuell den
Eingabefokus26 zugewiesen hat. Existiert keine solche Paarung, schlägt der
Read-Aufruf fehl.
Handelt es sich beim auszulesenden Gerät um eine Spacemaus, wird außerdem
noch der Inhalt der übertragenen Daten auf einen Buttondruck geprüft. Wird ein
Buttondruck festgestellt, der das Anfordern eines Eingabefokuswechsels auf ein
gültiges Gerätepaar darstellt, werden beide URBs, welche zuvor in der Probe
Funktion der Spacemaus und dem Touchpad zugewiesen wurden, vom USB-
Subsystem abgemeldet. Danach werden Sie mit den Daten der neu
zuzuweisenden Geräte initialisiert und wieder am USB-Subsystem angemeldet.
Die möglichen Werte für einen Fokuswechsel sind 1, 2, 4, 8, 16, 32, 64 und 128,
was den Datenwerten der durchnummerierten 8 Aktionsbuttons auf der 26 Zur Erinnerung: Der Eingabefokus stellt die Berechtigung für nur eines der Gerätepaare dar, Daten an die Gerätedateien zu senden. Siehe auch die Aufgabenbeschreibung in der Einleitung.
77
Spacemaus entspricht. Jeder Wert wird treiberintern einem der 8 möglichen
Spacemaus-Touchpad-Gerätepaare zugeordnet. Gibt es kein gültiges Gerätepaar
mit der für den Fokuswechsel angegebenen Nummer, wird der Buttondruck
ignoriert und das aktuelle Gerätepaar behält den Fokus.
5.5 Probleme bei der Implementierung
Eines der Probleme die bei der Programmierung von Kerneltreibern gelöst
werden müssen, besteht darin nebenläufigen Zugriff auf globale Variablen zu
koordinieren. Die meisten Kerneltreiber arbeiten mit einem globalen
Strukturfeld, in der die Informationen mehrerer zu verwaltender Geräte abgelegt
werden. Da es sich bei allen oben genannten Treiberfunktionen um
Callbackfunktionen handelt, die jederzeit unabhängig voneinander aufgerufen
werden können, sobald ein bestimmtes Ereignis eintritt, können leicht
Situationen auftreten in denen mehrere verschiedene Funktionen gleichzeitig
ausgeführt werden. Ein Gerät wird beispielsweise an- oder abgeschlossen oder
Schreib/Lesezugriffe auf ein Gerät werden ausgeführt. Es besteht auch die
Möglichkeit dass eine Funktion zum gleichen Zeitpunkt mehrfach ausgeführt
wird. Dies kann vorkommen, wenn das an- oder abschließen eines Gerätes
schnell hintereinander erfolgt, oder wenn mehrere Prozesse gleichzeitig Schreib-
oder Lesezugriffe auf ein Gerät ausführen.
Da Linux ein Mehrprozessbetriebssystem ist, wechselt der Prozessor in diesem
Fall nach einem bestimmten Schema ständig zwischen den einzelnen Prozessen,
indem das Betriebssystem einem Prozess nach einer gewissen Zeit den Prozessor
entzieht und ihm dafür einen anderen Prozess zuweist27. Bei unkontrolliertem
Zugriff verschiedener Prozesse auf dieselben Datenstrukturen kann es bei diesen
Wechseln unter Umständen zu Fehlern kommen, so genannten race conditions28.
Um Fehler solcher Art zu vermeiden muss Programmcode der auf die gleichen
27 Dieses Verfahren wird auch als Scheduling bezeichnet. 28 Dieses Problem stellt sich normalerweise nicht für Kernelcode auf Einprozessorsystemen, da Kernelcode im Gegensatz zu User-Space Code keinen Prozessorentzug erfährt, ohne dies explizit anzufordern. Gut programmierte Treiber sollten aber auch immer den Einsatz auf Multiprozessorsystemen mit in Betracht ziehen. Da es sich beim Visualisierungsserver der OfuturO-Umgebung, auf dem der Treiber letztlich laufen soll, ebenfalls um ein Multiprozessorsystem handelt, war der Einsatz von Mutexe hier obligatorisch.
78
Daten wie anderer Programmcode zugreift mit Hilfe von
Koordinierungsmechanismen reentrant gemacht werden. Das bedeutet, dass
sichergestellt werden muss, dass ein Prozess keine Manipulationen an globalen
Datenstrukturen vornehmen darf, mit denen ein anderer Prozess gerade noch
arbeitet.
Unter Linux gibt es verschiedene solcher Koordinierungsmechanismen, als
Beispiele sind da Semaphore, Mutexe und Spinlocks zu nennen. Der SMTP-
Treiber verwendet in den kritischen Routinen Mutexe29. Die betreffenden
Routinen sind hier die Read-, Probe-, und die Disconnect-Routine, da innerhalb
dieser Routinen auf globale Daten zugegriffen wird. Zum einen sind dies die
beiden usb_InputDevice-Datenstrukturfelder für die Repräsentation der
Spacemäuse und der Touchpads, zum anderen ist dies die globale Integer-
Variable in welcher die Nummer des aktuell den Eingabefokus besitzenden
Gerätepaares gespeichert ist.
Da die beschriebenen Koordinierungsmaßnahmen eine zentrale Problematik bei
der Treiberprogrammierung und insbesondere innerhalb des SMTP-Treibers
darstellen, wird im Folgenden noch einmal näher darauf eingegangen. Dabei
werden die möglichen Fälle untersucht, in denen es zu den beschriebenen race
conditions kommen kann. Im Anschluss daran wird gezeigt, wie diese Probleme
in der Implementation des Treibers gelöst sind.
Fall 1: Ein Gerät wird entfernt von dem gerade gelesen wird.- Entspricht
einem gleichzeitigem Aufruf von Read und Disconnect.
Wenn ein Prozess über Read�versucht von einem Gerät zu lesen, welches soeben
in einem parallel laufenden Disconnect gelöscht wird, kann es beim Versuch auf
ein nicht mehr vorhandenes Gerät zuzugreifen, zu schwerwiegenden Fehlern
kommen. Daher muss verhindert werden, dass Read überhaupt diesen Versuch
unternimmt, sobald das Gerät entfernt wurde.
29 Mutexe (mutual exclusion) sind betriebssysteminterne Datenstrukturen auf die zwei grundlegende Operationen ausgeführt werden können: Down und Up. Down auf einem Mutex sperrt dieses für andere Prozesse solange bis wieder ein Up erfolgt.
79
Zu diesem Zweck reguliert ein Mutex den Zugriff auf die Geräte innerhalb von
Read und Disconnect. Die Down-Operation des Mutex muss in beiden
Funktionen aufgerufen werden, bevor zum ersten Mal auf die
Gerätedatenstruktur zugegriffen wird. Der erste Zugriff beim Lesen besteht
dabei aus einem Überprüfen der Struktur auf ein Vorhandensein des Gerätes.
Sollte die Überprüfung ergeben, dass das Gerät nicht mehr vorhanden ist, wird
der Lesevorgang abgebrochen. Ansonsten wird der Read-Prozess anschließend
suspendiert, um auf das Ereignis einer Datenübermittlung zu warten (siehe Die
Read-Funktion oben). Wenn dieses Ereignis eingetroffen ist und Read mittels
der URB-Callback-Methode reaktiviert wird, (siehe Die URB-Completion-
Routine oben) wird das Mutex wieder freigegeben. Erst wenn der Lesevorgang
komplett abgeschlossen ist und noch bevor ein erneutes Lesen den Prozess
wieder suspendieren kann, kann die Disconnect-Routine ausgeführt werden.
Abgesehen von der Gerätedatenstruktur wird innerhalb von Read auch noch auf
die oben erwähnte globale Integer-Variable zugegriffen, in welcher die Nummer
des Gerätepaares gespeichert ist, das aktuell den Eingabefokus besitzt. Diese
Nummer muss ermittelt werden, noch bevor auf die Gerätedatenstruktur
zugegriffen wird. Auch hier kann es jedoch wieder zu Problemen kommen, falls
gleichzeitig Disconnect ausgeführt wird, denn durch den Aufruf von Disconnect
besteht die Möglichkeit, dass sich die Nummer des Gerätepaares ändert, falls
eines der Geräte abgeschlossen wird, das zu diesem Zeitpunkt den Eingabefokus
besitzt (siehe Die Disconnect-Funktion oben).
Den Zugriff regelt hier ein weiteres Mutex, das noch vor dem eingesetzt wird,
das den Zugriff auf die Gerätedatenstruktur regelt. Dieses Mutex muss neben
dem anderen ebenfalls frei sein, damit Disconnect aufgerufen werden kann.
Damit zwischen den Bereichen die beide Mutexe schützen, keine Änderungen an
der Integer-Variablen oder der Gerätedatenstruktur durch Disconnect auftreten
können, werden beide Mutexe verschachtelt aufgerufen, d.h. noch bevor das
erste freigegeben wird, wird das zweite schon blockiert (Abbildung 5.2).
Der Zugriff auf die Integer-Variable wird von einem globalen Mutex geregelt.
Der Zugriff auf die Gerätedatenstruktur wird dagegen nicht von einem einzelnen
globalen Mutex geregelt, da es vom Read-Prozess auch gehalten wird, während
80
Disconnect Down (globaler Mutex) Down (struktureigener Mutex) Löschen eines Gerätes Eventuelles Neuzuweisen der Gerätepaarnummer mit dem
Eingabefokus Up (struktureigener Mutex) UP (globaler Mutex)
Read Down (globaler Mutex) Auslesen der aktuellen Gerätepaarnummer Zugriff auf das Gerät Down(struktureigener Mutex) Up(globaler Mutex) Suspendieren des Prozesses Datenübermittlung Up(struktureigener Mutex)
URB- Callback Reaktivieren von Read
a b
Read suspendiert ist. Dadurch können Probleme auftreten sobald ein weiterer
Leseprozess gestartet wird. Diese Problematik wird weiter unten unter Fall 4,
dem gleichzeitigen Ausführen mehrerer Lesevorgänge, beschrieben.
Aus diesem Grund werden auch zwei Mutexe verwendet, denn das globale
Mutex darf nicht gehalten werden, während Read suspendiert wird und das
andere Mutex wiederum kann, da es Teil der Gerätedatenstruktur ist, erst
ermittelt werden, nachdem durch Einsatz des globalen Mutex sichergestellt ist,
dass das richtige Gerät betrachtet wird. Der beschriebene Sachverhalt ist in der
unten stehenden Abbildung 5.2 noch einmal schematisch dargestellt.
Abb. 5.2: Schematische Darstellung der Race Condition Problematik im SMTP-Treiber zwischen
der Read- und der Disconnect-Routine. Die schwarzen Pfeile zeigen an, ab welchem
Programmabschnitt welche Funktion blockiert wird. a) Befindet sich Read in diesem
Programmabschnitt wird Disconnect an dieser Stelle blockiert. b) Befindet sich Disconnect in
diesem Programmabschnitt wird Read an dieser Stelle blockiert.
Über die oben beschriebene Situation hinaus können aber auch noch Fälle
auftreten in denen die kritischen Routinen selbst gleichzeitig aufgerufen werden:
Fall 2: Zwei oder mehr vom Treiber behandelte Geräte werden nahezu
gleichzeitig am USBus angeschlossen- Entspricht einem mehrfachen Aufruf
von Probe.
Werden zwei oder mehr Geräte kurz hintereinander an den USBus
angeschlossen, kann es vorkommen, dass mehrere Probe Funktionen fast
81
gleichzeitig laufen. Weist die erste Probe Funktion ihrem Gerät einen Platz in
der globalen Datenstruktur zur Geräteverwaltung zu, bekommt ein nebenher
laufendes Probe nichts davon mit, dass dieser Platz bereits belegt ist und weist
seinem Gerät fälschlicherweise eventuell denselben Platz zu. Abhilfe schafft hier
ein weiteres globales Mutex, das innerhalb von Probe aufgerufen wird, bevor ein
Zugriff auf die Gerätedatenstruktur erfolgt. Der Einsatz des Mutex erfolgt in
dieser Funktion im Gegensatz zu den Mutexen in Disconnect und Read also
nicht um den Zugriff verschiedener Funktionen auf die selben Daten zu
koordinieren, sondern lediglich zur Koordination eines mehrfachen eigenem
Zugriffes, indem verhindert wird, dass mehrere Probe-Funktionen gleichzeitig
die globale Gerätedatenstruktur auslesen und beschreiben können.
Fall 3: Zwei oder mehr vom Treiber behandelte Geräte werden nahezu
gleichzeitig vom USBus entfernt- Entspricht einem mehrfachen Aufruf von
Disconnect.
Werden zwei oder mehr Geräte gleichzeitig vom USBus entfernt, wird die
Disconnect Funktion für jedes dieser Geräte aufgerufen. Das Entfernen eines
Gerätes bedeutet aber, dass möglicherweise eine Gerätepaarung zerstört worden
ist. In diesem Fall versucht Disconnect ein noch freies Gerät am USBus zu
finden um wieder eine gültiges Paar herzustellen. Wird dieses Gerät gleichzeitig
auch in einem zweiten Disconnect-Prozess entfernt, hat das ursprüngliche
Disconnect keine Information hierüber und weist somit ein nicht mehr
vorhandenes Gerät einer Gerätepaarung zu.
Die Disconnect-Funktion ist vor diesem Ereignis gesichert, indem sie vor jedem
Zugriff auf die Gerätedatenstruktur das auch in Read zum Einsatz kommende,
struktureigene Mutex für sich beanspruchen muss.
82
Fall 4: Es werden Touchpad und Spacemaus- Gerätedateien gleichzeitig
ausgelesen. Entspricht einem gleichzeitigen Aufruf von zwei Read-
Prozessen.
Das Suspendieren des Read-Prozesses mit gehaltenem Mutex stellt bei mehrfach
ablaufenden Read-Prozessen zur gleichen Zeit ein Problem dar. Das Mutex
blockiert nämlich jedes weitere Read solange, bis der erste Prozess wieder
reaktiviert wird, seine Daten übermittelt und das Mutex wieder freigibt. Das
bedeutet in der Praxis, dass zum Empfangen von Gerätedaten aus Read-
Zugriffen immer gewartet werden muss, bis der gerade das Mutex besitzende
Prozess seine Daten übermittelt hat. Da für die Eingabeverarbeitung in der
OfuturO-Umgebung jedoch zwei Read-Prozesse, einer für die Spacemäuse und
der zweite für die Touchpads, ungestört voneinander arbeiten müssen, sind diese
Einschränkungen nicht akzeptabel. Aus diesem Grund wird innerhalb von Read
zum Schützen der Gerätedatenstruktur ein Mutex pro Gerät verwendet. Diese
Mutexe sind zugleich Teil der Gerätedatenstruktur. Auf diese Weise können
Geräte, die Down-Operationen auf ihrem Mutex ausführen, andere Geräte nicht
beeinflussen.
Abbildung 5.3 zeigt die schematische Darstellung des Blockierens gleicher
Funktionen:
83
Abb. 5.3: Schematische Darstellung der Race Conditions Problematik im SMTP-Treiber. Die
Pfeile zeigen ab welchem Programmabschnitt sich die Funktionen selbst blockieren. a) Befindet
sich Read in diesem Programmabschnitt wird ein parallel ausgeführtes Read an dieser Stelle
blockiert. b) Befindet sich Disconnect in diesem Abschnitt wird ein parallel ausgeführtes
Disconnect hier blockiert. c) Befindet sich Probe in diesem Abschnitt wird ein parallel
ausgeführtes Probe hier blockiert.
Probe Down(globaler Mutex) Zuweisen eines neuen Gerätes an die Geräte- datenstruktur Up(globaler Mutex)
Probe Down(globaler Mutex) Zuweisen eines neuen Gerätes an die Geräte- datenstruktur Up(globaler Mutex)
Read Down(globaler Mutex) Auslesen der ak- tuellen Geräte- paarnr., Zugriff auf das Gerät Down(geräte- struktureigener Mutex) UP(globaler Mutex) Suspendierung d. Prozesses, Daten- übermittlung, evntl. Fokus- wechsel mit Neu- zuweisen der URBs Up(geräte- struktureigener Mutex)
Disconnect Down(globaler Mutex) Down(geräte-struktureigener Mutex) Löschen eines Gerätes, eventu- elles Neuzuweisen d. Gerätepaarnr. mit dem Eingabefokus UP(geräte- struktureigener Mutex) Up(globaler Mutex)
Disconnect Down(globaler Mutex) Down(geräte- struktureigener Mutex) Löschen eines Gerätes, eventu- elles Neuzuweisen d. Gerätepaarnr. mit dem Eingabefokus UP(geräte- struktureigener Mutex) Up(globaler Mutex)
Read Down(globaler Mutex) Auslesen der ak- tuellen Geräte- paarnr., Zugriff auf das Gerät Down(geräte- struktureigener Mutex) UP(globaler Mutex) Suspendierung d. Prozesses, Daten- übermittlung, evntl. Fokus- wechsel mit Neu- zuweisen der URBs Up(geräte- struktureigener Mutex)
a a
a a
b b
c c
84
Kapitel 6
Das Versenden visualisierter Daten über
Gesten
In diesem Kapitel wird die Lösung der in Kapitel 4 erläuterten zweiten
Teilaufgabe beschrieben. Wie im vorigen Kapitel wird dabei zuerst die
Aufgabenstellung analysiert, bevor die eigentliche Lösung vorgestellt wird.
6.1 Analyse der Aufgabenstellung zur Gestenerkennung
Die hier gefundene Lösung soll eine exemplarische Lösung für das Versenden
von in OfururO visualisierten Daten über Gesten auf den Touchpads der
darstellen. Welche Gesten letztendlich in der OfuturO-Umgebung eingesetzt
werden muss noch entschieden werden. In der hier vorgestellten Lösung ist die
Auswahl der in der Einleitung vorgestellten Funktionen zur Behandlung von
Daten im Shared Workspace mittels Gesten implementiert.
An erster Stelle der Überlegungen zur Implementation stand die Frage, welche
Geste der einzelnen Aktion zugeordnet werden soll. Jede dieser Gesten soll
dabei den folgenden Satz an Kriterien erfüllen, um dem Anwender die Arbeit zu
erleichtern:
1. Leichte Ausführbarkeit
In erster Linie sollten die Gesten leicht ausführbar sein. Die Gestenausführung
auf den Touchpads soll als Alternative zu einer Implementation der damit
verbundenen Funktionen in der GUI der Workstationsoftware zur Verfügung
stehen. Es soll daher für den Anwender eine Erleichterung darstellen mit Hilfe
der Gesten zu arbeiten anstatt die Aktionen über die GUI auszuführen.
85
Zudem soll der Benutzer dabei nicht unnötig lange in seinem Arbeitsablauf
unterbrochen werden, was bedeutet, dass es sich um knappe und einfache Gesten
handeln muss. Weiterhin sollen die gewünschten Aktionen möglichst nebenher
ausführbar sein, ohne dem Benutzer die volle Konzentration abzuverlangen.
2. Leichte Erlernbarkeit
Um als Alternative zur GUI überhaupt wahrgenommen zu werden sollen die
Gesten leicht erlernbar sein. Dies ist insbesondere dann wichtig, wenn nicht
immer dieselben Personen an OfuturO-Sitzungen teilnehmen.
3. Hoher Erinnerungswert
Nach einmaliger Unterweisung des Anwenders in den Gebrauch der
Eingabegeräte innerhalb der OfuturO-Umgebung soll dieser sich auch an die
Gesten erinnern können, wenn er längere Zeit nicht an einer OfuturO-Sitzung
teilgenommen hat. Dies ist besonders dann wichtig, wenn Konferenzen nicht an
der Tagesordnung stehen.
4. Nachvollziehbarkeit
Die Bewegungsabläufe welche die Gesten darstellen, sollen einen
Zusammenhang zur ausgelösten Aktion erkennen lassen. Dies ist unter anderem
entscheidend für einen möglichst intuitiven und nebenläufigen Einsatz der
Gesten.
5. Flexibilität in der Ausführungsart
Eine bestimmte Geste kann auf ganz unterschiedliche Arten ausgeführt werden.
Beispielsweise ist es möglich Gesten schnell oder langsam, genau oder ungenau
auszuführen. Je nach Geste können diese Ausführungsarten nicht nur von
Anwender zu Anwender sondern auch in den einzelnen Bewegungsabschnitten
innerhalb der Geste variieren. Eine Implementierung muss daher so erfolgen,
dass sie eine gewisse Toleranz in der Ausführungsart einer Geste aufweist.
86
Lokalisieren einer Berührung auf der Touchpadoberfläche
Das in 4.2.1 vorgestellte Easy Cat Touchpad von Cirque arbeitet auf Grundlage
der von Cirque entwickelten GlidePoint® Technologie30. GlidePoint® arbeitet
mit Hilfe eines Gitters aus vertikalen und horizontalen Elektroden, das sich unter
der Kunststoffschicht, die als Sensoroberfläche dient, befindet. Das Gitter ist
mit einem integrierten Schaltkreis (IC) verbunden. Der Strom in den
Kreuzungspunkten des Elektrodengitters wird in kurzen Intervallen gemessen
und Stromschwankungen werden registriert und geben Auskunft über die
berührte Fläche. Als Berührungspunkt wird die Position des Mittelpunktes der
berührten Fläche berechnet (siehe Abbildung 6.1 und [Cir03] sowie [Ade03]).
Abb. 6.1: Funktionsweise der GlidePoint® Technologie
Bei Bewegungen über die Touchpadoberfläche wird eine Positionsänderung des
berechneten Fingermittelpunktes von einem Abfrageintervall zum nächsten in
die unter 4.2.1 erwähnten Bewegungswerte umgewandelt. Die Werte variieren je
nach Größe der relativen Positionsänderung zwischen zwei Abfrageintervallen.
Die minimale Schrittweite bei einer registrierten Bewegung beträgt 1, bzw. 0 bei
keiner Bewegung.
30 Die GlidePoint® Technologie ist heute weit verbreitet und kommt in vielen Laptops als Mausalternative, aber auch in Tastaturen zum Einsatz.
87
Bei den durch das Touchpad übermittelten Werten handelt es sich also nicht um
Absolutwerte innerhalb eines festen Koordinatensystems, sondern lediglich um
Relativwerte. Die Tatsache, dass nur mit Relativwerten gearbeitet werden kann,
stellt ein Problem bei der Implementierung einer Gestenerkennung auf den
Touchpads dar, da auf diese Weise nicht mit Verfahren gearbeitet werden kann,
die auf der Grundlage von Koordinatenmengen arbeiten.
Aus den Relativwerten, die währen der Gestenausführung ausgegeben werden,
können jedoch einfach absolute Koordinaten generiert werden, wenn die
relativen X- und Y-Werte dabei als Versatzvektoren betrachtet werden. Für die
Startkoordinate wird ein beliebiger Punkt im Koordinatensystem, gewählt. Die
jeweils nächste Koordinate ergibt sich dann durch das Addieren des jeweiligen
Versatzvektors zur vorhergehenden Koordinate. Auf diese Weise lässt sich eine
Koordinatenmenge erzeugen, aus deren Verlauf man die Geste erkennen kann.
Voraussetzung ist allerdings, dass die Geste in ihrem gesamten
Bewegungsablauf mit gleich bleibender Geschwindigkeit ausgeführt wird.
Ansonsten würde selbst eine auf dem Touchpad perfekt gezeichnete Figur
aufgrund der sich mit der Ausführungsgeschwindigkeit ändernden Relativwerte
zu einem verfälschten Ergebnis führen. Abbildung 6.2 zeigt die Problematik auf.
Abb. 6.2: Ausführung einer Kreisgeste auf einem Touchpad und Abbildung im
Koordinatensystem beim Versuch die Gestenform aus Relativwerten zusammenzusetzen. In den
schnell ausgeführten Bewegungsabschnitten kommt es zu Dehnungen, in den langsam
ausgeführten Bewegungsabschnitten zu Stauchungen beim Umwandeln der Relativdaten in
Absolutdaten.
88
Es dürfte einem Anwender aber äußerst schwer fallen, eine Geste mit dem
Finger in gleich bleibender Geschwindigkeit zu beschreiben. Aufgrund dieser
Tatsache wird in der Implementierung der Gestenerkennung teilweise eine
andere Methode angewandt. Statt die Geste über Koordinaten zu identifizieren,
kann der Gestenverlauf anhand von Richtungswechseln verfolgt werden. Ein
Richtungswechsel ist an einem Vorzeichenwechsel der relativen X- bzw. Y-
Werte erkennbar. Auf diese Art lässt sich jedoch nur der allgemeine Verlauf,
nicht aber die exakte Geste bestimmen. Beispielsweise ist es anhand der
relativen Bewegungsdaten schwierig zu entscheiden, wo sich der Endpunkt einer
Geste, die auf dem Touchpad ausgeführt wurde, relativ zum Anfangspunkt
befindet. Dies ist jedoch auch nicht unbedingt erforderlich, wenn man davon
ausgeht, dass der Benutzer eine Gestenfigur eher vom Bewegungsablauf her
korrekt ausführen soll, als sie exakt auf dem Touchpad nachzuzeichnen.
6.2 Realisierung der Gestenerkennung
Das Identifizieren aller Gesten ist in der Klasse fpTouchpadNode implementiert.
Diese wurde wie fpSpacemouseNode von der Avangoklasse fpSerialDevice
abgeleitet. Die Aufgabe beider Klassen ist das Auslesen der Touchpad- bzw.
Spacemausgerätedateien. Dazu muss zuvor der av-daemon gestartet werden, der
die Daten weiterleitet (siehe 6.5).
Während fpTouchpadNode neben dem Weiterleiten der Touchpadgerätedaten
auch eine Interpretation der Daten in Form der Gestenerkennung vornimmt,
werden die Spacemausgerätedaten in fpSpacemouseNode lediglich
weitergeleitet. Beide Dateien verwenden zu diesem Zweck von fpSerialDevice
vererbte Methoden.
Die Auswahl der geeigneten Gesten fand unter Berücksichtigung der oben
aufgeführten Kriterien statt:
Die Geste für das Versenden von Dokumenten, die sich im Shared Workspace
befinden, zur Workstation des rechten Nachbarn, besteht aus der Bewegung des
Fingers auf der Sensorfläche von links unten, diagonal über die Fläche nach
rechts oben.
89
Die Geste für das Versenden von Dokumenten, die sich im Shared Workspace
befinden, zur Worksation des linken Nachbarn besteht aus der Bewegung des
Fingers auf der Sensorfläche von rechts unten, diagonal über die Fläche nach
links oben.
Beide Gesten symbolisieren ein „Führen“ des zu verschickenden Dokumentes
von sich weg in Richtung des Empfängers. Die Sensorfläche des Touchpads soll
dabei eine Tischfläche symbolisieren, über die ein virtuelles Dokument
verschoben wird.
Beide Gesten auf der Sensorfläche müssen eine Gerade darstellen. Die Gerade
muss eine Steigung aufweisen, wobei der Anfangspunkt beim Versenden von
Dokumenten zum rechten Nachbarn unterhalb und links vom Endpunkt liegen
muss. Zum Versenden von Dokumenten zum linken Nachbarn muss der
Anfangspunkt der Geraden unterhalb und rechts vom Endpunkt liegen.
Damit das Ausführen einer Geste von gewöhnlichen Bewegungsdaten
unterschieden werden kann, muss während der Ausführung der linke Button des
Touchpads gedrückt gehalten werden. Eine Geste kann so mit nur einer Hand
ausgeführt werden, indem der Button mit dem Daumen gehalten und die
Gestenbewegung mit dem Zeige- oder Mittelfinger ausgeführt wird.
Obwohl sich, wie oben erläutert, bei einer Gestenerkennung auf den Touchpads
das Umwandeln der relativen Positionsdaten in Koordinaten nicht empfiehlt,
wurde hier bei der Implementation der Erkennung dieser Gesten, dennoch so
verfahren. Der Grund dafür liegt darin, dass eine Gerade eine der einfachsten
geometrischen Formen darstellt. Hierbei spielt es keine Rolle, ob bestimmte
Abschnitte der Gestendurchführung schnell oder langsam erfolgen. Für die Form
der Geraden bleibt dies auch ohne Folgen, wenn die relativen Bewegungswerte
die sie darstellen, aufsummiert und als Koordinaten angezeigt werden.
Die Gestenerkennung wird dadurch realisiert, dass zunächst alle Koordinaten aus
denen die Gestenfigur besteht, zwischengespeichert werden. Die Koordinaten
werden dabei durch Addieren der relativen Bewegungsvektoren, die als Daten
vom Touchpad übermittelt werden, auf die jeweils zuvor berechnete Koordinate
ermittelt. Als erste Koordinate wird willkürlich der Koordinatenursprung P(0/0)
verwendet, der somit als Startpunkt der Gestenfigur dient.
90
Nach dem Speichern der Werte werden zunächst nur Startpunkt und Endpunkt,
auf ihre relative Lage zueinander geprüft. Wie bereits erwähnt sind nur Gesten
gültig, die von unten nach oben rechts, bzw. von unten nach oben links geführt
werden. Trifft eine dieser Bedingungen zu werden Steigung und Länge der
Geraden aus den Koordinaten für den Anfangs- und Endpunkt ermittelt.
Handelt es sich dabei um gültige Werte, d.h. entsprechen die Werte den
konfigurierten Vorgaben, wird die Gestenfigur daraufhin geprüft, ob es sich auch
tatsächlich um eine Gerade handelt. Zu diesem Zweck werden sämtliche die
Figur darstellenden Koordinaten durchlaufen und deren X-Komponenten in die
Geradengleichung y=mx eingesetzt. m ist dabei die zuvor aus End- und
Anfangspunkt ermittelte Steigung. Die y-Komponente jeder Geraden wird nun
mit dem Gleichungswert verglichen, wobei die y-Komponenten um einen festen
Wert, dem Toleranzwert nach oben oder unten hin abweichen darf. Die
Lösungsmenge der erlaubten Koordinaten liegt somit innerhalb eines
rechteckigen Intervalls, dessen Längsachse die durch die Geradengleichung
repräsentierte Gerade darstellt (Abbildung 6.3).
Abb. 6.3: Gestenverlauf innerhalb des Toleranzintervalls das durch die Gerade definiert wird, die
durch Anfangs- und Endpunkt der Geste verläuft.
Durch den Toleranzwert wird erreicht, dass eine ausgeführte Gestenbewegung
des Benutzers keine exakte Gerade darstellen muss. Stattdessen genügt es eine
angenäherte Gerade mit dem Finger zu führen. Ob eine Geste als Gerade erkannt
wird, ist sowohl von der Geschwindigkeit mit der die Geste ausgeführt wird, als
auch von dem Maß abhängig in dem die Bewegungsausführung von der
91
Darstellung einer Geraden abweicht. Je nach gewünschter Toleranz und
erwarteter Gestenausführungsgeschwindigkeit muss dieser Toleranzwert
angepasst werden. Es ist daher schwierig eine Regel zum Ermitteln des Wertes
aufzustellen. Am besten lässt er sich durch praktisches Ausprobieren ermitteln.
Der Toleranzwert liegt in fpTouchpadNode bei 100, da dieser Wert sich als
optimal für eine zügig durchgeführte Gestenbewegung erwiesen hat, die nicht
allzu stark von einer Geraden abweicht.
Da intern alle Koordinaten in einem nur begrenzten Speicherbereich abgelegt
werden, darf das Ausführen einer Geste nicht zu lange dauern, da ansonsten zu
viele Koordinaten generiert würden31. Wird die Geste als Gerade erkannt, soll
das Versenden des im Shared Workspace befindlichen Dokumentes an die linke
bzw. rechte Nachbarworkstation erfolgen. Zu diesem Zweck müssen die
Netzwerkschnittstellen der Client und Serversoftware noch angepasst werden.
Zum jetzigen Zeitpunkt sind noch keine der dafür nötigen Funktionen in Client
und Server implementiert.
Zum Schicken eines visualisierten Dokumentes an alle Konferenzteilnehmer
gleichzeitig, wird das Beschreiben einer Kreisbewegung auf der Sensorfläche
des Touchpads ausgeführt. Die Kreisbewegung soll dabei für den globalen
Charakter der damit ausgelösten Aktion des Versendens der Daten an alle
Teilnehmer stehen. Wie bei den Gesten zum Verschicken eines Dokumentes von
der eigenen Workstation zu einer anderen, muss auch hier während der
Ausführung der linke Touchpadbutton gedrückt gehalten werden. Die
Kreisbewegung muss außerdem im Uhrzeigersinn erfolgen. Der Startpunkt der
Gestenbewegung ist beliebig wählbar, vorgegeben ist jedoch das mindestens
einmalige Beschreiben eines Kreises.
Zum Erkennen einer kreisförmigen Geste wird das oben bereits beschriebene
Verfahren der Interpretation von Richtungswechseln innerhalb einer
Gestenausführung verwendet.
Das Ausführen einer Kreisfigur lässt sich an aufeinander folgenden
Vorzeichenwechseln der X- und Y-Relativwerte erkennen. Auf jeden 31 Da die Touchpadfläche begrenzt ist, ist eine zu lange dauernde Geste die eine Gerade darstellt, gleichzusetzen mit einer zu langsam ausgeführten Geste.
92
Vorzeichenwechsel der X-Werte muss dabei ein Vorzeichenwechsel des Y-
Wertes erfolgen und umgekehrt. Insgesamt müssen mindestens drei Wechsel
erfolgen um einen vollständigen Kreis zu beschreiben (Abbildung 6.4).
Abb. 6.4: Vorzeichenwechsel der relativen Bewegungswerte beim Ausführen einer Kreisgeste
auf dem Touchpad
Eine höhere Anzahl an auftretenden Vorzeichenwechseln ist ebenfalls gültig,
solange dabei die alternierende Reihenfolge von Vorzeichenwechseln der X- und
Y-Werte eingehalten wird. Wird diese Reihenfolge nicht eingehalten ist die
Geste ungültig. Dies trifft ebenso auf Gesten zu, bei denen die ersten drei
Vorzeichenwechsel dieser Regel entsprechen (also eine Kreisbewegung
ausgeführt wird), die darauf folgenden aber davon abweichen.
Pausen in der Gestendurchführung, bzw. sehr langsam ausgeführte Gesten
können zur Ausgabe von Nullwerten führen. Damit diese Nullwerte keine
Registrierung eines Vorzeichenwechsels bewirken, etwa wenn zuvor negative
Bewegungsdaten übermittelt wurden, werden Nullwerte bei der Untersuchung
auf Vorzeichenwechsel ignoriert.
93
6.3 Analyse der Aufgabenstellung zur Zuordnung von
Eingabegeräten zu Workstations
Neben dem Erkennen der jeweiligen Gesten auf den Touchpads musste zum
Zeitpunkt der Implementierung der hier vorgestellten Lösung noch ein internes
Problem gelöst werden, mit dem der Anwender selbst nicht in Berührung
kommt. Da alle Eingabegeräte als permanente Werkzeuge in den OfuturO-Tisch
integriert sind, ergab sich das Problem der Zuordnung der Geräte zu den
angeschlossenen Workstations. Dabei muss berücksichtigt werden, dass
möglicherweise nicht immer alle Plätze am Tisch belegt sind. Dadurch können
bestimmte Aktionen von vornherein nicht sinnvoll sein, wie beispielsweise das
Versenden eines Dokumentes an einen nicht vorhandenen Sitznachbarn.
Außerdem soll jede Workstation an jeden Platz beliebig an- und abgeschlossen
werden können. Es dürfen also keine Annahmen darüber gemacht werden,
wessen Workstation sich gerade an einem belegten Platz befindet.
Aus diesen Vorgaben resultiert, dass eine Vorgehensweise gefunden werden
musste, die vorgibt, wie die einzelnen Eingabegeräte, die sämtlich an den
Visualisierungsserver angeschlossen bleiben sollen, den immer nur zeitweise
angeschlossenen Workstations zugeordnet werden können.
Die Serversoftware, welche auf dem Visualisierungsserver läuft und die
Kommunikation der einzelnen Workstations mit dem Visualisierungssystem
regelt, speicherte zu diesem Zeitpunkt bereits intern die IP-Adressen der mit ihr
verbundenen Workstations. Diese Liste konnte durch eine Anfrage über das
lokale Netzwerk eingeholt werden. Die Liste machte allerdings keine Angaben
darüber, an welchem Platz sich angeschlossene Workstations befinden. Um diese
Informationen auch noch ermitteln zu können, wurden verschiedene
Lösungsmöglichkeiten in Betracht gezogen:
- Die Benutzer müssen ihre Workstations in einer festgelegten Reihenfolge
anschließen. Wird ein Platz frei, so muss der nächste Anwender der sich der
Konferenz mit seiner Workstation anschließen will, den der Reihenfolge nach
ersten freien Platz belegen. Die Serversoftware kann auf diese Weise intern eine
Zuordnung der einzelnen Teilnehmer zu den Plätzen am OfuturO-Tisch machen.
94
Vorteil: Es sind keine weiteren Konfigurationsmaßnahmen von Seiten der
Anwender nötig. Der DHCP-Dienst kann zur Vergabe der IP-Adressen an die
Workstations verwendet werden.
Nachteil: Eine große Verantwortung für den reibungslosen Ablauf einer Sitzung
liegt beim Anwender. Wird einmal die Vorgabe der Anschlussreihenfolge nicht
beachtet, geht der Server von falschen Tatsachen aus und die gesamte
Eingabeverarbeitung arbeitet falsch. Voraussetzung ist also, dass jeder
Anwender über die Vorgabe informiert ist und diese auch befolgt.
- Jeder Platz wird durchnummeriert und jeder Platznummer wird eine feste IP-
Adresse zugewiesen. Anhand der IP-Adressen, kann die Serversoftware
erkennen an welchen Plätzen sich Workstations angemeldet haben.
Vorteil: Der Anwender kann einen beliebigen freien Platz am OfuturO-Tisch
auswählen.
Nachteil: Es kann kein DHCP-Service zur IP-Nummernvergabe verwendet
werden. Stattdessen muss der Anwender selbst vor dem Anschluss seiner
Workstation zuerst die IP-Adresse seines Systems anpassen. Darüber hinaus
muss die IP-Adresse mit der übereinstimmen, die dem gewählten Platz am Tisch
entspricht. Wie in der obigen Lösung liegt somit auch bei dieser Lösung ein
großer Teil der Verantwortung beim Anwender.
- Jeder Platz wird durchnummeriert und der erste Schritt beim Einloggen in die
Workstationsoftware besteht in der Angabe der Platznummer an der sich der
Anwender gerade befindet. Erst danach steht dem Anwender die eigentliche
Workstation-GUI zur Verfügung. Die IP-Adresse der Workstation wird beim
Anmelden am Server zusammen mit der Platznummer abgelegt.
Vorteil: Die Teilnehmer können die Sitzplätze beliebig auswählen. Der DHCP-
Service kann genutzt werden, so dass keine weiteren Einstellungen am System
der Workstations nötig sind. Eine falsche Angabe beim Einloggen kann erkannt
und als Fehler gemeldet werden, wenn es sich um eine Nummer handelt, die
bereits vergeben ist.
95
Nachteil: Der Benutzer ist zum zusätzlichen Schritt der Platznummerneingabe
gezwungen.
6.4 Realisierung der Zuordnung von Eingabegeräten zu
Workstations
Um das Problem mit der Zuweisung der Gerätepaare zu den einzelnen
Workstations zu lösen, wurde die dritte der oben vorgestellten
Lösungsalternativen gewählt. Somit werden die einzelnen Arbeitsplätze künftig
mit Nummern versehen und ein Benutzer, der mit der GUI der
Workstationsoftware arbeiten möchte, muss als ersten Schritt beim Einloggen
angeben, an welchem Platz er sich befindet. Platznummer, sowie IP-Adresse der
angemeldeten Workstation, werden von der Serversoftware vermerkt. Um dies
zu realisieren war eine Änderung in der Serversoftware nötig, die vom Autor der
Software vorgenommen wurde.
Als nächstes musste eine feste Reihenfolge unter den Gerätepaaren beachtet
werden. Wie unter 5.2 beschrieben, wird eine solche Reihenfolge bereits intern
vom SMTP-Treiber vorgenommen. Sie ergibt sich dabei aus der Reihenfolge in
der die Geräte am USBus angeschlossen werden. Hier soll die Konvention
gelten, dass jedes Gerätepaar, der Workstation mit gleicher Nummer zugewiesen
wird. Weiter soll hier davon ausgegangen werden, dass die Nummerierung an
den Arbeitsplätzen für die Workstations entgegen dem Uhrzeigersinn
vorgenommen wird (Abbildung 6.5).
96
Abb. 6.5: Platznummernvergabe am OfuturO-Tisch
Auf diese Weise ist für jede Gerätepaarnummer die eigene Workstationnummer,
sowie die der rechten und linken Nachbarworkstation definiert32. Wird auf einem
der Touchpads eine gültige Geste erkannt, erfolgen die damit verbunden
Aktionen.
Damit der Klasse fpTouchpadNode die Nummer des eigenen Gerätepaares
bekannt ist, muss ihr diese SMTP-treiberinterne Nummer zuvor erst vom Treiber
bekannt gegeben werden. Wie bereits in der Beschreibung der Read-Funktion
unter 5.4.3 erwähnt, wird vom SMTP-Treiber, neben den 8 eigentlichen
Datenbytes, die vom Touchpad gesendet werden, noch ein neuntes Byte in die
Gerätedatei weitergeleitet. Dieses Byte wird als erstes verschickt und enthält die
vom SMTP-Treiber intern verwaltete Gerätepaarnummer zu welcher das
Touchpad gehört. Beim Auslesen der Touchpadgerätedatei greift
fpTouchpadNode jedes Mal auf dieses erste Byte zu, sobald eine Geste
identifiziert worden ist.
6.5 Die Klassen fpTouchpadNode und fpSpacemouseNode
Sowohl fpTouchpadNode als auch fpSpacemousNode sind von fpSerialDevice
abgeleitet, einer Klasse zum Verwalten von Geräteeingaben über eine serielle
Schnittstelle.
32 Workstation 1 hat hierbei als linken Nachbarn die Workstation 3, während diese als rechten Nachbarn wiederum Workstation 1 hat.
97
Die Methoden die in diesen Klassen (re)implementiert wurde ist die vererbte
Methode readLoop von fpSerialDevice, die als virtuell deklariert ist und in den
Klassen fpTouchpadNode und fpSpacemouseNode überschrieben wurden. Neben
readLoop erben beide Klassen noch weitere, von fpSerialDevice und seinen
Vorgängern implementierte Methoden. Auf diese Methoden soll hier jedoch
nicht eingegangen werden, da sie unverändert übernommen worden sind und in
den Avango-Quellcodes eingesehen werden können.
Instanzen der Klassen fpTouchpadNode und fpSpacemouseNode werden über ein
Schemeskript erstellt. Im folgenden wird die überschriebene Methode readLoop,
sowohl für fpSpacemouse als auch für fpTouchpad vorgestellt.
Die Methode readLoop
Diese Methode stellt das Kernstück der Klassen fpTouchpadNode und
fpSpacemouseNode dar. Hauptaufgabe von readLoop ist das Übertragen der
Gerätedaten über den av-daemon, so dass Avango-Objekten der Zugriff darauf
ermöglicht wird. Der Zugriff erfolgt dabei über Matrizen, in die Translations-
und Rotationswerte übertragen werden. Die Matrizen sind Bestandteil einer so
genannten Station. Eine Station kommt einem Ereignisempfänger gleich, in dem
Bewegungen und Buttonbetätigungen gespeichert werden. Außer Matrizen
beinhaltet eine Station zu diesem Zweck noch Felder für das Anzeigen von
Buttonwerten und Felder für das Anzeigen sonstiger Werte, für den Fall, dass ein
Gerät über weitere Funktionen verfügt. Ein Gerät kann mehrere Stations
besitzen, wobei es der Implementation von readLoop überlassen ist festzulegen,
wie und welche Daten in die Felder der Station übertragen werden.
Aufgabe des av-daemons ist es die in den Station-Komponenten gespeicherten
Werte in einen Speicherbereich zu übertragen von dem aus eine Avango-
Applikation sie auslesen kann33.
Das Auslesen erfolgt über einen so genannten Sensor. Der Sensor wiederum ist
mit einem DeviceService verbunden, der mit dem av-daemon verbunden ist.
33 Realisiert wird dies durch ein Shared-Memory-Segment, das vom av-daemon beschrieben und von einer Avango- Applikation ausgelesen werden kann.
98
Wird nun ein von fpDCS34 abgeleitetes Objekt instanziiert, kann es die eigene
Matrix mit der des Sensors verknüpfen. Die Sensormatrix wiederum wird über
den av-daemon mit den von einer Station übertragenen Werten versorgt.
fpSpacemouseNode sorgt lediglich für das Übertragen der aus der
Spacemausgerätedatei ausgelesenen Daten an eine verknüpfte Station. Dazu
werden die Werte für die Rotationen und für die Translationen in entsprechende
Rotations- und Tranlationsmatritzen übertragen. Die Ergebnismatrix, die an die
Station weitergegeben wird, ergibt sich dann aus der Multiplikation aller
Matrizen miteinander.
Da fpTouchpadNode keine Rotationsdaten ausliest, müssen hier nur
Translationsdaten in eine Matrix übertragen und an die Station weitergeleitet
werden. Darüber hinaus wird in fpTouchpadNode eine Interpretation der
empfangenen Gerätedaten in Form der Gestenerkennung vorgenommen. Dabei
wird zuerst auf die Kreisfigur geprüft. Bei einem Fehlschlagen, d.h. es konnte
keine Kreisgeste erkannt werden, werden die Gestendaten auf eine mögliche
Gerade hin untersucht.
Wird eine Gerade als Geste identifiziert, wird mittels einer Netzwerkanfrage
vom Server die Liste mit den angeschlossenen Workstations angefordert und in
einer internen Datenstruktur zwischengespeichert. Anhand der
Workstationnummern findet eine Zuordnung zwischen dem Touchpad und der
damit verbundenen Workstation statt. Dabei wird überprüft ob eine Workstation
an dem Platz zu dem das Touchpad gehört, überhaupt vorhanden ist. Dadurch
wird vermieden, dass Anfragen bearbeitet werden, die von einem Gerät gemacht
werden, das sich an einem unbesetzten Platz befindet. Anschließend wird
überprüft, ob die Workstation mit der Nummer zu der gesendet werden soll,
angeschlossen ist. Beides wird dadurch erreicht, dass von der Serversoftware die
Liste mit den im Netzwerk angeschlossenen Workstations angefordert wird. Da
sich diese Liste jederzeit ändern kann, erfolgt das Anfordern jedes Mal, wenn ein
Dokument über eine Geste verschickt werden soll.
Sind sowohl Ausgangs- als auch Zielworkstation identifiziert und als vorhanden
registriert, erfolgt das Verschicken des Dokumentes mittels eines Signals an die
Serversoftware. Das Signal beinhaltet die Art der auszuführenden Aktion:
34 Ein fpDCS-Objekt ist die unterste Instanz eines Avango-Knotens, aus denen ein Avango-Scene-Graph aufgebaut wird.
99
Das Übertragen der Datensätze im Shared Workspace an die eigene, eine andere
als die eigene oder alle Workstations gleichzeitig.
100
Kapitel 7
Ergebnis
In diesem Kapitel sollen die in dieser Diplomarbeit erzielten Ergebnisse
ausgewertet und interpretiert werden. Dabei werden Vorteile und Schwachstellen
der Lösungen aufgezeigt und gegebenenfalls Verbesserungsvorschläge gemacht.
Grundlage für die Bewertung sind die nachfolgend vorgestellte
Beispielapplikation, sowie die Erfahrungswerte, die während der Ausarbeitung
der einzelnen Lösungsschritte gesammelt wurden.
7.1 Die Beispielapplikation zur Demonstration der
erzielten Ergebnisse
Die Bestandteile der Beispielapplikation an der die Funktionalität der
gefundenen Lösungen demonstriert werden kann, wurden als Schemeskripte
implementiert. Der erste Teil ist im File SampleApplikation.scm codiert
und kann mit der Befehlszeile
exec $AV_HOME/build/bin/aview.sh–v –o device:mon –f
SampleApplikation.scm
aus einem Shellskript heraus aufgerufen werden. Alternativ können die in
SampleApplikation implementierten Befehle auch einzeln in die Avango-Shell
eingegeben werden. Durch Aufrufen der oben genannten Befehlszeile wird die
Avango-Shell auf dem Visualisierungsserver gestartet und es werden zwei
Grafikobjekte auf dem Bildschirm dargestellt, ein dreidimensionales Objekt in
Form eines Würfels und ein zweidimensionales Objekt in Form eines
Textdokumentes. Die Darstellung auf dem Bildschirm steht hierbei
stellvertretend für die Darstellung von Grafikobjekten, die in Zukunft auf der
Projektionsfläche des OfuturO-Tisches erfolgen soll. Die Grafikobjekte Würfel
und Textdokument entsprechen dabei Daten, die im Shared Workspace lagern.
101
Um die Objekte mit Hilfe von Spacemaus und Touchpad steuern zu können,
muss noch der av-daemon gestartet und diesem das zweite Teil der
Beispielapplikation in Form des Schemeskriptes ofuturo-devices.scm
übergeben werden. Das Skript erstellt und konfiguriert Avango-Objekte vom
Typ Device, welche die Touchpad- und Spacemausgerätedateien auslesen und an
den av-daemon weiterleiten. Damit die Daten aus den Gerätedateien ausgelesen
werden können muss der SMTP-Treiber geladen sein. Wenn mindestens eine
Magellan Spacemouse Plus und ein Cirque Easy Cat Touchpad am USBus des
Visualisierungsservers angeschlossen sind, kann der dargestellte Würfel mit der
Spacemaus und das dargestellte Textdokument mit dem Touchpad gesteuert
werden. Die Spacemaus ermöglicht dabei Rotationen um alle Raumachsen des
Würfels und Translationen entlang aller Achsen. Das Touchpad ermöglicht die
Steuerung des Textdokumentes auf dem Bildschirm entlang der X- und Y-
Achse. Sind mindestens noch eine weitere Spacemaus und ein weiteres
Touchpad angeschlossen, kann der Eingabefokus durch einen Buttondruck auf
der momentan den Fokus besitzenden Spacemaus gewechselt werden. Der
Wechsel erfolgt dabei auf das Gerätepaar mit der Nummer, die dem gedrückten
Button entspricht. Die Gerätepaarnummer wird von der Anschlussreihenfolge
der Geräte bestimmt (siehe auch 5.2 für Details).
Ist der GVM Server aktiviert, kann ein Touchpad eingesetzt werden, um im
Shared Workspace gelagerte Daten mit Hilfe von Gesten zu versenden.
Voraussetzung ist dabei, dass zumindest zwei Workstations am Server
angemeldet sind. Besitzt ein Touchpad den Eingabefokus und ist es einer der
Workstations zugeordnet (siehe 6.4 für das Verfahren der Zuordnung zwischen
Workstations und Eingabegeräten) können die Daten im Shared Workspace an
eine andere Workstation verschickt werden. Durch das Ausführen einer
diagonalen Bewegung von links unten nach rechts oben kann der Anwender die
Daten an die von seiner Workstation aus gesehen rechte Nachbarworkstation
senden. Durch das Ausführen einer diagonalen Bewegung von rechts unten nach
links oben kann der Anwender die Daten an die von seiner Workstation aus
gesehen linke Nachbarworkstation senden. Durch das Ausführen einer
Kreisbewegung im Uhrzeigersinn kann der Anwender die Daten an alle im
Netzwerk angeschlossenen Workstations, inklusive seiner eigenen senden.
102
Da die Beispielapplikation nicht wirklich Daten darstellt und steuern lässt, die
sich im Shared Workspace befinden, kann es sich bei den Daten die aus dem
Shared Workspace versendet werden, um andere Daten handelt, als die welche
auf dem Bildschirm visualisiert sind.
7.2 Betrachtung der Lösung zum Einbinden der
Eingabegeräte in OfuturO
Die Beispielapplikation zeigt, dass die gestellten Anforderungen an die
Eingabeverarbeitung in OfuturO erfüllt sind. Sowohl 2D- als auch 3D-Daten
können mit den Eingabegeräten gesteuert werden. Die Eingabe ist dabei auf
einen bestimmten Benutzer beschränkt, der die Eingabemöglichkeit
weiterreichen kann.
Der SMTP-Treiber arbeitet dazu praktisch indem er eine ganze Reihe von
einzelnen Geräten zu einem Gerät abstrahiert. Dieses SMTP-Gerät stellt die
kombinierten Eingabemöglichkeiten von einem Touchpad für Bewegungen in
der Ebene und von einer Spacemaus für Bewegungen im Raum zur Verfügung.
Es erlaubt dazu eine exklusive Eingabe über bis zu acht Gerätepaare und den
Wechsel des Fokus’ für die Eingabe.
Dabei werden die Flächenbewegungsdaten und die Raumdaten in jeweils
gesonderte Gerätedateien umgeleitet. Eine Anwendung die auf diese
Gerätedateien zugreift bekommt von der paarweisen Zuordnung einzelner Geräte
ebenso nichts mit wie von einem Wechsel des Eingabefokus. Dadurch
beschränkt sich die Aufgabe der Anwendung im Auslesen der Raum- und
Flächenbewegungsdaten aus den beiden Gerätedateien um diese dann nach
eigenem Ermessen zu verarbeiten. Da der SMTP-Treiber als eigenständiges
Kernelmodul implementiert ist, benötigt er im Gegensatz zu vielen anderen
Eingabegerätetreibern weder das Modul input noch das Modul hid.
Der SMTP-Treiber ist allerdings speziell auf die Anforderungen der
Eingabeverarbeitung in der OfuturO-Umgebung ausgelegt. Das macht einen
universellen Einsatz unmöglich. Will man flexibler mit der Verarbeitung von
103
Eingabedaten umgehen, empfiehlt sich eher der Einsatz einzelner Gerätetreiber
für jeden Gerätetyp. Obwohl viele Treiber durchaus mehrere Geräte behandeln,
ist die im SMTP-Treiber gewählte Vorgehensweise zwei Gerätearten zu Paaren
zu verknüpfen für Treiber unüblich. Normalerweise beschränken sich diese
allein auf das Übertragen der Gerätedaten, sowie auf Konfigurationsfunktionen.
Bei der hier gefundenen Lösung war vor allem die Vorgabe einer
Eingabeverarbeitung über einen Fokus ausschlaggebend dafür, dass sowohl
Spacemaus als auch Touchpad von nur einem Treiber behandelt werden.
Es mag Anwendungen im Bereich der Konferenzszenarien oder der Virtual
Reality allgemein geben, in der 2D- und 3D-Daten ähnlich wie beim OfuturO-
Projekt durch kombinierte 2D- und 3D-taugliche Eingabegeräte bearbeitet
werden sollen. Für diese Anwendungen stellt der SMTP-Treiber eine
Beispiellösung dar, wie man Geräte unterschiedlicher Art innerhalb eines
Kerneltreibers behandeln und miteinander wechselwirken lassen kann. In den
meisten Fällen dürfte es aber einfacher sein ein Wechselwirken von Geräten
untereinander, außerhalb eines Kerneltreibers zu implementieren. Die Erfahrung
mit dem SMTP-Treiber zeigt, dass die Problematik der race conditions, die in
Kerneltreibern sowieso schon besteht, massiv zunimmt, wenn auch noch
Abhängigkeiten der Geräte untereinander beachtet werden müssen.
So findet sich eine Schwachstelle in der Lösung der race conditions Problematik
innerhalb der Read-Funktion (siehe 5.5). Eine kritische Situation tritt dabei auf,
sobald der Eingabefokus gewechselt wird. Der Fokuswechsel wird immer durch
einen Buttondruck auf der Spacemaus ausgelöst, die momentan den
Eingabefokus besitzt. Der Wechsel, sowohl für die Spacemaus als auch für das
dazugehörige Touchpad, findet somit im Read- Prozess, welcher der Spacemaus-
Gerätedatei zugewiesen ist, statt (rot beschrifteter Bereich in Abbildung 5.3). Zu
diesem Zeitpunkt hat Read aber schon die Kontrolle über das globale Mutex
wieder zurückgegeben. Ein Prozess, der die Touchpad- Gerätedatei ausliest,
könnte jetzt bereits parallel die Nummer des Eingabefokus besitzenden
Gerätepaares auslesen, obwohl diese kurze Zeit danach vom Spacemaus
auslesenden Read samt der URB- Zuweisung geändert wird. Die Folge ist, dass
der Touchpad auslesende Prozess versucht Daten von einem Gerät zu lesen,
104
dessen URB gar nicht mehr mit dem USB- Subsystem verlinkt ist. In diesem Fall
wird einer Touchpad- Gerätedatei auslesenden Applikation anstatt der
Gerätedaten einmal eine Fehlübermittlung angezeigt, bevor die Daten wieder
korrekt ausgelesen werden.
Da dies in der Praxis jedoch selten auftreten, bzw. falls doch, für den Anwender
unbemerkt bleiben dürfte und zudem keine schwerwiegenden Fehler dadurch
ausgelöst werden, wurden hier keine weiteren Koordinierungsmaßnahmen
getroffen.
Alternative Lösungsmöglichkeit
Ein Einbinden der Eingabegeräte in die OfuturO-Umgebung ist auch anders
denkbar:
Statt die gesamte Logik zur paarweisen Verknüpfung von Spacemäusen und
Touchpads sowie dem Eingabefokuswechsel direkt im Treiber zu
implementieren, könnte sie auch in die die Gerätedateien auslesenden
Avangoklassen verlagert werden. Die Aufgabe der Klasse fpSpacemouse bzw.
fpTouchpad wäre dann das Auslesen von nicht nur einer, sondern mehrerer
Gerätedateien, da normalerweise jedem am USBus angeschlossenen Gerät eine
eigene Datei zugewiesen wird. Es würden dann zwei Treiber benötigt, (ein
Spaceaustreiber sowie ein Touchpadtreiber) deren Aufgabe lediglich im
Übertragen der Daten von den Geräten in die entsprechenden Dateien und
eventueller Gerätekonfigurationsfunktionen bestünde. Die paarweise Zuweisung
von Spacemouse und Touchpad müsste in diesem Fall in den Avangoklassen
implementiert werden, ebenso wie die Funktion zum Fokuswechsel. Innerhalb
der Klassen müsste dann entschieden werden von welchem der angeschlossenen
Geräte die Daten über den av-daemon weitergeleitet werden.
Ein Problem wäre bei dieser Lösung die Kommunikation zwischen der Klassen
die die Spacemauseingabe und der Klasse welche die Touchpadeingabe
behandelt. Eine Kommunikation wäre nötig um einen Eingabefokuswechsel zu
koordinieren, da die Touchpadklasse über jeden Fokuswechsel informiert
werden müsste den die Spacemausklasse registriert. Beim SMTP-Treiber fällt
105
dieses Problem weg, da Spacemaus- und Touchpadgeräte von globalen
Strukturen behandelt werden und sich über diese Strukturen koordinieren
können.
Eine weitere Alternative ergibt sich bezüglich der Rolle des SMTP-Treibers als
Kernelmodul: Anstatt einen Treiber als eigenständiges Modul zu implementieren
besteht besonders für Eingabegerätetreiber die Möglichkeit auf bereits
vorhandenen Module aufzubauen. Das Modul hid stellt zu diesem Zweck schon
viele Funktionen für die Behandlung von Mensch-Computer-Schnittstellen unter
Linux zur Verfügung, die durch das Modul input für die Behandlung von
Eingabeschnittstellen noch spezialisiert werden können. Viel
Implementierungsarbeit, die bei der Programmierung des SMTP-Treibers
erforderlich war, wird durch Verwenden dieser Module schon
vorweggenommen. Allerdings geht der verringerte Programmieraufwand zu
Lasten der Kontrolle über die Geräteverwaltung. Da der SMTP-Treiber ein sehr
spezialisierter Treiber ist, der zwei Geräte in einem ganz bestimmten Konsens
zueinander behandelt, erschien es einfacher auf vorgefertigte Module zu
verzichten, die eher darauf ausgelegt sind einzelne Geräte auf herkömmliche
Weise zu behandeln.
Verbesserungsmöglichkeiten
Der SMTP-Treiber stellt in seiner jetzigen Form noch keine Möglichkeiten zu
einer Konfiguration der Geräte zur Verfügung. Damit fehlt dem Treiber eine der
grundlegenden Funktionen die ein Kerneltreiber gewöhnlich übernimmt.
Insbesondere die Spacemäuse verfügen über eine große Zahl von
Konfigurationsmöglichkeiten (siehe 4.2.2). Diese Funktionen könnten mit Hilfe
des control-endpoints implementiert und über die ioctl-Schnittstelle zugänglich
gemacht werden. Damit wäre die Möglichkeit gegeben die in der Hardware
implementierten Funktionen beispielsweise über Auswahlmenus auf der GUI der
Workstations zu steuern.
Eine weitere Konfigurationsmöglichkeit könnte darin bestehen den
Eingabefokus steuern zu können. In der momentanen Implementierung ist dies
106
nur durch den Buttondruck auf einer Spacemaus möglich, die gerade den
Eingabefokus besitzt.
7.3 Betrachtung der Lösung zum Versenden
visualisierter Daten über die Gesten
7.3.1 Die Gestenerkennung auf den Touchpads
Die Beispielapplikation zeigt, dass das Versenden von visualisierten Daten über
Gesten, die Diagonalen von links unten nach rechts oben, bzw. von rechts unten
nach links oben, darstellen, in der Praxis ohne größere Schwierigkeiten
funktioniert. Defizite treten allerdings beim Beschreiben der Kreisgeste auf. Hier
wird nicht jede Kreisbewegung als solche erkannt, was vor allem darauf
zurückzuführen ist, dass das Beschreiben eines Kreises mehr Sorgfalt erfordert
als das Beschreiben einer Diagonalen.
Die unter 6.1 angeführte Problematik zeigt außerdem, dass die in OfururO
eingebundenen Touchpads nur bedingte Möglichkeiten bieten um auf der
Sensorfläche beschriebene Figuren abzufragen. Das Hauptproblem liegt hierbei
in der unter 6.1 angeführten Problematik, dass die in Touchpads verwendete
Technologie keine Ausgabe von Bewegungsdaten als Absolutwerte, sondern nur
in Form von Relativwerten erzielt. Eine Figureninterpretation ist dadurch in
erster Linie durch Analyse von Änderungen in den Bewegungsabläufen durch
Betrachten von Vorzeichenwechseln in der Folge der übermittelten Werte
möglich. Dadurch kann in der Regel zwar der grobe Bewegungsablauf, nicht
jedoch die exakte Figur die auf der Sensorfläche ausgeführt wurde, erfasst
werden. So erkennt die in fpTouchpad implementierte Funktion zum
Registrieren einer Kreisfigur, eine solche in jedem Gestenverlauf, der einen
dreimaligen, zwischen X- und Y-Werten alternierenden Vorzeichenwechsel nach
sich zieht. Dies ist jedoch nicht nur beim Beschreiben eines Kreises der Fall.
Jede Geste, die eine konvexe Fläche umschreibt erfüllt diese Bedingungen. Als
Beispiel seien hier ein Dreieck oder ein Rechteck genannt.
107
Hinzu kommt, dass keine Zeigevorrichtung durch das Touchpad gesteuert wird,
anhand der ein Benutzer die von ihm gemachte Geste verfolgen kann. Dieser
Umstand dürfte eine Implementierung komplexerer Gesten erschweren.
Es muss jedoch zwischen dem exakten Nachvollziehen einer Figur und einer
Geste unterschieden werden. Eines der unter 6.1 angeführten Kriterien für die
Implementierung der Gestenerkennung ist, eine gewisse Freiheit in der
Gestenausführung zu erlauben.
Verbesserungsmöglichkeiten
Um eine genauere Gestenausführung und komplexere Gesten zu ermöglichen,
wäre es von Vorteil wenn der Gestenverlauf durch eine Zeigevorrichtung auf der
Projektionsfläche der OfuturO-Plattform nachvollzogen werden könnte. Die
Zeigevorrichtung könnte eingeblendet werden, sobald auf dem Touchpad der
Button gedrückt und somit der Beginn einer Gestenbewegung signalisiert wird.
Der Zeiger könnte dabei die zurückgelegte Spur auf der Projektionsfläche
markieren, so dass der Benutzer jederzeit weiß, wo er sich relativ zum
Ausgangspunkt der Gestenbewegung befindet. Auf diese Weise könnten die
Relativwerte, die vom Touchpad ausgegeben werden zu einer Reihe von
Koordinaten zusammengesetzt werden, die eine Figur darstellt, welche exakt der
auf der Projektionsfläche beschriebenen Figur entspräche. Die so konstruierte
Figur könnte dann in fpTouchpadNode mit vorgegebenen Figuren auf
Übereinstimmung verglichen werden.
7.3.2 Die Zuordnung der Workstations zu den Gerätepaaren
Das Ausführen der durch die Gesten bezweckten Aktionen wird dadurch
erschwert, dass die Geräte auf denen die Gesten ausgeführt werden nicht mit den
einzelnen Workstations der Benutzer verbunden, sondern zentral am
Visualisierungsserver angeschlossen sind. Die Problematik die sich daraus
ergibt, sowie die Lösung wurden unter 6.1 bzw. 6.2 erläutert. Die in 6.2
gefundene Lösung hat den Nachteil, dass jedem Platz am OfuturO-Tisch eine
108
feste Nummer zugewiesen werden muss. Dadurch müssen die Gerätepaare der
Reihenfolge ihrer Platznummern entsprechend angeschlossen werden, damit die
interne Nummernzuweisung denen der Plätze entspricht. Ein Teil der
Flexibilität, die im SMTP-Treiber realisiert wurde, indem Spacemouse-
Touchpad-Gerätepaare auch ohne bestimmte Vorgaben in der
Anschlussreihenfolge gebildet werden, geht dadurch wieder verloren. Dies kann
die Arbeit innerhalb von OfuturO allerdings als nicht allzu bedeutend angesehen
werden, da hier für die Eingabegeräte eine permanente Verbindung am
Visualisierungsserver geplant ist, wodurch die Anschlussprozedur nur bei einem
Systemneustart wiederholt werden muss.
Schwerwiegender ist die Tatsache, dass zu dem eigentlichen Login des OfuturO-
Konferenzteilnehmers an der GUI seiner Workstation der zusätzliche
Arbeitsschritt der Platznummerneingabe erfolgen muss. Hier liegt es in der
Verantwortung des Benutzers die richtige Platznummer einzugeben. Eine
fehlerhafte Eingabe kann von der Serversoftware, die sowohl Platz- als auch IP-
Nummer der Workstation speichert, in der Regel nicht erkannt werden.
Wie beschrieben musste den Datenbytes der Touchpadgeräte ein zusätzliches
Byte innerhalb des SMTP-Treibers zugefügt werden, um die Zuordnung
zwischen den Gerätepaaren und den angeschlossenen Workstations zu
realisieren. Dies stellt in gewisser Hinsicht einen Bruch in der klaren
Abgrenzung zwischen den Aufgaben des SMTP-Treibers und den Aufgaben der
Applikationsklasse fpTouchpadNode dar. Der Treiber, dessen Aufgabe auf das
Übertragen von Daten eines Gerätepaares beschränkt bleiben sollte, übernimmt
damit bereits einen Teil der Aufgabe, zur mit der Gestenerkennung realisierten
Dokumentenübertragung.
109
Literaturverzeichnis [Ade03] Homepage Heinz Ade, Touchpad Technologie, 2003 URL:
http://www.heinz-ade.de/texte/technologie-1.htm [Axe99] Jan Axelson, USB Handbuch für Entwickler, 1.Aufl., Bonn,
MITP-Verlag, 2001 [Boh99] G. Bohmann, Virtual Reality, Drantum 1999, URL:
http://www.uni-vechta.de/studium/homepages/bohmann.guido/VR.doc
[Cir03] Homepage Cirque, Technologie/ GlideTechnologie®,2003
URL : http://www.cirque.com/tech/glide.html [FIT03] Fraunhofer FIT. KoKoBel Homepage. April 2003. URL: http:
//www.fit.fraunhofer.de/projekte/kokobel/index.xml. [Fli00] Detlef Fliegl, URL: http://usb.cs.tum.edu/download/usbdoc, 2000 [Gal03] Goran Galunic, Office Of The Future- Einbettung virtueller
Hilfsmittel in Arbeitsumgebungen am Beispiel der Entwicklung einer Visualisierungs- und Kommunikationsschnittstelle für ein Mixed Reality Conferencing System, Diplomarbeit FH Köln, 2003
[GKG+03] G. Goebbels, E. Kruij, G. Galunic, T. Orthey, A. Ivanovic, L.
Sanfilippo. OfuturO - A Mixed Reality Desk Environment for Supporting Creativity Methods, In Proceedings of 5th SBC Symposium on Virtual Reality (SVR 2003) Riberao Preto, Sao Paulo, Brazil 2003.
[Goe01] G. Goebbels. Team work in Distributed Collaborative Virtual
Environments, Dissertation University of Pretore, South Africa, 2001.
[GTB+02] G.Goebbels, K.Troche, M.Braun, A.Ivanovic, A.Grab, K.von Lübtow, H.F.Zeilhofer, R.Sader, F.Thieringer, K.Albrecht, K.Praxmarer, E.Keeve, N.Hanssen, Z.Krol, F.Hasenbrink, Arsys-Tricorder - Entwicklung eines Augmented Reality Systems für die intraoperative Navigation am Beispiel des individuellen Transplantatdesigns in der Mund-Kiefer-Gesichtschirurgie, Proceedings der BMBF Statustagung, 05. -06.11.2002, Leipzig, Germany
[Gui03] Homepage vom Linux USGuide, URL:http://linuxusbguide.sourceforge.net
110
[Her03] Helmut Herold, Linux/Unix- Systemprogrammierung, 2. Aufl., München: Addison- Wesley, 2003
[IMK03] Fraunhofer IMK. Avango Homepage. April 2003. URL:
http://www.avango.org. [IU97a] Hiroshi Ishii and Brygg Ullmer. Tangible Bits: Towards
Seamless Interfaces between People, Bits and Atoms. ACM Press, Chi 1997.
[IU97b] Hiroshi Ishii and Brygg Ullmer. The metaDESK: Models and
Prototypes, for Tangible User Interfaces. ACM Press, Banff, Alberta, Canada, 1997.
[KR98] M. Kohlhaas, H. Regenbrecht, Virtual Reality- Virtual Reality
Aided Design, URL: http:// www.uni-weimar.de/architektur/InfAR/lehre/Course01/index.html
[Lin03] Homepage vom Linux USB Projekt, URL: http://www.linux-
usb.org, 2003 [Log99] Magellan/ Space Mouse Programming Guide, Version 2.1,
LogiCad3D, Seefeld, Germany, 1999 [MC99] Paul Milgram, Herman Colquhoun, A Taxonomy of Real and
Virtual World Display Integration, o.O.,1999. [Mic03] Sun Microsystems. Java 3D API Homepage. Juni 2003. URL:
http://java.sun.com/products/java-media/3D. [Phi03] N. Philippsen, Virtuelle Realität, URL: http://www.it.fht-
esslingen.de/~schmidt/vorlesungen/vr/seminar/ ws9899/virtuellerealitaet.html
[RC02] Allesandro Rubini, Jonathan Corbet, Linux Gerätetreiber,
2.Auflage, Köln: O’ Reilly Verlag, 2002 [RL01] Ramesh Raskar and Kok-Lim Low. Interacting with Spatially
Augmented Reality. ACM Press, o.O., 2001. [RWC+98] Ramesh Raskar, Greg Welsh, Matt Cutts, Adam Lake, Lev
Stesin, and Henry Fuchs. The Office of the Future: A Unified Approach to Image-Based Modeling and Spatially Immersive Displays, o.O., 1998.
[SGH98] Norbert A. Streitz, Jörg Geissler, and Torsten Holmer.
Roomware for Cooperative Buildings: Integrated Design of Architectural Spaces and Information Spaces. Springer Verlag, o.O.,1998.
111
[Sut65] I.E. Sutherland, The Ultimate Display, New York, 1965
[Sut68] I.E. Sutherland, A Head- Mounted Three- Dimensional Display, New York ,1968
[Tra98] Henrik Tramberend. Avango: A Distributed Virtual Reality Framework, ACM, 1998.
[Vie03] Homepage Viewtec, Virtual Reality, 2003, URL: http://www.viewtec.ch/techdiv/vr_info_d.html
[Wel93] Pierre Wellner. Interacting with Paper on the DigitalDesk. ACM Press, New York, 1993.
112
Anhang
1. Die Datei SampleApplikation.scm
1 (define tp-service (make-instance-by-name “fpDeviceService“)
2 (-> tp-service ‘register-service “DeviceService”)
3 (-> tp-service ‘connect-daemon)
4 (define tpsensor (make-instance-by-name “fpDeviceSensor”))
5 (-> (-> tpsensor ‘Station) ‘set-value “touchpad”))
6
7 (define textdocument (make-instance-by-name “fpLoadFile”))
8 (-> (-> textdocument ‘Name) ‘set-value “Document”)
9 (-> (-> textdocument ‘Filename) ‘set-value “document.iv”)
10 (-> (-> textdocument ‘Matrix) ‘connect-from (-> mysensor ‘Matrix))
11 (-> (-> av-root ‘Children) ‘add-1value textdocument)
12
13
14 (define sm-service (make-instance-by-name “fpDeviceService“)
15 (-> sm-service ‘register-service “DeviceService”)
16 (-> sm-service ‘connect-daemon)
17 (define smsensor (make-instance-by-name “fpDeviceSensor”))
18 (-> (-> smsensor ‘Station) ‘set-value “spacemouse”))
19
20 (define cube (make-instance-by-name “fpLoadFile”))
21 (-> (-> cube ‘Name) ‘set-value “Cube”)
22 (-> (-> cube ‘Filename) ‘set-value “cube.iv”)
23 (-> (-> cube ‘Matrix) ‘connect-from (-> mysensor ‘Matrix))
24 (-> (-> av-root ‘Children) ‘add-1value cube)
2. Die Datei ofuturo-devices.scm
1 (add-device “device1“ “fpTouchpadNode“)
2 (config-device “device1“ “tty“ “/dev/usb/touchpad“)
3 (add-station “device1” “touchpad” 1)
4 (start-device “device1”)
5
6
7 (add-device “device2“ “fpSpacemouseNode“)
8 (config-device “device2“ “tty“ “/dev/usb/spacemouse“)
9 (add-station “device2” “spacemouse” 1)
10(start-device “device2”)
113
Um die Beispielapplikation zu starten muss zuerst der av-daemon gestartet
werden. Mit der Option –f kann der av-daemon direkt mit ofuturo-
devices.scm aufgerufen werden:
�AV_HOME/bin/av-daemon.sh –f usb-devices.scm �
Danach muss die Avango-Shell gestartet werden, damit sie das File zum
Erstellen der Grafikobjekte einliest:
$AV_HOME/build/bin/aview.sh -v -o device:mon -f SampleApplikation.scm Damit die Gerätedaten in die richtigen Gerätedateien umgeleitet werden, muss außerdem der SMTP-Treiber geladen sein: $ insmod smtp-driver.o
114
Erklärung
Ich versichere, die von mir vorgelegte Arbeit selbständig verfasst zu haben. Alle
Stellen, die wörtlich oder sinngemäß aus veröffentlichten oder nicht
veröffentlichten Arbeiten anderer entnommen sind, habe ich als entnommen
kenntlich gemacht. Sämtliche Quellen und Hilfsmittel, die ich für die Arbeit
benutzt habe, sind angegeben. Die Arbeit hat mit gleichem Inhalt bzw. in
wesentlichen Teilen noch keiner anderen Prüfungsbehörde vorgelegen.
Ort, Datum Unterschrift
