Iterative Entwicklung einer AR-Anwendung mittels Round-trip Engineering

Transkript

1 Fakultät für Mathematik und Informatik Institut für Informatik Bernhard-von-Cotta-Str Freiberg Bakkalaureatarbeit Iterative Entwicklung einer AR-Anwendung mittels Round-trip Engineering Robert Schneider Angewandte Informatik Vertiefung: Technik Matrikel: Wintersemester 2012/13 Betreuer/1. Korrektor: Prof. Bernhard Jung 2. Korrektor: Matthias Lenk

2 Eidesstattliche Erklärung Ich versichere, dass ich diese Arbeit selbständig verfasst und keine anderen Hilfsmittel als die angegebenen benutzt habe. Die Stellen der Arbeit, die anderen Werken dem Wortlaut oder dem Sinn nach entnommen sind, habe ich in jedem einzelnen Fall unter Angabe der Quelle als Entlehnung kenntlich gemacht. Diese Versicherung bezieht sich auch auf die bildlichen Darstellungen. Wintersemester 2012/13 Robert Schneider

3 Inhaltsverzeichnis 3 Inhaltsverzeichnis Abkürzungsverzeichnis 5 Abbildungsverzeichnis 6 1 Einleitung Aufbau der Arbeit Augmented Reality Definition Anwendungsgebiete Medizin Montage und Wartung Automobil-Industrie Architektur Werbung Unterhaltung Tracking Marker-basiertes Tracking Markerloses Tracking Laufzeitbasiertes Tracking Displays Optical See-Through Display Video See-Through Display Szenengraphen Stand der Technik ARToolkit ARmsk Popcode AndAR MetaIO Vuforia Das Agrajag-Framework Architektur des Agrajag-Frameworks AgrajagActivity AgrajagX3DParser AgrajagSzenegraph AgrajagTracker VuforiaRenderer AgrajagRenderer ARSensorManager AgrajagView Unterstützte Szenengraphknoten Ablauf der Anwendung Implementierung des Agrajag-Frameworks AgrajagActivity AgrajagRenderer

4 Inhaltsverzeichnis AgrajagTracker API des Agrajag-Frameworks MainActivity ARSensorManager AgrajagRenderer AgrajagSceneGraph Roundtrip3D und die Scene Structure and Integration Modelling Language SSIML/AR Vereinfachung von SSIML/AR durch die Nutzung des Agrajag-Frameworks Implementierung einer Beispielanwendung Implementierung mittels des Agrajag-Frameworks Die AndroidManifest.xml Datei Die MainActivity Klasse Die EventHandlerBeispiel Klasse Das 3D-Objekt Implementierung mittels SSIML/AR Die Ssiml Diagram Datei Zusammenfassung 41 8 Anhang Bilder Quellcode Aufbau der beigefügten CD Quellenverzeichnis 47

5 Inhaltsverzeichnis 5 Abkürzungsverzeichnis AR Augmented Reality AV Augmented Virtuality CES Consumer Electronics Show DICE Dynamic and Intuitive Control Experience GPS Global-Positioning-System GUI Graphical User Interface HMD Head Mounted Display HUD Head Up Display MR Mixed Reality NDK Native Development Kit SSIML Scene Structure and Integration Modelling Language X3D Extensible 3D XML Extensible Markup Language

6 Abbildungsverzeichnis 6 Abbildungsverzeichnis 0 Modell-gesteuerter Entwicklungsprozess mittels Round-trip Engineering [1] Mixed Reality AR in der Medizin AR in der Automobil-Industrie AR in der Innenarchitektur Reflektierender Marker Marker mit Muster Kantenbasiertes Tracking[12] Wikitude [15] See-Through Display [3] Video See-Through Displays [3] Szenengraph Marker des ARToolkit Popcode-Marker Vuforia Marker Komponenten des Frameworks Frame Marker Ablauf Agrajag SSIML Beispiel[23] Beispiel einer Scene Structure and Integration Modelling Language (SSIML)/AR Anwendung Blender das Bett der Schrank Das SSIML Diagramm Augmented Reality in der Werbung AR in der Sesamstraße Damoklesschert [27]

7 1 Einleitung 7 1 Einleitung Augmented Reality Anwendungen werden in der heutigen Zeit durch die rasante Entwicklung des Smartphone- und Tablet-Marktes immer beliebter. Sie werden für Werbung, Medizin oder Spiele genutzt und sind Gegenstand zahlreicher Forschungsprojekte. Die Entwicklung einer solchen Anwendung ist allerdings komplex und zeitaufwändig. Es müssen 3D-Objekte modelliert, Interaktionen zwischen ihnen geplant und Quellcode für die Anwendung geschrieben werden. Da diese Aufgaben meist nicht von einem einzelnen Entwickler durchgeführt werden kann es zu Inkonsistenzen zwischen den einzelnen Modulen kommen. Um diese Inkonsistenzen zu beseitigen und die Entwicklung von Anwendungen zu vereinfachen beschäftigt sich das Roundtrip3D Projekt des Instituts für Informatik an der TU Bergakademie Freiberg damit ein Codegerüst mittels domänenspezifischer Sprachen zu generieren. Die Entwicklung von AR- und VR-Anwendungen findet dabei wie in Abb. 0 dargestellt statt: Basierend auf einem domänenspezifischen Modell Codegerüste (3D-Modell und Anwendungslogik) generiert. Diese werden an die jeweiligen Entwicklergruppen (3D-Designer und Programmierer) herausgegeben, die nun unabhängig voneinander mit den Werkzeugen ihrer Wahl (z.b. Blender zur 3D-Modellierung und Eclipse zur Programmierung) den Code vervollständigen können. Nach dieser Implementierungsphase kann der Code der jeweiligen Entwicklergruppen Inkonsistenzen beinhalten. Beispielsweise können Umbenennungen von Objekten des 3D-Modells dazu führen, dass Zugriffe aus dem Programmcode auf eben diese Modelle nicht mehr möglich sind. Daher werden in einem nächsten Schritt die weiterentwickelten Codegerüste synchronisiert. Aus dieser konsistenten Basis wird wieder ein domänenspezifisches Modell abgeleitet, welches zusätzliche Änderungen ermöglicht. Die erneute Codegenerierung aus diesem Modell stellt sicher dass sämtliche Änderungen aus den letzten Entwicklungsphasen im jeweiligen Code (3D-Modell und Anwendungslogik) enthalten sind und Inkonsistenzen beseitigt wurden. Um diesen iterativen Entwicklungsprozess zu unterstützen soll in dieser Arbeit eine Struktur für das zu generierende Codegerüst der AR-Anwendung entwickelt werden. Dieses Gerüst soll dabei übersichtlich und high-levelig sein um den Programmieraufwand zu reduzieren. Zusätzlich soll sich das Codegerüst an Entwurfsmuster aus bereits existierenden VR-Anwendungen anderer Plattformen des Roundtrip3D Projektes anlehnen bzw. diese Muster geeignet erweitern, um die Codegenerierung zu vereinheitlichen [1]. Das AR-Framework, auf dem die spätere Anwendung bassiert, dient dabei als Adapter zwischen Anwendungscode und einem low-level AR-Framework. Daher sollten zunächst vorhandene Augmented Reality Frameworks für das Android Betriebssystem auf ihre Tauglichkeit zur Generierung mittels einer domänenspezifischen Sprache untersucht werden. Aufgrund dieser Erkenntnis soll ein Framework für AR-Anwendungen erstellt werden das die genannten Anforderungen erfüllt. Zuletzt soll eine AR-Beispielanwendung mithilfe der Codegenerierung für dieses Framework erstellt werden. 1.1 Aufbau der Arbeit Kapitel 3 beshäftigt sich damit einen allgemeinen Überblick über das Thema Augmented Reality zu geben. Dabei werden Themen wie Anwendungsgebiete und die technische Umsetzung einer Augmented Reality Anwendung angesprochen. Kapitel 3 befasst sich mit aktuell vorhandenen Augmented Reality Frameworks und testet diese auf ihre Benutzbarkeit für die Generierung von Anwendungen mittels domänenspezifischer Sprachen. In Kapitel 4 wird dann das Agrajag- Framework eingeführt und erläutert. Kapitel 5 befasst sich mit der SSIML-Sprachfamilie und ihrer Möglichkeiten zur Generierung von Codegerüsten für eine Iterative Anwendungsentwicklung. In Kapitel 6 wird eine mittels des Agrajag-Frameworks entwickelte Beispielanwendung erläutert. Abschließend wird in Kapitel 7 eine Zusammenfassung über die erreichten Problemlösungen sowie ein Ausblick auf eventuelle Nachfolgearbeiten gegeben.

8 1 Einleitung 8 Modell logik Domänenspezifisches Software- Designer 3D-Inhalt x3d x3d 3D-Modellierer Anwendungs- Webentwickler js js C++ Programmierer cpp cpp Android Programmer java java Abbildung 0: Modell-gesteuerter Entwicklungsprozess mittels Round-trip Engineering [1]

9 2 Augmented Reality 9 2 Augmented Reality 2.1 Definition Augmented Reality (AR) ist ein Teil der Mixed Reality (MR), in der virtuelle und reale Welten vermischt werden. Die MR setzt sich zusammen aus der Augmented Virtuality (AV) und der AR. In der Augmented Virtuality werden Objekte aus der realen Welt in virtuelle Umgebungen hineingebracht. Ein Beispiel wäre ein Virtueller Raum, in den Personen eingeblendet werden. Die Augmented Reality ist in erster Linie eine Anreicherung der realen Welt mit Informationen. Das können Sensorwerte, vorher aufgenommene Daten, oder 3D-Inhalte sein. Eine Klare Abtrennung, wo Augmented Reality aufhört und wo Augmented Virtuality anfängt gibt es allerdings nicht. (Abb. 1) Abbildung 1: Unterteilung der Mixed Reality [2] Es gibt viele verschiedene Quellen, die Augmented Reality definieren. Die am meisten genannte Definiton ist jedoch die von Azuma[3], die folgende 3 Punkte nennt: 1. Kombinieren von virtueller und realer Welt 2. Wechselseitige Beeinflussung in Echtzeit 3. Einblenden von 3D Inhalten Der erste Punkt gibt klar an, dass ein Fall von Mixed Reality vorliegen muss. Es muss also zu einer Vermischung von Objekten der Virtual Reality und Objekten der Realen Welt kommen. Der zweite Punkt schließt Compositing-Techniken (Vermischung von verschiedenen Bildinhalten) aus, die in der Filmindustrie eingesetzt werden. Hier kommt es zwar zur Verschmelzung von virtuellen Objekten mit echt gedrehten Szenen, allerdings fehlt hier die Möglichkeit für den Nutzer interaktiv in diese Verschmelzung einzugreifen. So kann er zum Beispiel nicht die virtuell erzeugten Figuren aus Filmen wie Avatar an eine von ihm bestimmte Position verschieben. Der dritte Punkt hingegen schließt einfache Chroma-Keying Verfahren aus, die zum Beispiel bei Blue- oder Green-Screen Projektionen in Nachrichtensendungen oder Wetterberichten genutzt werden, um ein virtuelles Studio anzuzeigen, oder die Wetterinformationen auf einer Wand abzubilden. In diesen Verfahren werden bestimmte Farben (meist Grün oder Blau) durch virtuell erzeugte Objekte überlagert. Diese Definition zieht klare Grenzen, was Augmented Reality ist und was nicht. Allerdings stützt sie sich nur auf technische Merkmale. Andere Definitionen deklarieren AR als eine Ausweitung der Sinneswahrnehmung des Menschen mittels verschiedener Sensoren, um Umgebungseigenschaften, die ohne diese Sensoren nicht wahrgenommen werden könnten, wahrzunehmen[4].

10 2 Augmented Reality Anwendungsgebiete Augmented Reality wird heutzutage in vielen Gebieten eingesetzt. Zu den populärsten gehören die Medizin, industrielle Anwendungen, die Automobilindustrie sowie die Architektur, die Werbeindustrie und die Spiele- und Entertainment-Branche Medizin Immer mehr werden in der Medizin Operationen durchgeführt, bei denen der Chirurg sich nur noch mittels eines Kamerabildes, das durch eine endoskopisch in den Körper eingeführte Kamera erzeugt wird, orientieren kann. Dieses Video wird auf einem Monitor über, oder neben dem Patienten dargestellt, was eine Belastung des Arztes mit sich führt, da dieser ständig eine zusätzliche Informationsquelle im Raum beobachten muss. Diese Informationen muss er dann mental auf den Patienten übertragen. Ein Ansatz der Augmented Reality ist es, die bei Voruntersuchungen gesammelten Daten, wie Röntgenbilder, MRT- und CT, mit dem zu untersuchenden Körperteil zu überlagern (Abb. 2). Abbildung 2: Augmented Reality in der Medizin [5] Montage und Wartung In der Industrie und Wartung kommen immer mehr Augmented Reality Systeme zum Einsatz. Sie können als Training oder Lernunterstützende Systeme, oder direkt als Hilfssystem bei der Fertigung eingesetzt werden. Die Positionierung von Schweißpunkten, die nur mit einer geringen Toleranz angebracht werden müssen, erfolgte früher mittels eines Messarms. Heutzutage wird der Schweißstand von einem Kamerasystem umgeben und die Schweißpistole getrackt (sh. Unterabschnitt 2.3). Dadurch ist ein viel schnelleres genaues Arbeiten möglich. Auch in der Wartung kommen Augmented Reality Systeme zum Einsatz. Hier wird zum Beispiel anhand von Animationen gezeigt, in welcher Reihenfolge welcher Arbeitsschritt ausgefürt werden muss, um ein bestimmtes Teil auszutauschen Automobil-Industrie In der Automobil-Industrie hat Augmented Reality ein immer größer werdendes Potential. Mercedes- Benz stellte 2012 auf der Consumer Electronics Show (CES) ein System namens Dynamic and Intuitive Control Experience (DICE) vor. Dieses System projiziert Informationen über am Straßenrand befindliche Objekte, wie Restaurants oder Sehenswürdigkeiten, auf die Frontscheibe des Autos. Der Fahrer kann über Gestensteuerung diese Informationen steuern. Dieses Projektions-

11 2 Augmented Reality 11 prinzip wird schon seit vielen Jahren bei Kampfjets eingesetzt, bei dem dem Piloten Informationen über sein Zeil eingeblendet werden. Abbildung 3: Augmented Reality in der Automobil- Industrie [6] Architektur Auch in der Innenarchitektur kann AR eingesetzt werden. Mittels entsprechend großer Marker ist es möglich das Möbelstück schon vor dem Kauf in den Raum zu stellen und zu schauen, ob das Möbelstück in den Raum passt. Abbildung 4: Augmented Reality in der Innenarchitektur [7] Werbung In der Werbung wird immer mehr auf Augmented Reality gesetzt. Mehrere Zeitschriften und Kataloge bieten mittlerweile digitale Versionen ihrer Produkte mittels speziell entwickelter Smartphone- Anwendungen an. (Abb. 24(a)) Lego geht noch einen Schritt weiter. Sie haben ein Gerät entwickelt, das die Inhalte ihrer Spielzeuge auf den Verpackungen als 3D-Modell anzeigt (Abb. 24(b)). Dieser 3D-Kiosk wurde mittels des MetaIO-Framewoks umgesetzt (s. Kapitel 3.5) Unterhaltung Durch die Verbreitung von Smartphones wurden immer mehr AR-Anwendungen entwickelt. Die Auswahl dieser Spiele ist groß. Einfache Moorhuhn-artige Spiele, bei denen man im Zimmer umherfliegende Gegenstände abschießen muss sind nur ein kleiner Teil. Andere Spiele ähneln eher dem Capture-The-Flag Prinzip, wo in der Realen Welt bestimmte Orte aufgesucht und aufgenommen werden wie zum Beispiel Googles Ingress[8]. Auch in Spielen für Kinder ist Augmented Reality sehr beliebt. Die Firma Qualcomm kreierte mittels ihres Vuforia-Frameworks (s. Kapitel

12 2 Augmented Reality ) eine Sesamstraßen Anwendung (Abb. 25). Diese nimmt Spielfiguren aus Plastik auf und erweckt diese auf dem Tablet zum leben. 2.3 Tracking Ein wichtiger Teil der AR ist das Verarbeiten von Sensorinformationen, um die Lage eines Objektes bezüglich der Kamera im Raum zu bestimmen. Dafür gibt es verschiedene Ansätze, wie das Tracken mittels eines Bildverarbeitenden Systemes oder die Positionsbestimmung mittels Global- Positioning-System (GPS)-Satelliten, um das so genannte Tracking zu realisieren Marker-basiertes Tracking Das Marker-basierte Tracking ist eine Form des optischen Trackings. Dabei wird in einem aufgenommenen Bild mittels eines Bildverarbeitungssystems nach Mustern gesucht. Diese Muster (später Marker genannt) werden an dem zu trackenden Gegenstand angebracht. Das Bildverarbeitungssystem kann dann anhand des Markers die Position und Orientierung bezüglich der Kamera im Raum berechnen, und die Informationen an den Renderer weiterreichen. Grundsätzlich zählen Marker mit Mustern und reflektierende Marker zu dem System des Marker-basierten Trackings. Reflektierende Marker Reflektierende Marker haben eine spezielle retroreflektive Beschichtung, die das Licht in die Richtung zurück wirft, aus der es gekommen ist. Diese Beschichtung wird auch auf KFZ-Kennzeichen eingesetzt, damit im Fall einer Geschwindigkeitsmessung diese gut zu erkennen sind. Durch die retroreflektive Eigenschaft kann eine Infrarot-Lichtquelle direkt an den Kameras angebracht werden. Meistens wird für diese Art von Markern ein Gerüst aus Stäben und Kugeln eingesetzt (Abb. 5). Um die Position im Raum zu erkennen müssen mindestens zwei Kameras eingesetzt werden, die an vorher definierten Positionen platziert werden [9]. Die Kameras suchen nach den hellsten Stellen im Bild und können so pro Kamera die X- und Y-Position der Marker bestimmen. Aus den Informationen beider Systeme kann die Position im Raum bestimmt werden. Durch die feste Position der reflektierenden Kugeln zueinander kann durch Abstandsmessung die Rotation bestimmt werden. Dieses System bietet den Vorteil, dass das Tracking unabhängig von der Umgebungsbeleuchtung ist. Allerdings ist die vorherige Kalibrierung des Kamerasystems aufwändig. Verdeckung einer Kamera durch Personen oder durch den Marker selbst (zwei Kugeln hintereinander) führen zu Problemen die Position und die Rotation richtig zu erkennen. Abbildung 5: Reflektierender Marker [10]

13 2 Augmented Reality 13 Marker mit Mustern Marker mit Mustern nutzen ein anderes System zur Erkennung der Lage im Raum. Es sind meist quadratische oder rechteckige Marker ohne Rotationssymmetrien (Abb. 6), also Marker die nicht dasselbe Muster aufweisen, wenn man sie dreht. Für die Bestimmung der Position und der Rotation sucht das Bildverarbeitungssystem nach stark unterschiedlichen Farb-, oder Helligkeitswerten. Aus den gefundenen Kanten werden die Eckpunkte des Musters bestimmt, die Informationen zur Neigung gegenüber der Kamera liefern. Durch das Muster in der Mitte des Markers wird die Rotation erkannt. Hätte der Marker kein Muster im Inneren könnten nur Winkel zwischen 0 und 90 Grad erkannt werden. Der Ursprung des Koordinatensystems liegt bei diesem System direkt bei der Kamera. Dadurch ist es möglich die Trackingdaten ohne größere Probleme einer 3D-Renderengine zu übergeben. Ein großer Nachteil ist, dass der Marker nur in Positonen um 90 Grad gegenüber der Kamera gedreht werden kann, da diese sonst das Muster nicht mehr erkennen kann. Außerdem ist das System sehr empfindlich gegenüber schlechten Beleuchtungsverhältnissen und partielle Verdeckung der Marker. Abbildung 6: Quadratischer Marker ohne Rotationssymmetrien[11] Markerloses Tracking Markerloses Tracking greift nicht wie das Marker-basierte Tracking auf vorgefertigte Muster zurück. Dadurch ist das Markerlose Tracking wesentlich aufwändiger, da das aufgenommene Kamerabild ausreichen muss um eine Lagebestimmung zu erhalten. Dafür gibt es verschiedene Ansätze. Der wohl am meisten verbreitete Ansatz ist das Tracken von Kanten und Ecken. Farbund Kontrastunterschiede können ebenfalls für die Feature-Erkennung, also der Erkennung von bestimmten Mustern oder Kanten im Bild, genutzt werden. Bei dieser Art der Feature-Erkennung werden mittels eines Bildverarbeitungssystems Punkte und Kanten in dem Videostream gesucht. Aus mehreren solcher Punkte kann dann die Position der Kamera relativ zu der Umgebung berechnet werden [12]. Außerdem können Ebenen für die Platzierung des 3D-Objektes ausfindig gemacht werden (Abb. 7). Eine weitere Art des Markerlosen Trackings ist es, 3D-Modelle des zu Trackenden Objektes zu benutzen [13]. Dabei werden Referenzbilder des zu Trackenden Objektes aus verschiedenen Kamerapositionen aufgenommen. Das zu Untersuchende Bild wird dann mit den zuvor generierten Bildern verglichen und daraus die Position abgeleitet. Abbildung 7: Kantenbasiertes Tracking[12]

14 2 Augmented Reality Laufzeitbasiertes Tracking Das Laufzeitbasierte Tracking ist eine Technik, die keine Kamera zur Bilderkennung nutzt, um Muster zu erkennen. Es basiert darauf, dass mehrere Sendequellen zur Positionserkennung genutzt werden. Diese Sendequellen können zum Beispiel GPS-Satelliten sein. Dabei wird die Laufzeit zwischen dem Empfänger und einem Satelliten gemessen. Aus den Laufzeiten die mittels Abfrage von drei Satelliten errechnet werden kann die Position des Empfängers berechnet werden. Ein großes Problem von Tracking mittels GPS-Systemen ist, dass es ungenau ist [3]. Trotzdem wurden verschieden AR-Browser wie Wikitude [14] entwickelt, die mittels GPS-Koordinaten und Bilderkennung Informationen, wie Hotelbewertungen oder Wikipedia-Artikel auf dem Smartphone anzeigen (Abb. 8). Abbildung 8: der "Wikidude Augmented Reality Browser"[15] 2.4 Displays Um Virtuelle Objekte in der Realen Welt anzuzeigen werden Displays benötigt. Dabei gibt es zwei verschiedene Ansätze wie diese realisiert werden können Optical See-Through Display Ein Optical See-Through Display ist eine Methode Virtuelle Objekte in mit der Realen Welt zu verknüpfen. Dabei trägt der Nutzer ein Head Mounted Display (HMD). Dieser Helm beinhaltet ein lichtdurchlässiges Anzeigegerät durch das der Nutzer zwar noch die reale Welt sehen kann, das jedoch Virtuelle Objekte von einem im Helm angebrachten Display reflektiert (Abb. 9). Diese Technik ist ähnlich der in Militärflugzeugen eingesetzten Head Up Display (HUD) [3]. Da die Anzeigegeräte wie ein halbdurchlässiger Spiegel funktionieren, wird das Lichtverhältnis in dem HMD drastisch reduziert [16]. Ein weiterer Nachteil von HMDs ist die Größe und das Gewicht, da alle Module, die für die Anzeige und das Tracken der Kopfbewegung zuständig sind in dem Helm untergebracht werden müssen. So wurde das von Ivan Sutherland 1968 entwickelte HMD [17] als Damoklesschwert bezeichnet, da es so schwer war, das es an der Decke befestigt werden musste (Abb. 26).

15 2 Augmented Reality 15 Abbildung 9: Schema eines Optical See-Through Displays [3] Video See-Through Display Ein Video See-Through Display verwendet anders als ein Optical See-Through Display (sh. Unterabschnitt 2.4.1) Videokameras, um die reale Welt aufzunehmen. Das von der Kamera aufgenommene Bild wird dann mit den virtuellen Objekten vermischt, und auf einen Bildschirm übertragen (Abb. 10(a)). Ein großer Vorteil von Video See-Through Displays ist es, dass das Bild gleichzeitig mit den überlagernden virtuellen Elementen angezeigt wird. Dadurch kommt es zu keinen Verzögerungen zwischen realem Bild und überlagernden Elementen durch die Berechnungsdauer des AR-Systems. Dies hat allerdings den Nachteil, dass die Bewegungen des Nutzers und das angezeigte Bild nicht synchron sind. Ein weiterer Nachteil ist, dass die Wahrnehmung der Realität durch den Anwender stark von der Auflösung und der Qualität der Kamera abhängig ist. Es gibt verschiedene Ansätze, ein Video See-Through Display umzusetzen. Zum einen kann wie auch schon bei den Optical See-Through Displays ein HMD verwendet werden. Dabei werden an Stelle des Halbdurchlässigen Spiegels kleine Bildschirme angebracht, die das erzeugte Gesamtbild anzeigen (Abb. 10(a)). Ein anderer Ansatz ist, einen einzelnen Bildschirm als Anzeigegerät zu benutzen (Abb. 10(b)). Dieser Bildschirm kann entweder ein Computer-Bildschirm, oder ein Display eines mobilen Gerätes (Smartphone, PocketPC) sein. Dies hat den Vorteil, dass mehrere Anwender das Ergebnis sehen können, allerdings mindert es die Immersion des Nutzers drastisch [9]. (a) HMD-basiert (b) Monitorbasiert Abbildung 10: Video See-Through Displays [3]

16 2 Augmented Reality Szenengraphen Ein Szenengraph ist eine objektorientierte Datenstruktur, die zur Entwicklung von 3D- Anwendungen genutzt wird. Er ist als ein gerichteter Baum (zusammenhängender, gerichteter Graph, der keine Kreise aufweist) aufgebaut. Der Wurzelknoten enthält dabei die gesamte Szene. Unter diesem hängen weitere Kindknoten, die Transformationen, Gruppen, oder Geometrieinformationen enthalten können. Dabei führen Veränderungen am Elternknoten (zum Beispiel Änderungen an einem Transformationsknoten) zum Ändern des Kindknotens. Dieser Kindknoten kann jedoch auch selbst noch manipuliert werden. Ein Beispiel wäre die Modellierung eines Autos (Abb. 11). Alle Elemente sind indirekt Kindknoten des Wurzelknotens. Wird die Gesamte Szene bewegt, bewegt sich auch der Rest mit. Unter dem Wurzelknoten hängt die Gruppe Auto. Diese Gruppe teilt sich wiederum in das Chassis und die Gruppe Räder auf. Jeder der Räder wird wieder unter einen Transformationsknoten gehangen. Durch diesen Aufbau ist es möglich das sich jedes Rad unabhängig vom Vaterknoten bewegen kann, und das Auto trotzdem noch als eine Einheit bewegt werden kann. Viele Sprachen für die Entwicklung von 3D-Anwendungen implementieren das Szenengraphenprinzip. Die populärsten sind Extensible 3D (X3D), eine auf der Extensible Markup Language (XML) basierende Sprache für 3D-Modelle welche unter anderem zur Entwicklung von Webanwendungen genutzt werden kann und OpenSceneGraph. Wurzelknoten Transformation Gruppe: Auto Legende: (quad.) Gruppe (oval) Transformation Wurzelknoten Geometrie Eltern-Kind Beziehung Transformation Gruppe: Räder Chassis Transformation Transformation Transformation Transformation Rad Rad Rad Rad Abbildung 11: Szenengraph eines Autos

17 3 Stand der Technik 17 3 Stand der Technik Zur Zeit existieren mehrere Augmented Reality Frameworks, die zur Entwicklung von Android Anwendungen genutzt werden können. In diesem Kapitel soll ein kurzer Überblick über diese gegeben werden, und untersucht werden, ob die Frameworks sich zur Code-Generierung aus SSIML (sh. Abschnitt 5) Modellen eignen. 3.1 ARToolkit Das ARToolkit wurde ursprünglich von Dr. Hirokazu Kato vom Nara Institute of Science and Technology im Jahr 1999 entwickelt und später von dem Human Interface Technology Lab (HITLab) der Universität Washington unter der GNU General Public License veröffentlicht. Seit dem ist es für eine Menge Plattformen erschienen. Zu den wichtigsten zählen Microsoft Windows, Apple s Mac OS-X und GNU/Linux sowie die mobilen Plattformen Android und Apple s IOS. Das Framework ist ursprünglich in C und C++ geschrieben, unterstützt jedoch auch andere Sprachen, wie Java oder Matlab. Die Implementierung der letztgenannten Sprachen findet mittels Wrapper-Klassen und nativen Bibliotheken statt. Das ARToolkit unterstützt sowohl Optical See-Through Displays als auch Video See-Through Displays, also beide Formen, die als Display in Augmented Reality Anwendungen mit optischen Trackern eingesetzt werden können. Auf Grund seiner Implementierung in C und C++ läuft es auf den meisten Systemen in einer akzeptablen Geschwindigkeit. Um eine Positionsbestimmung im realen Raum zu erhalten nutzt das ARToolkit quadratische zweifarbige Marker, die einen durchgängigen schwarzen Rand haben müssen(abb. 12). Auf Grund dieses sehr dicken schwarzen Randes, der insgesamt die Hälfte des Markers einnimmt, sind die Marker schwerer zu individualisieren, als es bei anderen Frameworks der Fall ist. Das Rendern von 3D-Objekten wird in der Android Version mittels OpenGL-ES realisiert. Mittels weiteren Bibliotheken kann auch OpenSceneGraph, Flash Actionscript sowie die Unity-Game- Engine benutzt werden. Dadurch wird das Framework sehr flexibel. Durch die übersichtliche API ist es problemlos möglich einfache Anwendungen zu gestalten, die auf den meisten Geräten sehr gut laufen. Sollen allerdings komplexere Funktionen, wie Kollisionserkennung oder Object- Picking, implementiert werden muss mittels NDK auf native Bibliotheken zurückgegriffen werden. Seit 2007 wird das ARToolkit nicht mehr weiterentwickelt, wodurch neue Trackingmethoden, wie das benutzen von 3D-Modellen als Vorlage oder neuere Renderer nicht benutzt werden können. Abbildung 12: Marker des ARToolkit

18 3 Stand der Technik ARmsk Das ARmsk Framework wurde 2011 unter der GNU General Public License veröffentlicht. Es ist ein ausschließlich für Android entwickeltes Framework und nutzt nicht wie die anderen hier vorgestellten Bibliotheken Marker zum Tracken von Objekten in der realen Welt. Um mittels Bilderkennung die Positionsbestimmung durchzuführen baut es auf die OpenCV- Bibliotheken auf. Das Framework benutzt zum Rendern das mittlerweile veraltete OpenGL-1, was die Implementierung komplexerer 3D-Szenen sehr schwer gestaltet, da die Objekte zur Ausführung der Anwendung bereits in einem Array vordefiniert sein müssen. Durch das markerlose Trackingverfahren ist ARmsk sehr langsam, und lief auf dem Testgerät nur sehr stockend. Außerdem ist die Testanwendung nur in der Lage mittels eines selbst aufgenommenen Bildes zu erkennen, wo im Raum der 3D-Inhalt gerendert werden soll. Dadurch ist leider nur ein Marker pro Anwendung möglich. Hier wäre es besser gewesen verschiedene Featureerkennungsalgorithmen wie eine Kantenerkennung oder ähnliche Funktionen von OpenCV zu nutzen. Die Dokumentation des Frameworks beinhaltet nur eine Beispiel-Anwendung, die auch im Android Play Store heruntergeladen werden kann und ein Gerüst für eigene Anwendungen. Eine Klassendokumentation fehlt ganz. Seit Ende 2011 wird ARmsk nicht mehr weiterentwickelt. Aufgrund der sehr niedrigen Bildwiederholfrequenz und der schlechten Dokumentation eignet es sich nicht für die in dieser Arbeit erzielte Anwendung. 3.3 Popcode Popcode ist ein vom Machine Intelligence Lab am Department of Engineering der Universität Cambridge entwickeltes Framework. Es wurde speziell für Mobile Plattformen entwickelt, läuft allerdings auch mittels eines von Popcode entwickelten Viewes auch auf Microsoft Windows. Es nutzt nicht die für mobile Plattformen vorgesehenen Entwicklungsumgebungen, sondern funktioniert nur über eine Eigenständige Anwendung. Diese lädt entsprechende Marker und 3D Informationen über das Internet oder von der SD Karte nach sobald ein Strichcode-artiger Popcode (Abb. 13) mittels Kamera aufgenommen wurde. Die Informationen werden mittels XML-Dateien vom Entwickler festgelegt, wobei Animationen Abbildung 13: Marker des Popcode-Frameworks und Interaktionen mit dem Benutzer mittels der Skriptsprache LUA in derselben Datei erzeugt werden können. Um eigene Marker zu erzeugen benötigt man den in dem Developer Kit enthaltenen Markergenerator. Dieser wandelt das Bild in ein von Popcode lesbares Format um, und erzeugt einen Popcode auf dem Bild. Diese generierten Dateien werden dann zusammen mit der XML Datei in einen Ordner, der sich auf der SD-Karte befindet kopiert, und von da durch die Popcode Anwendung eingelesen. Der 3D-Inhalt kann entweder durch Primitiven, wie Würfel, Ebenen, oder Kugeln in der XML-Datei selbst, oder mittels Export eines 3D-Modells in das ARO-Format bestimmt werden.

19 3 Stand der Technik 19 Mittlerweile ist Popcode ein Teil der Zappar-Anwendung und wird als Popcode nicht mehr weiterentwickelt. 3.4 AndAR Das AndAR Framework wurde 2010 von Tobias Domhan im Rahmen seiner Studienarbeit [18] entwickelt, und basiert auf dem ARToolkit. Allerdings ist es, nicht wie das ARToolkit, nur für die Android Plattform erschienen, und nutzt daher nur Video See-Through Displays (sh. Unterabschnitt 2.4.2). Es umschließt alle vom ARToolkit bereitgestellten Nativen Methoden. Somit ist es möglich eine AR-Anwendung nur mit Java zu erstellen. Um 3D-Objekte zu laden kann das von Wavefront entwickelte OBJ Format oder OpenGL-ES-1.0 direkt im Quellcode verwendet werden. Als Dokumentation ist eine Beispielanwendung, jedoch keine API-Dokumentation vorhanden. Die mittels AndAR entwickelten Anwendungen liefen auf den Testgeräten relativ langsam. Seit 2010 wird AndAR nicht mehr weiterentwickelt. 3.5 MetaIO MetaIO ist ein von der MetaIO GmbH entwickeltes Augmented Reality Angebot. Die Firma mit Hauptsitz in München bietet Augmented Reality Lösungen für viele Plattformen, und viele Kunden an. Eine der bekanntesten Anwendungen, die die Firma entwickelt hat ist die Lego-Digital Box. Diese Box filmt Lego-Verpackungen, und rendert auf die Oberseite des Kartons das fertig zusammengebaute Model. Für Entwickler sind das PC-SDK, das Web-SDK, sowie das für Android und IOS entwickelte Mobile-SDK erhältlich. Ein großer Nachteil des Mobile-SDK ist, das jede neue Anwendung bei MetaIO registriert, und mittels eines generierten Schlüssels validiert werden muss. Außerdem wird in der Basic-License -Version ein Wasserzeichen auf das Video gerendert. Diese Registrierung macht die Generierung von Anwendungscode aus SSIML Modellen sehr umständlich. 3.6 Vuforia Das Vuforia-Toolkit ist ein von der Firma Qualcomm entwickeltes Framework. Es ist für das Android-Betriebssystem sowie für das I-OS System von Apple erschienen. Im Gegensatz zu den anderen vorgestellten Toolkits kann es mehrere verschienene Trackingmethoden benutzen. Es unterstützt vorgenerierte Marker, die einen Strichcodeartigen Rahmen (Abb. 14) haben, sowie eigene Bildmarker, die vorher mittels eines webbasierten Generators in ein vom Framework erkanntes Format umgewandelt werden müssen. Außerdem ist es möglich eigene virtuelle Buttons zu erstellen, die durch Verdeckung ausgelöst werden. Das Vuforia Toolkit kann außerdem mittels der Unity-Game-Engine Programme und Spiele erzeugen. Ein großer Nachteil ist es, das der Code für Android zwar in Java geschrieben wird, allerdings das gesamte 3D-Rendering in den Nativen Teil, der mittels des NDK vor-kompiliert werden muss, stattfindet. Dadurch ist die Flexibilität die die Codegenerierung benötigt nicht gegeben. Als sehr Performant stellte sich die Tracking-Komponente des Toolkits heraus. Abbildung 14: Marker des Vuforia Frameworks[11]

20 4 Das Agrajag-Framework 20 4 Das Agrajag-Framework In diesem Kapitel soll das entwickelte AR-Framework Agrajag vorgestellt werden. Der Name Agrajag bezieht sich dabei auf eine Figur aus Douglas Adams Romanreihe Per Anhalter durch die Galaxis. 4.1 Architektur des Agrajag-Frameworks Das Agrajag-Framework besteht aus mehreren Teilen, die Szenengraphen einlesen, das Tracken der Marker sowie das Rendering der 3D-Objekte übernehmen. Zum Einlesen des gewünschten Scenengraphen werden die beiden Parser AgrajagARParser und AgrajagX3DParser benutzt. Als Tracker wird das Bildverarbeitungssystem des Vuforia-Frameworks benutzt [19]. Dies bietet den Vorteil, dass die sehr aufwendigen Bild verarbeitenden Prozesse mittels Native Development Kit (NDK) durch C++-Code umgesetzt werden können. Dieses System übergibt, nach Erkennen eines Markers, die benötigte Marker-ID und die Transformationsmatrix an den Java- Teil des Programms. Das Rendering des entsprechenden 3D-Objektes übernimmt der von Dennis Ippel entwickelte Rajawali-Renderer [20] AgrajagActivity Eine Activity ist in der Android-Programmierung ein Containerelement, das Graphical User Interface (GUI)-Elemente wie Buttons oder Oberflächen für das Rendern von 3D-Objekten enthalten kann. Es ist das Element, was als Einstiegsmethode in ein Android-Programm dient. Die AgrajagActivity ist die Activity, von der die StartActivity der Anwendung erbt. Sie startet alle anderen Funktionen, wie den Parser, den Tracker und die Kamera AgrajagX3DParser Die in Unterabschnitt 4.1 genannten Parser erben von dem, im Rajawali-Renderer bereitgestellten AParser. Da dieser nur OBJ und MD2-Dateien einlesen kann, musste er für die auf XML basierende Beschreibungssprache für 3D-Objekte X3D erweitert werden. Der AgrajagARParser geht dafür jeden einzelnen Tag in der X3D Datei durch und erzeugt für jeden gefundenen validen Knoten ein Objekt, welches er dem Szenegraph übergibt. Diese Objekte sind im Paket org.agrajag.types definiert. Wenn der Typ des Tags ein Inline-Knoten ist, wird ein neuer AgrajagX3DParser gestartet, der die neue X3D-Datei auf valide Knoten untersucht. Findet der Parser in einem Transformationsknoten das Tag markerid, so wird dieser Knoten und die ID in die Liste der zu rendernden Objekte aufgenommen AgrajagSzenegraph Der AgrajagSceneGraph repräsentiert die interne Datenstruktur der 3D-Objekte. Sämtliche zu rendernde Objekte und Transformationsknoten sind in ihm gespeichert. Dabei wird das erste Element an einen Wurzelknoten als Kindknoten angehangen. Unter dieses Element werden die weiteren, vom Parser generierten Knoten gehängt. Ist eine Datei vollständig ausgelesen, wird die nächste Datei wieder unter den Wurzelknoten beziehungsweise den nächst höheren Knoten gehängt. Der Szenengraph beinhaltet außerdem Methoden zur Objektmanipulation, wie zum Beispiel hinzufügen oder löschen von Knoten, oder das Ändern des Materials.

21 4 Das Agrajag-Framework 21 Ablaufsteuerung AgrajagActivity Datenverwaltung AgrajagX3DParser AgrajagSzeneGraph Featureerkennung AgrajagTracker Rendering AgrajagRenderer VuforiaRenderer AgrajagView Eventverwaltung ARSensorManager Abbildung 15: Komponenten des Frameworks AgrajagTracker Der AgrajagTracker ist das Element, das für die Featureerkennung zuständig ist. Er ist Teil des Vuforia-Frameworks von Qualcomm (sh. Kapitel 3.6) und nutzt die von Qualcomm bereitgestellten Frame-Marker (Abb. 16). Dies hat den Grund, dass nicht neue Marker vom Anwender angelernt und mittels NDK neu kompiliert werden müssen, da sie im nativen Teil der Anwendung bereits vorhanden sind. Diese Marker können trotz der vorgefertigten Ränder stark individualisiert werden, da der mittlere Bereich nicht für die Lageerkennung genutzt wird. Der Tracker erkennt die Lage der Marker abhängig von der Kameraposition und erzeugt daraus Transformationsmatrizen. Diese Transformationsmatrizen werden im NDK verarbeitet und über entsprechende Schnittstellen an den in Java geschriebenen AgrajagRenderer übergeben. Abbildung 16: Frame Marker des Vuforia Frameworks[11]

22 4 Das Agrajag-Framework VuforiaRenderer Der VuforiaRenderer ist für die Wiedergabe des Kamerabildes zuständig. Dieses Bild wird auf eine GLSurfaceView des Android Frameworks gerendert. Über dieser GLSurfaceView wird eine zweite durchsichtige GLSurfaceView gelegt, die das Renderergebnis des AgrajagRenderers anzeigt AgrajagRenderer Der AgrajagRenderer ist das Herzstück des Frameworks. Er ist zuständig für die Anzeige der im AgrajagSceneGraph gespeicherten Elemente. Er basiert auf dem von Dennis Ippel entwickelten Rajawali-Renderer [20] und wurde durch Methoden zur Scenengraphenmanipulation erweitert. Der Renderer bekommt vom NDK die MarkerID und die entsprechende Transformationsmatrix des sich im Bild befindlichen Markers übergeben. Diese Transformation wird nach der Überprüfung, ob ein 3D-Objekt für den Marker registriert ist, auf den entsprechenden Knoten im AgrajagScenegraph angewendet. Der Renderer enthält außerdem Methoden zur Kollisionserkennung von zwei 3D-Objekten. Eine weitere Funktion ist das Erkennen, ob ein 3D-Objekt vom Anwender auf dem Display berührt wird ARSensorManager Der ARSensorManager ist für die Registrierung und Validierung von Sensoreingaben (Berühren des Objektes) zuständig. Bei ihm können Klassen und Funktionen auf bestimmte Ereignisse (zum Beispiel: 3D-Objekt Tisch berührt) registriert werden. Wird dieses Ereignis ausgelöst, kontrolliert der ARSensorManager, ob die Methode in der entsprechenden Klasse existiert und führt sie mittels der in Java implementierten Reflection-Library aus AgrajagView Die AgrajagView ist eine SurfaceView des Android-Frameworks. Sie ist dafür zuständig, das der Anwender zusätzlich GUIElemente hinzufügen kann Unterstützte Szenengraphknoten ARObject: Das ARObject ist die Basisklasse aller unterstützten Knoten. Es enthält jeweils eine Liste von Kindknoten und zur Unterstützung von Szenengraphenfunktionen (das Umhängen von Knoten) jeweils eine Referenz auf den Elternknoten. Der Group-Knoten: Die Group ist die Implementierung der Gruppe. Sie kann mehrere Kindknoten enthalten, bietet darüber hinaus keine weitere Funktionalität. Transformation: Der Transformation-Knoten ist für alle Objekttransformationen, also Positions-, Skalierungs-, Scherungs- beziehungsweise Orientierungsänderungen zuständig. In ihm wird darüber hinaus die MarkerId für das zu rendernde Objekt gespeichert. Dieses Attribut ist in diesem Knoten implementiert, da jedes zu rendernde Objekt unter einem Transformationsknoten hängen muss. Inline: Ein Inline-Knoten ist ein Knoten, der eine weitere X3D-Datei enthalten kann. Diese wird dann

23 4 Das Agrajag-Framework 23 ebenfalls vom AgrajagX3DParser durchgegangen und dem AgrajagScenegraph hinzugefügt. Switch: Der Switch ist ein der Gruppe ähnlicher Knoten. Im Unterschied zur Gruppe gibt er immer nur einen der unter sich befindlichen Kindknoten an den Renderer weiter. Dieser Kindknoten kann zum Beispiel durch eine Berührung des Switchknotens durch den Anwender ausgetauscht werden. Shape: Die Shape beinhaltet die eigentliche 3D-Information. In ihr sind alle Vertices, Edges und Faces gespeichert. Material: Das Material ist kein Knoten im Szenengraph sondern ein Attribut der Shape. Es repräsentiert den Shader, der für die Berechnung der Farbe, Reflektion und Transparenz von dem Renderer benötigt wird Ablauf der Anwendung Als Einstiegspunkt in die Anwendung dient die in einer von der AgrajagActivity erbenden Klasse vorhandene Methode oncreate(). Diese Methode sorgt dafür, das entsprechende Methoden zur Initialisierung des AgrajagTrackers und des AgrajagRenderers aufgerufen werden. Dabei werden im Tracker 512 Marker erzeugt, und die Kamera kalibriert. Ist dies geschehen, wird die vorher angelegte X3D-Datei eingelesen und mittels des AgrajagX3DParsers in die interne Szenengraphstruktur umgewandelt. Dabei wird für jeden gefundenen Knoten ein extra Objekt erzeugt, was als Kindknoten an den AgrajagSceneGraph gehanen wird. Von diesem Zeitpunkt ist es möglich 3-Dimensionale Objekte anzeigen zu lassen. Der AgrajagTracker schaut nun bei jedem aufgenommenen Bild nach, ob sich ein Marker in diesem Befindet. Ist dies der Fall wird die MarkerID und eine entsprechende Transformationsmatrix an den Renderer weitergegeben. Dieser überprüft, ob der MarkerID ein 3D-Objekt zugeordnet ist. Ist dies der Fall wird das entsprechende 3D-Objekt gerendert. Dieser Prozess des Trackens und des Renderns wiederholt sich ständig bis zum Abbruch der Anwendung. Wird das Display des Gerätes berührt, testet der Renderer, ob unter den Koordinaten der Berührung ein 3D-Objekt vorhanden ist. Ist dies der Fall, wird im ARSensorManager überprüft, ob dem berührten Objekt eine Methode zugeordnet wurde. Diese Methode wird mittels Reflection gesucht, und ausgeführt.

24 4 Das Agrajag-Framework 24 initialisiere Anwendung lade Szenengraph konfiguriere Marker starte Renderer untersuche Kamerabild positioniere Objekt ja Marker gefunden? nein rendere Objekt Abbildung 17: Vereinfachter schematischer Ablauf

25 4 Das Agrajag-Framework Implementierung des Agrajag-Frameworks In diesem Kapitel soll es nun um die direkte Implementierung des Frameworks gehen, indem die wichtigsten Methoden und Klassen vorgestellt werden AgrajagActivity oncreate: Die oncreate-methode (Listing 1) der AgrajagActivity ist der Startpunkt der Anwendung. Hier werden die wichtigsten Variablen initialisiert und der SplashScreen geladen. Dieser hat den Zweck die Kamerakalibrierung und die Renderinitialisierung vor dem Anwender zu verbergen. Listing 1: oncreate(bundle savedinstancestate) 1 protected void oncreate ( Bundle savedinstancestate ) { 2 super. oncreate ( savedinstancestate ) ; 3 DebugLog. LOGD ( "Agrajag::onCreate" ) ; 4 5 this. PACKAGE_NAME = getapplicationcontext ( ). getpackagename ( ) ; 6 this. arsensormanager = ARSensorManager. getinstance ( ) ; 7 this. arsensormanager. initializemanager ( this. PACKAGE_NAME ) ; 8 this. viewlist = new ArrayList<View>() ; 9 this. objectmap = new HashMap<String, String>() ; // S e t the splash screen image to d i s p l a y during i n i t i a l i z a t i o n : 12 msplashscreenimageresource = R. drawable. splash ; // Query the QCAR i n i t i a l i z a t i o n f l a g s : 15 mqcarflags = getinitializationflags ( ) ; // Update the a p p l i c a t i o n s t a t u s to s t a r t i n i t i a l i z i n g a p p l i c a t i o n 18 updateapplicationstatus ( APPSTATUS_INIT_APP ) ; } intiapplicationar: initapplicationar (Listing 12) wird aufgerufen, sobald alle Nativen Komponenten des Vuforia- Frameworks erfolgreich initialisiert sind. In ihr werden die verschiedenen übereinanderliegenden SurfaceView s des Android-Frameworks und die Renderer für das Kamerabild, und die 3D- Objekte initialisiert. loadscenegraph: Die loadscenegraph-methode (Listing 2) ist die wichtigste Schnittstelle an den Nutzer nach außen. Durch sie gibt der Anwender an, welche X3D-Dateien aus dem Ordner assets geladen werden. Der Integer-Parameter scale der für die Skalierung der gesamten Szene zuständig ist, ist dabei Optional. Durch Aufrufen der Methode wird ein neuer Task (Hintergrundprozess) gestartet, der das Parsen der X3D-Datei übernimmt. Wird diese Methode mehrfach aufgerufen werden alle geladenen Szenengraphen an einen gemeinsamen Wurzelknoten gehangen. Listing 2: loadscenegraph(string filename, int scale) 1 protected void loadscenegraph ( String filename, int scale ) {

26 4 Das Agrajag-Framework 26 2 DebugLog. LOGI ( "Start parsing X3D File " + filename ) ; 3 AgrajagSceneGraph scenegraph = AgrajagSceneGraph. getinstance ( ) ; 4 scenegraph. setaactivity ( this ) ; 5 this. mfilename = filename ; 6 this. isparsed = true ; 7 parsingtask = new ParsingTask ( ) ; 8 parsingtask. execute ( filename ) ; 9 } onarinitialised: onarinitialised (Listing 3) wird aufgerufen, sobald die geladene X3D-Datei vollständig eingelesen, und mittels des AgrajagSceneGraph verarbeitet wurde. In ihr wird jedem (entweder in der X3D-Datei, oder durch registersceneelement) registrierten Knoten eine MarkerID zugewiesen. Anschließend wird der gesamte Szenengraph dem AgrajagRenderer übergeben. Listing 3: onarinitialised() 1 public void onarinitialised ( ) { 2 AgrajagSceneGraph scenegraph = AgrajagSceneGraph. getinstance ( ) ; 3 scenegraph. setaactivity ( this ) ; 4 arenderer. start ( ) ; 5 6 if ( isparsed ) { 7 for ( HashMap. Entry<String, String> entry : objectmap. entryset ( ) ) { 8 BaseObject3D object = scenegraph. getelement ( entry. getkey ( ) ) ; 9 int id = Integer. parseint ( entry. getvalue ( ) ) ; 10 arenderer. addparsedobject ( object, this. parsedscale, id ) ; 11 } arenderer. addscenegraph ( scenegraph ) ; 14 } 15 } AgrajagRenderer initscene: Die Methode initscene (Listing 13) ist die Initialieirungsmethode des AgrajagRenderers. In ihr werden alle wichtigen Einstellungen, die für das Rendern der 3D-Objekte zuständig sind vorgenommen. Hier wird die Virtuelle Kamera auf die feste Position (0, 0, 0) im Koordinatensystem des Renderers (Rechte Hand) gesetzt. Des Weiteren wird auch die globale Lichtquelle positioniert und konfiguriert. setrenderparameters: setrenderparameters (Listing 14) wird mittels NDK aufgerufen, sobald der AgrajagTracker einen Marker erkannt hat. Nach der Validierung ob für den erkannten Marker ein Knoten im Szenengraph registriert ist werden die 3D-Objekte positioniert und ein Renderflag für das entsprechende 3D-Objekt aktiviert. onobjectpicked: onobjectpicked (Listing 4) wird aufgerufen, sobald der Anwender ein 3D-Objekt auf seinem Display berührt. Der Renderer überprüft mittels des ARSensorManagers, ob eine Methode für das berührte 3D-Objekt oder für ein im Szenengraph über ihm hängender Knoten vorhanden

27 4 Das Agrajag-Framework 27 ist. Ist dies der Fall, wird sie vom ARSensorManager mittels der Reflection Bibliothek geprüft und ausgeführt. Listing 4: onobjectpicked(baseobject3d tempobject) 1 public void onobjectpicked ( BaseObject3D tempobject ) { 2 ispicked = true ; 3 for ( Entry<String, BaseObject3D> entry : rendermap. entryset ( ) ) { 4 if ( tempobject. equals ( entry. getvalue ( ) ) ) { 5 setpickedtracker ( Integer. parseint ( entry. getkey ( ) ) ) ; 6 } 7 } 8 setpickedobject ( tempobject ) ; 9 ARSensorManager manager = aactivity. getarsensormanager ( ) ; 10 if ( manager. hasmethod ( tempobject. getname ( ) ) ) { 11 manager. runmethod ( tempobject. getname ( ) ) ; 12 } else if ( manager. hasmethod ( getpickedtracker ( ) ) ) { 13 manager. runmethod ( getpickedtracker ( ) ) ; 14 } else { 15 DebugLog. LOGE ( "Method not found" ) ; 16 } 17 } AgrajagTracker inittracker: Um die vom Vuforia-Framework bereitgestellten Marker zu nutzen müssen diese initialisiert werden. Dieser Schritt wird für alle 512 möglichen Marker durchgeführt (Listing 15). renderframe: Die renderframe-methode (Listing 16) ist ein Teil des in C++ geschriebenen Nativen Quellcodes. Sie sorgt dafür, das alle für den aktuell erkannten Marker berechneten Parameter an den Java-Teil des Frameworks weiter gegeben werden. 4.3 API des Agrajag-Frameworks In diesem Kapitel soll es nun darum gehen die Schnittstellen für den Anwender zu erläutern MainActivity Die MainActivity ist die von der AgrajagActivity erbende Klasse. In ihr stehen dem Anwender Methoden zum Laden von 3D-Objekten oder Task-Sequenzen zur verfügung. loadscenegraph(string filename, int scale): Diese Methode lädt den in einer X3D-Datei enthaltenen 3D-Inhalt. Als Parameter wird ihr die X3D-Datei, die sich im Ordner assets befinden muss, und eine Skalierung für die geladene Scene übergeben. loadtasksequence(string filename): Die loadtasksequence Methode ist für das Laden eines mittels SSIML/Tasks generierten Ablaufplanes (Tasksequence) vorgesehen. Sie lädt wie die loadscenegraph-methode eine Ressource

28 4 Das Agrajag-Framework 28 aus dem assets Ordner. addview(int resourceid): addview fügt eine extra GUI-Ebene der Anwendung hinzu. Dadurch können zum Beispiel ButtonWidgets als Interaktionselement zum Umschalten des Switch-Knotens genutzt werden. Die LayoutView [21] muss als XML-Datei vorliegen und durch das Android-Framework eine ResourceID zugeordnet bekommen haben. getguielement(int resourceid): Da die Verwaltung der Oberflächenelemente von dem Agrajag-Framework übernommen wird müssen einzelnen GUI-Elemente auf andere Weise Eventlistener zugeordnet werden. Um die dafür nötige Referenz zu bekommen kann die getguielement-methode verwendet werden. onarinitialised(): Zusätzliche Elemente können dem AgrajagRenderer erst nach seiner vollständigen Initialisierung übergeben werden. Diese Methode wird ausgeführt, sobald der Renderer einsatzbereit ist. registersceneelement(int markerid, String objectname): Mit dieser Methode können zusätzlich ARObjekte für Marker registriert werden ARSensorManager Der ARSensorManager verwaltet alle Ereignisse die vom Anwender auf ein 3D-Objekt festgelegt werden können. Da er als Singelton implementiert ist kann jede Klasse auf ihn zugreifen. Die AgrajagActivity besitzt jedoch schon eine Referenz auf ihn, so das mittels arsensormanager auf alle wichtigen Funktionen zugegriffen werden kann. registereventhandler(string name, String method, String classname): Diese Methode registriert ein TouchEvent auf ein 3D-Objekt bei dem ARSensorManager. Dafür benötigt es den Namen eines Scenengraphenknotens (zum Beispiel sofa ), den Namen der Methode die ausgeführt werden soll, und den Namen der Klasse inklusive Paketnamen (qualifiedname), in der diese Methode vorhanden ist. 4.4 AgrajagRenderer Wie auch bei dem ARSensorManager kann auf Komponenten des AgrajagRenderer von überall zugegriffen werden. Auch er ist mittels der Variable arenderer in der AgrajagActivity verfügbar. addobject(baseobject3d object, int scale, int marker): Die addobject-methode fügt ein 3D-Objekt der Szene hinzu. Dieses 3D-Objekt kann ein PrimitiveObject (Cube, Sphere etc.), oder ein durch externe Parser erzeugtes Objekt sein. addobject(int objectid, int textureid, int scale, int marker): Wird eine OBJ-Datei als Importformat benötigt kann diese mittels der vom Android-Framework vergebenen ResourceID geladen werden. Die OBJ-Datei muss dafür im Ordner res/raw vorhanden sein.

29 4 Das Agrajag-Framework 29 setcamcorrectionfactor(double factorx, double factory): Da das Framework auf verschiedenen Displayauflösungen läuft, kann es sein, das das die Transformationen des 3D-Objektes und die Transformationen des Markers nicht genau übereinstimmen. Dieses Verhalten kann mittels eines Faktors in X- und Y-Richtung korrigiert werden. addcube(int size, int markerid): Die Methode addcube dient als Kalibrierungswerkzeug für den CamCorrectionFactor. setlightintensity(float intensity): Wird die Szene zu dunkel oder zu hell dargestellt kann die globale Beleuchtung mittels dieser Methode angepasst werden. 4.5 AgrajagSceneGraph Der AgrajagSceneGraph dient zur Speicherung und Manipulation der 3D-Objekte. Auf ihn kann mittels getinstance aus jeder Klasse zugegriffen werden. getelement(string name): Diese Methode übergibt die Referenz auf ein im Szenengraph enthaltenes Element. addchild(child, name): Die addchild-methode fügt dem Szenengraph ein neues Objekt hinzu. Als zweiter Parameter kann entweder der Name, oder die direkte Referenz auf ein im Szenengraph enthaltenes Objekt genutzt werden. removechild(obj): Diese Methode löscht ein Element mitsamt seinen Kindknoten aus dem Szenengraph. changeposition(object, newparent): Die changeposition-methode hängt ein Knoten von seinem Elternknoten ab, und fügt es einem anderen Knoten als Kindknoten hinzu.

30 5 Roundtrip3D und die Scene Structure and Integration Modelling Language 30 5 Roundtrip3D und die Scene Structure and Integration Modelling Language Die Scene Structure and Integration Modelling Language (SSIML) wurde von Arnd Vitzthum im Rahmen seiner Dissertation [22] entwickelt und wird zur Entwicklung interaktiver 3D-Anwendungen genutzt. Bei dieser Entwicklung kommt es häufig zu Problemen wie Inkonsistenzen, da verschiedene Entwickler unterschiedliche Komponenten der Anwendung, wie die 3D-Modellierung oder die Implementierung des Programmcodes übernehmen. Um diesen Problemen entgegen zu wirken wurde ein Lösungsansatz mittels domänenspezifischer Sprachen realisiert. Eine Sammlung an Sprachkomponenten, die die Basissprache SSIML erweitern, hilft mittels visueller Modelle Verknüpfungen zwischen den verschiedenen Komponenten zu spezifizieren. Ausgehend von der Basissprache gibt es noch SSIML/Tasks, SSIML/Behaviour, SSIML/Components, und SSIML/AR. Während SSIML/Tasks für die Spezifizierung von interaktiven 3D-Handbüchern zuständig ist, kümmert sich SSIML/Behaviour um das Verhalten der 3D-Objekte. SSIML/Components ist für die Unterteilung der 3D-Elemente in einzelne Unterkomponenten zuständig, und SSIML/AR kümmert sich um die Augmented Reality Funktionalität. Ist eine Anwendung mit SSIML modelliert, können in einem Vorwärtsschritt Codegerüste für die 3D-Szene (X3D) sowie für die Anwendungslogik (Java) generiert werden. Die Konsistenz zwischen den Codebausteinen ist dabei sichergestellt. Nach der Vervollständigung dieser Codegerüste durch die jeweiligen Entwicklergruppen kann der Code zurück in ein SSIML-Modell überführt werden (Rückwärtsschritt). Nach einem erneuten Vorwärtsschritt werden etwaige Inkonsistenzen zwischen 3D- und Anwendungscode beseitigt. Genaueres zur iterativen Entwicklung von 3D-Anwendungen kann zum Beispiel in [1] nachgelesen werden. 5.1 SSIML/AR SSIML/AR ist ein Teil der SSIML-Sprachfamilie, und zuständig für die Generierung von AR- Anwendungen. Dafür bringt es mehrere Komponenten mit [22]. Das RealObject ist ein sich im zu Trackenden Raum befindliches Objekt. Es kann auch als Marker verwendet werden, enthält jedoch keine Informationen über ein zu überlagerndes Virtuelles Objekt. Das VirtualObject ist ein rein Virtuelles Objekt. Es dient dazu Informationen oder 3D- Objekte anzuzeigen und gegebenenfalls mit ihnen zu interagieren. Das HybridObject ist das zu Trackende Objekt. Es enthält Informationen, an welcher Stelle Virtuelle Objekte angezeigt werden sollen. Der VideoTracker ist die Kamerabild verarbeitende Einheit von SSIML/AR. Er sorgt für die Lageerkennung der Marker in der Szene. Der SceneUpdater ist die Komponente, die die errechneten Positionen auf die hybriden oder die virtuellen Objekte anwendet. Zusätzlich zu diesen Komponenten werden noch zwei Beziehungstypen hinzugefügt. Die TracksRelationship besagt, dass die ermittelten Positionswerte von einer Anwendungskomponente bereitgestellt werden. Die AlignsRelationship gibt an, welche Laufzeitinstanzen eines RealObject oder eines HybridObject verfolgt oder ausgerichtet werden.

31 5 Roundtrip3D und die Scene Structure and Integration Modelling Language 31 Abbildung 18: Beispiel einer in SSIML modelierten Anwendung [23] Abbildung 19: Beispiel einer in SSIML/AR modelierten Anwendung [22]

32 5 Roundtrip3D und die Scene Structure and Integration Modelling Language Vereinfachung von SSIML/AR durch die Nutzung des Agrajag-Frameworks Die oben genannten Komponenten wurden für eine Implementierung mittels eines Low-Level- Frameworks wie das ARToolkit (sh. Unterabschnitt 3.1) entwickelt. Da das Agrajag-Framework ein High-Level-Framework darstellt ergeben sich einige Änderungen bezüglich des mittels SSIML/AR erzeugten Modell zur Codegenerierung. Dies führt zu einer starken Vereinfachung des Modells. Dadurch entfallen der VideoTracker, der SceneUpdater, die TracksRelationship und die AlignsRelationship da diese Elemente nun vom Agrajag-Framework gekapselt werden. Die Komponenten HybridObject, RealObject und VirtualObject werden zu einem neuen HybridObject zusammengefasst. Diese neue Komponente beinhaltet Informationen wie die MarkerID des zu Trackenden Markers und die referenzierte X3D-Datei, die die Geometrie- Informationen für das anzuzeigende 3D-Objekt enthält.

33 6 Implementierung einer Beispielanwendung 33 6 Implementierung einer Beispielanwendung Dieses Kapitel handelt von der Implementierung einer Beispielanwendung. Diese Anwendung soll ein Innenraum-Planer, mit dem 3D-Objekte von Möbelstücken im Raum verschoben werden können, werden. Hierfür werden zwei verschiedene Ansätze genutzt. 6.1 Implementierung mittels des Agrajag-Frameworks Um eine AR-Anwendung mittels des Agrajag-Frameworks zu entwickeln muss zunächst ein neues Android-Projekt in Eclipse angelegt und die Datei agrajag.jar zusammen mit den Ordnern armeabi und armeabi-v7a in den Ordner libs kopiert werden Die AndroidManifest.xml Datei Damit das Android System Zugriff auf die Kamera erhält muss die AndroidManifest.xml (sh. Listing 5) Datei modifiziert werden. Dafür müssen Rechte für die Kameranutzung und den Telefonstatus hinzugefügt werden. Zusätzlich müssen noch Rechte für den Zugang zum Internet gewährleistet sein, da die Initialisierung des VuforiaTrackers diese benötigt. Um die vollständige Unterstützung des Renderers zu erhalten muss die Anwendung für OpenGL-ES 2 konfiguriert werden. Listing 5: AndroidManifest.xml 1 <?xml version="1.0" encoding="utf-8"?> 2 <manifest xmlns:android=" 3 package="org.agrajagbeispiel" 4 android:versioncode="1" 5 android: versionname="1.0" > 6 <uses sdk android:minsdkversion="8" 7 a n d r o i d : t a r g e t S d k V e r s i o n="10" /> 8 <uses p e r m i s s i o n android:name="android.permission.camera" /> 9 <uses p e r m i s s i o n android:name="android.permission.internet" /> 10 <uses p e r m i s s i o n android:name="android.permission. ACCESS_NETWORK_STATE" /> 11 <uses p e r m i s s i o n android:name="android.permission.access_wifi_state" /> 12 <uses p e r m i s s i o n android:name="android.permission.read_phone_state" /> 13 <uses f e a t u r e android:name="android.hardware.camera" 14 a n d r o i d : r e q u i r e d="true" /> 15 <uses f e a t u r e 16 a n d r o i d : g l E s V e r s i o n="0x " 17 a n d r o i d : r e q u i r e d="true" /> 18 <a p p l i c a t i o n 19 android:allowbackup="true" 20 a n d r o i d : i c o n="@drawable/ic_launcher" 21 a n d r o i d : l a b e l="@string/app_name" 22 android: theme="@android:style/theme.notitlebar.fullscreen" > 23 <activity 24 android:name="org.agrajagbeispiel.mainactivity" 25 a n d r o i d : l a b e l="@string/app_name" 26 a n d r o i d : s c r e e n O r i e n t a t i o n="landscape"> 27 <i n t e n t f i l t e r>

34 6 Implementierung einer Beispielanwendung <a c t i o n android:name="android.intent.action.main" /> <c a t e g o r y android:name="android.intent.category. LAUNCHER" /> 31 </ i n t e n t f i l t e r> 32 </ activity> 33 </ a p p l i c a t i o n> 34 </ manifest> Die MainActivity Klasse Diese Klasse ist der Haupteinstiegspunkt für eine Android-Anwendung. Damit alle Funktionen des Agrajag-Frameworks genutzt werden können, muss die Klasse von AgrajagActivity erben. Danach stehen alle im Kapitel 4.3 vorgestellten Methoden zur Verfügung. Um eine X3D-Datei zu einen Marker zuzuordnen genügt es mittels loadscenegraph( einex3ddatei.x3d,1); zu laden. Um mit dem Virtuellen Objekten interagieren zu können, müssen die Objekte bei dem ARSensorManager registriert werden. In der Beispielanwendung wird bei einem TouchEvent auf einen Switch-Knoten die Methode onswitchklick() in der Klasse EventHandlerBeispiel aufgerufen (Listing 6). Listing 6: Die MainActivity Klasse 1 public class MainActivity extends AgrajagActivity { 2 4 protected void oncreate ( Bundle savedinstancestate ) { 5 super. oncreate ( savedinstancestate ) ; 6 loadscenegraph ( "wohnung.x3d", 1 ) ; 7 8 arsensormanager. registereventhandler ( "Switch", "onswitchtouched", 9 "org.agrajagbeispiel.eventhandlerbeispiel" ) ; 10 } 11 } Die EventHandlerBeispiel Klasse Eine von SSIMLApplicationClass erbende Klasse stellt Methoden zur Manipulation des Szenengraphen zur Verfügung. Es wird empfohlen alle durch den ARSensorManager verwalteten Methoden in diese Klasse zu implementieren. Listing 7: Die EventHandlerBeispiel 1 public class EventHandlerBeispiel extends SSIMLApplicationClass { 2 3 public void onswitchtouched ( ) { 4 Switch mswitch = ( Switch ) getsceneelement ( "Switch" ) ; 5 mswitch. nextobject ( ) ; 6 } 7 }

35 6 Implementierung einer Beispielanwendung Das 3D-Objekt 3D-Objekte können auf mehrere Arten der Szene hinzugefügt werden. Diese Varianten unterscheiden sich jedoch nur in dem zu ladenden Dateiformat. So ist es möglich einzelne 3D-Objekte mittels des Wavefront OBJ-Formates der Szene hinzuzufügen (sh. Unterabschnitt 4.4). Die für die von komplexen Szenen besser geeignete Methode ist jedoch X3D-Dateien zu verwenden (Listing 8). Dieses kann ohne Weiteres aus Blender exportiert werden. Dabei ist zu beachten, dass folgende Einstellungen vorgenommen werden ((Abb. 20)). Abbildung 20: Die Exporteinstellungen für den Blender X3D Exporter Um ein 3D-Objekt einem Marker zuzuweisen wurde das Attribut markerid dem Transform- Knoten hinzugefügt. Dieser Knoten wird mit all seinen Kindknoten bei erkennen des entsprechenden Markers gerendert. Wird die Szene komplexer, ist es möglich weitere X3D-Dateien mittels eines Inline-Knoten nachzuladen. Soll ein anderer Knoten auf einem Marker angezeigt werden (zum Beispiel der Wurzelknoten) kann dieser mittels registersceneelement(int markerid, String objectname) in der MainActivity-Klasse verwendet werden. Listing 8: wohnung.xml 1 <?xml version="1.0" encoding="utf-8"?> 2 <! DOCTYPE X3D PUBLIC "ISO//Web3D//DTD X3D 3.0//EN" " specifications/x3d-3.0.dtd"> 3 <X3D version="3.0" p r o f i l e="immersive"> 4 <Scene> 5 <Viewpoint orientation=' ' p o s i t i o n='0 0 0'> 6 </ Viewpoint> 7 <WorldInfo DEF="generatedWorldInfo1" t i t l e ="HomeScene" i n f o=""> 8 </ WorldInfo> 9 <Transform DEF="mainTransform" translation="0 0 0" rotation=" " scale="1 1 1" center="0 0 0" s c a l e O r i e n t a t i o n=" "> 10 <Switch DEF="Switch"> 11 <Transform DEF="bettTramsform" translation="0 0 0" rotation=" " scale="1 1 1" center="0 0 0" s c a l e O r i e n t a t i o n=" " markerid="1">

36 6 Implementierung einer Beispielanwendung <Inline DEF="bett" u r l="wohnung/bett.x3d" > 13 </ Inline> 14 </ Transform> 15 <Transform DEF="schrankTransform" translation="0 0 0" rotation=" " scale="1 1 1" center="0 0 0" s c a l e O r i e n t a t i o n=" " markerid="1"> 16 <Inline DEF="schrank" u r l="wohnung/schrank.x3d"> 17 </ Inline> 18 </ Transform> 19 </ Switch> 20 </ Transform> 21 </ Scene> 22 </ X3D> Mittels diesen Beispielquellcodes kann nun ohne großen Aufwand eine AR-Anwendung für Android geschrieben werden, die erst ein 3D-Modell eines Bettes anzeigt (Abb. 21). Dieses Bett wird nun durch einen Schrank ersetzt, sobald es auf dem Display berührt wird (Abb. 22). Abbildung 21: Das 3D-Modell des Bettes auf Marker 1 Abbildung 22: Das 3D-Modell des Schrankes auf Marker 1