Achtung:

Sie haben Javascript deaktiviert!
Sie haben versucht eine Funktion zu nutzen, die nur mit Javascript möglich ist. Um sämtliche Funktionalitäten unserer Internetseite zu nutzen, aktivieren Sie bitte Javascript in Ihrem Browser.

Medizinische Bildverarbeitung Bildinformationen anzeigen

Medizinische Bildverarbeitung

Interaktives Arbeiten in Augmented Reality

Abbildung 1
Abbildung 2: ARGlove
Abbildung 3: AR Baukasten mit Datenhandschuh
Abbildung 4: AR Baukasten mit Paddle und Maus

Diplomarbeit von Benedikt Redmer

Motivation

Nachdem sich in den letzten Jahrzehnten gleich mehrere Technologien zur Darstellung von virtuellen Objekten etabliert haben, existiert heute eine große Anzahl unterschiedlicher Virtual Reality (VR) und Augmented Reality (AR) Anwendungen. Diese Systeme, die durch eine vollständige Ersetzung oder ein teilweises erweitern die optische Wahrnehmung des Benutzers manipulieren, erzeugen eine hochgradig immersive Arbeitsumgebung in der die Interaktion mit klassischer Hardware wie Maus, Tastatur und Bildschirm wenig sinnvoll geworden ist. Der Einsatz spezieller Ein- und Ausgabegeräte, sowie Ihnen eigener Interaktionstechniken ist unumgänglich geworden. Dabei existieren neben relativ weit verbreiteten Geräten wie Datenhandschuh und Head-Mounted Displays (HMDs) auch eine vielzahl weiterer Geräte mit ähnlichen (z.B. 3D-Maus) oder aber auch mit den für den jeweiligen Anwendungsfall spezialisierten Eigenschaften (z.B. HeadSet für Spracheingabe).

Während Softwarentwickler von AR/VR Systemen heutzutage bereits durch eine beachtliche Anzahl qualitativ hochwertiger Bibliotheken und APIs für die Darstellung von 3D-Grafik unterstützt werden, bedeutet es immer noch einen hohen Implementierungsaufwand die unterschiedliche Hardwareausstattung des Benutzers bei den Ein- und Ausgabegeräten zu berücksichtigen. Dieses Problem wird vor allem noch dadurch verschärft, dass im AR/VR Bereich sehr häufig spezielle Hardware-Eigenkostruktionen auf der Basis kommerziell vertriebener Eingabegeräte eingesetzt werden.

Aufgabenstellung

Entwicklung eines Konzeptes für den hardwareunabhängigen Zugriff auf speziell im AR/VR Systemen eingesetzte Eingabegeräte.
Neben der Unterstützung handelsüblicher Eingabegeräte soll die Möglickeit vorgesehen werden spezielle Hardwarekonstruktionen sowie die Ihnen zugrundeliegenden Eigenschaften im Konzept direkt abzubilden zu können. Auch für diese als "abstrakt" bezeichneten Eingabegeräte soll der einheitliche Datenzugriff gewährleistet bleiben.

Ziel der Arbeit

Implementierung einer Programmierbibliothek (API) für den geräteunabhängigen Zugriff auf unterschiedliche AR/VR Hardware. Die Hauptanforderungen dafür sind:

Einfache Anwendung

Die Einbindung verschiedenster Eingabegeräte soll für Softwarentwickler möglichst einfach gestalltet werden. Insbesondere soll der programmiertechnische Overhead für die Initialisierung der Geräte oder die Abfrage von Geräteereignissen (Klicks, Positionsangaben) gering gehalten werden.

Erweiterbarkeit

Da für AR-Anwendungen immmer neue Geräte konzipiert werden, soll die Bibliothek auf einfache Art und Weise erweitert werden können. Des Weiteren soll sich die API in bereits bestehende Anwendungen soll es ohne größere Änderungen integrieren lassen können.

Abstraktion

Da nicht immer gewährleistet werden kann, dass alle Eingabegeräte auf allen Systemen zur Verfügung stehen soll es möglich sein einzelne Geräte durch andere zu simulieren. Unterschiedliche Datentypen (Position, Rotation, Fingerkrümmung, ...) sollen in einer Datenstruktur zusammengefasst werden um einen einheitlichen Datenzugriff zu gewährleisten.Geschwindigkeit ist für viele Anwendungen ein entscheidender Faktor. Da ein hohes Maß an Abstraktion aber auch immer mit Geschwindigkeitseinbussen einhergeht sollte es für den Programmierer möglich sein den Abstraktionsgrad frei zu wählen.

Realisierung

Die Augmented Reality Input Device Abstraction (ARIDA) Bibliothek abstrahiert die reale Hardware durch das bereits bekannte Konzept der virtuellen Eingabegeräte, (in ARIDA als DeviceDriver bezeichnet). Dabei werden sowohl der Low-Level Hardware Treiber als auch die zur Verfügung gestellten Gerätedaten gekapselt. Datenstrukturen wie Int- oder Boolvektoren werden benutzt um den einheitlichen Datenzugriff sicherzustellen. Des Weiteren ist es für die weitere Verarbeitung der Gerätedaten möglich zusätzliche Informationen wie Zeitstempel oder Verlässlichkeitsangaben hinzuzufügen.

Alle von DeviceDriver gesammelten Daten werden in einer zentralen Datenstruktur namens InputDevice verwaltet. Diese realisiert eine höhere Abstraktionsstufe in der Geräteaktionen erkannt werden können. Dazu wird eine Liste sogenannter Detetoren geführt, die auf bestimmte Aktionen reagieren und bei eintreten ein entsprechendes Event generieren. Dies kann z.B. ein einfacher Klick sein oder aber auch die Erkennung einer Geste (vom Datenhandschuh oder Maus). Da alle DeviceDriver Daten geräteunabhängig sind, können die Detektoren universell eingesetzt werden. Für die Erkennung von Gesten eines Datenhanschuhs und einer Maus kann so z.B. der gleiche Detektor eingesetzt werden. Des Weiteren können Detektoren verschachtelt werden um komplexe Aktionen zu erkennen. Ein Detektor für die Erkennung einer Geste kann z.B. mit einem Detecktor zur Erkennung eines Klicks kombiniert werden. Damit läßt sich erkennen ob eine Geste z.B. mit geschlossener Hand oder gedrückter Tastaturtaste ausgeführt wurde. Das große Potential des Detektorenkonzeptes macht es relativ einfach auch sonst komplexe Aufgabenstellungen einfach zu lösen. Das doppeltes Tracking eines Datenhandschuhs zur Verbesserung der Zuverlässigkeit kann so ganz einfach über einen Detektor der die beiden Datenströme vom optischen und elektromagnetischen Sensor anhand eines Zuverlässigkeitswertes mittelt sehr einfach implementiert werden.

ARIDA puffert intern die Daten- und Eventströme. Damit lassen sich auch zeitlich abhängige Ereignisse (Gesten, Bewegungen) detektieren. Andererseits können Gerätedaten auch direkt vom DevieDriver abgefragt werden. Damit wird auch ein performanterer Zugriff via Polling auf die Eingabegeräte realisiert. Insgesamt bietet ARIDA also die drei Zugriffsarten: direkt über InputDevice, indirekt über den Zugriff auf den Datenpuffer und eventbasiert.
Im Rahmen dieser Arbeit wurden für ARIDA die Unterstützung für die Geräte Maus, Tastatur, ARToolkit-Paddle und Datenhandschuh implementiert. Anhand einer kleinen eigenen Anwendung (ARGlove) sowie der Integration in eine bestehende AR Projekt (AR-Baukasten) würde die Tragfähigkeit des Konzeptes überprüft.

Links

ARToolKit

Für weitere Informationen bitte E-Mail an ben@redmer.net

Die Universität der Informationsgesellschaft