Räumliche Navigationstechniken für Zoomable User Interfaces

Räumliche Navigationstechniken für
Zoomable User Interfaces
Bericht zum Masterprojekt
von Stephan Huber
1 EINLEITUNG ................................................................................................................................................. 1
2 ÜBERSICHT .................................................................................................................................................. 4
3 OPTITRACK TRACKING TOOLS ............................................................................................................. 6
3.1 ALLGEMEINE INFORMATIONEN ................................................................................................................... 6
3.2 AUFBAU DER KAMERAS ............................................................................................................................... 8
3.3 KALIBRIERUNG DER KAMERAS ................................................................................................................ 10
3.3.1 ABLAUF DER KALIBRIERUNG............................................................................................................................... 12
3.4 DEFINITION VON TRACKABLES (RIGID BODIES) ................................................................................... 15
3.5 STREAMING SERVER ................................................................................................................................. 20
3.6 NATNET SDK ........................................................................................................................................... 21
4 PROXIMITY TOOLKIT ............................................................................................................................ 24
4.1 EINFÜHRUNG ............................................................................................................................................. 24
4.2 OPTITRACKINPUTMODULE ..................................................................................................................... 25
4.2.1 KLASSEN ................................................................................................................................................................. 25
4.2.2 BESCHREIBUNG DER VSK-DATEI ....................................................................................................................... 26
4.2.3 KONVERTIERUNG VON QUATERNION IN EULERWINKEL ................................................................................ 28
4.3 PROXIMITY SERVER.................................................................................................................................. 30
4.3.1 STARTEN DES SERVERS ........................................................................................................................................ 30
4.3.2 SERVER GUI ........................................................................................................................................................... 31
4.3.3 VSK-DATEIPFAD ................................................................................................................................................... 32
4.3.4 DEFINITION VON POINTERN ................................................................................................................................ 32
4.3.5 KALIBRIERUNG DES SPACE .................................................................................................................................. 34
4.3.6 DEFINITION VON DISPLAYS ................................................................................................................................. 35
4.3.7 RELATION VISUALIZER ......................................................................................................................................... 37
4.4 CLIENT ANWENDUNG ............................................................................................................................... 37
4.4.1 PRESENCEMANAGER ............................................................................................................................................ 38
4.4.2 PRESENCECONTROL ............................................................................................................................................. 39
4.4.3 PRESENCERELATION ............................................................................................................................................ 39
5 PROXEMIC ZUI PROTOTYP .................................................................................................................. 41
5.1 ÜBERSICHT ................................................................................................................................................ 41
5.2 COMMON.................................................................................................................................................... 46
5.3 SHARED VIEW ........................................................................................................................................... 49
5.3.1 KONFIGURATION ................................................................................................................................................... 50
5.3.2 KOMMUNIKATION ................................................................................................................................................. 51
5.3.3 VIEWPORTMANAGER ........................................................................................................................................... 52
5.4 REMOTE VIEW .......................................................................................................................................... 53
5.4.1 KOMMUNIKATION ................................................................................................................................................. 53
5.4.2 HEAD-UP-DISPLAY ............................................................................................................................................... 54
5.5 KALMAN FILTER ....................................................................................................................................... 56
6 ZUSAMMENFASSUNG UND AUSBLICK .............................................................................................. 58
7 LITERATURVERZEICHNIS .................................................................................................................... 59
1 Einleitung
Im Projekt Blended Library werden neue Interaktionskonzepte für die Bibliothek der
Zukunft entwickelt1. In der Vision ist ein Living Lab beschrieben, welches die Besucher
der Bibliothek bei verschiedenen Aufgaben unterstützt. Zu den Aufgaben zählen z.B. die
Suche und Recherche im Datenbestand der Bibliothek oder das Verfassen einer schriftlichen Arbeit.
Das Living Lab der Blended Library ist wie in Mark Weisers Vision von Ubiquitous Computing (Ubicomp) [Weiser 1999] mit mehreren Displays in unterschiedlicher Größe,
Auflösung und mit verschiedenen Eingabemodalitäten ausgestattet. Ein 3m x 1,2m großes Whiteboard mit einer Aufprojektion von 2084 x 768 Pixeln bietet den Benutzern
genügend Platz zur Präsentation, Diskussion und Bearbeitung von Informationen. Konvergent zur Interaktion an einem konventionellen Whiteboard wird ein Stift als Eingabegerät genutzt, mit welchem digitale Inhalte erstellt und manipuliert werden. Im restlichen Teil des Living Labs befinden sich weitere vertikale und horizontale Displays wie
z.B. ein Full HD Wanddisplay und zwei Tabletops. An diesen Geräten interagieren die
Benutzer über Stifte, (Multi-)Touch, Maus, Tastatur und eine Kombination aus den genannten Eingabemodalitäten. Wie in Mark Weisers Vision werden im Living Lab auch
kleinere und mobile Geräte eingesetzt, wie z.B. iPads oder Surface Tablets.
In der Bibliothek der Universität Konstanz bieten Bereiche in der Größe des Living Labs
nicht nur Raum für die individuelle Arbeit einzelner Studenten oder Mitarbeiter. Ein
großer Teil wird intensiv für G
ruppenarbeit genutzt, bestehend aus zwei bis sieben
Personen2. Aus diesem Grund reicht es nicht aus, ausschließlich Anwendungen und
Interaktionstechniken für einzelne Benutzer zu entwickeln. Zur Unterstützung von
Gruppenarbeit müssen auch Konzepte und User Interfaces (UIs) für eine kollaborative
Zusammenarbeit berücksichtig werden.
Dabei ist das kollaborative Arbeiten nicht auf ein Display beschränkt. Aktuelle Forschungsprojekte der Blended Library zeigen im Living Lab Forschungsprototypen und
Konzepte, welche mehrere Displays miteinander kombinieren (z. B. [Rädle, H. Jetter, et
al. 2012] und [Rädle, Weiler, et al. 2012]).
Für eine nahtlose Interaktion über mehrere Displays hinweg werden neue User Interfaces benötigt, welche die Anforderungen eines Multi-Display Environments (MDEs)
erfüllen. Abgeleitet aus der Taxonomie des „CDOM Frameworks“ von Miguel Nacenta et
al. [Nacenta et al. 2009] sind das z.B. die Unterstützung von verschiedenen Displayauflösungen und Eingabemodalitäten, einer hohen Awareness über den Zustand des Systems
und realitätsbasierter Interaktion [Jacob et al. 2008].
Zoomable User Interfaces (ZUIs) erfüllen bereits eine der genannten Anforderungen. Sie
sind unabhängig von Displaygrößen und passen sich dynamisch an die zur Verfügung
stehende Auflösung an. Zudem bieten sie durch bekannte Navigationskonzepte wie
Zooming und Panning jederzeit Zugang zu einem großen Informationsraum, wenn auch
dieser nicht immer vollständig sichtbar ist [H.-C. Jetter et al. 2012].
1
2
Projekt-Website: http://hci.uni-konstanz.de/blendedlibrary (Abgerufen am 24.02.2013)
Ergebnisse des Onlinefragebogens vom 24.03.2012 des Projekts Blended Library, Universität Konstanz
1
Das ZOIL Framework3 von Hans-Christian Jetter [H. Jetter 2012] geht einen Schritt weiter und unterstützt verschiedene Eingabemodalitäten wie z.B. Maus und Tastatur, (Multi-)Touch und Stifteingabe. Des Weiteren ermöglicht das Framework die Synchronisation eines Datenraums über mehrere Geräte hinweg. In Anlehnung an die Metapher einer
Kamera, erhält jedes Gerät bzw. Display eine eigene manipulierbare Sicht (Viewport) auf
die Informationslandschaft (siehe Abbildung 1).
Abbildung 1 – Beispielhafte Skizzierung der Kamera Metapher des ZOIL Frameworks. Die drei Bereiche 1,2
und 3 auf der Weltkarte werden auf je einem der drei Displays angezeigt [H. Jetter 2012].
Basierend auf dieser Metapher und dem ZOIL Framework wurde in diesem Projekt ein
Prototyp entwickelt, welcher mehreren Benutzern eine kollaborative Zusammenarbeit
in einem ZUI ermöglicht. Der Fokus des Projekts liegt dabei auf einer Multi-User Navigation durch Zooming und Panning in einer Informationslandschaft.
Hierzu wurden neue Navigationskonzepte unter Berücksichtigung der Reality-Based
Interaction entwickelt und in einer Studie mit der konventionellen Eingabe Multi-Touch
verglichen. Zur Umsetzung von realitätsbasierten Navigationstechniken wird das Proximity Toolkit [Marquardt et al. 2011] und eine Auswahl der verfügbaren Proxemic
Dimensions (Orientation, Distance, Motion, Identity, Location) [Ballendat et al. 2010]
eingesetzt.
Mit Hilfe des Proxemic ZUI Prototypen sollen schließlich folgende Forschungsfragen
beantwortet werden:
1. Unterstützt eine Navigationstechnik basierend auf den Proxemic Interactions im
Vergleich zu einer multi-touch Eingabe das räumliche Gedächtnis in ZUIs besser?
2. Ist die Leistung (zurückgelegter Weg und Zeit) der Navigationstechnik basierend
auf den Proxemic Interactions im Vergleich zur multi-touch Eingabemethode in
ZUIs besser?
Projekt-Website auf der Open Source Plattform CodePlex: http://zoil.codeplex.com/ (Abgerufen am
24.02.2013)
3
2
Der Fokus des Projekts und der damit zusammenhängenden Masterarbeit liegt auf der
Beantwortung der beiden Forschungsfragen. Die Studie (Gedächtnis-Studie) zu Beantwortung dieser Fragen basiert auf einer vorhergehenden Studie von Hans-Christian
Jetter et al. [H.-C. Jetter et al. 2012] zum Thema räumliches Gedächtnis und NavigationsLeistung in ZUIs. In dieser Studie wurden ebenfalls zwei Eingabemodalitäten (Maus vs.
Multi-Touch) gegenübergestellt und die Gedächtnisleistung sowie Navigationsleistung
gemessen. Die Resultate der Zooming+Panning Navigation zeigen in dieser Studie keine
signifikanten Unterschiede in der Gedächtnisleistung. Stattdessen waren die Navigationskosten mit der Maus 28% geringer als bei der Eingabe über Multi-Touch. Mit diesem
Projekt wird schließlich untersucht, ob eine räumliche Bewegung zur Navigation in
einem ZUI die Gedächtnisleistung im Vergleich zu Multi-Touch verbessert. Eine detaillierte Beschreibung der Gedächtnis-Studie ist nicht Bestandteil des Projektberichts.
3
2 Übersicht
Die Entwicklung des Prototyps zur Beantwortung der Forschungsfragen (siehe Kapitel
1) ist in drei Unterprojekte aufgeteilt.
Zu Anfang musste ein Versuchsaufbau eingerichtet werden, um Bewegungen von Benutzern beobachten und interpretieren zu können. Das Labor Media Room bietet hierfür
gute Voraussetzungen, da es genügend Platz zur Verfügung stellt und eine freie Bewegung im Raum ermöglicht. Zudem befinden sich mehrere große und hochauflösende
Displays im Media Room, von welchen die beiden Cubes (siehe Abbildung 2) für dieses
Projekt eingesetzt werden. Zusammen besitzen die Cubes eine Auflösung von
3480x1080 Pixeln mit einer steglosen Displayfläche von ca. 120 Zoll. Der Interaktionsbereich vor den Cubes umfasst ca. 7,5 Quadratmeter. Für das Tracking in diesem Bereich
werden Produkte der Firma NaturalPoint4 eingesetzt. Hierzu zählen OptiTrack Kameras,
welche innerhalb des Traversensystems des Media Rooms (siehe Abbildung 1) montiert
sind und die Software Tracking Tools, welche die Videostreams der Kameras verarbeitet. Eine detaillierte Beschreibung des Aufbaus und der Konfiguration des Systems wird
in Kapitel 3 aufgeführt. Zudem dient dieses Kapitel als Anleitung und Erfahrungsbericht
zum Umgang mit dem Tracking-System.
Abbildung 2 – Cube-Displays und Traversensystem im Labor Media Room
In Kapitel 4 wird anschließend die Verarbeitung der Tracking-Daten unter Verwendung
des Proximity Toolkits beschrieben. Das Proximity Toolkit stellt Informationen zu Relationen im Raum zwischen Benutzer-und-Benutzer, Benutzer-und-Objekt sowie zwischen
Objekt-und-Objekt bereit. Zu den Objekten zählen in diesem Projekt die Cube-Displays
und Tablet-PCs. Des Weiteren wird in Kapitel 4 die Kommunikation zwischen den Tracking Tools und dem Proximity Server beschrieben. Dies beinhaltet die Entwicklung
eines Input Moduls und die Konfiguration des Proximity Servers. Das Input Modul wird
für die Verbindung zwischen Tracking Tools und Proximity Server benötigt und ist für
die Aufbereitung der Tracking-Daten zuständig. Der Proximity Server selbst stellt Informationen zu ausgewählten Benutzern und Objekten über das Netzwerk bereit und
dient zur Kalibrierung des Bereichs vor und inklusive der Cubes.
Die gesammelten und aufbereiteten Tracking-Daten werden schließlich zur Entwicklung
von neuen Interaktionstechniken zur Navigation in ZUIs verwendet. Zur Untersuchung
der Navigationstechniken muss der Prototyp in der ersten Version keine Multi-User
4
Website der Firma NaturalPoint: www.naturalpoint.com/ (Abgerufen am 24.02.2013)
4
Navigation unterstützten. Es werden jedoch bereits Mechanismen und Funktionen bereitgestellt, welche zukünftig eine Multi-User Navigation ermöglichen. Die Entwicklung
des ZUI Prototyps sowie eine Beschreibung der Interaktionstechniken sind in Kapitel 5
aufgeführt.
5
3 OptiTrack Tracking Tools
In diesem Kapitel wird der Aufbau des Tracking-Systems und die Software Tracking
Tools näher beschrieben. Eine Installationsanleitung der Software ist nicht Bestandteil
des Projektberichts. Hierzu empfiehlt sich der „Tracking Tools 2.4.0 User Guide“5, welcher auf der Herstellerseite zur Verfügung steht.
3.1 Allgemeine Informationen
Zur Erkennung und zur Beobachtung von Personen wird die Software Tracking Tools6
der Firma NaturalPoint eingesetzt, welche von der Herstellerseite heruntergeladen
werden muss. Die Beschreibungen und Hinweise in diesem Kapitel basieren auf der
Softwareversion 2.5.0.
Zur Aktivierung der Software wird ein Lizenzschlüssel benötigt, welche entweder auf
einer Kamera vorinstalliert ist oder auf einem USB-Dongle zur Verfügung steht. In diesem Projekt wird der USB-Dongle eingesetzt, da die zur Verfügung stehende LizenzKamera nicht in diesem Projekt verwendet wird. Die Kamera ist seitlich gekennzeichnet
und muss bei Verwendung des Schlüssels korrekt mit dem Rechner verkabelt sein.
Tipp: Bevor mit der Software Tracking Tools gearbeitet wird ist zu beachten, dass keine
zur Laufzeit geänderten Einstellungen wie z. B. die Kalibrierung der Kameras oder die
Definition von Trackables automatisch gespeichert werden. Aus eigener Erfahrung ist zu
empfehlen alle Änderung immer sofort zu speichern! Auch beim Schließen des Programms wird der Benutzer nicht auf etwaige Änderungen hingewiesen und die Software
sofort beendet.
In diesem Projekt werden 18 Kameras des Typs OptiTrack V100:R2 (siehe Abbildung 4)
eingesetzt. Sie erkennen laut Hersteller Marker mit einer Größe von 3/4 Zoll (19.05 mm,
siehe Abbildung 3a) in bis zu 11 Metern Entfernung. Für das Tracking von Benutzern
werden in diesem Projekt Marker in der Größe von 5/8 Zoll (15,875 mm, siehe Abbildung 3b) eingesetzt, da der abzudeckende Bereich eine maximale Distanz von ca. fünf
Metern nicht übersteigt. Weitere Details zur OptiTrack V100:R2 sind neben Abbildung 1
aufgelistet.
V100: R2
Auflösung: 640 x 480
Framerate: max. 100 FPS
Latenz: 10 ms
24 Kameras pro System
Abbildung 3 – Zwei verschieden große
Marker. (A) zeigt einen 3/4 Zoll Marker
und (B) einen 5/8 Zoll Marker.
Abbildung 4 – OptiTrack V100:R2 Kamera
Link zum Dokument Tracking Tools 2.4.0 User Guide:
http://www.naturalpoint.com/optitrack/static/documents/Tracking Tools 2.4.0 User Guide.pdf (Abgerufen am 24.02.2013)
6 Tracking Tools Software-Download-Website:
http://www.naturalpoint.com/optitrack/downloads/tracking-tools.html (Abgerufen am 24.02.2013)
5
6
Für die Kameras werden zwei verschiedene Linsen eingesetzt. Die erste Linse besitzt ein
horizontales Sichtfeld von 46° (4.5 Objektiv) und bietet laut Hersteller eine „[...] ideale
Balance zwischen Sichtfeld und Tracking-Auflösung [...]“7. Sie wird in diesem Projekt bei
10 Kameras eingesetzt. Die andere Linse hat ein Sichtfeld von 58° (3.5 Objektiv) und ist
vor allem für kleine Räume gut geeignet. Sie wird bei den restlichen 8 Kameras benutzt.
Die Kombination beider Linsen und eine genaue Ausrichten der Kameras bietet eine
Tracking-Genauigkeit im Bereich von ca. 1 bis 2 mm8. Dies ermöglicht eine millimetergenaue Bestimmung von Position und Orientierung und erfüllt die Anforderung einer
pixelgenauen Navigation des Projekts.
Zur Verbindung der Kameras mit einem Rechner werden neben Standard USB-Kabeln
auch USB-Verlängerungskabel und drei OptiHubs in der Version 2 (siehe Abbildung 5)
eingesetzt. Ein OptiHub hat im Vergleich zu einem Standard USB-Hub folgende Vorteile:



Einfache Verkabelung der V100: R2 Kameras
Konstante Stromspannung für ein stabiles Tracking.
Einen High Power Mode, welcher das Tracking von kleineren Markern verbessert
und den Einsatz von Linsen mit großer Verzerrung unterstützt.
Abbildung 5 – OptiTrack OptiHub 2
Abbildung 6 – Bauteile zur Befestigung der Kameras. (A) Manfrotto Neigekopf 234, (B) Global Truss Aufnehmer klein CODE 812, (C) UNC 3/8 Zoll und metrische Schraube.
Für die Aufhängung der Kameras innerhalb des Traversensystems werden drei Komponenten benötigt (siehe Abbildung 6). Die Kamera wird auf einem Neigekopf für Einbeinstative des Typs 234 der Firma Manfrotto montiert. Dieser ermöglicht eine frontale
Neigung im Bereich von 180° und eine horizontale Drehung der Kamera um 360°. Der
Hersteller-Website für die Kameralinsen http://www.naturalpoint.com/optitrack/products/m12lenses/ (Abgerufen am 24.02.2013)
8 Durchschnittliche Abweichung nach letzter erfolgreicher Kalibrierung am 12.02.2013.
7
7
Neigekopf ist wiederum auf einem Global Truss Aufnehmer klein (CODE 812) befestigt,
welcher an den Verstrebungen des Traversensystems angebracht wird. Die mitgelieferte
Geräteschraube M10 (metrisches Gewinde) ist nicht mit dem „Zoll“-Gewinde des Neigekopfs kompatibel. Sie muss durch eine Sechskantschraube mit einem amerikanischen
Gewinde (UNC9) von 3/8 Zoll Durchmesser und einer Länge von 3/4 Zoll ersetzt werden.
3.2 Aufbau der Kameras
Vor der Kalibrierung müssen die Kameras entsprechend der Anforderungen installiert
werden. Hierzu gehört eine genaue Positionierung, Ausrichtung und Verkabelung zur
Abdeckung des definierten Bereichs.
In diesem Projekt kommen, wie in Kapitel 3.1 beschrieben, 18 Kameras zum Einsatz. Sie
sind auf Deckenhöhe montiert, um den gesamten Bereich vor den Cubes zu erfassen
(siehe Abbildung 7). Vier der acht Weitwinkelkameras (3.5 Objektiv) in den Ecken, zwei
frontal über den Cubes und zwei zentriert rechts und links im Raum. Die Kameras mit
dem kleineren Öffnungswinkel (4.5 Objektiv) sind direkt über und gegenüber der beiden
Cubes installiert, sowie zwei in Richtung Mitte des Bereichs. Auf Augenhöhe des Benutzers werden keine Kameras installiert, da die Marker nicht von umherlaufenden Personen verdeckt werden sollen. Zur Verbesserung des Trackings mehrerer Personen empfiehlt es sich zusätzlich Kameras auf Deckenhöhe innerhalb des Bereichs zu positionieren. Sie decken die noch fehlende Sicht aus der Vogelperspektive ab, ähnlich wie bei
einer Landkarte.
Aus Erfahrungswerten empfiehlt sich eine Positionierung und Ausrichtung in zwei
Schritten. Im ersten Schritt werden die Kameras grob im Raum verteilt. Anschließend
folgt eine korrekte Verkabelung, um mit Hilfe der Livebilder aus den Tracking Tools eine
präzise Ausrichtung durchzuführen.
Abbildung 7 – Position und Ausrichtung der Kameras im Media Room sowie die Tracking-Abdeckung des
Raums. Die 10 roten Kameras sind mit einem 4.5er Objektiv ausgestattet und die anderen 8 Kameras mit
einem 3.5er Objektiv.
Unified Thread Standard (UNC): http://de.wikipedia.org/wiki/Unified_Thread_Standard (Abgerufen am
24.02.2013)
9
8
Dabei ist zu beachten, dass die Position in der Höhe zwischen benachbarten Kameras
variiert werden sollte. Dies sorgt für ausreichend unterschiedliche Blickwinkel und die
notwendigen Überschneidungen für eine optimale Triangulation10.
Tipp: Zur einfachen Überprüfung und Ausrichtung des Blickfelds einer Kamera kann ihr
„Video Type“ in den Tracking Tools von „Precision Mode“ auf einen der drei „Grayscale
Modes“ geändert werden (siehe Abbildung 1). Im „Grayscale Mode“ wird das reale RAWImage der Kamera angezeigt. Zudem ist dieser Modus hilfreich um kleinere Störquellen,
wie z.B. Infrarot LEDs oder stark reflektierende Objekte besser zu identifizieren.
Abbildung 8 – Ausschnitt aus dem Fenster „Camera Preview“. Kamera 1 zeigt ein Videobild im „Grayscale
Mode“ und Kamera 2 ein Video im „Precision Mode“.
Die Verkabelung der Kameras ist von den eingesetzten Modellen abhängig. Beide Kameramodelle, OptiTrack V100 und V100:R2, besitzen einen USB- und eine KlinkenSchnittstelle. Beim Einsatz des Kameramodells OptiTrack V100 müssen beide Schnittstellen zur Synchronisation verwendet werden. Dies gilt auch für das neue Modell, sofern ein gemischtes System mit beiden Modellen aufgebaut wird. Über die USBSchnittstelle werden alle Kameras mit aktiven USB-Hubs verbunden, welche ein eigenes
Netzteil besitzen, da die Standardstromspannung über USB zu gering ist. Das USBVerbindungskabel zwischen Kamera und USB-Hub darf laut Hersteller eine Länge von 5
Metern nicht überschreiten und es dürfen auch keine USB-Verlängerungskabel eingesetzt werden. Jeder USB-Hub wird schließlich auf direktem Weg mit dem TrackingRechner verbunden. NaturalPoint empfiehlt voneinander unabhängige USB-Steckplätze
bzw. USB-Controller je Hub zu verwenden, um eine effiziente Leistung der Kameras zu
erhalten. Im Gegensatz zur Verbindung zwischen Kamera und USB-Hub darf die Verbindung zwischen Hub und Computer bis zu 15 Meter lang sein und bis zu zwei USBVerlängerungskabel beinhalten.
Zur Synchronisation der alten Kameras und in einem gemischten System werden spezielle Splitter- und RCA-Kabel (Cinch-Kabel) verwendet. Jede Kamera erhält ein SplitterKabel, welches einen Eingang und Ausgang besitzt. Bei der Vernetzung der Kameras
über die RCA-Kabel muss darauf geachtet werden, dass kein geschlossener Kreislauf
entsteht. Dies bedeutet, dass bei der ersten Kamera nur das Ausgangs-Kabel des Splitters und bei der letzten nur das Eingangs-Kabel zum Einsatz kommen. Schließlich werden alle Kameras in Reihe über die jeweiligen Ein- und Ausgänge mit Hilfe von RCAKabeln verbunden. Zur Veranschaulichung empfiehlt sich das Dokument „OptiHub Setup
„Triangulation ist eine geometrische Methode der optischen Abstandsmessung durch genaue Winkelmessung innerhalb von Dreiecken. Die Berechnung erfolgt mittels trigonometrischer Funktionen“:
https://de.wikipedia.org/wiki/Triangulation_(Messtechnik) (Abgerufen am 24.02.2013)
10
9
with Mixed 18 V100 R1/R2 Cameras“ innerhalb des PDFs „OptiHub Quick Start Guide“11
der Firma NaturalPoint.
In diesem Projekt werden ausschließlich OptiTrack V100:R2 Kameras eingesetzt, welche
zusammen mit den OptiHubs eine übersichtliche Verkabelung ermöglichen. Im Gegensatz zur vorhergehenden Beschreibung werden die Splitter- und RCA-Kabel zwischen
den Kameras nicht mehr benötigt. Stattdessen findet eine Synchronisation über die
OptiHubs statt, welche über je ein RCA-Kabel in Reihe miteinander verbunden sind. Eine
Übersicht dieser Verkabelung wird ebenfalls im PDF „OptiHub Quick Start Guide“ unter
„OptiHub Setup with 18 V100:R2 or Flex 13 Cameras“ skizziert.
Nach einer vollständigen Verkabelung wird die Software Tracking Tools gestartet. Wenn
alle Kameras eine eindeutige ID besitzen wurde alles korrekt installiert und es kann mit
der Software-Kalibrierung fortgefahren werden.
Tipp: Tracking Tools erst öffnen wenn alle USB- oder OptiHubs verbunden sind, mit
Strom versorgt werden und eine Verbindung zu den Kameras besteht. Ansonsten kann
es vorkommen, dass die Kameras trotz korrekter Verkabelung nicht richtig oder unvollständig erkannt werden. Eine Änderung der Verkabelung zur Laufzeit ist nicht zu empfehlen und erfordert in dem meisten Fällen einen Neustart der Software.
3.3 Kalibrierung der Kameras
Vor der Kalibrierung müssen einige Einstellungen überprüft und wenn notwendig angepasst werden.
Für den Aufbau mit OptiHubs und OptiTrack V100:R2 Kameras ist es möglich den Modus „High Power“ zu verwenden (siehe Abbildung 9). In diesem Modus wird die maximale Distanz zwischen Markern und Kamera erhöht und die Sichtbarkeit der Trackables
erhöht. Bei einem Aufbau mit beiden Kameramodellen ist dieser Modus nicht verfügbar.
Des Weiteren muss der Illumination Type auf „Continous IR“ eingestellt sein, um leicht
reflektierenden Objekte wie z.B. Kleidungsstücke oder die menschliche Haut auszuschließen.
Abbildung 9 – Einstellung der Kameras bei Verwendung von OptiHubs und OptiTrack V100:R2 Modellen.
Link zum Dokument OptiHub Qick Start Guid:
http://www.naturalpoint.com/optitrack/static/documents/OptiHub Quick Start Guide.pdf (Abgerufen
am 24.02.2013)
11
10
Im zweiten Schritt wird die Einstellungen der Kalibrierung über den Pane „3-Marker
Calibration“ geöffnet (siehe Abbildung 10).
Abbildung 10 – Einstellung der (A) Solver- und (B) Advanced Options der 3-Marker Calibration.
Tipp: In der Vergangenheit hat sich ein zweistufiges Kalibrierungsverfahren bewährt.
Hierbei wird zuerst ein schnelles Verfahren mit geringer Qualität (Medium) gewählt, um
nach kurzer Zeit abschätzen zu können, ob die Kalibrierung ein erfolgreiches Ergebnis
liefern wird. Ist dies der Fall, wird die Qualität im zweiten Schritt auf „High“ erhöht um
ein präziseres Ergebnis zu erhalten. Dies ist vor allem hilfreich und spart Zeit, wenn bei
der Ausrichtung der Kameras ein Fehler gemacht wurde und dieser erst wieder korrigiert werden muss.
Solver Options
Als Erstes wird die Qualität bei den „Solver Options“ auf „Medium“ oder „High“ gestellt
(siehe Abbildung 10). Für den OptiWand (siehe Abbildung 11) muss der Wert auf
400mm (Medium) eingestellt sein. Die restlichen Standardwerte der Solver Options
bleiben unverändert.
Abbildung 11 – OptiWand-Stabkonstruktion zur Kalibrierung der Kameras.
Data Acquisition und Display Options
Die Standardeinstellungen der „Data Acquisition“ und „Display Options“ müssen nicht
geändert werden.
11
Advanced Options
Der „LensType“ in den „Advanced Options“ muss auf „Auto Select“ eingestellt sein (siehe
Abbildung 10), da in unserem Projekt zwei unterschiedliche Kameralinsen zum Einsatz
kommen (siehe Kapitel 3.1). Die Software ermittelt bei dieser Kalibrierung die Linsen
der einzelnen Kamera automatisch. Die Resultate weichen in den meisten Fällen etwas
von den eigentlichen Werten der Linsen ab, mindern die Tracking-Qualität aber nicht. Ist
die Abweichung größer als 0,4 kann die Option „3rd Order Intrinsics“ auf „True“ gestellt
werden. Sie verbessert die Berechnung der Linsenkrümmung während der Kalkulation
der Kalibrierungsdaten, benötigt aber auch wesentlich mehr Rechenleistung und Zeit.
3.3.1 Ablauf der Kalibrierung.
Bevor mit der Kalibrierung begonnen wird müssen alle Marker und reflektierende Objekte aus dem Sichtfeld der Kameras entfernt werden. Dies gilt auch für den OptiWand.
Zur Überprüfung empfiehlt sich die Ansicht „Camera Preview“ (siehe Abbildung 12) in
den Tracking Tools. Sie zeigt durch rote Markierungen innerhalb der Kamerabilder wo
noch Marker oder Störquellen erkannt werden.
Abbildung 12 – Ausschnitt der Ansicht Camera Preview der Tracking Tools. Roter Kreis markiert das Symbol
zum Öffnen der Camera Preview.
Tipp: Kleine konstante Störquellen, welche nicht aus dem Raum entfernt werden können, lassen sich für den Zeitraum der Kalibrierung durch den Button „Block Visible“
ignorieren. Zur Erstellung einer perfekten Kalibrierung sollte diese Funktion wenn
möglich nicht genutzt werden.
Nach dem alle Vorkehrungen getroffen sind wird die Kalibrierung durch einen Klick auf
den Button „Start Wanding“ gestartet (siehe Abbildung 10). Die Ansicht „Calibration
Engine“ wird geändert und zeigt ab jetzt den aktuellen Stand der gesammelten Kalibrierungsdaten an. Zur Sammlung von Daten muss das OptiWand vor den Kameras mehrfach hin und her bewegt werden. Hierfür empfiehlt sich die in Abbildung 13 dargestellte
Bewegung, welche vor jeder Kamera durchgeführt werden muss.
12
Abbildung 13 – Bewegung des OptiWands vor einer Kamera zur Kalibrierung des Tracking-Systems.
Ziel ist es eine hohe Qualität (Very High) in der Live-Ansicht der „Calibration Engine“ zu
erreichen (siehe
Abbildung 14).
(A)
(B)
Abbildung 14 – Resultate während der Kalibrierung der Kameras. (A) zeigt Werte vor der Kalkulation und (B)
während der Kalkulation.
Jede Kamera muss ein Minimum an „Samplen“ besitzen. Die Anzahl an „Samplen“ steht
in Abhängigkeit zur Anzahl der eingesetzten Kameras und kann laut Hersteller mit folgender Formel berechnet werden:
x = Zahl zwischen 200 und 225
n = Anzahl der Kameras
13
Samples = x * n
Für unseren Aufbau mit 18 Kameras werden nach dieser Formel zwischen 3600 und
3960 Samples benötigt. Zuletzt ist es wichtig eine hohe Streuung der gesammelten Werte zu erhalten. Diese liegt auf einer Skala von 0.0 bis 1.0, wobei 1.0 für eine optimale
Streuung steht. Für ein erfolgreiches Ergebnis müssen alle Kameras eine Streuung von
0.6 oder höher erreichen.
Nach dem die zuvor beschrieben Zielwerte erreicht sind wird mit der Kalkulation fortgefahren. Hierzu auf den Button „Calculate“ klicken (siehe
Abbildung 14a). Die Ansicht der „Calibration Engine“ ändert sich und zeigt fortlaufend die aktuellen Resultate
der Kalkulation an (siehe
Abbildung 14b). Für ein erfolgreiches Ergebnis müssen nach maximal 15 Minuten „MeanError“-Werte mit einem Höchstwert von 0.15 bis 0.20 erreicht sein. Ist dies nicht der
Fall, empfiehlt sich eine Wiederholung der Kalibrierung. Sind nach bis zu 15 Minuten die
genannten Höchstwerte erreicht, wird die Kalkulation bis zu zwei Stunden fortgesetzt,
um ein sehr präzises Gesamtresultat zu erhalten.
Zum Beenden der Kalkulation auf „Apply Result“ klicken und anschließend im neuen
Fenster „Apply“. Danach folgt eine Aufforderung die „Tracking Tools Timeline“ zu speichern, welche allerdings im normalen Betrieb nicht weiter benötigt wird.
Tipp: Bei einem zweistufigen Kalibrierungsverfahren werden nach 15 Minuten und
erfolgreichen Werten die Resultate bestätigt und im Fenster „Calibration Result Report“
mit „Apply and Refine“ fortgefahren. Dies führt zu qualitativ besseren Resultaten bei der
Berechnung der Kalibrierung. Wie zuvor beschrieben wird die Kalkulation für mindestens zwei Stunden fortgesetzt und anschließend bestätigt.
Ground Plane
Im letzten Schritt muss das „Ground Plane“ (siehe Abbildung 15) positioniert und gespeichert werden. Während des gesamten Vorgangs dürfen keine zusätzlichen Marker
und reflektierenden Objekte im Sichtfeld der Kameras stehen.
Als Erstes im Tab „3-Marker Calibration“ auf den Eintrag „Ground Plane“ wechseln und
das reale „Ground Plane“ im Raum platzieren. Es bestimmt den Nullpunkt sowie die
Lage der x-, y- und z-Achse. Wenn die Einstellung „Right Handed System“ in den „Application Settings“ auf „True“ eingestellt ist, handelt es sich wie in unserem Projekt um ein
rechtshändiges Koordinatensystem. Dies bedeutet, dass der Pfeil auf dem „Ground Plane“, ausgehend von z, in die negative Richtung der z-Achse zeigt und die andere Achse
des „Ground Planes“ in die positive Richtung der x-Achse (siehe
Abbildung 16). Die y-Achse verläuft ausgehend vom Nullpunkt senkrecht nach oben und ist
ebenfalls positiv. Nach der korrekten Positionierung des „Ground Planes“ auf „Set
Ground Plane“ klicken und abschließend das nun fertige Resultat der Kalibrierung speichern. Es empfiehlt sich zusätzlich das gesamte Projekt zu speichern. Hierzu im Menü
File auf „Save Project“ klicken.
In diesem Projekt wird das Ground Plane links unterhalb der Cubes positioniert (siehe
Abbildung 16).
14
Abbildung 15 – OptiTrack Ground Plane
Abbildung 16 – Positionierung des Ground Planes
3.4 Definition von Trackables (Rigid Bodies)
Nach einer erfolgreichen Kalibrierung (siehe Kapitel 3.3) ist es möglich Trackables zu
definieren. Trackables sind Objekte, bestehend aus mehreren Markern, deren Position
und Rotation im Raum bestimmt und über die Zeit nachverfolgt werden kann.
Zur Erstellung eines Trackables muss ein Objekt mit Markern ausgestattet sein. Hierzu
stehen unterschiedliche Größen und Ausführungen von Markern zur Verfügung. Zum
einen gibt es Kugel-Marker (siehe Abbildung 17a), welche über ein Gewinde mit Gewindestäben oder „Marker Bases“ (runde Klettverschluss-Flächen) auf Objekten befestigt
werden (siehe Abbildung 17b) und zum anderen es gibt Marker in Form von Klebepunkten und Klebestreifen sowie aktive LED Marker (siehe Abbildung 17a). In diesem Projekt
haben wir uns für die Kugel-Marker entschieden, da sie in alle Richtungen reflektieren
und so eine höhere Sichtbarkeit garantieren. Von den Kugeln gibt es zwei unterschiedliche Größen, 5/8 Zoll und 3/4 Zoll Marker. Grundlegend gilt: Je größer die reflektierende
Fläche eines Markers desto höher ist seine Sichtbarkeit. Da in unserem Projekt die maximale Distanz von fünf Metern zwischen Markern und Kameras nicht überschritten
wird, erfüllt die 5/8 große Kugel unsere Anforderungen (siehe hierzu auch Kapitel 3.1).
Abbildung 17 – (A) zeigt verschiedene Arten von Markern: (1) und (2) sind Klebe-Marker, (3) Kugel-Marker
und (4) aktive LED Marker. (B) zeigt Bauteile, um die Marker auf Objekten zu befestigen: (1) „Marker Base“,
(2) Gewindestäbe und (3) Verstrebungen zum Anbringen von Gewindestäben.
15
Im Folgenden wird die Erstellung eines Trackables anhand einer Basecap beschrieben,
welche in diesem Projekt für das Tracking eines Benutzers verwendet wird. Ebenso ist
in diesem Projekt ein Tablet-PC mit Markern ausgestattet, wobei sich die Vorgehensweise zur Erstellung des Trackables nicht von der einer Basecap unterscheidet und daher
nicht weiter erläutert wird.
Für das Tracking eines Benutzers eignet sich eine dunkelfarbige Basecap, welche keine
zufälligen und ungewollte Reflektionen auslösen kann und durch ihre Position auf dem
Kopf nur geringfügig von anderen Benutzern verdeckt wird. Zur Befestigung von Markern werden „Marker Bases“ (siehe Abbildung oben) in der Größe von 1.5 Zoll eingesetzt und die entsprechenden „ 5/8 Zoll“-Variante der Kugel-Marker. Über ihr Gewinde
werden die Marker mit den Bases verschraubt und können anschließend beliebig auf
der Basecap positioniert werden.
Je nach Anzahl der definierten und gleichzeitig sichtbaren Trackables in einem Projekt,
muss die Anzahl der Marker je Trackable erhöht werden. Ansonsten kann es zu Überschneidungen zwischen den Trackables kommen und schließlich falsch getrackten Objekten. Jedes Trackable muss erfahrungsgemäß mindestens 3 bis 4 Markern besitzen.
Neben der Anzahl ist eine genaue und überlegte Positionierung der Marker zu beachten.
Diese dürfen sich nicht gegenseitig verdecken und müssen daher in unterschiedlicher
Lage auf einem Objekt positioniert werden. Eine Positionierung der Marker in einer
Reihe auf gleicher Achse und in identischer Höhe ist z.B. nicht von Vorteil. Bei einer
planaren Fläche muss aus Erfahrung ein Mindestabstand von acht bis zehn Zentimetern
zwischen den Markern eingehalten werden.
Abbildung 18 – Erste Version der Basecaps. Die Marker befinden sich ausschließlich vorne auf dem Schirm
der Kappe.
16
Abbildung 19 – Zweite Version der Basecap. Die Marker werden hauptsächlich auf dem Kopfteil der Kappe
angebracht.
In einem ersten Versuch haben wir Marker vorne auf der Basecap montiert (siehe Abbildung 18). Dies hatte zwei maßgebliche Nachteile. Zum einen wurden die Marker oft
vom restlichen Teil der Basecap verdeckt und zum anderen änderte sich die Position
eines Benutzers bereits bei der Drehung des Kopfes, was in unserem Prototyp zu falschen Aktionen geführt hat. Daher haben wir uns entschieden die Marker hauptsächlich
auf dem Kopfteil der Basecap zu befestigen (siehe Abbildung 19), um die Wahrscheinlichkeit einer Verdeckung zur verringern. Ein Marker ist zentral auf der Mitte des Kopfteils positioniert und wird später als Pivot-Punkt definiert. Der Pivot-Punkt bestimmt
die Position eines Trackables und wird standardmäßig durch den geometrischer Mittelpunkt aller Marker bestimmt. Durch die Festlegung des Pivot-Punkts auf der Mitte des
Kopfes resultiert eine Kopfdrehung in einer sehr schwachen Bewegung der Person.
Abbildung 20 – Definition eines Trackables. Von links nach rechts: Zuerst die Marker mit einer Bounding Box
selektieren und anschließend im Pane Trackables auf „Create From Selection“ klicken.
Als nächstes wird die Basecap in den „Tracking Tools“ definiert. Hierzu das Objekt sichtbar im Zentrum der Kameras auf einem festen Untergrund positionieren und die sichtbaren Marker der Basecap mit Hilfe einer Bounding Box auswählen (siehe Abbildung
20). Die Software zeigt anschließend an, welche Kameras die selektierten Marker sehen.
17
Zum Abschluss auf „Create From Selection“ im Pane „Trackables“ klicken und das Trackable wird erstellt.
Tipp: Die Selektion von mehreren Markern eines Objekts zeigt wie erfolgreich die Kameras ausgerichtet und kalibriert sind. Je mehr Kameras mit dem selektierten Objekt
verbunden sind desto besser das Tracking. In jedem Fall muss ein Marker immer von
mindestens drei Kameras gleichzeitig gesehen werden.
Abbildung 21 – Screenshot der Software Tracking Tools. Links ist der Project Explorer rot umrandet und
rechts die Eigenschaften des ausgewählten Trackables.
Ist das „Trackable“ im „Project Explorer“ ausgewählt, werden seine Eigenschaften rechts
in den Tracking Tools angezeigt (siehe Abbildung 21). Für unser Projekt ändern wir den
Namen des Trackables in „User1“, welcher später auch im Proximity Toolkit verwendet
wird. Für die Berechnung der Rotation aktivieren wir den internen Kalman Filter über
die Einstellung „Smoothing Settings“. Er filtert kleine unruhige Kopfbewegungen raus,
die auch im „Stillstand“ von Personen ausgeführt werden. Hierzu wird ein Wert zwischen 0, kein Filter, und 1, maximale Filterung, gewählt. Für die Rotation wählen wir in
unserem Projekt den maximalen Wert von 1, welchen wir empirisch in mehreren explorativen Tests ermittelt haben. Die Translation in den „Smoothing Settings“ muss für
dieses Projekt nicht durch den Kalman Filter verändert werden. Die restlichen Einstellungen im Pane „Trackable“ können für den normalen Gebrauch ihre Standardwerte
behalten.
Tipp: Werden in zukünftigen Projekten mehrere Basecaps in einem Multi-User Prototyp
eingesetzt ist darauf zu achten, dass sich die Markerkonstelationen der einzelnen Basecaps unterscheiden. Bei mehreren ähnlichen Trackables empfiehlt es sich die Werte
„Min Marker Count“ und „Flexibility“ in den Einstellungen des Trackables zu erhöhen.
„Min Marker Count“ bestimmt die minimale Anzahl an gleichzeitig sichtbaren Markern,
welche für die Erkennung des Trackables notwendig sind. Die „Flexibility“ beschreibt
stattdessen die maximal mögliche Abweichung eines Markers von seiner eigentlichen
Position im Trackable.
18
Zum Abschluss wird die Orientierung der Basecap im Tab „Orientation“ angepasst (siehe
Abbildung 22). Hier ist es möglich den Pivot-Punkt des Objekts manuell zu verschieben
und auch die Rotation über Nummernfelder manuell zu verändern, so dass die eingestellten Werte bei jeder Bewegung mit verrechnet werden. Zusätzlich kann der PivotPunkt über das Kontextmenü eines Markers auf den ausgewählten Marker gelegt werden (siehe Abbildung 23). Bei unserer Basecap wird der Pivot-Punkt durch den zentralen Marker auf dem Kopfteil der Basecap bestimmt. Zur Einstellung der Rotation gibt es
neben den Nummernfeldern den Button „Reset To Current Orientation“. Dabei werden
die drei Werte der Rotation in der aktuellen Position des Objekts auf null gesetzt. In
unserem Projekt richten wir die Basecap frontal in Richtung der Cubes aus, so dass beim
direkten Blick auf die Displays alle drei Rotationswerte auf null stehen. Der Grund hierfür ist eine korrekte Ausrichtung der „Pointer“ des Proximity Toolkits, welche in Kapitel
4.2 genauer beschrieben sind.
Abbildung 22 – Ausschnitt aus dem Tab Orientation der Tracking Tools.
19
Abbildung 23 – Einstellung des Pivot-Punkts über das Kontextmenü eines Markers.
Die aktuellen Werte des selektierten Trackables zu Position und Rotation werden im
Tab „Real-Time Info“ angezeigt. In unregelmäßigen Abständen kann es vorkommen,
dass diese Anzeige nicht korrekt funktioniert und die Tracking Tools neu gestartet werden müssen. Nach der Erstellung eines „Trackable“ ist es wichtig das Projekt manuell zu
speichern.
3.5 Streaming Server
Nach der Kalibrierung der Kameras und der Definition der Trackables ist es möglich die
Tracking-Daten über einen Streaming Server zu senden. Hierzu muss das „Streaming
Pane“ geöffnet und anschließend der Streaming Server konfiguriert werden (siehe Abbildung 24). Zur Verwendung des Servers mit dem Proximity Toolkit werden bei den
„Streaming Options“ beide Einstellungen, „Stream Markers“ und „Stream Rigid Bodies“
auf „True“ gestellt. In diesem Projekt streamen wir die Daten ausschließlich zum Proximity Server und ändern in den „Network Options“ den „Type“ auf „Unicast“. Wenn der
Proximity Server auf dem gleichen Rechner wie die Software Tracking Tools läuft, muss
die Einstellung „Local Interface“ unter „Network Interface Selection“ auf „Local Loopback“ gestellt werden. In anderen Fällen wird hier die IP-Adresse des entfernten Rechners eingetragen. Zuletzt ist es wichtig den Server über das Häkchen „Broadcast Frame
Data“ zu starten. Die restlichen Einstellungen bleiben unverändert.
20
Abbildung 24 – Einstellungen für das Streaming der Trackingdaten.
3.6 NatNet SDK
Zur Kommunikation mit dem Streaming Server wird das NatNet SDK 2.212 verwendet. Es
bietet einen nativen Client für die Programmiersprachen C und C++, sowie einen „Managed“-Client für .NET C# (siehe Abbildung 25). Für unser Projekt verwenden wir den
„Managed“ Client bzw. die „Managed“ DLL, da das Proximity Toolkit ebenfalls unter .NET
entwickelt ist.
Abbildung 25 – Aufbau des NatNet SDK
Internetlink zum Download des NatNet SDKs 2.2:
http://media.naturalpoint.com/software/OptiTrack_files/NatNetSDK2.2.zip (Abgerufen am 24.02.2013)
12
21
Als Erstes muss die NatNetML.dll in das eigene Projekt eingebunden werden. Die DLL
befindet sich im Unterordner „lib“ des NatNet SDKs.
Zum Aufbau einer Verbindung wird eine Instanz der Klasse „NatNetClientML“ mit einem
„iConnectionType“ initialisiert. Dieser Wert ist entweder „0“ für „Multicast“ oder 1 für
„Unicast“ und muss der Einstellung „Type“ in den „Network Options“ des Streaming
Servers entsprechen (siehe Kapitel 3.5).
int connectionType = 1;
NatNetClientML natNetClient = new NatNetClientML(connectionType);
Für den Verbindungsaufbau wird anschließend die Methode „Initialize“ des Clients
aufgerufen. Als Übergabewerte erhält die Methode die IP Adresse des Rechners auf dem
der Client läuft sowie die IP Adresse und den Port des Servers. Der Port muss der Einstellung „Command Port“ des Streaming Servers entsprechen und ist standardmäßig auf
1510 eingestellt. Beim Aufrufen der Methode wird abschließend einen Rückgabewert
geliefert, welcher bei einer erfolgreichen Verbindung 0 ist.
string localIP = "192.168.178.5";
string serverIP = "192.168.178.2";
int serverPort = 1510;
int returnCode;
returnCode = natNetClient.Initialize(localIP, serverIP, _serverPort);
Es ist aus Erfahrung zu empfehlen die Verbindung durch einen zusätzlichen Test zu
überprüfen. Hierzu werden Informationen über die Servereigenschaften unter Verwendung der Methode „GetServerDescription“ des Clients angefordert. Ist auch hier der
Rückgabewert 0, ist eine erfolgreiche Verbindung mit dem Server aufgebaut.
ServerDescription serverDescription = new ServerDescription();
returnCode += natNetClient.GetServerDescription(serverDescription);
Nach einer erfolgreichen Verbindung gibt es zwei Möglichkeiten Daten zu empfangen.
Die erste Möglichkeit ist Event-basiert. Jeder über das Streaming gesendete Frame wird
über das Event empfangen und kann weiter verarbeitet werden.
natNetClient.OnFrameReady += NatNetClientOnFrameReady;
void NatNetClientOnFrameReady(FrameOfMocapData data, NatNetClientML client){…}
Für das Proximity Toolkit verwenden wir die zweite Variante. Diese besteht aus zwei
Methoden, welche in definierten Zeitintervallen aufgerufen werden.
Über die Methode „GetDataDescription“ werden Informationen wie Name der Trackables, Anzahl der Marker eines Trackables und die Reihenfolge, in welcher die Trackables
gesendet werden empfangen. Die eigentlichen Daten wie Position und Orientierung
werden über die zweite Methode „GetLastFrameOfData“ erhalten.
List<DataDescriptor> optiTrackData = new List<DataDescriptor>();
natNetClient.GetDataDescriptions(out optiTrackData);
22
FrameOfMocapData optiTrackData = _natNetClient.GetLastFrameOfData();
Tipp: Die empfangenen Daten über die Methode „GetLastFrameOfData“ müssen zur
weiteren Verarbeitung noch modifiziert werden. Koordinaten wie X, Y und Z der Marker
müssen mit dem Faktor 1000 multipliziert werden, um die tatsächlichen Werte in Millimeter zu erhalten. Die drei Werte zur Orientierung der Trackables sind nicht wie erwartet in Eulerwinkeln13 angegeben. Stattdessen handelt es sich um Quaternion (siehe Kapitel 4.2.3), welche zur Weiterverarbeitung im Proximity Toolkit in Winkel konvertiert
werden müssen. Die genaue Verarbeitung der Tracking-Daten wird in Kapitel 4.2 bei der
Beschreibung des OptiTrackInputModules erläutert.
„Die Eulerschen Winkel (oder Eulerwinkel) sind ein Satz dreier unabhängiger Variabler, mit denen die
Orientierung (Drehlage) eines festen Körpers im dreidimensionalen Raum beschrieben werden kann“:
https://de.wikipedia.org/wiki/Eulersche_Winkel (Abgerufen am 25.02.2013)
13
23
4 Proximity Toolkit
In diesem Kapitel werden die für dieses Projekt notwendigen Teile des Proximity Toolkits beschrieben. Hierzu zählt das Input Modul für die OptiTrack Kameras in Kapitel 4.2,
der Proximity Server in Kapitel 4.3 und das Projekt ProximityToolkit.WPF für ClientAnwendungen in Kapitel 4.4.
4.1 Einführung
Das Proximity Toolkit [Marquardt et al. 2011] unterstützt die Entwicklung von Prototypen im Bereich des Ubicomp und basiert auf der Theorie der Proxemic Interaction
[Ballendat et al. 2010]. Mit Hilfe des Toolkits können Beziehungen zwischen verschiedenen Entitäten im Raum beobachtet und interpretiert werden. Zu den Entitäten zählen
Personen sowie statische und mobile Objekte, wie z.B. Displays, Tablet-PCs, Stühle oder
Türen.
Die Beziehungen zwischen den Entitäten werden durch fünf Proxemic Dimensions beschrieben: Orientierung (Orientation), Distanz (Distance), Identität (Identity), Bewegung (Motion) und Ort (Location) (siehe Abbildung 26).
Abbildung 26 – Skizzierung der fünf Proxemic Dimensions [Greenberg et al. 2011]
Die Orientation beschreibt die Ausrichtung zwischen zwei Objekten wie z.B. zwischen
einem Benutzer und einem Display und zeigt z.B. ob ein Benutzer frontal zum Display
steht oder nicht. Die Distance hingegen ermöglicht eine Aussage über die Entfernung
zwischen zwei Objekten und zeigt z.B. ob ein Benutzer das Display berührt oder nur auf
das Display zeigt. Mit Hilfe der Identity lässt sich feststellen welche Objekte oder Personen gerade in Relation zu einander stehen und mit der Dimension Motion ob diese Objekte und Personen in Bewegung sind. Über die Bewegung kann z.B. die Geschwindigkeit
bestimmt werden, in welcher sich ein Benutzer auf ein Display zubewegt. Letztere Dimension Location beschreibt den Raum und dessen verschiedene Bereiche. Diese Bereiche werden über „ fixed-„ und „semi-fixed features“ definiert. „Fixed features“ sind Objekte, welche nicht bewegt werden können wie z.B. der Eingang eines Raums oder ein
Pfad, der durch den Raum führt, hingegen „Semi-fixed features“ Objekte beschreiben,
deren Positionen variabel sind wie z.B. die Position eines Stuhl oder eines Tisches.
Alle fünf Dimensionen werden direkt oder indirekt über eine High-Level API des Proximity Toolkits zur Verfügung gestellt, welche in Kapitel 4.4 näher beschrieben ist.
24
Zur Definition der Entitäten in einem Raum wird der Proximity Server verwendet. Er
bietet neben normalen Servereigenschaften eine eigene GUI zur Erstellung und Kalibrierung des Raums und der darin enthaltenen Entitäten. Eine genaue Beschreibung des
Servers ist in Kapitel 4.3 aufgeführt.
Das Proximity Toolkit besitzt standardmäßig ein Input Modul für Vicon Kameras und
eines für die Microsoft Kinect. Zur Umsetzung unseres Projekts musste ein neues Input
Modul geschrieben werden, um mit den OptiTrack Kameras arbeiten zu können. Das
Modul und dessen Entwicklung wird im folgenden Kapitel 4.2 näher beschrieben.
4.2 OptiTrackInputModule
Das OptiTrackInputModule erhält die Tracking-Daten über den Streaming Server der
Tracking Tools und wandelt die empfangenen RigidBodies (Trackables) in Presences
um. Diese werden anschließend an den Proximity Server zur Bestimmung der Proxemic
Dimensions weitergeleitet und allen Client Anwendungen zur Verfügung gestellt.
Als Vorlage zur Entwicklung des OptiTrackInputModule wurde das ViconInputModule
verwendet. Es ermöglicht einen guten Einstieg und zeigt, wie die Tracking-Daten für das
Proximity Toolkit empfangen und weiter verarbeitet werden. Ein großer Teil der Klassen wurde für das OptiTrackInputModule übernommen und umgeschrieben.
4.2.1 Klassen
Ähnlich dem ViconInputModule, ist das OptiTrackInputModule in folgende Klassen
unterteilt:
OptiTrackInputModule
Hierbei handelt es sich um die Hauptklasse, eine Art API, welche vom ProximityInputModule abgeleitet ist und für die Kommunikation mit dem Proximity Server benötigt
wird. Sie stellt die Methoden, Events und Objekte zur Verfügung, die der Proximity Server für das Streaming der Tracking-Daten benötigt.
OptiTrackConnection
Die OptiTrackConnection Klasse baut mit Hilfe des NatNet SDKs (siehe Kapitel 3.6) eine
Verbindung zu den Tracking Tools auf, empfängt die Tracking-Daten und leitet diese zur
Verarbeitung an den OptiTrackDataProcessor weiter.
OptiTrackDataProcessor
Der OptiTrackDataProcessor verarbeitet die empfangenen Tracking-Daten. Zur Weiterverarbeitung im Proximity Toolkit werden diese von ihm in eine Datenstruktur überführt und stetig aktualisiert.
Klassen zu Beschreibung der Datenmodelle
Jedes in den Tracking Tools erstellte Trackable wird, wenn eine VSK-Datei existiert, in
das Datenmodell des OptiTrackSubject geschrieben. Das OptiTrackSubject enthält wiederum folgende untergeordnete Datenstruktur:


OptiTrackSkeleton: Beschreibt das gesamte Skelet des Trackables.
OptiTrackSegment: Beschreibt ein Segment aus dem OptiTrackSkeleton.
o OptiTrackPointer: Beschreibt alle Pointer der vorhandenen Segmente.
25



OptiTrackMarker: Beschreibt alle Marker des OptiTrackSkeleton.
OptiTrackJoint: Beschreibt die Verbindungen zwischen den einzelnen Segmenten.
OptiTrackStick: Beschreibt die Verbindungen zwischen den einzelnen OptiTrackMarkern.
Eventklassen
Zur Verarbeitung von Verbindungsproblemen wird die Klasse ConnectionProblem verwendet. Wenn die Tracking Tools nicht gestartet sind, kommt die Klasse TrackingToolsProblem zum Einsatz. Letzteres wird die Klasse VskProblem verwendet, wenn der Pfad
zu den VSK-Dateien nicht gesetzt ist oder einen Fehler enthält.
UI Klassen
Das OptiTrackInputModule zeigt Fehlerinformationen der Eventklassen in eigenen
Dialogen an. Der ConnectionDialog wird für Fehler des Events ConnectionProblem verwendet, der TrackingToolsDialog für die TrackingTools-Events und der VskDialog für
VskProblem-Events. Zusätzlich existiert noch die OptiTrackPropertyPage für die Einstellung des Pfades der VSK-Dateien und ein VskEditor, in welchem die Einstellungen der
vorhandenen VSK-Dateien zur Laufzeit geändert werden können.
Alle übrigen Klassen sind ohne größere Anpassung aus dem ViconInputModule übernommen und werden in diesem Bericht nicht weiter erläutert.
4.2.2 Beschreibung der VSK-Datei
In den Tracking Tools definierte Trackables müssen zur Verarbeitung im OptiTrackInputModule eine VSK-Datei besitzen. In dieser Datei sind Informationen zu Markern,
Pointern und Segmenten in einem XML-Format gespeichert.
Im Gegensatz zum Vicon System lässt sich diese Datei nicht über die Tracking Tools
generieren. Aus diesem Grund muss die VSK-Datei für jedes Trackable manuell erstellt
werden.
Zu Anfang steht ein XML Header, welcher grundlegende Informationen zur XML-Datei
enthält.
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
Als nächstes folgt das root-Element KinematicModel. Es beinhaltet das Skeleton, welches
ein Segment und je nach Anforderung mehrere Pointer enthält sowie das MarkerSet mit
allen Markern und Sticks des Trackables.
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<KinematicModel>
<Skeleton>
<Segment>
<JointFree/>
</Segment>
<Pointers>
<Pointer/>
</Pointers>
</Skeleton>
<MarkerSet>
<Markers>
<Marker/>
26
</Markers>
<Sticks>
<Stick/>
</Sticks>
</MarkerSet>
</KinematicModel>
Segment
Das XML-Element Segment beschreibt die Art des Trackables. Hierzu wird innerhalb des
Segments ein JointType definiert. Es existieren die JointTypes JointFree, JointBall,
JointCylindrical und JointHinge. In diesem Projekt verwenden wir ausschließlich JointFree, da unsere Trackables in alle Himmelsrichtungen rotierbar sind. Das Element JointFree besitzt neben seiner JointType-Bezeichnung eine weitere Eigenschaft:

NAME: Frei wählbar.
Das übergeordnete Segment enthält zusätzlich noch eine Farbe:


NAME: Frei wählbarer Name. Dient später als Referenz für Marker und Pointer
innerhalb der VSK-Datei.
RGB: Farbe des Segments für die visuelle Repräsentation in der GUI des Proximity Servers.
<Segment NAME="NameOfSegment" RGB="255 164 0">
<JointFree NAME="NameOfJointFree" />
</Segment>
Pointer
Neben dem Segment kann das Skeleton eine beliebige Anzahl an Pointern enthalten.
Diese müssen im Gegensatz zu den restlichen Tags nicht manuell über einen Texteditor
definiert werden. Hierzu bietet der Proximity Server eine GUI an, die in Kapitel 4.3 beschrieben ist. Lediglich das Löschen eines Pointers ist nicht über die GUI möglich. Folgende Informationen sind in jedem Pointer enthalten:






NAME: Frei wählbar.
POSITION: Muss der Position eines definierten Markers entsprechen und wird als
dreidimensionale Koordinate in folgender Reihenfolge angegeben: “x y z“. Es besteht die Möglichkeit, dass mehrere Pointer die gleiche Position besitzen.
DIRECTION: Bestimmt, in welche der drei vorhandenen Dimensionen der Pointer
zeigt. Die Reihenfolge der Dimensionen entspricht der Reihenfolge bei der
„POSITION“. Nur ein Wert der drei Dimensionen darf 1 oder -1 sein. Die anderen
zwei Werte müssen 0 sein. 1 bedeutet, dass der Pointer in die positive Richtung
der ausgewählten Dimension zeigt und -1 in die negative Richtung (siehe Abbildung 1).
TOUCHDISTANCE: Beliebig wählbare Zahl, welche die Distanz festlegt, die zwischen zwei Presences erreicht sein muss, um ein Touch-Event auszulösen.
SEGMENT: Name des Segments in der VSK-Datei.
RGB: Farbe des Pointers für die visuelle Repräsentation in der GUI des Proximity
Servers.
<Pointer NAME="NameOfPointer" POSITION="0 0 0" DIRECTION="0 0 1"
27
TOUCHDISTANCE="10" RGB="255 255 0" SEGMENT="NameOfSegment" />
Marker
Die Marker müssen im Gegensatz zu den Pointern manuell in die VSK-Datei geschrieben
werden. Die drei Werte zur Bestimmung ihrer Position stehen in den Tracking Tools zur
Verfügung und werden nach Auswahl des Trackables unter dem Menüpunkt „Marker
Locations“ aufgelistet (siehe Abbildung 1). Zusammen mit der Position enthält jeder
Marker folgende Eigenschaften:




NAME: Frei wählbar.
POSITION: Die Position besteht, wie bei den Pointern, aus drei Werten die eine
dreidimensionale Koordinate bestimmen. Die Reihenfolge ist ebenfalls „x y z“.
RGB: Farbe des Markers zur visuellen Repräsentation in der GUI des Proximity
Servers.
SEGMENT: Name des Segments in der VSK-Datei.
<Marker NAME="NameOfMarker" POSITION="0 0 0"
RGB="255 164 0" SEGMENT="NameOfSegment" />
Stick
Nach der Definition der Marker ist werden die Sticks hinzugefügt. Ein Stick beschreibt
die visuelle Verbindung zwischen zwei Markern. Er wird ebenfalls wie die Marker in der
GUI des Proximity Servers angezeigt. Jeder Stick enthält folgende Eigenschaften:



MARKER1: Bestimmt den Anfang des Sticks und muss dem Name eines Markers
in der VSK-Datei enthalten.
MARKER2: Bestimmt das Ende des Sticks und muss ebenfalls einen Marker aus
der VSK-Datei enthalten.
RGB: Farbe des Sticks zur visuellen Repräsentation in der GUI des Proximity Servers.
<Stick MARKER1="NameOfMarker1" MARKER2="NameOfMarker2" RGB="255 164 0" />
4.2.3 Konvertierung von Quaternion in Eulerwinkel
Die größte Herausforderung bei der Entwicklung des OptiTrack Input Moduls ist die
Umwandlung des ViconDataProcessors in den OptiTrackDataProcessor. Der Grund
hierfür ist das Format der Tracking-Daten des Tracking Tools.
Im Vergleich zur Low-Level Netzwerkkommunikation innerhalb des ViconInputModule,
stellt NaturalPoint eine High-Level API über das NatNet SDK zur Verfügung. Dies hat
zwar den Vorteil, dass nicht wie bei Vicon große Strings in ein Objekt Format geparst
werden müssen. Allerdings entspricht das Format der Tracking-Daten nicht den notwendigen Anforderungen zur Weiterverarbeitung im Proximity Toolkit.
Anstelle von den Eulerwinkeln Roll (Rotation um die x-Achse), Pitch (Rotation um die zAchse) und Yaw (Rotation um die y-Achse) zur Berechnung der Orientierung im Raum
(siehe Abbildung 27) liefern die Tracking Tools Quaternion.
Quaternion erweitern die komplexen Zahlen um zwei weitere imaginäre Dimensionen.
Dabei besteht jedes Quaternion aus vier Skalaren, einem Realteil (qw) und drei Imaginärteilen (qx, qy, qz).
Quaternion q = qw + qx + qy + qz
28
Mit Hilfe der Quaternion ist es möglich die Rotationen eines Körpers im dreidimensionalen Raum zu beschreiben. Sie werden als Alternative zur Rotationsberechnung mit Eulerwinkeln genutzt, weil sie keinen Gimbal Lock (kardanische Blockade) verursachen
können. Ein Gimbal Lock entsteht genau dann, wenn nach einer oder mehreren Rotationen, zwei Achsen aufeinander liegen und somit eine Dimension eliminiert wird (siehe
Abbildung 27). Diese bedeutet z.B., dass bei einer Überlagerung von Pitch und Roll, eine
Veränderung der Eulerwinkel Roll und Yaw zur exakt der gleichen Rotationsbewegung
führen.
Abbildung 27 – Die drei Winkel Roll, Pitch und Yaw beschreiben die Orientierung (Rotationen) eines Objekts
im Raum. Es besteht die Gefahr eines Gimbal Locks, wenn zwei Achsen aufeinander liegen.14
Zur Umrechnung von einem Quaternion in drei Eulerwinkel wird in diesem Projekt ein
Algorithmus von Martin John Baker15 verwendet, welcher im Ursprung als JavaImplementierung vorliegt und in C# konvertiert wurde. Der Algorithmus besteht aus
zwei logischen Rechenschritten.
Als Erstes muss das Quaternion wie folgt in eine 3x3 Matrix überführt werden.
M00 M01 M02
M10 M11 M12
M20 M21 M22
1 - 2*qy2 - 2*qz2
2*qx*qy - 2*qz*qw 2*qx*qz + 2*qy*qw
2*qx*qy + 2*qz*qw 1 - 2*qx2 - 2*qz2
2*qy*qz - 2*qx*qw
2*qx*qz - 2*qy*qw 2*qy*qz + 2*qx*qw 1 - 2*qx2 - 2*qy2
Ein Teil dieser Werte wird im zweiten Schritt zur Berechnung der Winkel Yaw, Pitch und
Roll verwendet und in folgende Formeln eingesetzt:
Yaw (heading) = atan2(-m20, m00)
Pitch (attitude) = asin(m10)
Roll (bank) = atan2(-m12, m11)
Diese Abbildung wurde auf der Internetseite von GIMBAL SYSTEMS veröffentlicht:
http://www.gimbalsystems.com/about/why-we-chose-the-name.html (Abgerufen am 26.02.2013)
15 Link zur Beschreibung des Algorithmus von Martin John Baker:
http://www.euclideanspace.com/maths/geometry/rotations/conversions/quaternionToEuler/ (Abgerufen am 25.02.2013)
14
29
heading = atan2(2*qy*qw-2*qx*qz , 1 - 2*qy2 - 2*qz2)
attitude = asin(2*qx*qy + 2*qz*qw)
bank = atan2(2*qx*qw-2*qy*qz , 1 - 2*qx2 - 2*qz2)
Bei der Umrechnung müssen die zwei Sonderfälle der Singularität beachtet werden,
welche an den Polen auftreten können. In diesen Fällen nimmt Pitch den Wert 90°
(Nordpol) oder -90° (Südpol) an. Dies hat zur Folge, dass die Werte der beiden anderen
Winkeln 0 ergeben, was laut Aussage von Baker kein valides Resultat darstellt. Zur Behandlung der beiden Sonderfälle wird folgender Test durchgeführt, wobei 0.499 in einem Winkel von 86,3° resultiert.
Test = qx*qy + qz*qw
Wenn das Resultat des Tests größer als 0.499 (Singularität am Nordpol) ist, müssen die
zuvor beschrieben Formeln für die drei Winkel durch folgende ersetzt werden:
heading = 2 * atan2(qx,qw)
attitude = Math.PI/2
bank = 0
Wenn das Resultat stattdessen kleiner als -0.499 (Singularität am Südpol) ist, werden
folgende Formeln angewandt:
heading = -2 * atan2(qx,qw)
attitude = - Math.PI/2
bank = 0
Neben der Umwandlung der Quaternion müssen auch die Koordinaten x, y und z konvertiert werden. Hierzu werden alle Koordinaten mit dem Faktor 1000 multipliziert, um
Werte in Millimetern zu erhalten. Abschließend werden die gesamten Daten in einem
Zwischenspeicher persistiert und stehen anderen Klassen für eine Weiterverarbeitung
zur Verfügung.
4.3 Proximity Server
Die aufbereiteten Daten des OptiTrackInputModule stellt der Proximity Server nach der
Weiterverarbeitung im Netzwerk bereit. Mit Hilfe des Servers wird der Interaktionsraum kalibriert, Displays im Raum definiert und alle Presences verwaltet. Auf Anfrage
berechnet der Server Werte zur Bestimmung der fünf Proxemic Dimensions zwischen
ausgewählten Presences. In diesem Kapitel werden die Server GUI und deren Konfiguration näher beschrieben.
4.3.1 Starten des Servers
Vor dem Start des Proximity Servers öffnet sich ein Fenster für die Auswahl des Input
Moduls (siehe Abbildung 28a), wobei in unserem Projekt ausschließlich das OptiTrackInputModule angezeigt wird. Nach Bestätigung des Fensters wird ein weiterer Dialog
geöffnet, in welchem die IP-Adresse und den Port des Servers eingestellt werden kann
(siehe Abbildung 28b). Die IP-Adresse entspricht dabei der IP-Adresse des Rechners, auf
welchem der Server läuft. Zum Starten des Servers wird abschließend der grüne Button
30
im Dialogfeld angeklickt oder der rote Button, wenn der Server noch nicht gestartet
werden soll.
Abbildung 28 – Dialogfenster während des Startens des Proximity Servers. (A) Fenster zur Auswahl der Input
Module und (B) Fenster zur Einstellung der IP und des Ports.
Menü + Toolbar
Visuelle Darstellung des Raums
Presence
Visualizer
+
Eigenschaften
Project
Explorer
Informationsleiste
Abbildung 29 – Screenshot der GUI des Proximity Servers.
4.3.2 Server GUI
Das Fenster des Proximity Servers ist in fünf Bereiche unterteilt (siehe Abbildung 29).
Oben befinden sich eine Menü- und eine Toolbar. Mit Hilfe der Menübar werden die
Einstellungen zu den vorhandenen Modulen aufgerufen und die Toolbar bearbeitet.
Am unteren Ende des Fensters ist eine Informationsleiste platziert, welche den Status
des Servers und aufkommende Fehlermeldungen anzeigt.
Im linken Teil des Fensters sind die Input Module und Presences aufgelistet. Die einzelnen Presences werden hierarchisch, ähnlich eines Dateiexplorers, abgebildet und einem
root-Element untergeordnet, welches den Space (Raum) beschreibt. Hierzu zählen Displays, Volumes, Devices und Presences (Trackables).
31
In der Mitte des Proximity Servers werden der virtuelle Raum und die darin sichtbaren
Presences angezeigt. Dies erleichtert die Kalibrierung, das Erstellen von Displays und
das Testen einer Anwendung.
Die Eigenschaften eines Presences werden nach einem Aufruf rechts neben dem virtuellen Raum angezeigt, ausgenommen der Presences, die in den Tracking Tools erstellt
wurden. Diese müssen über den VSK-Editor des Proximity Servers bearbeitet werden.
Wenn keine Eigenschaften eines Presences aufgerufen sind, wird der Relation Visualizer
rechts zur Verfügung gestellt. Mit ihm ist es möglich die Relations (oder auch Proxemic
Dimensions) zwischen zwei Presences zu überprüfen bevor eine eigene Anwendung
entwickelt wird.
4.3.3 VSK-Dateipfad
Für die Verwendung des Relation Visualizer müssen die Presences korrekt im Proximity
Server angezeigt werden und der Space kalibriert sein.
Zur Anzeige der Presences ist die einmalige Einstellung des Pfades zu den VSK-Dateien
notwendig. Hierzu das Kontextmenü des OptiTrack Input Moduls öffnen und auf „Module Settings“ klicken (siehe Abbildung 30a). Daraufhin öffnet sich das Fenster „Proximity
Server Settings“ (siehe Abbildung 30b). In dem Tab „Module Settings“ besteht rechts die
Möglichkeit den „VSK Library Path“ einzustellen. Nach Bestätigung der Einstellungen
muss der Proximity Server neugestartet werden, ansonsten werden die VSK-Dateien
nicht geladen.
Abbildung 30 – Einstellung des VSK Library Pfads. (A) Kontextmenü des OptiTrackInputModule und (B)
Dialogfenster zur Einstellung des VSK Library Pfads.
Tipp: Wenn der VSK-Dateipfad nicht angeben ist wird eine Fehlermeldung unten zentral
in der Informationsleiste des Proximity Servers angezeigt. Mit einem Klick auf die Meldung öffnet sich ein neues Fenster, welches Detailinformationen bereitstellt.
4.3.4 Definition von Pointern
Für alle über den VSK-Dateipfad verfügbaren Presences können mehrere Pointer definiert werden. Ein Pointer ist ein Zeiger in Form eines Vektors, ausgehend von einem
Marker des Presences. Dieser Vektor zeigt in eine positive oder negative Richtung der
vorhandenen Achsen x, y oder z. In unserem Projekt benötigen wir für die Basecap (sie32
he Kapitel 3.4) genau einen Pointer. Zur Erstellung eines Pointers wird der VSK-Editor
über das Kontextmenü des OptiTrack Input Moduls geöffnet (siehe Abbildung 30a). Eine
Combo Box im oberen Bereich des VSK-Editors ermöglicht die Auswahl der Presences
(VSK-Dateien) (siehe Abbildung 31a), dessen Komponenten nach der Selektion links im
Fenster zur Verfügung stehen. Hierzu gehören z. B. das Segment, die Marker und die
Sticks. Bei Bedarf ist es möglich die Eigenschaften der einzelnen Komponenten rechts im
Fenster zu bearbeiten (siehe Abbildung 31).
Abbildung 31 – VSK Editor des Proximity Servers. (A) zeigt die Combo Box zur Auswahl einer VSK-Datei und
Combo Box zum Hinzufügen eines Pointers. (B) zeigt die Bearbeitung eines Pointers.
Zur Erstellung eines Pointers wird unten links aus einer Combo Box der Eintrag „Pointer“ ausgewählt und anschließend auf „Add“ geklickt (siehe Abbildung 31a). Rechts im
Fenster stehen anschließend die Eigenschaften des Pointers zur Verfügung (siehe Abbildung 31b). Der Name des Pointers unserer Basecap wird in „FrontPointer“ umbenannt,
da der Pointer ausgehend vom Kopf des Benutzers nach vorne zeigt. Der Ursprung (Origin) des Pointers ist bei unserer Basecap der Pivot-Punkt, bzw. die Position des Presences (siehe Kapitel 3.4). Bei der Direction wird für z (letzte Stelle) eine „-1“ eingetragen.
Dies ergibt sich aus folgendem Sachverhalt:
Wenn der Benutzer frontal zum Display steht und sich die Basecap in ihrem Ursprung
befindet, d.h. die Basecap wurde nicht rotiert und die Eulerwinkel (Yaw, Pitch und Roll)
zu Beschreibung der Rotation (siehe Kapitel 4.2.3) sind 0.0, zeigt unser Pointer entlang
der z-Achse in Richtung der Cubes (siehe Abbildung 32). Zuletzt werden noch die
TouchDistance, die Farbe und das Segment eingestellt (siehe Kapitel 4.2.2). Abschließend die Datei speichern und den Proximity Server neustarten.
33
Abbildung 32 – Der Pointer (blaue und gelb gestrichelte Linie) des Presences (gelb) zeigt frontal in Richtung
des Displays (blaues Rechteck).
Tipp: Es gibt keine Möglichkeit bereits vorhandene oder neu hinzugefügte Pointer im
VSK-Editor zu entfernen. Zum Entfernen von Pointern oder anderen Komponenten muss
die VSK-Datei in einem externen Texteditor geöffnet werden (siehe Kapitel 4.2.2).
Abbildung 33 – Kalibrierung des Space. (A) zeigt das Kontextmenü des Space und (B) das Fenster zur Einstellung des Spaces.
4.3.5 Kalibrierung des Space
Im nächsten Schritt wird der Space kalibriert. Hierzu das Kontextmenü des Spaces (rootElement bei den Presences) öffnen und auf „Calibrate“ klicken (siehe Abbildung 33a). Im
rechten Teil des Servers werden anschließend die Einstellungen und Informationen zur
Kalibrierung angezeigt (siehe Abbildung 33b).
Als Erstes muss die „Space Orientation“ eingestellt werden. Dies ist manuell über die
Textfelder oder mit Hilfe der Location eines Presences möglich. Für die Einstellung
34
unter Verwendung eines Presences, muss die Location eines Markers oder die Location
des Presences per Drag & Drop auf das Feld Origin gezogen werden (siehe Abbildung
33b). Anschließend wird das Presence an die gewählte Stelle im Raum platziert und auf
das „papierkorbähnliche“ Symbol geklickt. Es erscheint ein kleines Menü, auf welchem
zwei Vorgehensweisen angeboten werden. Durch einen Klick auf „Capture Now“ wird
der aktuelle Wert der Location in das Feld eingetragen. Ebenso ist es möglich einen
Countdown einzustellen, welcher nach 5, 10 oder 30 Sekunden die aktuelle Position der
gewählten „Location“ automatisch erfasst.
Die gleiche Vorgehensweise wird schließlich für die „Front Direction“ und „Up Direction
angewandt. Anstelle einer Location wird hier ein „Pointer“ eines Presences per Drag &
Drop auf das Feld bewegt und in die jeweilige Richtung gezeigt (nach vorne und nach
oben im Raum). Homogen zur Origin ist es möglich die Werte auch manuell einzutragen.
Im zweiten Schritt wird die Größe des Raums definiert. Ähnlich der Orientierung (Orientation) gibt es zwei Möglichkeiten. Eine manuelle Einstellung der Werte und die Einstellung über ein Presence. Bei Variante zwei wird ein Presence ausgewählt und auf das
„Presence“-Symbol gedragged. Anschließend wird der rote „Aufnahme“-Button angeklickt und das Presence durch den kompletten Raum bewegt. Währenddessen ist es
möglich die Ausbreitung des virtuellen Raums in der Visualisierung zu verfolgen. Zum
Abschluss muss das gesamte Ergebnis bestätigt werden.
Tipp: Es empfiehlt sich die Kalibrierung über das Kontextmenü des Spaces zusätzlich als
separate Datei zu speichern, da eine zukünftig falsch gespeicherte Neukalibrierung nicht
mehr umkehrbar ist.
4.3.6 Definition von Displays
Zur Definition eines physischen Displays wird das Kontextmenü des Eintrags "Displays"
in den Presences aufgerufen und mit einem Klick auf "New Display" ein neues Display
erstellt (siehe Abbildung 34 Schritt 1). Zur Einstellung der Auflösung des Displays anschließend im Kontextmenü des neuen Displays auf "Mapping" klicken und rechts im
Proximity Server die Einstellungen bearbeiten (siehe Abbildung 34 Schritt 3). Wenn es
sich um das Display handelt, auf welchem der Proximity Server läuft, kann über die
Combo Box das logische Display ausgewählt werden.
Nach dem die Displayauflösung eingestellt ist, wird die Größe und Position des Displays
im Space definiert. Hierzu wird ebenfalls das Kontextmenü des Displays geöffnet und
der Eintrag „Calibrate“ ausgewählt (siehe Abbildung 34 Schritt 4). Zur Einstellung der
vier Koordinaten für die vier Eckpunkte des Displays stehen, ähnlich wie bei der Kalibrierung des Spaces, zwei Möglichkeiten zur Verfügung. Die Werte können entweder
manuell in die Nummernfelder oder mit Hilfe der Location eines Markers eingetragen
werden. Für die zweite Variante die Location eines Markers auswählen und auf die vier
Kreisfelder ziehen. Anschließend je Koordinate das Kontextmenü über das „papierkorbähnliche“ Symbol öffnen, den Marker des Presences im Raum an die entsprechende
Position bewegen und die Koordinate aufzeichnen (siehe Abbildung 34 Schritt 4).
35
1
2
4
3
Abbildung 34 – Schrittweise Definition eines Displays von 1 bis 4. (1) zeigt das Kontextmenü des Explorereintrags Displays, (2) das Kontextmenü eines erstellten Displays, (3) die Einstellung für die Auflösung des Displays und (4) die Einstellung zur Kalibrierung des Displays.
Tipp: Zur Bestimmung der vier Koordinaten eines Displays eignet sich ein Presence in
Form eines Stabes. Es empfiehlt sich eine Anbringung von Markern an beiden Enden des
Stabes, um später „punktgenaue“ Positionen im Raum definieren zu können. In diesem
Projekt wurde ein Presence MagicWand erstellt, welches diese Anforderungen erfüllt
(siehe Abbildung 35).
Abbildung 35 – Presence MagicWand zur Kalibrierung von Displays und Space.
36
4.3.7 Relation Visualizer
Nach der Konfiguration des Raums und der Presences ist es mit Hilfe des „Relation Visualizer“ möglich die Proxemic Dimensions zwischen zwei Presences zu überprüfen. Über
die Combo Box „Relation“ wird eine Dimension ausgewählt und wenn möglich ein weiteres Objekt aus dessen Index, z.B. ein Pointer (siehe Abbildung 36). Die aktuellen Werte
einer gewählten Dimension werden unterhalb in einer Tabelle aufgeführt. In dem Beispiel in Abbildung 36 wird das Presence User1 mit dem Display „SmartBoard“ in Beziehung gestellt. Beide Presences sind per Drag & Drop aus dem Project Explorer auf die
Felder PresA und PresB bewegt worden.
Abbildung 36 – Beispiel zur Verwendung des Relation Visualizer. Das Presence User1 zeigt mit seinem FrontPointer auf das SmartBoard.
4.4 Client Anwendung
Die im Relation Visualizer angezeigten Informationen zu den fünf Proxemic Dimensions
stehen über das Netzwerk für Client-Anwendungen zur Verfügung. Zur Kommunikation
mit dem Proximity Server wird eine Referenz auf das Projekt "ProximityToolkit.WPF"
benötigt.
In dem Projekt "ProximityToolkit.WPF" stehen folgende Klassen zur Verfügung:



PresenceManager
PresenceControl
RelationControl
Instanzen aller drei Klassen werden in unserem Projekt im XAML-Code des MainWindows implementiert. Dies erfordert weniger Zeilen Programmcode und ist übersichtlicher als eine Implementierung in C#.
37
4.4.1 PresenceManager
Zum Aufbau einer Verbindung mit dem Proximity Server wird der „PresenceManager“
verwendet. Er benötigt zum Verbindungsaufbau die IP-Adresse und den Port des Servers. Leider ist es nicht möglich die IP-Adresse im XAML-Code zu definieren. Es empfiehlt sich daher die beiden Properties Port und IP zentral im Code-Behind zu übergeben.
XAML-Code:
<p:PresenceManager Name="PresenceManager"/>
Code-Behind C#-Code:
PresenceManager.IP = new IPAddress(long.Parse("127.0.0.1"));
PresenceManager.Port = 888;
Nach dem das Hauptfenster initialisiert ist wird der PresenceManager gestartet. Die
Methode Start liefert als Rückgabewert „True“, wenn eine erfolgreiche Verbindung zum
Server herstellt ist.
Code-Behind C#-Code:
bool started = PresenceManager.Start();
Durch den Aufruf der Start-Methode wird nicht nur eine Verbindung zum Server hergestellt, es werden auch alle definierten Presences auf ihre Verfügbarkeit überprüft. Dem
Entwickler bzw. Benutzer stehen diese Informationen über ein Dialog nach dem Start
der Anwendung zur Verfügung (siehe Abbildung 37). Wenn nicht alle Presences verfügbar sind, ist es trotzdem möglich das Dialogfenster über „Cancel“ zu schließen. Die eigene Anwendung wird hierdurch nicht beendet. Zum manuellen Stoppen des PresenceManagers wird die Methode Stop() aufgerufen.
Abbildung 37 – Dieser Dialog wird nach dem Start des PresenceManagers angezeigt. Er enthält Informationen
über den aktuellen Status der definierten Presences.
38
4.4.2 PresenceControl
Neben dem PresenceManager müssen auch alle erforderlichen Presences einzeln im
XAML-Code definiert sein. Hierzu wird die Klasse PresenceControl verwendet. Über das
Property PresenceName wird der Name des Presences aus dem Proximity Server angegeben und über das Event OnUpdated eingehende Updates behandelt (z.B. Updates zur
Position oder Orientierung im Raum).
XAML-Code:
<p:PresenceControl Name="User1" PresenceName="Basecap1" OnUpdated="OnUpdatedB1"/>
Handelt es sich beim dem definierten Presence um einem Display, Device oder Volume,
muss zusätzlich sein PresenceType angegeben werden.
XAML-Code:
<p:PresenceControl Name="Cubes" PresenceName="Display1" Presence-Type="Display"
OnUpdated="OnUpdatedCubes"/>
Das Event OnUpdated beinhaltet als Argument ein Objekt PresenceBase, welches die
fünf Proxemic Dimensions über folgende Properties zur Verfügung stellt:
private void OnUpdatedCubes(PresenceBase presence){
presence.ProxemicDirection
presence.ProxemicLocation
presence.ProxemicMotion
presence.ProxemicOrientation
presence.ProxemicRotation
}
Eine weitere wichtige Eigenschaft wird durch das Property IsVisible beschrieben. Sie
zeigt ob ein Presence sichtbar ist oder nicht.
4.4.3 PresenceRelation
Im Gegensatz zum PresenceControl ermöglicht die PresenceRelation eine Betrachtung
der Beziehung zwischen zwei Presences. Hierzu wird ein Presence dem Property NameA
zugewiesen und das andere dem Property NameB. Dabei ist zu beachten, dass die Beziehung immer aus Sicht von NameA untersucht wird, z.B ob NameA auf NameB zeigt (siehe nachfolgendes Codebeispiel). Für das Gegenteil müssen die beiden Presences vertauscht werden. Ob ein Presence z.B. auf ein anderes zeigt wird über das Event OnPointingUpdated überprüft.
<p:RelationControl Name="User1ToCubes" NameA="Basecap1" NameB="Display"
OnPointingUpdated="OnPointingUpdatedUser1ToCubes"/>
Insgesamt stehen folgende Events zur Verfügung:


OnLocationUpdated (LocationRelationEventArgs args)
OnDirectionUpdated (DirectionRelationEventArgs args)
39





OnOrientationUpdated (OrientationRelationEventArgs args)
OnRotationUpdated (RotationRelationEventArgs args)
OnMotionUpdated (MotionRelationEventArgs args)
OnCollisionUpdated (CollisionRelationEventArgs args)
OnPointingUpdated (PointingRelationEventArgs args)
Eine detaillierte Beschreibung der einzelnen Events findet sich in der Veröffentlichung
„The proximity toolkit: prototyping proxemic interactions in ubiquitous computing
ecologies“ von Marquardt et al. [Marquardt et al. 2011].
40
5 Proxemic ZUI Prototyp
Der Proxemic ZUI Prototyp (siehe Abbildung 38) wird zur Beantwortung der Forschungsfragen aus Kapitel 1 eingesetzt. Er ist unter Windows 7 für Desktop-Computer
und Tablet-PCs konzipiert. Zur Entwicklung wird WPF (Windows Foundation Presentation) aus dem Microsoft Framework .NET und das ZOIL Framework verwendet. Als
Entwicklertools kommen Microsoft Visual Studio 2010 und Microsoft Visual Studio 2012
zum Einsatz.
Abbildung 38 – Skizzierung des Proxemic ZUI Prototyps.
Aktuell umfasst der Proxemic ZUI Prototyp ca. 3000 Zeilen C#- und XAML-Code (eXtensible Application Markup Language) und ist in drei Projekte unterteilt. Die Shared View
auf den Cubes (siehe Kapitel 5.3), die Remote View auf den Tablet PCs (siehe Kapitel 5.4)
und Common für die Beschreibung der Datenobjekte (siehe Kapitel 5.2). Für die Korrektur der Tracking-Daten wird neben dem Kalman Filter in den Tracking Tools (siehe
Kapitel 3.4) zusätzlich ein projektinterner Kalman Filter verwendet (siehe Kapitel 5.5)
Die Einstellungen der einzelnen Projekte sind in den Application Settings gespeichert
und können vor oder teilweise zur Laufzeit verändert werden. Sie variieren je nach
Projekt und beinhalten z.B. Informationen zur Kommunikation zwischen Remote Views
und der Shared View sowie dem Databackend des ZOIL Frameworks.
5.1 Übersicht
Mit dem Proxemic ZUI Prototyp navigieren Benutzer über ihre Bewegung im Raum
durch eine zoombare Informationslandschaft. Die gesamte Informationslandschaft wird
auf einem Übersichtsdisplay (Shared View, siehe Abbildung 38) angezeigt, auf welchem
keine Interaktion möglich ist. Die Shared View dient als Referenz- und Orientierungspunkt während der Navigation und zeigt dem Benutzer die aktuelle Position und Größe
seines Viewports an. Jeder Benutzer hat zusätzlich ein persönliches Tablet (RemoteView), auf welchem sein Viewport im Vollbild zu sehen ist. Mit diesem Prototyp ist es für
mehrere Benutzer möglich gleichzeitig in der Informationslandschaft zu navigieren,
ohne den Viewport anderer Personen zu verändern. Hierzu sind folgende Navigations41
techniken, basierend auf den Proxemic Interactions (siehe Kapitel 4.1), iterativ entwickelt worden:
Ground Panning (GroundP)
Die Navigationstechnik Ground Panning basiert auf der Magic-Lens-Interaktionstechnik
aus dem Projekt PaperLens [Spindler et al. 2009]. Der Tablet-PC des Benutzers entspricht dabei der „Papier-Linse“ in PaperLens und der Bereich (Boden) vor dem Shared
Display der Fläche der Informationslandschaft auf der Shared View. Im Unterschied zu
PaperLens wird aber nicht die Position des Tablets getrackt sondern die Position des
Benutzers.
Eine Bewegung nach links oder rechts vor dem Shared Display entspricht einer PanningBewegung nach links oder rechts in der Informationslandschaft (siehe Abbildung 39).
Bewegt sich der Benutzer auf das Display zu, panned er nach oben oder bei einer Rückwärtsbewegung wieder nach unten innerhalb des ZUIs (siehe Abbildung 40). Dies hat
zur Folge, dass z.B. die Position links vor dem Display der Position oben links in der
Informationslandschaft entspricht und ganz hinten rechts im Raum unten rechts innerhalb des ZUIs. Zur Vergrößerung oder Verkleinerung (Zooming) des Viewports wird bei
dieser Navigationstechnik eine Pinch-Gesture mit der Hand (Greif-Geste) ausgeführt.
Über die Pinch-Gesture wird der Viewport festgehalten und anschließend über eine
vertikale Bewegung der Hand in Richtung des Displays in seiner Größe verändert (siehe
Abbildung 41). Zur Ausführung dieser Interaktionstechnik muss der Benutzer seinen
Fokus von dem mobilen Gerät auf die Shared View wechseln und ebenso die Eingabeform von Ganzkörperbewegung zu präziser Interaktion über die Hand ändern. Weitere
folgende Navigationstechniken versuchen dies wenn möglich über andere Navigationstechniken zu verhindern.
Abbildung 39 – Horizontales Panning in der Informationslandschaft.
42
Abbildung 40 – Vertikales Panning in der Informationslandschaft.
Abbildung 41 – Zooming durch die Ausführung einer Pinch-Gesture und die Bewegung des Arms.
Head Directed Panning (HeadDP)
Im Gegensatz zur Navigationstechnik GroundP wird bei Head Directed Panning die
Position des Viewports über die Bewegung des Kopfes verändert (siehe Abbildung 42).
Eine vertikale Kopfbewegung wird in eine vertikale Panning-Navigation überführt und
eine horizontale Kopfbewegung in einer horizontale Panning-Navigation. Der Viewport
befindet sich mit dieser Technik immer genau in „Blickrichtung“ des Benutzers, wobei
die Blickrichtung anhand der Ausrichtung des Kopfes bestimmt wird. Anders als bei
GroundP ist die Z-Position des Benutzers nicht durch eine Panning-Navigation belegt.
Dies ermöglicht eine Zooming-Navigation über eine vertikale Bewegung in Richtung der
Shared View (siehe Abbildung 43). Zur Vergrößerung eines Bereichs nähert sich der
Benutzer dem Display und entgegengesetzt, um wieder raus zu zoomen, ähnlich der
Interaktion in der realen Welt, wenn wir uns auf ein entferntes Objekt zu oder von ihm
weg bewegen. Ein großer Nachteil dieser Navigationstechnik ist die ständige Verände43
rung des Viewports durch die Kopfbewegung des Benutzers, sofern nicht ein weiterer
Mechanismus für einen Moduswechsel zum Stoppen der Navigation eingesetzt wird
(wie z. B. ein „Stop“-Button auf dem mobilen Gerät oder ein Sprachkommando). Ohne
diesen Mechanismus ist es nicht möglich auf das mobile Gerät zu schauen ohne den
zuvor gewählten Viewport zu verändern.
Abbildung 42 – Vertikale Panning-Navigation durch die vertikale Kopfbewegung des Benutzers.
Abbildung 43 – Zooming in der Informationslandschaft durch die Distanz zur Shared View.
Head Directed Vertical Panning (HeadDVP)
Eine Abwandlung der Navigationstechnik HeadDP ist Head Directed Vertical Panning.
Bei dieser Technik wird die Kopfbewegung ausschließlich für eine vertikale Bewegung
(Panning in y-Richtung) in der Informationslandschaft verwendet (siehe Abbildung 42),
was das Navigationsproblem aus HeadDP reduziert aber nicht vollständig löst. Für horizontales Panning bewegt sich der Benutzer nach links oder rechts vor dem Display und
verschiebt seinen Viewport gleichermaßen nach links oder rechts in der Informationslandschaft (siehe Abbildung 39). Die Zooming-Navigation verhält sich gleich wie bei der
Navigationstechnik HeadDP durch eine Vor- oder Rückwärtsbewegung vor dem Display
(siehe Abbildung 43). Auch bei dieser Technik wird ein Moduswechsel benötigt, um die
Navigation durch die Kopfbewegung zu pausieren. Ansonsten gelingt es dem Benutzer
nicht auf sein mobiles Gerät zu blicken, ohne den Viewport zu verändern.
44
Hand Directed Vertical Panning (HandDVP)
Bei der Navigationstechnik Hand Directed Vertical Panning wird im Gegensatz zu
HeadDP und HeadDVP kein Moduswechsel benötigt. Die horizontale Position und Größe
des Viewports wird wie bei der Technik HeadDVP über die Position des Benutzers vor
dem Display bestimmt. Für die vertikale Position wird die Kopfbewegung durch eine
vertikale Bewegung der Hand (siehe Abbildung 44) ersetzt. Gleich der Technik GroundP
muss eine Pinch-Gesture mit der Hand ausgeführt werden, um den Viewport festzuhalten und anschließend in vertikaler Richtung zu bewegen. Daraus ergibt sich jedoch ein
Wechsel der Eingabeformen wie bei der Technik GroundP.
Abbildung 44 – Vertikales Panning durch die Auf- und Ab-Bewegung des Arms bzw. der Hand.
Device Directed Panning (DeviceDP)
Das Resultat der letzten Iteration bei der Entwicklung der Navigationstechniken ist
Device Directed Panning. Diese Navigationstechnik basiert auf der Technik GroundP und
ist ebenfalls eine Ableitung der Interaktionstechnik der PaperLens [Spindler et al. 2009].
Im Gegensatz zu Technik GroundP wird die Position des Viewports nicht direkt durch
die Position des Benutzers bestimmt. Stattdessen wird das Tablet in vertikaler und
horizontaler Richtung vor der Displayoberfläche bewegt und der Viewport gleichermaßen auf die dahinterliegende Position in der Landschaft verschoben (siehe Abbildung
45). Die kognitive Leistung zur Übertragung der Informationslandschaft auf den Boden
vor der Shared View entfällt und wird durch eine Bewegung der Magic Lens vor Displayfläche ausgetauscht. Die horizontale Panning-Navigation entspricht dabei der Navigation
in HeadDVP und GroundP (siehe Abbildung 39), wobei die Bewegung des Benutzers
durch die Bewegung des Tablets ersetzt wird. Beide Hände werden bei dieser Technik,
im Gegensatz zu HandDP und HandDVP, ausschließlich zur Bewegung des Tablets und
zur Interaktion auf dem mobilen Gerät verwendet. Für eine Zooming-Operation wird das
Tablet auf das Display zu oder von ihm weg bewegt, ähnlich der Bewegung für Zooming
in HeadDP, HeadDVP und HandDVP (siehe Abbildung 43). Im Gegensatz zu den anderen
vier Navigationstechniken ändert sich die Eingabeform nicht. Zudem ist bei dieser Technik ein impliziter Modus-Wechsel zwischen aktiver und pausierter Navigation möglich.
Wenn das Tablet nahezu senkrecht in Richtung der Shared View gehalten wird, ist der
Navigationsmodus aktiviert, hingegen eine waagrechte Position des Tablets die Navigation pausiert. Der Benutzer führt diesen Wechsel implizit während der Navigation aus,
ohne explizit darauf achten zu müssen.
45
Abbildung 45 – Vertikales Panning durch die Auf- und Abbewegung des mobilen Geräts.
Die Technik Device Directed Panning wird auf Grund ihrer Vorteile gegenüber den
anderen Techniken mit der Eingabemodalität Multi-Touch verglichen und schließlich
zur Beantwortung der Forschungsfragen verwendet (siehe Kapitel 1).
5.2 Common
Zur Darstellung der ViewPorts und Datenobjekte in der Shared- und Remote View wurden verschiedene UserControls entwickelt, welche im Projekt Common gespeichert sind.
Alle UserControls bauen auf dem Modell des MVVM-Patterns auf und bestehen aus einem Model, einer View und einem ViewModel. Mit Hilfe des MVVM-Patterns wird die
View (visuelle Repräsentation des Objekts) von den Daten getrennt und kann für zukünftige Anforderungen variabel angepasst werden.
Die vorhandenen UserControls lassen sich in zwei Arten unterteilen. Zum einen gibt es
Controls, welche im ZOIL Databackend persistiert werden müssen. Hierzu gehören die
MemoryPlayCards und die SnapViewPorts.
Das UserControl RemoteViewPort muss stattdessen nicht persistiert werden und liegt
als einziges Objekt über der Informationslandschaft und ist ausschließlich auf der
Shared View sichtbar.
In folgenden Abschnitten werden die einzelnen UserControls und ihre Funktion kurz
beschrieben.
46
Abbildung 46 – UML Klassendiagramme der Datenobjekte des Proxemic ZUI Prototyp. Von links nach rechts:
MemoryPlayCard, SnapViewPort und RemotViewPort.
MemoryPlayCard
Die MemoryPlayCards werden zur Beantwortung der Forschungsfrage 1 (siehe Kapitel
1) benötigt und entsprechen den Karten aus der ZUI Studie von Jetter et al. [H.-C. Jetter
et al. 2012]. Jede MemoryPlayCard beinhalten ein ASCII –Zeichen als Symbol und eine
SymbolFont (siehe Abbildung 46), welche eine Schriftart definiert. Zu den Schriftarten
gehören Wingdings, Wingdings 2 und Webdings. Alle zur Verfügung stehenden ASCIIZeichen sind in einer XML-Datei gespeichert und werden zur Laufzeit geladen. Folgender XML-Code zeigt als Beispiel den Eintrag für das Zeichen „Auge“ (siehe Abbildung
47b):
<memorycard fontType="Webdings">N</memorycard>
Die View der MemoryPlayCard besteht aus zwei semantischen Zoomstufen. In der ersten
Zoomstufe wird anstelle des Symbols die Rückseite einer Spielkarte angezeigt (siehe
Abbildung 47a). Ab einer Größe von 260 Pixeln ist die zweite Zoomstufe mit dem Symbol sichtbar (siehe Abbildung 47b). Dieser Wert wurde empirisch ermittelt und erfüllt
bei einem speziellen Mindestabstand zwischen den Objekten folgende Anforderung: Zu
jedem Zeitpunkt darf der Benutzer immer nur ein Symbol gleichzeitig sehen. Ansonsten
ist es möglich über umliegende sichtbare Symbole auf die Position des eigentlich gesuchten Symbols zu schließen. Zur randomisierten Verteilung der Objekte wird ein
eigens implementierter Algorithmus verwendet. Dieser Algorithmus baut basierend auf
der Größe der Informationslandschaft des ZUIs und der Größe der Symbole ein Gitter47
netz auf. Hieraus ergibt sich eine Anzahl an Feldern mit möglichen Positionen für die
Symbole. Bei einer Landschaftsgröße von 3048 x 1080 Pixeln und einer Symbolgröße
von 50 Pixeln sind das 1260 Felder. Anschließend werden die vorhandenen Symbole in
Abhängigkeit der Displayauflösung des Tablets zufällig platziert, so dass niemals zwei
Symbole gleichzeitig sichtbar sind. Hierzu muss die minimale Größe der MemoryPlayCards berücksichtigt werden, bei welcher das Symbol sichtbar ist. Basierend
darauf wird eine minimale Distanz bestimmt, welche zwischen den MemoryPlayCards
eingehalten werden muss. Für jedes zufällig gewählte Feld müssen alle in dieser Distanz
umliegenden Felder überprüft werden bevor eine Karte platziert werden kann. Auf der
Shared View ist im Gegensatz zur Remote View zu jedem Zeitpunkt nur die Rückseite
der Spielkarte sichtbar, da die Versuchsperson ausschließlich über die Navigation einzelne Symbole auf ihrem mobilen Gerät aufdecken kann.
Abbildung 47 – Beispiel für eine MemoryPlayCard. (A) zeigt den Rückseite der MemoryPlayCard und (B) die
Vorderseite
SnapViewPort
Der SnapViewPort dient im Gegensatz zur MemoryPlayCard zur Beantwortung der zweiten Forschungsfrage, in welcher die Navigations-Performance der Benutzer hinterfragt
wird. Zusätzlich wird er auch in der Gedächtnis-Studie als Startpunkt vor jeder Navigationsaufgabe eingesetzt.
Er besteht aus einem farblich hervorgehobenen Rechteck und einem Titel „StartZone“
oder „DropZone“. In beiden Studien dient er als Zielfenster und muss am Ende einer
erfolgreichen Navigation auf dem Tablet des Benutzers vollständig sichtbar sein. Das
UML-Klassendiagramm des SnapViewPorts wird in Abbildung 46 gezeigt.
48
Abbildung 48 – Ausschnitt aus der Informationslandschaft des Proxemic ZUI Prototyps. Das rote und grüne
Rechteck sind SnapViewPorts, zu welchen der Benutzer mit seinem Viewport navigieren muss.
RemoteViewPort
Das letzte UserControl ist der RemoteViewPort in der Shared View, welcher die Größe
und Position des aktuellen Viewports eines Benutzers innerhalb des ZUIs zeigt. Ähnlich
dem SnapViewPort besteht die visuelle Repräsentation des RemoteViewPort aus einem
Rechteck mit einem farblich hervorgehobenen Rand und einem Titel. Der Titel wird
durch den Versuchsleiter bestimmt und ordnet neben der Farbe den RemoteViewPort
eindeutig einem Benutzer zu.
Zur Erstellung und dynamischen Anpassung des RemoteViewPorts müssen die Eigenschaften des Displays eines verbundenen Tablet-PCs beachtet werden. Eine höhere
Auflösung des Displays resultiert z.B. bei gleicher Navigation, im Vergleich zu einem
Tablet mit geringerer Auflösung, immer in einem größeren Viewport. Ebenso muss die
Aspectratio (Seitenverhältnis) berücksichtigt werden, da der angezeigte RemoteViewPort ansonsten nicht mit den Seitenverhältnissen des tatsächlichen Viewports auf
dem mobilen Display übereinstimmt. Alle weiteren Eigenschaften können dem UMLKlassendiagramm in Abbildung 46 entnommen werden.
5.3 Shared View
In diesem Kapitel wird das Projekt Shared View beschrieben, welches Klassen und Funktionen zur Konfiguration und Steuerung der Shared View beinhaltet. Im gesamten Projekt ist die Shared View der zentrale Baustein, an welchem alle Daten zusammen kommen. Neben der Verarbeitung der Daten des Proximity Servers, verwaltet die Shared
View die RemoteViewPorts und dient als Server für die Tablet-PCs. Die Shared View ist
in drei Layer unterteilt (siehe Abbildung 49). Die Basis bildet der Layer zur Kommunikation und Verwaltung der Daten. In der zweiten Schicht befindet sich die ZOIL Landschaft
inklusive der MemoryPlayCards und SnapViewPorts. In der obersten Schicht liegen
RemoteViewPorts.
49
Abbildung 49 – Aufteilung der Shared View in drei Layer: Communication Layer, ZOIL Landscape und RemoteViewPorts.
5.3.1 Konfiguration
Die Eigenschaften der drei Layer werden über die Application Settings der Shared View,
das „SpaceCalibrationTool“ und den „SharedViewController“ konfiguriert.
In den Application Settings werden Standardeinstellungen zur Kommunikation mit dem
ZOIL Data-Backend (z.B. Server-Name, IP-Adresse und Port) und dem CommunicationServer gespeichert. Der CommunicationServer nimmt alle Anfragen der Remote Views
(Tablet-PCs) entgegen und leitet diese an die entsprechenden Klassen weiter. Zuletzt
wird in den Application Settings die Größe der Informationslandschaft definiert. Alle
weiteren Eigenschaften werden zur Laufzeit über die zwei folgenden UserControls verändert:
SpaceCalibrationTool
Das SpaceCalibrationTool (siehe Abbildung 50) ist über den Short-Key C (für Calibration) verfügbar. Mit diesem Tool wird der Raum vor den Cube-Displays kalibriert, um aus
realen Koordinaten ZUI-Koordinaten zu berechnen. In unserem ZUI existieren drei Dimensionen. Neben dem Panning in x- und y-Richtung ist Zooming durch die Veränderung des Scale-Faktors möglich, ähnlich einer Bewegung auf der z-Achse. Hierzu muss
im realen Raum je Achse ein minimaler und maximaler Wert bestimmt werden, welcher
den minimalen und maximalen Koordinaten und Scale-Faktoren in der zoombaren Informationslandschaft entspricht. Eine Skizze innerhalb des SpaceCalibrationTools zeigt,
wie der Raum definiert ist, um diese Koordinaten bestimmen zu können (siehe Abbildung 50). Der Reihe nach werden die Positionen im Raum mit Hilfe des Trackables „MagicWand“ (siehe Kapitel 4.3.6) markiert und über den jeweiligen Button (z.B. Capture
X1) festgehalten. Abschließend müssen die Daten über den grünen Button bestätigt
werden. Der SpaceCalibrationManager speichert die Konfiguration in den Application
Settings und lädt diese beim nächsten Start der Anwendung. Eine erneute Kalibration ist
nicht notwendig, sofern der Versuchsaufbau oder die Application Settings nicht manuell
geändert wurden.
50
Abbildung 50 – Das SpaceCalibrationControl wird zur Kalibrierung der Informationslandschaft verwendet.
SharedViewController
Mit Hilfe des SharedViewControllers (siehe Abbildung 51) erhält der Versuchsleiter
Zugriff auf die verschiedenen Navigationstechniken und Versuchseinstellungen. Der
Controller wird über den Short-Key S (für Settings) aufgerufen und steht wie das SpaceCalibrationTool ausschließlich dem Versuchsleiter zur Verfügung. Über ihn ist es möglich die Navigationstechnik zur Laufzeit zu ändern ohne die Anwendung neu starten zu
müssen. Des Weiteren werden über diesen Controller die beiden Studien gestartet und
gestoppt.
Abbildung 51 – Über den SharedViewController wird die Navigationstechnik ausgewählt und die Studie
gestartet.
5.3.2 Kommunikation
Der Communication Layer der Shared View ist in drei Bereiche aufgeteilt. Die Kommunikation zwischen Shared View und Proximity Server, zwischen Shared View und Remote Views und zwischen Shared View und ZOIL Databackend. Letzteres ist nicht Bestandteil der Projektarbeit und wird daher nicht näher erläutert.
Die Kommunikation mit dem Proximity Server ist entsprechend der Beschreibung in
Kapitel 4.4 aufgebaut. In diesem Abschnitt wird daher ausschließlich der Prozess zur
Verarbeitung der eingehenden Daten des Proximity Servers beschrieben.
51
Alle Daten des Proximity Servers stehen über die jeweiligen Events zur Verfügung (siehe
Kapitel 4.4). Diese werden von dem MainWindow direkt an den ViewPortManager weitergeleitet, mit der Ausnahme des Presences MagicWand und der Pointing-Events. Die
Updates des MagicWands sind nur für das SpaceCalibrationTool von Bedeutung, da es
ausschließlich zur Kalibrierung der Shared View genutzt wird (siehe Kapitel 5.3.1). Bei
den Pointing-Events müssen die eingehenden Daten erst noch modifiziert werden, um
das natürliche Zittern von Benutzern während der Interaktion zu filtern. Hierzu wird ein
Kalman Filter verwendet, welcher in Kapitel 5.5 näher beschrieben ist.
Der ViewPortManager passt schließlich die RemoteViewPorts anhand der eingehenden
Daten an und sendet die neu berechnete Größe und Koordinate über den CommunicationServer an die Clients (Tablet-PCs).
Alle Clients müssen sich für eine Kommunikation mit der Shared View zuvor beim
CommunicationServer registrieren.
Die Registrierung der Clients erfolgt in zwei Schritten. Im ersten Schritt sucht der Client
über die Methode „Discover“ nach dem Server. Ist der Server gefunden, ist die grundlegende Verbindung zur Kommunikation aufgebaut. Im zweiten Schritt sendet der Client
weitere Daten, welche für das Erstellen und Verwalten eines Viewports benötigt werden. Folgende Informationen sind in diesen Daten enthalten:





ClientName: Wird als ID (Referenz) in der Shared View gespeichert und für das Senden von OSC-Nachrichten benötigt, z. B. „Samsung Iconia“.
PresenceMaster: Name des Presences, mit welchem die Position und Blickrichtung
des Benutzers oder Tablets ermittelt wird, z. B. „Tablet 1“ oder „User 1“.
PresenceSlave: Name eines zweiten Presences (Hand), welches neben dem PresenceMaster zur Interaktion genutzt wird, z. B. „Hand“.
ScreenWidth und ScreenHeight: Auflösung des Displays, z. B. „1280 x 800“.
Port: Wird für das Senden von OSC-Nachrichten benötigt, z. B. „4449“.
Der Server gibt diese Daten über das MainWindow an den ViewPortManager weiter,
welcher einen neuen RemoteViewPort erzeugt. Als Antwort erhält der Client vom CommunicationServer Informationen zur Größe der Informationslandschaft und ist für die
Navigation bereit.
5.3.3 ViewPortManager
Im obersten Layer werden die RemoteViewPorts dargestellt. Zur Verwaltung und Manipulation dieser UserControls wird der ViewPortManager verwendet. Innerhalb des
ViewPortManagers existieren zwei Möglichkeiten um RemoteViewPorts zu verändern:
Über die Methode UpdateViewPort werden Presences wie z.B. die Basecap (siehe Kapitel
3.4) übergeben. Ab diesem Zeitpunkt wird ein kleiner Entscheidungsbaum durchlaufen
welcher die eingehenden Werte den Eigenschaften des betreffenden RemoteViewPorts
zuweist. Hierzu gehört die Überprüfung der Sichtbarkeit des Presences, der aktuell
ausgewählte Navigationstechnik und ob es sich bei dem Presence um ein Master- oder
Slave-Presence handelt. Ein Master-Presence beschreibt in diesem Projekt eine Basecap
(bzw. den Benutzer) oder ein Tablet-PC, hingegen das Slave-Presence die Hand des
Benutzers definiert. Abschließend berechnet der ViewPortManager die Koordinaten und
52
Größe des RemoteViewPorts in Abhängigkeit seiner Eigenschaften (siehe Kapitel 5.2)
und der Kalibrierung des Raums (siehe Kapitel 5.3.1).
Neben der Methode UpdateViewPort ist es ebenso möglich den RemoteViewPort direkt
zu manipulieren, ohne seine Werte intern berechnen zu lassen. Hierzu stehen folgende
Methoden zur Verfügung:




ChangeViewPortXPosition()
ChangeViewPortYPosition()
ChangeViewPortWidth()
ChangeViewPortHeight()
Diese Methoden werden in beiden Studien während der Vergleichsbedingung (Multi)Touch als Eingabemodalität benötigt. Die Koordinaten und Größe des Viewports erhält
der ViewPortManager aus dem ZOIL Framework. Während der Interaktion auf dem
Tablet-PC werden diese stetig aktualisiert und über den CommunicationClient des Tablet-PCs and den CommunicationServer der Shared View gesendet.
Bei den Pointing-Navigationstechniken HeadDP und HeadDVP (siehe Kapitel 5.1) müssen die Displaykoordinaten ebenfalls nicht mehr berechnet werden, da diese Aufgabe
der Proximity Server übernimmt.
Unabhängig von der Art der Manipulation durchlaufen alle übergebenen oder berechneten Ergebnisse verschiedene Tests welche verhindern, dass ein RemoteViewPort außerhalb der Informationslandschaft bewegt wird. Über das Property „BoundariesActive“ in
den Application Settings der Shared View ist es möglich diese Restriktion zu deaktivieren.
Abschließend werden die neuen Werte an den RemoteViewPort übergeben und über
den CommunicationServer an die Tablet-PCs versandt. Dabei werden nur Tablets berücksichtig, welche nicht die Eingabemodalität (Multi-)Touch aktiviert haben. Alle anderen empfangen die Position und Größe ihres Viewports und passen ihre Ansicht entsprechend an.
5.4 Remote View
Neben der Shared View für die Cube-Displays ist die Remote View für die mobilen Geräte entwickelt. Sie zeigt dem Benutzer seinen aktuellen Viewport in der Informationslandschaft an und bietet zusätzliche Funktionen über ein Head-Up-Display (HUD).
5.4.1 Kommunikation
Die Kommunikation mit der Shared View wird über die Klasse CommunicationClient
geregelt. Wie in Kapitel 5.3.2 beschrieben muss sich jeder Client mit seinen Daten bei
der Shared View registrieren. Der CommunicationClient bietet nach erfolgreicher Verbindung eine Auswahl an Methoden an, um Kommandos an die Shared View zu senden.
Die für die beiden Studien wichtigen Kommandos (bzw. Methoden) sind:


SendStopProxemicNavigation: Mit diesem Kommando wird die Navigation auf
die Eingabemodalität (Multi-)Touch des mobilen Gerät geändert.
SendStartProxemicNavigation: Diese Methode ändert die Navigation von (Multi)Touch auf Bewegung im Raum.
53


SendViewPortChangedMessage: Während der Navigation über das Touch-Display
auf dem Tablet-PC, müssen die Daten zur Position und Größe des Viewports an
die Shared View gesendet werden, um den zugehörigen RemoteViewPort anzupassen. Das Kommando erwartet ein Objekt des Typs Rect (Rechteck), welches
die aktuelle Größe und Position enthält.
SendAcceptTarget: In der Performance-Studie müssen die Benutzer die jeweiligen Targets selbst bestätigen, um wieder zum StartTarget oder einem neuen Target navigieren zu können. Hierzu wird das Kommando SendAcceptTarget verwendet.
Des Weiteren erhält der Tablet-PC über den CommunicationClient Anweisungen von der
Shared View zum Starten und Stoppen der Studien.
5.4.2 Head-Up-Display
Ein Auswahl der in Kapitel 5.4.1 beschrieben Kommandos stehen zu Testzwecken oder
während der Studie über ein Head-Up-Display (HUD) zur Verfügung (siehe Abbildung
52). Das HUD besteht aus mehreren variablen Bausteinen und wird im XAML-Code
definiert.
Abbildung 52 – Beispiel zu Aufbau und Positionierung von HUDControls links und rechts in der Remote View
über der Informationslandschaft.
Als erstes wird ein Container-Element (HUDControl) erstellt, welches mehrere Funktionsblöcke (FunctionControls) aufnehmen kann. Je nach Anforderung wird es an einer
der vier möglichen Kanten des Displays positioniert.
<HUD:HUDControl x:Name="HUDControl" HorizontalAlignment="Right" VerticalAlignment=
"Stretch" Orientation="Vertical">
<HUD:HUDControl />
54
Ein FunctionControl beschreibt Funktionen, welche in einer Gruppe zusammengefasst
werden können, wie z.B. der Funktionsgruppe „Drag and Drop“ oder „Viewport“ (siehe
Abbildung 52).
<HUD:HUDControl x:Name="HUDControl" HorizontalAlignment="Right" VerticalAlignment=
"Stretch" Orientation="Vertical">
<HUD:HUDControl.FunctionControls>
<HUD:FunctionControl ControlName="Viewport" OrientationOfControl="Vertical">
</HUD:FunctionControl>
</HUD:HUDControl.FunctionControls>
<HUD:HUDControl />
Innerhalb eines FunctionControls werden schließlich die einzelnen Funktionen (FunctionButtons) definiert. Für das Beispiel oben sind das z.B. die Freeze-Function, um den
Viewport einzufrieren oder eine Share-Function, um den Viewport mit einer anderen
Person zu teilen. Jede Funktion ist visuell über einen dunkelgrauen Button innerhalb des
HUDs verfügbar und hat eine Eigenschaft IsToogleButton. Diese legt fest, ob der Button
für die Dauer der Aktion gedrückt werden muss oder ob ein Klick auf den Button die
Aktion auslöst und durch einen erneuten Klick wieder deaktiviert wird. Diese Eigenschaft wird nicht für alle Funktionen benötigt wie z.B. die Bestätigung einer Aufgabe
über den Button „Accept Target“.
<HUD:HUDControl x:Name="HUDControl" HorizontalAlignment="Right" VerticalAlignment=
"Stretch" Orientation="Vertical">
<HUD:HUDControl.FunctionControls>
<HUD:FunctionControl ControlName="Viewport" OrientationOfControl="Vertical">
<HUD:FunctionControl.FButtons>
<HUD:FunctionButton ButtonText="Freeze" IsToggleButton="True" Click="FreezeClick"
/>
<HUD:FunctionButton ButtonText="Share" IsToggleButton="True" Click="ShareClick" />
</HUD:FunctionControl.FButtons>
</HUD:FunctionControl>
</HUD:HUDControl.FunctionControls>
<HUD:HUDControl />
Das HUD für die Performance-Studie enthält nur eine Funktion um die aktuelle Aufgabe
zu bestätigen (siehe Abbildung 53). Zur Erhöhung der Treffsicherheit während der
Navigation, wird diese Funktion über zwei Buttons links und rechts am Rand des Displays zur Verfügung gestellt, welche auf die Länge der Displaykante vergrößert sind. Für
die Gedächtnis-Studie wird kein HUD benötigt.
55
Abbildung 53 – Beispiel für den Aufbau eines HUD-Displays zur Erhöhung der Treffsicherheit der Buttons
„Accept Task“.
5.5 Kalman Filter
Zur Korrektur des Zitterns bei den Navigationstechniken HDP und HDVP (siehe Kapitel
5.1) wird ein Kalman Filter aus dem OpenCV Framework verwendet. Im Gegensatz zu
dem Kalman Filter aus den Tracking Tools stellt der OpenCV Filter drei Variablen zur
Konfiguration bereit. Diese ermöglichen eine genauere Kalibrierung und mehr Kontrolle
über den Filter.
Zu den Variablen gehören die Process Noise, die Measurement Noise und die Strength
Matrix. Je höher die Process Noise oder Measurement Noise eingestellt werden, desto
resistenter wird der Kalman Filter gegenüber dem Zittern des Kopfes.
Die Process Noise wirkt sich speziell auf das Rauschen während der Bewegungen aus
und ist in Abhängigkeit von der Geschwindigkeit der Bewegung einzustellen. Bei langsamer Bewegung empfiehlt sich ein weniger starker Wert für die Process Noise, hingegen bei schneller Bewegung ein höherer Wert gewählt werden muss.
Die Measurement Noise wird stattdessen in Relation zur Distanz des Benutzers zum
Display eingestellt. Bei größerer Entfernung verstärkt sich das Rauschen und der Wert
für die Measurement Noise muss erhöht werden. Bei geringerer Distanz und weniger
Rauschen wir der Wert wieder nach unten korrigiert.
Es bedarf einiger Versuche um herauszufinden wie die Werte eingestellt werden müssen. In diesem Projekt haben wir folgende erfolgreiche Einstellungen empirisch ermittelt:



Strength Matrix: 0.6f
Process Noise: 1.0e-2
Measurement Noise: 1.0e-1
56
Das Projekt Kalman Filter stellt zwei Konstruktoren zur Verfügung. Der parameterlose
Konstruktor wendet automatisch die oben stehenden Werte an. Im zweiten Konstruktor
ist es möglich eigene Werte zu übergeben.
Nach dem der Kalman Filter initialisiert ist stehen zwei Methoden für die Neuberechnung der Punkt-Koordinaten zur Verfügung. Die erste Methode GetPredictedPoint() gibt
einen Punkt zurück, welchen der Kalman Filter als nächste mögliche Koordinate vorhersagt.
Die zweite Methode GetEstimatedPoint() gibt eine korrigierte Koordinate zurück, an
welcher sich der Punkt „schätzungsweise“ befinden sollte. Auch hier empfehlen sich
mehrere Tests um die geeignete Methode für die jeweilige Anwendung zu bestimmen.
In diesem Projekt wird die Methode GetEstimatedPoint() verwendet.
57
6 Zusammenfassung und Ausblick
In diesem Projektbericht wurden die verschiedenen Teilprojekte zur Entwicklung des
Proxemic ZUI Prototyps beschrieben und dokumentiert. Hierzu zählen als Erstes der
Aufbau und die Kalibrierung des Tracking Systems, die Konfiguration der Software
Tracking Tools und die Beschreibung der damit zusammenhängenden technischen
Komponenten. Im zweiten Teil wurden die Konfiguration und Verwendung des Proximity Toolkits, die damit zusammenhängende Entwicklung des OptiTrackInputModule und
der Einsatz und die Konfiguration des Proximity Servers erläutert. Abschließend wurde
der Aufbau und die Funktionalität des eigentlichen Proxemic ZUI Prototyps zur Untersuchung der Forschungsfragen vorgestellt.
Das Ziel des Proxemic ZUI Prototypen war die Entwicklung neuer Navigationstechniken
für Zoomable User Interfaces und ist mit diesem Projektbericht abgeschlossen. Die ausgewählte Technik Device Directed Panning wird im Anschluss an den Projektbericht der
konventionellen Eingabemodalität (Multi-)Touch in einer Studie gegenübergestellt. Das
Ziel der Studie ist die Beantwortung folgender Forschungsfragen:
Unterstützt eine Navigationstechnik basierend auf den Proxemic Interactions im Vergleich
zu einer multi-touch Eingabe das räumliche Gedächtnis in ZUIs besser?
Ist die Leistung (zurückgelegter Weg und Zeit) der Navigationstechnik basierend auf den
Proxemic Interactions im Vergleich zur multi-touch Eingabemethode in ZUIs besser?
Der Aufbau dieser Studie basiert auf einer vorausgehenden Studie von Jetter et al. [H.-C.
Jetter et al. 2012]. Die hierzu notwendigen Anpassungen und Ergänzungen des Proxemic
ZUI Prototyps sowie die Beschreibung des Studien-Designs sind Bestandteil der nachfolgenden Masterarbeit. Zu den Anpassungen zählen die Implementationen der Aufgabenstellungen und die automatisierte Erstellung eines Protokolls (Logs). Das Log des Prototyps wird während der Studie anfallende Informationen protokollieren, die später zur
Bewertung der Navigationstechniken verwendet werden (wie z. B. die benötige Zeit zur
Lösung einer Aufgabe oder die Genauigkeit des Resultats einer gelösten Aufgabe).
Dem Projektbericht liegt zusätzlich eine CD bei, welche alle in diesem Bericht referenzierten Dokumente der Firma Natural Point sowie die Software Tracking Tools und das
NatNet SDK enthält. Darüber hinaus sind weitere Materialien enthalten, die für diesen
Projektbericht nicht zwingend notwendig waren, aber möglicherweise in Zukunft beim
Umgang mit dem System von Bedeutung sein können.
58
7 Literaturverzeichnis
BALLENDAT, T., MARQUARDT, N. AND GREENBERG, S., 2010. Proxemic interaction: designing
for a proximity and orientation-aware environment. In ITS ’10 ACM International Conference on Interactive Tabletops and Surfaces. New York, NY, USA: ACM, pp. 121–
130.
JACOB, R.J.K. ET AL., 2008. Reality-based interaction. In CHI ’08 Proceeding of the twentysixth annual CHI conference on Human factors in computing systems. New York, NY,
USA: ACM, pp. 201–210.
JETTER, H., 2012. Design and Implementation of Post-WIMP Interactive Spaces with the
ZOIL Paradigm. University of Konstanz.
JETTER, H.-C., LEIFERT, S., GERKEN, J., SCHUBERT, S. AND REITERER, H., 2012. Does (multi)touch aid users’ spatial memory and navigation in “panning” and in “zooming & panning” UIs? In AVI ’12 Proceedings of the International Working Conference on Advanced Visual Interfaces. New York, NY, USA: ACM Press, p. 83.
MARQUARDT, N., DIAZ-MARINO, R. AND BORING, S., 2011. The proximity toolkit: prototyping
proxemic interactions in ubiquitous computing ecologies. In UIST ’11 Proceedings of
the 24th annual ACM symposium on User interface software and technology. New York,
NY, USA: ACM, pp. 315–326.
NACENTA, M., GUTWIN, C., ALIAKSEYEU, D. AND SUBRAMANIAN, S., 2009. There and Back
Again: Cross-Display Object Movement in Multi-Display Environments. HumanComputer Interaction, 24(1), pp.170–229.
RÄDLE, R., WEILER, A., ET AL., 2012. eBook meets tabletop. In Proceedings of the fifth ACM
workshop on Research advances in large digital book repositories and complementary
media - BooksOnline ’12. New York, NY, USA: ACM Press, pp. 3–6.
RÄDLE, R., JETTER, H. AND REITERER, H., 2012. TwisterSearch : Supporting Social Search
with Tabletop and Mobile Displays. In H. Reiterer & O. Deussen, eds. Mensch und
Computer 2012 Workshopband: interaktiv informiert. München: Oldenbourg Verlag, pp.
509–512.
SPINDLER, M., STELLMACH, S. AND DACHSELT, R., 2009. PaperLens: advanced magic lens
interaction above the tabletop. In ITS ’09 Proceedings of the ACM International Conference on Interactive Tabletops and Surfaces. New York, NY, USA: ACM Press, pp. 69–
76.
WEISER, M., 1999. The computer for the 21 st century. ACM SIGMOBILE Mobile Computing
and Communications Review, 3(3), pp.3–11.
59