Anwendungs- und Interaktionskomponente für AiRmob. Bachelorarbeit

Transkript

1 Fachbereich 4: Informatik Anwendungs- und Interaktionskomponente für AiRmob Bachelorarbeit zur Erlangung des Grades eines Bachelor of Science (B.Sc.) im Studiengang Computervisualistik vorgelegt von Nils Lichtenberg Erstgutachter: Zweitgutachter: Prof. Dr.-Ing. Stefan Müller (Institut für Computervisualistik, AG Computergraphik) Dipl. Inform. Dominik Grüntjens (Institut für Computervisualistik, AG Computergraphik) Koblenz, im April 2012

2 Erklärung Ich versichere, dass ich die vorliegende Arbeit selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe. Ja Nein Mit der Einstellung der Arbeit in die Bibliothek bin ich einverstanden. Der Veröffentlichung dieser Arbeit im Internet stimme ich zu (Ort, Datum) (Unterschrift) i

3 Zusammenfassung In dieser Arbeit wurde die zentrale Komponente eines Augmented Reality Frameworks für das Android OS entwickelt. Es handelt sich dabei um die Nutzerschnittstelle, mit der ein Programmierer das Framework in eine Android-Anwendung integriert und dessen Inhalt steuert. Ein Renderer und Tracker können auf einfache Weise an diese Komponente angeschlossen werden, um das Framework zu vervollständigen. Dies wurde in drei weiteren Bachelorarbeiten als Gruppenprojekt getan. Abstract In this thesis, the central component of an augmented reality framework was developed for the Android OS. It is about the user-interface that a programmer utilizes to integrate the framework into an Android application and to control its content. A renderer and tracker can be connected to this component in a simple manner to complete the framework. This was done in three additional bachelor s theses as a group project. ii

4 Inhaltsverzeichnis 1 Einleitung Motivation Das Projekt Zielsetzung Hintergrund Android Android Systemarchitektur Dalvik Virtual Machine Anwendungsrahmen Native Development Kit Augmented Reality Smartphones Bestehende Frameworks Ordnung von Frameworks Interaktion und User Interface ARToolkit ARToolkit Plus Studierstube ES AndAR Nutzungsbeispiel QCAR Nutzungsbeispiel AiRmob Zieldefinition der Teilarbeit Anforderungsliste Systemarchitektur Handler und Runnable AiRmobActivity Pipeline Pipelinehandler AiRmobCamera Funktionalitäten Integration Tracker Integration Renderer Austauschbarkeit AiRmob GPS GPSgetter GPS Alerts iii

5 5 Anwendungen Minimale Beispielanwendung Mensch ärgar dich nicht Aus Entwicklersicht Ballons Aus Entwicklersicht Techdemo Erreichte Ziele Evaluierung der eigenen Arbeit Pipelinevarianten GPS Genauigkeit AiRmobCamera AiRmob im Vergleich mit AndAR und QCAR Evaluierung des gesamten Frameworks Fazit und Ausblick 64 iv

6 1 Einleitung 1.1 Motivation Die Möglichkeiten, Anwendungen für mobile Geräte zu entwickeln, wachsen stetig zusammen mit der Rechenleistung der Geräte. Auch Smartphones haben einen Stand erreicht, der es erlaubt, komplexe und aufwändige Aufgaben in Echtzeit zu erledigen. Ein Bereich, der schon länger besteht und vor wenigen Jahren auch Smartphones erreicht hat, befasst sich mit dem Thema Augmented Reality (AR, = Erweiterte Realität ). Systeme zur Entwicklung von AR bestehen schon seit längerem, ein erster Ansatz ein solches System auf Smartphones bzw. Handys zu übertragen startete im Jahr 2004 (siehe [MLB04]). Seit dem sind verschiedene andere Frameworks entstanden um das Programmieren von AR-Anwendungen auf mobilen Geräten effizient zu ermöglichen. Diese werden später noch vorgestellt. Im Zuge dieser Arbeit soll ebenfalls eine Teilkomponente eines Frameworks für AR-Anwendungen unter dem Namen AiRmob ( = Augmented Reality mobile) entwickelt werden. 1.2 Das Projekt Autoren: Philipp Brandt, Florian Kathe, Nils Lichtenberg und Axel Peter Diese Arbeit ist ein Teil des AiRmob-Frameworks. Dieses Framework wurde im Zuge von insgesamt vier Bachelorarbeiten parallel entwickelt. Es soll das Entwickeln für Augmented Reality Applikationen für Android ermöglichen. Das Projekt entstand aus folgenden Arbeiten: Anwendungs- und Interaktionskomponente für AiRmob - von Nils Lichtenberg Bei dieser Arbeit handelt es sich um das Grundgerüst, welches auf einfache Art und Weise mit einem Tracking- und Renderingsystem erweitert und vervollständigt werden kann. Das Verknüpfen des Frameworks mit der Standard-Android-API soll dem Benutzer möglichst einfach gemacht werden. Zudem sollen verschiedene Beispielanwendungen entwickelt werden, die die Funktionalität des Frameworks präsentieren. Trackingkomponente für AiRmob - von Florian Kathe Grundlage dieser Arbeit soll ein Tracker sein, der auf Basis von Markern oder Features ein Objekt in einem Bild tracken kann und dessen Pose berechnet. Diese soll dann wiederum an den Renderer weitergegeben werden. Es sollen dabei zwei Tracker entwickelt werden, die als Standard- Tracker verwendet werden können und als Beispiel dienen, wie man Tra- 1

7 cker für dieses Framework entwickelt. 3D-Engine für AiRmob - von Axel Peter In dieser Arbeit wird eine 3D-Engine entwickelt, welche dem Benutzer ermöglichen soll, schnell und einfach 3D-Inhalte zu produzieren. Hierzu soll der Anwender nur über grundlegenste Kenntnisse von OpenGL verfügen müssen und die anfänglichen Schwierigkeiten eines Einstiegs in OpenGL ES 2.0 genommen werden. Fortgeschrittene Techniken für eine möglichst hohe Effizienz und Qualität der Darstellung sollen verwendet werden. Shader und Effekte für AiRmob - von Philipp Brandt Bestandteil dieser Arbeit ist die Entwicklung verschiedener Shader, die im Renderer des Frameworks integriert und aufgerufen werden. Es wird der aktuelle Stand der Technik ermittelt und im Verlauf der Arbeit versucht, möglichst aktuelle und anspruchsvolle Shader auf den gegebenen mobilen Endgeräten echtzeitfähig zu implementieren. Texte die gemeinsam verfasst wurden, werden wie dieser entsprechend kenntlich gemacht. 1.3 Zielsetzung Autoren: Philipp Brandt, Florian Kathe, Nils Lichtenberg und Axel Peter Das Hauptziel der Arbeiten ist die Entwicklung des AiRmob-Frameworks. Dieses soll eine einsteigerfreundliche Entwicklungsumgebung für Augmented Reallity (AR) Anwendungen auf Android-Geräten bieten. Hierzu sollen die Schritte, die zum Erstellen einer lauffähigen Applikation nötig sind, reduziert werden. Der Benutzer, im Falle dieses Frameworks ein Entwickler von Applikationen, soll in der Lage sein, mit minimalen Vorkenntnissen von Android, OpenGL und Trackingsystemen seine Ideen schnell umzusetzen. Gleichzeitig soll es für fortgeschrittene Benutzer möglich sein, eigene Trackingsysteme und Renderer in das Framework einzubinden. Das Android-SDK soll als Basis für dieses Framework dienen. Hierdurch wird es für die Benutzer möglich sein, auf allen gängigen Betriebssystemen zu entwickeln (siehe Abschnitt 2.1). Entwickelt wird es auf der SDK- Version 2.3 (Gingerbread) und ist somit für diese und alle späteren lauffähig. Zusätzlich sollen mit Hilfe des Frameworks in gemeinsamer Arbeit zwei Applikationen entstehen. Die erste Applikation ist eine Techdemo. Mit ihr soll es möglich sein, diverse Einstellungen für die verschiedenen Komponenten auf Effizienz und Stabilität testen zu können. Diese Applikation ent- 2

8 steht parallel zur Entwicklung des eigentlichen Frameworks und wird nach und nach um neue Funktionalitäten erweitert. Die zweite Anwendung ist eine Beispielapplikation. Diese soll mit dem Framework selbst entwickelt worden sein und dadurch aufzeigen, in welcher Weise die Komponenten des Frameworks für eine Gesamtapplikation benutzt werden. Die genaue Zielsetzung und Umsetzung dieser Teilarbeit wird in Abschnitt 4 beschrieben. 2 Hintergrund 2.1 Android Das Android Betriebssystem wird seit 2007 offiziell von der Open Handset Alliance in Zusammenarbeit mit Google entwickelt (siehe [wika]). Die Open Handset Alliance umfasst eine Fülle von Firmen aus Bereichen der Telekommunikation, Softwareentwicklung und Halbleiter-Herstellung. Seit dem Start verbreitet sich Android auf dem Smartphonemarkt und hat sogar laut einer Studie von ComScore (siehe [Com]), was die Benutzerzahlen betrifft, den größten Marktanteil. Es wird allerdings nicht nur als Betriebssystem ausgeliefert, sondern als komplettes Softwarepaket für mobile Geräte. Mitgeliefert wird das Betriebssystem, Middleware und grundlegende Anwendungen für mobile Geräte (siehe [OHA]). Um für Android zu programmieren, steht das Android SDK für Windows, Mac und Linux zur Verfügung. Auf allen Plattformen empfiehlt sich das Nutzen von Eclipse, da hierfür auch ein Plugin des SDKs angeboten wird (siehe [Anda]). Am weitesten verbreitet war zuletzt die Version 2.2 Froyo, im November 2011 übernahm Version 2.3 Gingerbread erstmals die Führung (siehe [Goo]). Ende des Jahres erschien bereits Version 4.0 Ice Cream Sandwich. Diese vereinigte die Systemversionen für Smartphones (bis einschließlich Gingerbread) und Versionen für Tablet PCs Honeycomb. Hauptaugenmerk liegt hier in der Vereinung der Benutzerschnittstellen für Smartphones und Tablet PCs (siehe [Andb]). Auf Basis von Gingerbread wird in dieser Arbeit entwickelt, da hiermit der Großteil der Geräte abgedeckt wird. Die wichtigsten Funktionen, die benötigt werden, sind ebenfalls enthalten. Die nächsten Abschnitte beschreiben das Android-Betreibssystem, wie es auch im Buch von Becker und Pant zu finden ist (siehe [And10], S. 19ff) Android Systemarchitektur Android baut auf einem freien Linux-Kernel auf. Dieser enthält die Grundlegenden Elemente für das System. Als Laufzeitumgebung wird die Dalvik Virtual Machine (DVM) eingesetzt. Die Vorteile der DVM werden in einem späteren Abschnitt erläutert. Alle Grundfunktionalitäten, auf die der 3

9 Anwendungsrahmen zugreift, werden in Form von C/C++-Bibliotheken bereitgestellt. Diese basieren teilweise auf offener Software, wie zum Beispiel dem WebKit, welches die Grundlage für Webbrowser darstellt, oder OpenGL ES, was zur Darstellung von Grafiken dient. Der Anwendungsrahmen selbst stellt das dar, was der Entwickler letztendlich nutzt, um eine Anwendung für Android zu programmieren. Primär wird hier der Zugriff auf die Hardware ermöglicht. Als oberste Ebene steht die Anwendungsschicht. Hier findet die Interaktion mit dem Nutzer statt und Anwendungen können untereinander kommunizieren. Android-, Drittanbieter-, und eigene Anwendungen sind dabei als gleichwertig zu betrachten. Abbildung 1 stellt die Systemarchitektur dar. Anwendungsschicht Android- Anwendungen Drittanbieter- Anwendungen Eigene Anwendungen Anwendungsrahmen Activity Manager Content Provider Location Manager Notification Manager Package Manager Resource Manager Oberflächenelemente (Views) Connectivity Manager Telephony Manager Window Manager Bibliotheken Grafik (SGL, OpenGL ES, FreeType) Media-Framework SQLite-Datenbank SSL Android-Laufzeitumgebung Android- Laufzeitbibliotheken libc (Systembibliotheken) Oberflächen-Manager WebKit DVM (Dalvik Virtual Machine) Linux-Kernel Gerätetreiber (Bildschirm, Kamera, WiFi, Tastatur ect. Energieverwaltung Speicherverwaltung Prozessverwaltung IPC-Treiber (Binder) Abbildung 1: Android Systemarchitektur (siehe [And10], S. 20) 4

10 2.1.2 Dalvik Virtual Machine Die Dalvik Virtual Machine wurde von Google speziell für die Anforderungen mobiler Endgeräte entwickelt. Sie basiert auf der Quelloffenen Java Virtual Machine Apache Harmony und deswegen kann Android komplett in Java programmiert werden. Im Gegensatz zur JVM arbeitet die DVM mit Registern (siehe [DVM]), wodurch Berechnungen stark beschleunigt werden können. Der Weg von Javacode zum verwendbaren DVM-Bytecode sieht folgendermaßen aus (siehe [And10] S. 21ff, [Dom10], S. 9ff): Zunächst wird der Javacode von einem normalen Java-Compiler in Java-Bytecode übersetzt. Für jede Java-Klasse entsteht eine Datei. Diese werden von dx, einem Programm im Android Development Kit, in Dalvik-Bytecode, das so genannte dex-format, übertragen. Aus allen Java-Klassen entsteht dann eine einzige dex-datei, die alle Klassen enthält (siehe [Dom10] S. 9,10). Dieser Vorgang wird Cross-Compiling genannt. Zuletzt wird die dex-datei und alle weiteren Dateien, die von einer Anwendung genutzt werden sollen, in einer.apk-datei zusammengefasst. Diese stellt das Pendant zu Javas.jar-Dateien dar und lässt sich von Android Geräten entpacken, um die Anwendung zu installieren. Der Aufbau einer solchen.apk-datei ist auch mit dem einer.zip-datei zu vergleichen Anwendungsrahmen Der Anwendungsrahmen umfasst diejenigen Komponenten, die zur Programmierung von Android-Anwendungen genutzt werden. Laut Becker und Pant gibt es vier zentrale Elemente, aus denen sich eine Android Anwendung zusammensetzen kann, diese werden im Folgenden beschrieben (siehe [And10] S. 24ff) : Activity Service Content Provider Broadcast Receiver Activities treten mit dem Benutzer in Interaktion. Sie stellen das Benutzerinterface, bzw. die grafische Oberfläche dar und reagieren auf Eingaben des Benutzers. Darüber hinaus können hier wichtige Programmabläufe implementiert werden. Eine Anwendung, die mit dem Nutzer interagiert, besteht also aus mindestens einer Activity, kann aber auch mehrere enthalten, wobei aber immer nur eine im Vordergrund für den Anwender nutzbar ist. Wenn mehrere Activities vorhanden sind, können sich diese gegenseitig aufrufen und in den Vordergrund bringen. Eine Activity ist jedoch nicht 5

11 von sich selbst aus sichtbar. Um Elemente wie Text, Buttons oder Grafiken auf den Bildschirm zu zeichnen, ist eine View notwendig, welche an die Activity gekoppelt wird. Der Lebenszyklus einer Activity teilt sich in drei Schleifen auf. Die Schleifen unterscheiden, ob die Activity gestartet oder komplett beendet wird, ob sie im Hintergrund läuft oder ob sie sich im Vordergrund befindet (siehe [Andc]). Abbildung 2 stellt den Lebenszyklus grafisch dar. Activity launched oncreate() User navigates to the activity onstart() onresume() onrestart() App process killed Apps with higher priority need memory Activity running Another activity comes into the foreground onpause() The activity is no longer visible onstop() User returns to the activity User navigates to the activity The activity is finishing or being destroyed by the system ondestroy() Activity shut down Abbildung 2: Activity-Lebenszyklus (siehe [Andc]) Ein Service arbeitet ähnlich wie eine Activity, verfügt aber über keine Bedienoberfläche. Eingesetzt werden Services bei Operationen, die eine Anwendung im Hintergrund erledigt, ohne dass der Nutzer direkt auf den Ablauf der Operation Einfluss nimmt. So ist es möglich, dass eine Anwen- 6

12 dung mit einer Activity sichtbar ist, während eine andere Anwendung parallel dazu eine Aufgabe im Hintergrund mit Hilfe eines Service verrichtet. Damit ein Service unabhängig von der Anwendung arbeiten kann, von der er aufgerufen wurde, muss er jedoch zusätzlich einen neuen Thread starten. Er arbeitet dann im selben Speicherbereich wie die eigentliche Anwendung. Um Anwendung und Service klar zu trennen, kann ein Service jedoch in einem eigenen Prozess gestartet werden. Somit wird ihm ein eigener Speicherbereich zugeteilt, was die Kommunikation mit der Hauptanwendung aber umständlicher macht. Der Content Provider verwaltet den Zugriff auf Daten, die sich innerhalb von Android-Anwendungen befinden. Über ihn können Anwendungen auf die Daten von anderen Anwendungen zugreifen oder eigene Daten öffentlich machen. Die Androidplattform unterstützt von Haus aus verschiedene Datenformate wie zum Beispiel für Audio-, Video oder Bilddateien. Daten die frei auf dem Speicher des Androidgeräts abgelegt sind, können mit den Standard-Methoden von Java geladen und geschrieben werden. Der Broadcast Receiver ist für Systemnachrichten zuständig. Beispielsweise Nachrichten über den Akkuzustand oder den Netzwerkempfang werden über den Broadcast Receiver abgewickelt. Die genannten Komponenten, welche eine Android Anwendung ausmachen, müssen nicht zwingend alle in einer Anwendung enthalten sein. Das Framework, welches in dieser Arbeit entwickelt werden soll, wird zum Beispiel auf den Service verzichten, da Hintergrundoperationen ausschließlich in Threads abgewickelt werden sollen. Weitere Komponenten, die wichtig für eine Augmented Reality Anwendung sein können, sind der Location Manager (siehe [Andd]) und der Sensor Manager (siehe [Ande]). Mit ihnen lässt sich die Position des Smartphones per GPS oder auch anhand des Mobilfunknetzes bestimmen, sowie die räumliche Ausrichtung der Kamera. Ein Beispiel wäre, dass in einem größeren Gebiet, welches die Messgenauigkeit von GPS klar überschreitet, mehrere Marker verteilt sind, die vom System erkannt werden sollen. Ist zusätzlich eine grobe Postion der Marker bekannt, so kann das Trackingsystem anhand der Positionsdaten des Smartphones von vornherein verschiedene Marker ausschließen, wenn diese in unerreichbarer Ferne liegen. So kann die Suche nach Markern vereinfacht werden Native Development Kit Das Native Development Kit (NDK) ermöglicht das Nutzen von C++ Code auf Android Geräten (siehe [Andf]). Da diese Funktion in dieser Arbeit nicht genutzt wird, soll es nur kurz erwähnt werden. Wie bereits in Abschnitt beschrieben, nutzt Android normalerweise Javacode, der von der DVM verwendet wird. Die Speicherverwaltung der virtuellen Maschine und das Fehlen von Pointern in Java kann jedoch bei manchen Anwen- 7

13 dungen zum Einbüßen von Rechengeschwindigkeit führen. Durch das Java Native Interface (JNI), welches mit dem NDK mitgeliefert wird, kann C++ Code an entsprechende Android-Java Klassen angebunden werden. Neben der Beschleunigung von CPU-lastigen Operationen kann bestehender C++ Code leicht in Android-Anwendungen eingebracht werden. 2.2 Augmented Reality Augmented Reality deckt einen Bereich zwischen Realität und Virtualität ab. Im Fall dieser Ausarbeitung wird also das Kamerabild eines Smartphones oder Tablet PCs mit virtuellen Elementen eines Renderers überlagert. Wird Realität und Virtualität vermischt, spricht man von Mixed Reality. Eine genaue Abgrenzung der Teilbereiche ist nicht möglich, weswegen Milgram (siehe [Mil94]) von einem Kontinuum spricht. AR steht nun dafür, dass der reale Anteil gegenüber dem virtuellen überwiegt. Abbildung 3: Realitäts-Virtualitäts Kontinuum von Milgram (siehe [Mil94]) Nötige Voraussetzungen für ein System, um als AR-System bezeichnet zu werden, sind nach Azuma (siehe [Azu97]) folgendermaßen definiert: Kombination von Realem und Virtuellem Interaktion in Echtzeit Registrierung der echten Welt in 3D Der letzte Punkt besagt, dass sich die virtuellen Elemente an der echten Welt ausrichten und nicht nur über das reale Bild statisch überblendet werden. Ein erstes System, welches diese Voraussetzungen erfüllt, wurde 1968 von Ivan Sutherland entwickelt (siehe [Sut68]). Er stellte das erste Head Mounted Display (HMD) vor, welches aufgrund der geringen Rechenleistung nur ein Gittermodell über die reale Welt legte (siehe [Wag07], S. 15). Abbildung 4 zeigt das HMD an einem Sensor, der die Blickrichtung und Position bestimmt. Die Bewegungsfreiheit des Probanden war durch die feste Installation des Sensors stark eingeschränkt. 8

14 Abbildung 4: HMD an Bewegungssensor (siehe [Sut68]) Mehr Freiheit bot das 1997 entwickelte System MARS (= mobile augmented reality system). Die Weiterentwicklung der genutzten Hardware machte es für den Probanden möglich, das System mit sich herum zu tragen. Die Rechenleistung war im Gegensatz zu Sutherlands ersten HMD ebenfalls größer, sodass nicht nur ein Gittermodell, sondern richtige 3D Objekte im HMD eingeblendet werden konnten. Zusätzlich verfügte der Benutzer über ein 2D-Display, welches auch als Eingabegerät diente. Zur Ortsbestimmung wurde GPS benutzt (siehe [FMHW97]). Abbildung 5 zeigt einen Probanden mit MARS. Abbildung 5: Proband mit Computer, HMD und 2D-Display (siehe [FMHW97]) In der folgenden Abbildung 6 wird die weitere Entwicklung von mobilen Geräten bis 2007 nach Wagner (siehe [Wag07], S. 4) dargestellt. Jede Form hat seine eigenen Vor- und Nachteile. Man kann sagen, dass die Rechenleistung von links nach rechts abnimmt. Das gilt auch für Größe und Gewicht 9

15 der Geräte. Dadurch wird die Funktionalität aber ebenso eingeschränkt. Während in a) der Benutzer beide Hände frei und durch ein HMD die beste Integration von Virtuellem und Realem hat, ist bei b) noch eine einigermaßen exakte Interaktion aufgrund des großen Displays möglich. Bei c) und d) werden Nutzereingaben immer schwieriger, wohingegen aber eine bessere Mobilität gewährleistet ist. Die Grafik unterscheidet noch zwischen PDA und Mobiltelefon. PDAs dienten bisher als kleine Minicomputer und boten im Gegensatz zu Handys ein etwas größeres Display und vor allem eine Touchfunktion. Mittlerweile sind diese beiden Variationen funktionell zu den bekannten Smartphones verschmolzen. Abbildung 6: a) Computer und HMD, b) Tablet PC, c) PDA, d) Mobiltelefon (siehe [Wag07], S. 4) Azuma stellte des Weiteren schon 1997 sechs verschiedene Anwendungsbereiche für Augmented Realtity vor: Medizin, Fabrikation und Instandsetzung, Annotation und Visualisierung, Planung von Roboterbewegungen, Unterhaltungselektronik, militärische Flugzeuge. Im Militärbereich sollen HMDs einmal die Head Up Displays (HUD) ersetzen. In den anderen Bereichen wird Augmented Reality dazu genutzt, um eine räumliche Planung zu erleichtern. In der Medizin ist es denkbar, Eingriffe mit AR besser planen zu können, indem dem Arzt die Lage eines Tumors direkt am Patienten angezigt wird (siehe [Azu97]). Abbildung 7 zeigt ein Beispiel für eine AR-Anwendung. Im Hintergrund ist ein einfacher Marker zu erkennen. Zu diesem wird in der Videoansicht des Handys ein 3D-Objekt hinzugefügt. Die Grundlage ist also das reale Bild und dieses wird mit einem virtuellen Element erweitert. Bezogen auf das Mixed Reality Kontinuum nach Milgram handelt es sich also um Augmented Reality. 10

16 2.3 Smartphones Abbildung 7: Beispiel für AR (siehe [Wag07], S.25) Smartphones sind in der Gesellschaft weit verbreitet. Einer Studie von IMS Research zufolge (siehe [IMS]) machen Smartphones 28% der gesamten Handyverkäufe aus (Stand Juli 2011). Bis 2016 sollen die Verkaufszahlen noch weiter steigen. Smartphones sind also auf dem Weg dahin, ein Alltagsgegenstand zu werden. Ensprechend können AR-Anwendungen immer größere Teile der Bevölkerung erreichen, da keine spezielle und unkomfortable Hardware wie im Beispiel von MARS benötigt wird. Mobile Geräte sind in der Regel darauf ausgelegt, lange Akkulaufzeiten zu erreichen. Dies schlägt sich auf die Prozessorleistung, sowie die Kapazität und Geschwindigkeit des Arbeitsspeichers nieder (siehe [JR09]). Es ist also besonders darauf zu achten, Datenaustausch innerhalb der Anwendung gering zu halten, Berechnungen geschickt zu implementieren und nur unbedingt notwendige Aktionen auszuführen. Das erste Smartphone, welches mit Android betrieben wurde, war das HTC Dream oder auch T-Mobile G1, welches 2008 auf den Markt kam und eine Taktrate von 528MHz mit 192MB RAM erreichte (siehe [wikb]). 11

17 Abbildung 8: HTC Dream bzw. T-Mobile G1 (Quelle [wikb]) Die Rechenleistung von Smartphones entwickelt sich jedoch sehr schnell wurden mit dem HTC Desire schon 1GHz Singlecore und 512MB RAM geboten (siehe [wikc]). Das Samsung Galaxy S2, welches 2011 auf den Markt kam, erreicht dann bereits mit einem 1,2GHz Dualcore und 1GB RAM eine beachtliche Leistung (siehe [wikd]). Die Entwicklung wird jedoch durch die der Akkuleistung beeinträchtigt (siehe [mob]). Die steigende Leistung der Geräte kann durch Energieeffizienz oder durch einen größeren Akku nicht kompensiert werden, da sich dieser Bereich nicht so schnell entwickelt. In den Anfängen von AR wurden feste, externe Monitore oder Head Mounted Displays als Anzeigegeräte benutzt (siehe [Azu97]). Bei Smartphones ist nun zu beachten, dass der Nutzer immer nur eine Hand zur Interaktion mit anderen Objekten frei hat. Dafür kann das Smartphone als Interaktionsobjekt selbst dienen. Smartphones haben außerdem den Anspruch, immer und überall nutzbar zu sein. Selbst Internetnutzung ist mit einem Smartphone fast überall möglich. So wäre es auch denkbar, Anwendungen mit Diensten im Internet zu verknüpfen und gewisse Aufgaben auf Servern zu erledigen, was natürlich von der Bandbreite abhängig ist. Übertragen auf eine AR-Anwendung auf Smartphones bedeutet das, dass bekannte Benutzerinteraktionen mit Markern zwar möglich sind, aber die Unabhängigkeit von Smartphones dadurch eingeschränkt wird. Beispielsweise Tangible User Interfaces (TUI) nutzen einen realen, physikalischen Gegenstand, der vom System getrackt wird, als Interaktionsobjekt (siehe [BKP97]). Es ist aber nicht davon auszugehen, dass jeder Anwender zusätzlich einen Marker mit sich trägt, um eine bestimmte Anwendung nutzen zu können. Eine spontane und für jedermann zugängliche Einsatzmöglichkeit ist nur dann gewährleistet, wenn neben dem Smartphone keine weiteren Voraussetzungen gegeben sind, um eine Anwendung zu nutzen; umgebungsbezogene Anwendungen ausgenommen. 12

18 3 Bestehende Frameworks In diesem Abschnitt sollen Augmented Reality Frameworks näher vorgestellt werden. Nach allgemeinen Hintergrundinformationen wird das AR- Toolkit, das ARToolkit Plus und Studierstube ES beschrieben. Diese stellen eine wichtige und die erste Entwicklungslaufbahn dar, die auch einen Zweig für mobile AR-Frameworks enthält. Anschließend wird auf AndAR und QCAR eingegangen. Diese beiden Frameworks richten sich speziell an Android. Somit bieten sie eine gewisse Vergleichbarkeit zu dem Framework, welches in dieser Arbeit entwickelt wird, und es soll kurz auf die Vorgehensweise beim Gebrauch beider eingegangen werden. 3.1 Ordnung von Frameworks Frameworks für AR lassen sich nach Looser und Billinghurst (siehe [LB05]) in drei Kategorien unterteilen: Low-Level Toolkit: Bietet einen hohen Grad an Flexibilität, benötigt aber eine lange Entwicklungszeit für komplexe Anwendungen (Bsp.: ARToolkit (siehe[arta], [WS07a]) und MXRToolKit (siehe [MXR]) High-Level Toolkit: Stellt eine große Auswahl an integrierten Services bereit, lässt sich besser auf andere Plattformen übertragen und stellt eine einfache Möglichkeit dar, AR-Anwendungen zu implementieren (Bsp.: ARTHUR (siehe [BLO + 05])) Rapid-Prototyping Tool: Richtet sich an Nutzer ohne oder mit wenig Programmierkenntnissen. Umsetzung erfolgt in Scriptsprachen oder komplett durch Autorensoftware (Bsp.: DART (siehe [MGDJ04])) 3.2 Interaktion und User Interface AR bringt neben der Darstellung von Inhalten auch neue Möglichkeiten zur Interaktion mit sich. Von Billinghurst (siehe [BKP]) werden Tangible AR-, Hybrid AR-Interfaces und Collaborative AR als wichtige Aspekte genannt. Tangible AR überträgt das Konzept, virtuelle Objekte durch physikalisch vorhandenen Gegenstände zu steuern, auf AR. Dies ist besonders intuitiv, da die realen Elemente grafisch überlagert werden können und so noch einen besseren Bezug zu ihrer Funktion erhalten. Hybrid AR Interfaces vereinen mehrere Methoden zu einem ergänzenden oder alternierenden Gesamtsystem. Hier sind Kombinationen aus physikalischen Eingaben, Touchscreens und Sprachkommandos denkbar. Auch das Feedback einer Anwendung kann auf haptische, visuelle oder akustische Weise erfolgen. 13

19 Collaborative AR bietet die Möglickeit für mehrere Benutzer in ein und der selben physikalischen, als auch virtuellen Umgebung, zu arbeiten. Die drei genannten Interaktionstechniken sind vor der Zeit von Smartphones entstanden. Eine neue Technik wird von Lee (siehe [LYKK06]) vorgestellt. Die so genannte Freeze-Set-Go Interaktionsmethode (FSG) berücksichtigt besonders das Handhaben von Handheld-Geräten mit Touchscreen. Wenn ein Nutzer auf einem Touchscreen eines Smartphones mit der virtuellen Umgebung interagieren soll, wird er es in der Regel in der einen Hand halten und mit der anderen bedienen. Dabei kann das Bild schnell verwackeln, womit die Bedienung erschwert wird. Anstrengend ist auch die Interaktion innerhalb eines Bereichs über dem Kopf des Anwenders. Noch schwieriger ist der Fall, wenn der Benutzer sich in Bewegung befindet und sogar immer wieder den Blick von der Anwendung nehmen muss, während sich ständig die Perspektive der AR-Szene verändert. Um diese Probleme zu umgehen, soll dem Benutzer eine Funktion angeboten werden, das Live-Kamerabild einzufrieren. Das reale Bild steht dann still und virtuelle Objekte können aus der statischen Perspektive heraus manipuliert werden. Das Tracking wird in dieser Zeit auch ausgesetzt, da sich die virtuelle Szene an dem eingefrorenen Bild orientiert. Sobald der Nutzer mit seinem Vorhaben fertig ist, kann er das Livekamerabild wieder einschalten und die Änderungen werden auch in der liveaugmentierten Darstellung beibehalten. 3.3 ARToolkit Das ARToolkit (siehe [ARTa]) ist ein Low-Level Framework, dessen Entwicklung Ende der 90er Jahre an der University of Washington begann. Es bietet Unterstützung für viele Plattformen (Windows, Linux, Mac OS X, SGI) und Geräteschnittstellen (USB, Firewire, Capture Card). Da zur Entwicklungszeit Smartphones noch kein großes Thema waren, ist das Framework auch nicht auf die Nutzung mit Smartphones optimiert. Es gibt allerdings zwei Weiterentwicklungen, die auf dem ARToolkit basieren, welche die Besonderheiten von Smartphones, bzw. Mobiltelefonen zu berücksichtigen versuchen. Das Framework ist unter der GNU General Public License veröffentlicht und somit für jedermann nutzbar. 3.4 ARToolkit Plus ARToolkit Plus ist eine Weiterentwicklung von ARToolkit, welche von Wagner und Schmalstieg bis einschließlich 2006 umgesetzt wurde. Es soll im 14

20 Folgenden vorgestellt werden (siehe [WS07a]). Das Projekt wurde eingeleitet, nachdem zuerst 2003 der Code von ARToolkit auf die mobile Windowsplattform Windows CE portiert wurde (siehe [WS03]). ARToolkit Plus ist eine optimierte Variante, welche sich speziell an Mobile Geräte richtet und in C++ verfasst ist. Nötige Berechnungen werden in Integer (fixed point) durchgeführt, da Float-Operationen aufgrund fehlender Floating-Point-Units (FPU) in manchen Smartphones, aber auch selbst mit FPU bis zu zweimal langsamer sind (siehe auch [Andg]). Bei der Bildverarbeitung, also dem Trackingvorgang, wird das von der Gerätekamera unterstützte Bildformat genutzt, um aufwändige Umrechnungen in andere Formate zu vermeiden. Um das Erkennen von Markern zu beschleunigen, liefert das Framework ein Set von vorgegebenen ID-Markern mit. In jedem ID-Marker ist seine ID codiert. Dadurch ist kein Matchen vom Kamerabild auf die Auswahl von möglichen Markern notwendig. Dem System können allerdings keine individuellen Marker antrainiert werden. Stationäre Trackingsysteme können auf die äußeren Begebenheiten angepasst werden. Bei mobilen Varianten ist die mögliche Änderung von Lichtverhältnissen besonders zu beachten. Wechselt man mit mobilen Geräten den Raum oder von drinnen nach draußen, ist mit starken Unterschieden in der Beleuchtung zu rechnen. Das kann den Erfolg des Trackings schnell beeinflussen. ARToolkit Plus bietet eine Vorgehensweise, die eine schnelle Anpassung an die Helligkeit leistet. Desweiteren werden an möglichst vielen Stellen Look-Up Tabellen eingesetzt, um Rechenzeiten möglichst gering zu halten. Um eine gewisse Portabilität zu gewährleisten, beschränkt sich das Framework nur auf Interfaces zum Eingeben von Kamerabildern und Ausgeben von Matrizen. Grund dafür sind die zahlreichen Betriebssysteme, die für mobile Geräte existieren und eine uniforme Anbindung der Kamera oder eines Rendersystems schwer möglich machen (siehe [WS07a]). ARToolkit Plus ist also nur durch die unterstützten Pixelformate beschränkt, dafür fehlen Methoden zur Weiterverarbeitung der Trackingergebnisse aber völlig und kann somit als Low-Level-Toolkit eingeordnet werden. Ebenso wie die Basis ARToolkit, ist dieses Framework auch unter der GNU General Public License verfügbar. Das Projekt wurde allerdings im Juni 2006 eingestellt (siehe [ARTb]). 3.5 Studierstube ES Studierstube ES ist ein weiteres Framework, das von Schmalstieg und Wagner entwickelt wurde (siehe [WS07b]). Es schloss sich zunächst an die Arbeit von ARToolkitPlus (siehe Abschnitt 3.4) an, indem Trackingelemente aus diesem Projekt übernommen wurden. Im Laufe der Entwicklung hat sich Studierstube ES aber komplett von seinem Vorgänger abgelöst und stellt ein von Grund auf neu entwickeltes System dar. Der größte Unterschied zu den vorangegangenen Frameworks ist ein Angebot von nützli- 15

21 chen Services, die über die reine Anbindung eines Trackers hinausgehen. So enthält Studierstube ES einen Netzwerkclient, der zum einen das Verknüpfen mehrerer Benutzer möglich macht und zum anderen Teilkomponenten einer Anwendung vom Smartphone auf den Server verlagern kann. Die Steuerung der Anwendung über den Server kann mit XML Inhalten gesteuert werden. Weiter wird ein XML-basierter Szenegraph angeboten, der für effizientes Rendern von 3D-Inhalten sorgt. Durch die gebotenen Services kann Studierstube ES dem Benutzer weitaus mehr Arbeit beim Entwickeln einer AR-Anwendung abnehmen, als ein alleinstehender Tracker. Deswegen kann es als High-Level-Toolkit eingeordnet werden. Durch die XML-Unterstützung der Netzwerk- und Renderkomponente können sogar Autorentools mit grafischer Oberfläche an das System angebunden werden. 3.6 AndAR AndAR stellt ein spezielles Framework für Android dar. Es basiert auf dem ARToolkit (siehe Abschnitt 3.3) und wurde im Rahmen einer Studienarbeit von T. Domhan entwickelt (siehe [Dom10]). AndAR zielt darauf ab, dem Nutzer eine Möglichkeit zu bieten, AR-Anwendungen für Android Geräte zu entwickeln, ohne Code über die Grenzen von Java und des Android- SDK hinaus implementieren zu müssen. Zum Tracken werden die Libraries aus ARToolkit genutzt, welche in C++ vorliegen. Diese werden dem Framework über das NDK zur Verfügung gestellt. Die Funktionalität der nativen Methoden ist in Java-Methoden gekapselt, sodass der Programmierer sich nicht mit dem NDK auseinandersetzen muss. Darüber hinaus nimmt AndAR dem Benutzer einige Voreinstellungen ab, die nötig sind, um 3D-Renderer und das Kamerabild zu verknüpfen. Es spezialisiert die Klasse Activity von Android (siehe Abschnitt 2.1.3) und erledigt dort die nötigen Schritte. Beim Programmieren legt man wiederum ein spezialisiertes Objekt dieser Klasse an und hat somit die von AndAR implementierte Funktionalität zur Verfügung. AndAR macht sich die Trackinglibrary von ARToolkit zunutze. Sobald es korrekt eingerichtet ist, wird dem Benutzer nach dem Trackingvorgang eine Transformationsmatrix geliefert, welche in OpenGL weiterverwendet werden kann. Das Kamerabild wird von AndAR durch den Renderer dargestellt. Das heißt, das Kamerabild wird an den Renderer gesendet und dieser stellt es als Textur auf einem Polygon im Hintergrund dar. Auf manchen Geräten kann das die Performance stark beeinflussen (siehe [JR09]). Zudem empfängt die Kamera unter Nutzung von AndAR Bilder im YCbCr Format. OpenGL unterstützt aber nur RGB Formate für Texturen. Es ist also pro Bild notwendig, dieses in ein anderes Format zu übersetzen und es zusätzlich als Textur zu rendern. In neueren Android Versionen kann die Kamera zwar auch RGB Bilder liefern, zugleich ist es aber möglich, den Renderer mit transparentem Hin- 16

22 tergrund auszustatten und ihn vor den Kamera-Livestream zu platzieren. So wird der Konvertierungsschritt und das Senden der Bilddaten an den Renderer vermieden. Diese Möglichkeit wird bei AndAR aber noch nicht genutzt. Als 3D-Objekte können Dateien im obj-format genutzt werden. Die obj-dateien werden intern in ein formatunabhängiges Objekt geladen. Deswegen ist es möglich, das Framework mit entsprechenden Parsern um die Unterstützung von weiteren 3D-Formaten zu erweitern. Um Pattern files für Markerobjekte zu erstellen, kann das von ARToolkit mitgelieferte Programm mk_patt verwendet werden. Abbildung 9 zeigt die Systemarchitektur von AndAR. Für den Benutzer sind letztendlich nur die drei Custom-Klassen von Belang. Die Funktionsweise der Klassen wird im folgenden Abschnitt zum Nutzungsbeispiel beschrieben. Abbildung 9: AndAR Systemarchitektur (siehe [Dom10], S. 31) AndAR bietet keine weiteren Services und kann deshalb als Low-Level- Toolkit eingeordnet werden Nutzungsbeispiel Nun soll beschrieben werden, was nötig ist, um ein einfaches 3D-Objekt auf einem Marker zu platzieren. Die Beschreibung orientiert sich an dem AndARSampleProjekt, welches auf der Projektseite 1 von AndAR zu finden ist. Als Basis für die Anwendung dient die CostumActivity. Diese leitet sich von

23 der AndARActivity, welche die nötige Funktionalität beinhaltet, um Tracking, Rendering und das Anzeigen des Kamerabildes zu ermöglichen, ab. Alles was hier getan werden muss, ist ein CustomObject anzulegen und es beim Tracking des ARToolkits zu registrieren, indem man ein Patternfile übergibt. Optional kann hier noch ein CustomRenderer zugefügt werden, der die OpenGL Umgebung mit Initialisierungswerten versieht. Das CustomObject, welches zuvor mit einem Marker initialisiert wurde, ist in der Lage, 3D-Objekte auf diesen Marker zu zeichnen. Dazu kann der Benutzer die im Objekt enthaltene draw()-methode überschreiben, welche der gleichnamingen OpenGL-Methode entspricht. Hier kann die von Android angebotene OpenGL API verwendet werden. Es müssen also Vertices definiert (oder geladen) und Materialeigenschaften eingestellt werden. Im Custom- Renderer werden, wenn gewünscht, alle Objekte erstellt, welche sich unabhängig vom Tracking verhalten sollen. Beispielsweise eine Lichtquelle, welche ebenfalls mit der Standard-OpenGL-Syntax implementiert wird. Einen Marker in AndAR zu benutzen und ein 3D-Objekt entsprechend zu transformieren ist sehr einfach. Im Grunde reichen hierfür zwei Schritte aus: Anlegen des Objekts und Registrieren des Objekts beim Tracker. Das 3D- Objekt zu zeichnen ist aber vollkommen dem Programmierer überlassen. Hier müssen OpenGL-Kenntnisse vorhanden sein, um Elemente zu rendern und sichtbar machen zu können. AndAR kann also eher als Tracking- Library angesehen werden, genauso wie seine Basis ARToolkit. 3.7 QCAR Das Qualcomm Augmented Reality SDK ist ein vom Qualcomm Developer Network (siehe [Qua]) entwickeltes Framework, welches im April 2011 in der Version 1.0 erschienen ist. Ziel ist die optimale Umsetzung von Bildverarbeitung im Zusammenhang mit AR auf Smartphones. Das SDK unterstützt sowohl Android- als auch ios-geräte. Abbildung 10 zeigt die grobe Struktur einer Anwednung, die auf dem Framework basiert. 18

24 Abbildung 10: QCAR Entwicklungsprozess (siehe [Qua]) Vom Framework wird die QCAR Library angeboten. Sie sorgt für das Verwalten der nötigen Komponenten wie Kamera und Tracker und bildet den Kern des Frameworks. Weiter gibt es ein eigenes Datenformat für trackbare Elemente. Von diesen gibt es drei Varianten: Image Targets, Multi Targets und Frame Marker. Um solche Targets selbst zu erstellen, wird auf der Webseite 2 von Qualcomm ein eigenes Tool angeboten. Dort wird eine Datei erstellt, welche dem Tracker des Frameworks das Tracken des gewünschten Bildes ermöglicht. Bei den Image Targets handelt es sich um Bilder, die mit Hilfe von Natural Feature Tracking geortet werden können. Eine Besonderheit ist, dass darauf reagiert werden kann, wenn bestimmte Bereiche des Image Targets verdeckt werden. Diese Bereiche werden Virtual Button genannt. Abbildung 11 zeigt ein Beispiel eines Image Targets mit 3D-Objekt benötigt Nutzeraccount Abbildung 11: QCAR Image Marker (siehe [Qua]) 19

25 Multi Targets sind eine Kombination aus mehreren Image Targets. So kann zum Beispiel jede Seite eines Würfels mit einem Image Target belegt werden und jedes dieser Targets liegt dann im selben Koordinatensystem. Frame Marker kommen ohne Natural Features aus. Sie erinnern an die einfachen schwarz-weißen Marker, unterscheiden sich jedoch darin, dass im Rand jedes Markers eine ID binär kodiert ist. Der Innenteil der Marker kann dann mit beliebigen Bildern gefüllt werden. ID Marker sind bereits aus Abschnitt 3.4 bekannt. Die Verarbeitungspipeline von QCAR ist ähnlich der von AndAR, durch Spezialisierung auf bestimmte Geräte jedoch effizienter. Nach dem Start der Kamera werden also regelmäßig Kamerabilder abgegriffen und in Bildformate konvertiert, die vom Renderer bzw. vom Tracker verwendet werden können. Der Renderer nutzt das Bild wie AndAR, um den Videohintergrund als Textur auf einem Polygon zu rendern. Der Tracker erhält ein Format zur performanten Bildverarbeitung. Nach jedem verarbeiteten Bild steht die resultierende Kameramatrix für den Renderer zur Verfügung. Zusätzlich können auch anwendungsbezogene Informationen vom Tracker erhalten werden, beispielsweise das Aktivieren eines Virtual Button. Die Implementierung des Renderers ist auch hier vollkommen dem Benutzer überlassen. QCAR vereinfacht aber das Initialisieren wichtiger AR-Komponenten und bietet eine grafische Oberfläche zum Erstellen von eigenen Image Targets. Damit ist es stets als Low- Level-Framework anzusehen und wie bei AndAR liegt der Fokus auf der Trackingkomponente, da die Renderkomponente außen vor gelassen wird Nutzungsbeispiel In diesem Abschnitt sollen für QCAR ebenfalls die nötigen Schritte zum Anzeigen eines einfachen 3D-Objekts auf einem Marker bzw. Image Target beschrieben werden. Zunächst sind ein paar Initialisierungen notwendig. Der Programmierer muss das Starten und Stoppen der Kamera kontrollieren, d.h. er gibt an, wann getrackt wird und wann nicht. Kamerabilder werden dann automatisch an den Tracker weitergeleitet. Gerätespezifisch kann noch ein Image Converter eingestellt werden, der das von der Kamera gelieferte Bild in passende Formate für Renderer und Tracker umwandelt. Der Renderer übernimmt das Bild, um den Videohintergrund hinter den 3D-Objekten zu rendern. Einstellungen hierzu muss der Nutzer selbst treffen. Die Voreinstellungen sind damit abgeschlossen. Für jedes verarbeitete Bild wird ein so genanntes State Object aktualisiert. Dieses enthält alle Ergebnisse eines Trackingvorgangs. Der Programmierer muss nun den Inhalt des State Objects abfragen und an den Anwendungscode weitergeben. Unter anderem ist hier die Transformationsmatrix enthalten, die 3D-Objekte auf einen Marker abbildet. Hier endet jedoch der Einfluss des Frameworks. Die Weiterverarbeitung durch den Renderer bleibt dem Benutzer überlassen. QCAR ist etwas schwieriger, da mehrere Schritte notwendig sind, um 20

26 das Tracken und Rendern einzuleiten. Außerdem zwingt es den Benutzer dazu, das NDK zu benutzen. Zugriff auf das State Object wird zum Beispiel nur im C++ Code angeboten. Das Framework ist also eher für fortgeschrittenere Benutzer und komplexere Anwendungen geeignet. 4 AiRmob Wie bereits in Abschnitt 1.3 erwähnt, soll das AiRmob-Framework eine einfache Lösung zum Entwickeln von AR-Anwendungen bieten. Die Struktur zielt auf eine Zwischenlösung von Low- und High-Level Toolkit ab. Ein einfacher Einstieg für den Nutzer steht für die High-Level-Ansicht, die Möglichkeit eigene Renderer und Tracker zu integrieren, für die Low- Level-Ansicht. Im Folgenden wird auf den Baustein dieser Teilarbeit eingegangen und die Schnittstellen zu den anderen Arbeiten beschrieben. 4.1 Zieldefinition der Teilarbeit Die Anwendungs- und Interaktionskomponente ist der Teil des Frameworks, der primär vom Programmierer dazu benutzt wird, um das Framework zu kontrollieren und in eine Android-Anwendung zu integrieren. Hier können Voreinstellungen zum Tracker und Renderer getroffen und die Kamera kontrolliert werden. Weiter sind Funktionen, welche für AR-Anwendungen nützlich sind und auf Android-Funktionen basieren, so gekapselt, dass eine einfache Nutzung ermöglicht wird. Beispielsweise eine Verknüpfung von GPS-Daten und Markern oder bestimmte Eingabeoperationen des Endnutzers, welche auf den Renderer abgebildet werden. Die Verknüpfung der anderen Teilarbeiten wird ebenfalls von dieser Komponente übernommen. Eine Eingliederung in die Kategorien nach Looser und Billinghurst (siehe [LB05]) ist nicht eindeutig möglich. Einerseits kann man von einem High- Level Framework ausgehen, da dem Benutzer ein Interface von komplexeren Operationen zur Verfügung gestellt wird, welche grundlegendere Funktionen zusammenfassen. Andererseits ist es möglich, eigene Renderer oder Tracker zu implementieren und an das Framework anzuschließen, bzw. Kernfunktionen des Frameworks zu verändern. In diesem Fall würde man eher von einem Low-Level Framework sprechen. Wenn im Folgenden von einem Renderer die Rede ist, ist allgemein ein Renderer gemeint, der in der Lage ist, OpenGL-Inhalt zu zeichnen und sich durch die in dieser Arbeit vorgestellte Schnittstelle definiert. Wenn der spezielle Renderer gemeint ist, der in der Arbeit von Axel Peter entwickelt wurde, wird die Bezeichnung Engine, bzw. AiRmob-Engine verwendet. 21

27 4.2 Anforderungsliste Da alle vier am Framework beteiligten Arbeiten jeweils von den anderen abhängig sind, war es schwierig, eine genaue Anforderungsliste zu erstellen. Die im Folgenden genannten Punkte spiegeln deswegen lediglich die Grundidee wider, welche dieser Teilarbeit zugrunde liegt. Das Framework muss dem Benutzer das Verknüpfen von Renderer und Tracker erleichtern. Das Framework kann dem Benutzer das Verknüpfen von Renderer und Tracker abnehmen. Ein Renderer, der die AiRmob Oberklasse spezialisiert, soll automatisch Kameradaten empfangen. Ein Tracker, der die Airmob Oberklasse spezialisiert, soll automatisch Bilder als Trackingauftrag empfangen. Der Benutzer muss bei Standardeinstellungen des Frameworks keine spezielle Konfiguartion vornehmen, damit eine AR-Pipeline zustande kommt. Typische Funktionen, die bei AR-Anwendungen Verwendung finden, sollen vom Framework vereinfacht gekapselt werden. Das Framework muss ein Ausschlussverfahren für Marker in Abhängigkeit von GPS-Daten anbieten. Das Framework kann dem Benutzer verschiedene Android-Funktionen vereinfacht zur Verfügung stellen. Der Benutzer muss sich nicht um das Initialisieren der Kamera kümmern Das Framework ist so aufgebaut, dass einzelne Teilfunktionen der Oberklassen leicht überladen oder überschrieben werden können. 22

28 4.3 Systemarchitektur Autoren: Philipp Brandt, Florian Kathe, Nils Lichtenberg und Axel Peter In Abbildung 12 wird die Systemarchitektur des Frameworks, grob in die einzelnen Teilarbeiten aufgeteilt, dargestellt. Im Grunde ergibt sich hier eine Verarbeitungsschleife, die parallel zur eigentlichen Anwendungslogik einer App auf Basis des Frameworks abläuft. Framework Renderergebnis Empfängt Kamerabilder und verknüpft diese mit Engine und Tracker. Kamerabild Engine Verarbeitet Szene und Einstellungen zu gerendertem Bild View- und Projectionmatrix Tracker Berechnet die 3D- Pose eines angegebenen Objekts im Kamerabild Shader Rendert verschiedene Effekte auf die Szene unter Berücksichtigung übermittelter Werte Abbildung 12: Grobe Systemarchitektur Der Einstieg in die Schleife geschieht an der Komponente Framework. Hier wird nach einigen Initialisierungsschritten das Kamerabild empfangen und kontinuierlich an den Tracker weitergegeben. Der Tracker sucht in jedem Kamerabild, was er bekommt, nach einem vorher angegebenem Marker oder einer Textur. Wird eine Übereinstimmung gefunden, ist der nächste Schritt, die Lage des Objektes im Kamerabild zu bestimmen. Aus dieser Lage kann dann eine 3D-Pose (Viewmatrix) bestimmt werden, die im Framework weitergegeben wird. Zusätzlich wird bei der Initalisierung des Trackers noch eine Projectionmatrix berechnet, die auch in jedem Schleifendurchlauf an die Engine weitergegeben wird. Die Engine zeichnet die vom Programmierer angelegte Szene. Dazu wird die vom Tracker angereichte View- und Projectionmatrix genutzt, um die 3D-Objekte korrekt zur realen Welt zu platzieren. Mit diesen und aus der Szene ermittelt die Engine sämtliche zu zeichnenden Werte und übergibt sie an die Shader, um sie zu zeichnen. Die Shader nehmen je nach ihrer Aufgabe alle benötigten Werte entgegen 23

29 und berechnen die gewünschten Effekte. Bei mehreren Auswahlmöglichkeiten zu einem bestimmten Effekt (bspw. Beleuchtung), werden vom Benutzer festgelegte Entscheidungen mittels Variablen übermittelt. Die durch die ausgewählten Effekte berechneten Farb- oder Tiefenwerte werden wieder an den Renderer zurückgegeben. Die Ergebnisse der verschiedenen Shader werden verknüpft und das finale Renderergebnis an das Framework übermittelt. Das Renderergebnis wird anschließend in der Frameworkkomponente mit dem Livekamerabild überlagert, wodurch sich das fertige Ergebnis eines Verarbeitungsdurchgangs ergibt. Autor: Nils Lichtenberg Die grundlegende Architektur des AiRmob-Frameworks (siehe Abbildung 13) greift auf zwei Komponenten des Android-SDKs zu, die Activity und das Renderer-Interface zum Darstellen von OpenGL Inhalten. Ein Bestandteil des Renderers sind diverse Shader. Auf deren Integration wird in dieser Arbeit nicht eingegangen. Die AiRmobActivity spezialisiert die Activity und dient in erster Linie dazu, die AR-Komponenten Tracker und Renderer zu verknüpfen und auf einem Android-Gerät nutzbar zu machen. Die genaue Funktionsweise wird in den folgenden Abschnitten im Detail vorgestellt. Dabei soll der Aufbau Schritt für Schritt, angefangen bei einer groben Darstellung, verfeinert dargestellt werden. Zunächst werden beteiligte Klassen im Gesamtsystem erklärt und im weiteren Verlauf wird auf diese im Detail eingegangen. «component» AiRmobRenderer Integration Renderer «component» AiRmobActivity Integration Tracker «component» AiRmobTracker Erweiterbarkeit Renderer Interface Shader «component» Android-SDK «component» OpenGL «component» Activity Abbildung 13: Grobe AiRmob-Systemarchitektur im Komponentendiagramm Die AiRmobActivity muss dem Renderer und dem Tracker nicht direkt bekannt sein. Eine Kommunikation in beiden Richtungen ist dennoch möglich. Das Framework benutzt dazu einen Callbackmechanismus, der die 24

30 Android-Klasse Handler und das Java-Interface Runnable verwendet. Durch sie kann eine Activity aufgefordert werden, eine Aktion in ihre Abarbeitungsschlange aufzunehmen. Die Funktionalität wird im anschließenden Abschnitt beschrieben Handler und Runnable Klassen, die das Runnable-Interface implementieren, enthalten eine run()- Methode, die der eines Threads gleicht. Sobald das Runnable ausgeführt wird, wird diese Methode aufgerufen. Zusätzlich kann ein Runnable Daten enthalten, die vom aufrufenden Thread bereitgestellt und vom ausführenden Thread verarbeitet werden können. Damit ist ein Datenaustausch zwischen verschiedenen Threads realisierbar. Instanzen eines Runnable-Objekts sind beliebig oft wiederverwendbar. Die Klasse Handler ist im Android-SDK enthalten. Sie dient dazu, Runnable Objekte als Verarbeitungsauftrag in die Auftrags-Warteschlange einer Activity hinzuzufügen. Sobald ein Runnable-Objekt an der Reihe ist, wird dessen run()-methode aufgerufen. Ein Beispiel: Die Activity A und Klasse B arbeiten in verschiedenen Threads, beiden ist das Runnable R bekannt. R enthält eine Variable int i und die run()-methode inkrementiert i um 1 und gibt den Wert von i auf der Konsole aus. B legt nun eine Instanz von R an und belegt i mit dem Wert 1. Anschließend sendet B die Instanz des Runnables an den Handler von A. Das Runnable befindet sich nun in der Warteschleife von A. Sobald es ausgeführt wird, wird A den Wert von i um 1 erhöhen und gibt den neuen Wert auf der Konsole aus. Rein funktionell hat dies den Effekt, dass B den Auftrag gibt i zu erhöhen. In der eigentlichen Umsetzung ist es aber so, dass das Inkrementieren und Ausgeben von i im Thread von A stattfindet. Eine andere Einsatzmöglichkeit ist es, eine Activity durch den Callbackmechanismus dazu zu bringen, auf ein bestimmtes Ereignis zu warten. Ein Beispiel hierfür wäre, dass eine AiRmobActivity darauf wartet bis der Renderer fertig initialisiert ist, um dann einen Spielablauf zu starten. Der Renderer kann durch ein Runnable eine Methode innerhalb einer Activity- Instanz aufrufen, sobald dieser fertig geladen ist. Eine zweite Möglichkeit ist es, innerhalb der Activity einen weiteren Thread anzulegen, der die Bedingung eines Ereignisses in bestimmten Zeitabständen überprüft. Sobald diese erfüllt ist, wird ein Runnable an den Hauptthread der Activity gesendet und dieser veranlasst, in bestimmter Art und Weise weiterzuarbeiten. Würde man im Hauptthread der Activity auf das Laden des Renderers warten, wären in dieser Zeit keine anderen Interaktionen mehr möglich, da der Hauptthread belegt wäre. Kommunikation zwischen Threads ist im AiRmob-Framework auf die hier 25

31 beschriebenen Arten realisiert, sobald eine asynchrone Verarbeitung duldbar oder nötig ist AiRmobActivity Die AiRmobActivity ist die Kernklasse des Frameworks. Sie ist eine Unterklasse der Android-Activity (siehe Abschnitt 2.1.3) und ist somit für die grundlegenden Funktionen einer Anwendung verantwortlich. Hier werden wichtige Initialisierungen erledigt und nötige Einstellungen auf Defaultwerte gesetzt. Die Initialisierung läuft wie folgt ab und kann mit Abbildung 14, 15 verglichen werden: AiRmobActivity angelegt SurfaceView anlegen AiRmob- GLSurfaceView anlegen Tracker und AiRmobCamera anlegen PipelineHandler anlegen Renderer hinzufügen AiRmobCamera starten Renderer und Tracker mit Kameraparametern versorgen Kamera und Tracker bereit Renderer bereit Abbildung 14: Initialisierung der AiRmobActivity Die Trapezförmigen Elemente sollen hier andeuten, dass bei der Initialisierung grundlegend zwei voneinander unabhängige Abläufe abgearbeitet werden. Dies steht nicht für parallele Programmausführung. 26

32 Die Initialisierung erfolgt bezüglich des Activity-Lebenszyklus größtenteils in der oncreate-methode (siehe Abschnitt 2). Das heißt, alle nötigen Funktionsaufrufe werden einmalig beim Anwendungsstart ausgeführt. Lediglich das Behandeln der Kamera geschieht durch einen Callbackmechanismus. Die AiRmobActivity implementiert das Interface SurfaceHolder.Callback. Dadurch wird sie immer darüber informiert, ob ihre visuelle Oberfläche erstellt, zerstört oder geändert wird (siehe [Andh]). Die Activity erhält dadurch außerdem Informationen über die Displayausmaße, wie Seitenverhältnis und Auflösung. Um eine unabhängige Darstellung von 3D-Grafik und Kameralivestream zu ermöglichen, sind zwei Views nötig. Die eine stellt den Inhalt des Renderers dar (AiRmobGLSurfaceView), die andere das Kamerabild (SurfaceView). Beide Views stellen zusammen die Oberfläche der Activity dar. Ein Beispiel wie zwei Views überlagert werden, kann auf der Website von Imran Nazar gefunden werden (siehe [Naz]). Die AiRmob- GLSurfaceView erweitert die Androidklasse GLSurfaceView lediglich um einen angepassten Konstruktor und Voreinstellungen, um mit dem Framework arbeiten zu können. Bei der Erstellung wird sofort ein Renderer hinzugefügt. Die AiRmobActivity erzeugt die beiden genannten Views und verknüpft sie entsprechend. Die AiRmobGLSurfaceView liegt dabei über der SurfaceView. Dadurch dass der Renderer mit Transparenz arbeitet und als Clearcolor volle Transparenz benutzt, kann das Kamerabild hinter den 3D-Objekten sichtbar werden. Nun werden Tracker und AiRmobCamera angelegt. Das Erstellen der Kamera geschieht durch die Klasse AiRmobCamera, sobald die SurfaceView vom Betriebssystem fertig erstellt wurde. Der nächste Schritt ist das Anlegen eines Pipelinehandlers, der zur Kommunikation zwischen Tracker und Renderer genutzt werden soll. Zuletzt wird die Kamera gestartet und verfügbare Kameraparameter an Renderer und Tracker weitergeleitet. Die Initialisierung einer AR-fähigen Activity ist damit abgeschlossen. Ab hier kann der Pipelinehandler gestartet und somit das Tracking und Rendern zum Laufen gebracht werden. Die Schritte Pipelinehandler anlegen und AiRmobCamera starten werden später noch genauer beschrieben. Der Einsatz der Klasse GPSAlertCreator ist optional, sie wird in Abschnitt erläutert. 27

33 Android.SurfaceView -beeinflusst -zeichnet AiRmobCamera 1 1 -enthält Android.Camera AiRmobGLSurfaceView 1 -enthält -enthält enthält AiRmobActivity 1 -enthält 1 -beeinflusst Pipelinehandler -zeichnet -enthält 1 -enthält 1 1 -enthält -sendetbild CustomRenderer GSPAlertCreator 1 CustomTracker AiRmobRenderer «interface» GLSurfaceView.Renderer AiRmobTracker Abbildung 15: AiRmob Framework im schematischen UML-Klassendiagramm Die folgende Abbildung 16 zeigt nun die AiRmobActivity im Detail mit den enthaltenen Feldern und Methoden, welche im anschließenden Text vorgestellt werden. Zunächst enthält die AiRmobActivity Instanzen derjenigen Klassen, welche nach Abbildung 15 in direktem Zusammenhang mit dieser stehen. Deren Aufgabe wurde bereits angedeutet und wird später noch genauer beschrieben. Der messagehandler ist eine Instanz des Android.Handlers, der bereits in Abschnitt vorgestellt wurde. Diese kann an andere Objekte weitergegeben werden, um diesen einen Zugriff auf die Abarbeitungsschlange der AiRmobActivity zu gewähren. activityisinfront wird von den Methoden onresume() und onpause() gesetzt, sodass der Wert Aussage darüber gibt, ob die Anwendung im Vordergrund aktiv ist oder nicht. Das kann in einer App dazu genutzt werden um Schleifen in Threads auslaufen zu lassen oder gewisse Funktionen innerhalb der Anwendungslogik auf einen der beiden Zustände zu beschränken. Ähnliches gilt für frontfa- 28

34 cecamera, also ob die dem Nutzer zu- oder abgewandte Gerätekamera benutzt wird. Hier muss der Wert aber vom Benutzer selbst gesetzt werden um so das Verhalten der Anwendung zu kontrollieren. AiRmobActivity +messagehandler : Handler #mcam : AiRmobCamera #activityisinfront : Boolean #frontfacecamera : Boolean #mcamsv : Android.SurfaceView #mcamsh : Android.SurfaceHolder #CAMERA_RES_ID : int #mglsurfaceview : AiRmobGLSurfaceView #mtracker : AiRmobTracker #mrenderer : AiRmobRenderer +pipeline : Pipelinehandler +locationmanager : Android.Locationmanager -toggled : Boolean +oncreate() +surfacecreated() +surfacechanged(eing. holder : Android.SurfaceHolder, eing. format : int, eing. width : int, eing. height : int) +surfacedestroyed(eing. holder : Android.SurfaceHolder) +onairmobinitialized() +onrenderercreated() +onrendererchanged() +activatelocationmanager() +onreceivemarker(eing. markerid : string, eing. entering : int) +setpipelinemode(eing. mode : int) +setpipelinebuffersize(eing. buffersize : int) +onpick(eing. id : Object) +togglefreeze() +getobjectbyname(eing. name : string) : Object +getallobjects() : Object[] +pickmarkerplane(eing. displayx : int, eing. displayy : int) : float[] +getrotationtotapposition(eing. tapx : int, eing. tapy : int, eing. objectx : float, eing. obkjecty : float) : double +onresume() +onpause() Abbildung 16: AiRmobActivity im Detail Eine Instanz von AiRmob.Locationmanager ist mit locationmanager vorgegeben und wird durch die Methode activatelocationmanager() initialisiert. Sie kann dann vom GPSAlertCreator (siehe Abschnitt 4.7.2) genutzt werden, um das Framework mit GPS-Ereignissen zu versorgen. Der Wert CA- MERA_RES_ID gibt dem Framework vor, mit welcher Auflösung die Kamera bei Start initialisiert wird. Zuletzt ist noch mcamsh zu nennen. Es reagiert auf den bereits genannten SurfaceHolder.Callback und ist mit mcamsv verknüpft. Man kann sagen, dass mcamsh das Kamerabild besitzt und mcamsv das Kamerabild anzeigt. oncreate(), surfacecreated(), surfacechanged(), surfacedestroyed() sind Methoden, die vom Betriebssystem aufgerufen werden und enthalten den Code um das Framework zu initialisieren, bzw. die Kamera wieder freizugeben. Die Methoden getobjectbyname() und getallobjects() können dazu genutzt werden, auf im Renderer registrierte Objekte zuzugreifen. Dies wird in Abschnitt 4.6 noch einmal aufgegriffen. Al- 29

35 le verbleibenden Funktionen bieten AR-spezifische Anwendungslogik an und werden in Abschnitt 4.4 erläutert Pipeline Dem System liegt eine einfache Schleife zugrunde, welche für das Tracken der Kamerabilder und das korrekte Einsetzen der virtuellen Elemente sorgt. Das Empfangen einzelner Bilder wird unter Android durch einen PreviewCallback gehandhabt. Dieser wird für jedes Bild, welches die Kamera im Livemodus anzeigt, aufgerufen und empfängt das entsprechende Bild. Zunächst wurde jedes Bild vom Callback empfangen und an den Tracker weitergegeben. Solange das Bestimmen der Kameramatrix und schließlich das Rendern aus der richtigen Perspektive aber die Bildwiederholrate überschreitet, ist dies überflüssig. Es soll also immer nur ein Bild gleichzeitig vom Tracker verarbeitet werden. Eine Semaphorenmechanik sorgte dann dafür, dass neue Bilder während der Berechnung eines vorherigen Bildes ignoriert wurden. Um diese Vorgehensweise zu testen, wurde ein sich drehendes Dreieck vor dem Live-Kamerabild gezeichnet. Obwohl der Tracker bei dem Test noch keine Arbeit verrichtete, außer eine Sekunde zu warten um dann die Semaphore erneut zu öffnen, kam es zu einer sichtbar stockenden Bewegung des Dreiecks. Abbildung 17 stellt den Ablauf des PreviewCallbacks und die Schleife, die parallel zum Tracking verläuft, grafisch dar. Tracking gestartet PreviewCallback anmelden Kameramatrix an Renderer senden ja Bild empfangen Tracking durchführen Ja Tracking fortführen? Semaphore offen? nein nein Ende Bild verwerfen Abbildung 17: PreviewCallback 30

36 Der OneShotPreviewCallback löste das Problem. Er liefert nur ein Bild und beseitigt sich danach von selbst. Code innerhalb des Callbacks wird also nur einmal aufgerufen und es werden keine weiteren Bilder empfangen. Hier wird das Tracking in einem eigenen Thread gestartet. Sobald das Tracking beendet ist und die Kameramatrix an den Renderer weitergegeben wurde, wird aus dem Tracking-Thread heraus ein neuer Callback angemeldet, sodass ein weiteres Bild abgerufen werden kann. Durch diese Methode werden keine Bilder empfangen, die anschließend verworfen werden und es ist garantiert, dass immer nur ein Bild gleichzeitig getrackt wird und dasselbe Bild niemals zweimal. Ein weiterer positiver Effekt ist, dass nicht unnötig Speicherplatz von Bildern belegt wird, die dann nicht verwendet werden. Abbildung 18 stellt den Verlauf im Diagramm dar. Tracking gestartet PreviewCallback anmelden Bild empfangen PreviewCallback abmelden ja Ende nein Tracking fortführen? Kameramatrix an Renderer senden Tracking durchführen Abbildung 18: OneShotPreviewCallback Ein Nachteil des OneShotPreviewCallbacks ist es, dass vom Beenden eines Trackingvorgangs über das Empfangen des nächsten Bildes bis zum nächsten Trackingvorgang Zeit vergeht, in der der Tracker nicht arbeitet. Es wird also mit relativ wenigen Ressourcen getrackt, jedoch leidet darunter die Performance und die Anzahl der getrackten Bilder. Um diese Wartezeiten zu verkürzen oder zu umgehen, kann der PreviewCallBackWithBuffer eingesetzt werden. Er ähnelt dem normalen PreviewCallback, da für jedes angezeigte Kamerabild auch ein Callback ausgelöst wird. Der Unterschied ist jedoch, dass der PreviewCallBackWithBuffer Speicher für mehrere Bilder, die vom Callback empfangen werden, anlegen kann. Ist der Trackingvorgang des vorangegangenen Bildes also noch nicht erledigt, wird das neue Bild an einem anderen Speicherort abgelegt. Die maximale Anzahl an parallel vorhandenen Kamerabildern kann beliebig vorbestimmt werden. Ist der Buffer voll, werden nachfolgende Bilder wie beim PreviewCallback verworfen. Für den Fall, dass Platz im Buffer vorhanden war, wird für das Bild, welches dort abgelegt wird, auch der Inhalt des Callbacks aufgerufen. Für das AiRmob-Framework bedeutet das, dass mehrere Bilder parallel getrackt werden können. Durch den höheren Ressourcenaufwand kann so die 31

37 Wartezeit zwischen zwei Trackingvorgängen verkürzt oder sogar komplett umgangen werden, womit sich die Rate der verarbeiteten Bilder erhöhen kann. Der Ablauf ist in Abbildung 19 zu sehen. Tracking gestartet Bild empfangen Warte auf Freien Buffer ja Tracking durchführen Tracking fortführen? Kameramatrix an Renderer senden nein Ende Abbildung 19: PreviewCallbackWithBuffer Pipelinehandler Der Pipelinehandler implementiert den in Abschnitt vorgestellten Ablauf des OneShotPreviewCallbacks und des PreviewCallBackWithBuffer. Bei Nutzung der Buffer kann über die AiRmobActivity festgelegt werden, wie viele Bilder parallel verarbeitet werden können, der Defaultwert liegt bei 2. Es werden dann Speicherplätze reserviert, die der Größe eines Kamerabildes entsprechen. Es gibt jedoch unterschiedliche Möglichkeiten dies im Detail zu realisieren. Diese werden vom Pipelinehandler angeboten und können in der AiRmobActivity zur Laufzeit gesetzt und verändert werden. Bezüglich des Renderers gibt es zwei Auswahlmöglichkeiten, entweder kontinuierliches Rendern oder Rendern auf Anfrage. Beim kontinuierlichen Rendern nutzt der Renderer seine verfügbaren Ressourcen vollständig aus und berechnet so viele Bilder wie möglich. Beim Rendern auf Anfrage wartet der Pipelinehandler immer einen Trackingvorgang ab und stößt den Renderer dann zum Zeichnen eines neuen Bildes an. Es wird also nur so oft gezeichnet wie Bilder getrackt werden. Bei einer unbewegten 3D-Szene reicht das Rendern auf Anfrage aus, da jede Veränderung der 32

38 Darstellung ausschließlich von der Bewegung der Geräte-Kamera abhängig ist. Sobald Animationen eingesetzt werden, ist es sinnvoll kontinuierlich zu rendern, um einen flüssigen Ablauf zu sichern. Zur weiteren Auswahl steht die Darstellung des Kamera-Livestreams. Kamerabilder können entweder unabhängig vom Renderer und damit live dargestellt werden oder an den Renderer als Textur weitergegeben werden. Letzteres fordert vom Renderer, dass dieser die gegebene Textur als Hintergrund auf ein Bildschirm füllendes Polygon zeichnet. Da die Kamera ein Bild im YUV-Format liefert, OpenGL ES aber nur RGB-Formate akzeptiert, muss jedes Kamerabild vorher konvertiert werden. Das wird ebenfalls vom Pipelinehandler erledigt. Das Anmelden des Callbacks und das Empfangen des Kamerabildes geschehen im Hauptthread der Anwendung. Aufruf des Trackers, zusammen mit der Verarbeitung des Bildes und das Weiterleiten der Kameramatrix an den Renderer werden anschließend in einen neuen Thread verlagert, damit die Hauptanwendung ansprechbar bleibt. Pipelinehandler -mcam : Android.Camera -mtracker : AiRmobTracker -previewcallback : Android.PreviewCallback -mglsurfaceview : Android.GLSurfaceView -MODE_VIDEOBG_RENDER_ON_TRACKED : static final int -MODE_VIDEOBG_RENDER_CONTINUOUSLY : static final int -MODE_TEXTUREBG_RENDER_ON_TRACKED : static final int -MODE_FREEZE_ON_NEXT_FRAME : static final int -MODE_VIDEOBG_RENDER_ON_TRACKED_WITH_BUFFER : static final int -MODE_VIDEOBG_RENDER_CONTINUOUSLY_WITH_BUFFER : static final int -MODE_STOP_TRACKING : static final int -MODE_BEFORE_FREEZE : static final int -buffersize : int +setbuffersize(eing. size : int) +startpipeline(eing. cam : Android.Camera) +setpipelinemode(eing. mode : int) +setmode_videobg_render_continuously_with_buffer() +setmode_videobg_render_on_tracked_with_buffer() +setmode_videobg_render_on_tracked() +setmode_videobg_render_continuously() +setmode_texturebg_render_on_tracked() +setmode_freeze_on_next_frame() +setmode_stop_tracking() +decodeyuv420sp(eing. yuv420sp : byte[], eing. width : int, eing. height : int) : int[] Abbildung 20: Pipelinehandler im Detail 33

39 Der Inhalt der Klasse Pipelinehandler ist in Abbildung 20 zu sehen. Sie erhält eine Referenz auf die vom Framework genutzten Instanzen der Gerätekamera und des Trackers. So können Kamerabilder empfangen und an den Tracker weitergeleitet werden. Ein Zeiger auf die GLSurfaceView, welche den Renderer enthält, ermöglicht das Umschalten der Rendermodi. Die Konstanten werden dazu genutzt, um die verschiedenen Pipelinemodi zu setzen. Dies geschieht über den Aufruf der Methode setpipelinemode(). In Abhängigkeit der übergebenen Konstante wird dann eine der Methoden setmode_...() ausgelöst und das Feld previewcallback mit der dort implementierten Instanz eines PreviewCallbacks versehen. Auf diese Weise ist der aktuelle Pipelinemodus global gespeichert, was nötig ist, um den selben Callback zum Beispiel nach Stoppen der Kamera wieder automatisch aufrufen zu können. Wird ein Buffer verwendet, kann dessen Größe mit setbuffersize() gesetzt werden. Wenn das Kamerabild zusätzlich als Textur an den Renderer weitergegeben werden soll, wird dieses mit der Methode decodeyuv420sp() in eine RGB-Bitmap konvertiert. Da das Tracking in einen eigenen Thread verlagert wird, kann es zu Fehlern kommen, wenn die Anwendung geschlossen oder das Tracking abrupt gestoppt werden soll. Der Thread könnte dann ein Eingabebild verlangen, obwohl die Kamera längst beendet wurde. Um das zu umgehen, kann die Methode setmode_stop_tracking() verwendet werden. Somit wird ein PreviewCallback eingesetzt, der keine Funktionalität implementiert und dadurch problemlos neben der Hauptanwendung auslaufen kann AiRmobCamera AiRmobCamera ist eine Hilfsklasse, die die Nutzung der Android-Kamera vereinfachen soll. In Abschnitt wurde bereits erwähnt, dass das Erstellen der Kamera erst im Zusammenhang mit einem SurfaceHolder.Callback geschieht. Dieser wird ausgelöst, sobald die SurfaceView, welche einmal das Kamerabild darstellen soll, fertig erzeugt wurde. Durch den Callback kann die Kamera nun Zugriff auf das Displayformat erhalten, was nötig ist, um das Kamerabild unverzerrt anzeigen zu können. Das Starten der Kamera aus Abbildung 14 ist im Folgenden nochmal im Detail dargestellt. 34

40 AiRmobCamera starten Front- oder Back-Kamera öffnen bildschirmpassende Bildauflösung bestimmen AiRmobCamera gestartet Vorschaubildschirm starten Kameraparameter setzen Abbildung 21: Starten der AiRmob-Kamera Wenn das Android-Gerät über eine Kamera auf Vorder- und Rückseite verfügt, kann der Benutzer festlegen, welche der beiden genutzt wird. Standardgemäß ist es die auf der Rückseite. Im nächsten Schritt wird eine passende Kameraauflösung ermittelt. Verschiedene Geräte-Kameras verfügen über verschiedene mögliche Auflösungen, in denen Bilder an das System weitergegeben werden können. Im nächsten Schritt wird nun versucht, eine Auflösung zu finden, welche der des Displays am nächsten kommt, beziehungsweise zumindest vom Seitenverhältnis her sehr nahe kommt. Falls mehrere passende Auflösungen möglich sind, kann sich der Benutzer über Parameter zwischen drei Stufen für eine niedrige, mittlere oder hohe Auflösung entscheiden. Nun können Renderer und Tracker mit den benötigten Kameraparametern versehen werden, um eine korrekte Deckung von Kamerabild und Renderer zu erzielen. Zuletzt wird die Kamera an die SurfaceView gekoppelt und der Vorschaubildschirm gestartet. Hierzu muss die SurfaceView ebenfalls bereits fertig erstellt sein. AiRmobCamera +CAMERA_LOW : static int +CAMERA_MID : static int +CAMERA_HIGH : static int -msupportedsizes : List<Size> -mcam : Android.Camera -context : AiRmobActivity +openfrontfacingcamera() +opensimplecamera() +openbackfacingcamera() +getdevice() : Android.Camera -getoptimalpreviewsizes() : List<Size> +getcamerahorizontalangle() : float +getcameraverticalangle() : float +startvideostream(eing. sh : Android.SurfaceHolder, eing. width : int, eing. height : int, eing. sizeid : int) +stopvideostream() +getsupportedsizes() : string +starttracking() +stoptracking() Abbildung 22: AiRmobCamera im Detail 35

41 In Abbildung 22 ist die Klasse der AiRmobCamera im Detail aufgezeigt. Die drei Konstanten dienen dazu, vom Framework aus eine automatische Evaluierung von Kameraauflösungen, passend zum Display, zu steuern. Der Wert wird in der Methode startvideostream() als sizeid zusammen mit dem SurfaceHolder und den Displaymaßen genutzt. Es werden dann, aus allen von der Kamera unterstützen, drei Kameraauflösungen ermittelt, deren Seitenverhältnis am nächsten dem des Displays kommen. Dazu wird intern die Methode getoptimalpreviewsizes() aufgerufen. Der übermittelte SurfaceHolder ist eine Referenz auf die Instanz des SurfaceHolders, die in der AiRmobActivity angelegt wurde und wird ab Methodenaufruf mit Kamerabildern versorgt. stopvideostream() stoppt diesen Vorgang. Zusätzlich kann der Nutzer sich alle von der Kamera angebotenen Auflösungen durch getsupportedsizes() in einem String übergeben lassen. Das Feld mcam stellt eine Instanz der Android.Camera, also einen Zugriff auf das Endgerät, dar. Im Framework kann darauf durch Aufruf von getdevice() zugegriffen werden. Auf diese Weise kann der Programmierer in vollem Umfang mit der Gerätekamera agieren. context beinhaltet eine Referenz auf die AiRmobActivity, die die Instanz der AiRmobCamera erstellt hat. Sie wird im Konstruktor übergeben. Über diesen Weg kommuniziert die Klasse mit dem Pipelinehandler. Die Methoden openfrontfacingcamera(), openbackfacingcamera() und opensimplecamera() werden zum Initialisieren der Gerätekamera aufgerufen. Die ersten beiden versuchen gezielt, die vordere oder rückwärtige Kamera eines Geräts zu starten. Die dritte Methode gibt keine explizite Anweisung und startet somit standardgemäß die Kamera auf der Geräterückseite. Des Weiteren lassen sich die Öffnungswinkel der Kamera in horizontaler und vertikaler Ausrichtung abfragen. Das ist wichtig für den Renderer, um eine dem Kamerabild entsprechende perspektivische Verzerrung zu erreichen. Zuletzt wird über die AiRmobCamera das Tracking gestartet und gestoppt. 4.4 Funktionalitäten Die AiRmobActivity dient nicht nur zum Initialisieren einer AR-Anwendung. Es sind weitere Funktionen enthalten, die den Benutzer unterstützen und die Kommunikation mit dem Renderer und Tracker erleichtern. Die Kamera eines Android-Gerätes ist eine exklusive Ressource. Wenn eine Anwendung die Kamera benutzt, kann sie von keiner anderen Anwendung in Anspruch genommen werden, bis diese wieder freigegeben wird. Das Framework sorgt dafür, dass die Kamera beim Schließen oder Minimieren einer Anwendung auf Basis der AiRmobActivity freigegeben wird und beim erneuten Aufrufen automatisch das Tracking und der Kameralivestream fortgesetzt werden. 36

42 Die AiRmobActivity wird darüber informiert, wenn der Renderer fertig initialisiert wurde. Es wird dann eine entsprechende Methode (onrenderer- Created()) innerhalb der Klasse aufgerufen, mit der der Benutzer gewünschte Aktionen ausführen kann. Bei Änderung der Bildschirmmaße wird außerdem onrendererchanged() aufgerufen. Dies passiert mindestens einmal beim Start der Anwendung. Ebenso kann eine Methode aufgerufen werden, wenn durch Tippen auf den Bildschirm ein 3D-Objekt ausgewählt werden soll. Eine Referenz auf das Objekt und damit die Möglichkeit mit ihm zu interagieren wird in dieser Methode gegeben. In Abschnitt 3.2 wurde bereits das Freeze-Set-Go Verfahren beschrieben. Das Framework kann dies durch einen einfachen Funktionsaufruf (toggle- Freeze()) durchführen. Dieser dient zum Einfrieren und Fortführen des Kameralivestreams und Trackings. Das Interagieren mit 3D-Objekten des Renderers muss vom Benutzer selbst implementiert werden. Die Umsetzung ist geräte- bzw. versionsabhängig. Unter Honeycomb reicht es aus, den Kameralivestream zu stoppen. Das letzte Kamerabild wird dann weiter im Hintergrund angezeigt. Bei früheren Versionen von Android ist dies jedoch nicht der Fall. Um auch dort das letzte Kamerabild beizubehalten, muss es als Textur gespeichert und an den Renderer weitergegeben werden. Es muss dann so lange auf ein bildschirmfüllendes Polygon gerendert werden, bis die Kamera wieder freigegeben wird. Weiter wird ein Algorithmus (pickmarkerplane(x,y)) angeboten, welcher Displaykoordinaten auf die Ebene des Markers abbildet. Dazu wird die zuletzt bekannte Projektionsmatrix genutzt und invers auf die Bildschirmkoordinaten angewandt. Auf diese Weise lassen sich 3D-Objekte innerhalb einer Anwendung schnell an gewünschten Positionen auf der Markerebene platzieren. Für eine bestimmte Kommunikation mit dem Renderer wird eine Interfacedefintion angeboten, welche auf einen Callback reagiert. Der Renderer kann der AiRmobActivity, als Reaktion auf eine Bildschirmeingabe, eine Referenz auf ein 3D-Objekt senden (siehe dazu Abschnitt 4.6). Dazu muss dann eine Instanz des OnPickListeners vorhanden und an die AiRmobActivity angemeldet sein. So können verschiedene Methoden implementiert werden, um in verschiedenen Programmzuständen unterschiedlich auf das Erhalten von 3D-Objektreferenzen reagieren zu können. Neben dem Renderer muss eine Anwendung stets darauf warten, dass die visuelle Oberfläche einer AiRmobActivity fertig erstellt wurde. Das Framework ruft zu diesem Zeitpunkt die Methode onairmobinitialized() auf. Ab hier können also frühestens Funktionen aufgerufen werden, welche auf die Kamera oder das Tracking zugreifen. 37

43 Als kleine Hilfe zum Zugriff auf Speicherorte eines Gerätes bietet das Framework einen minimalen Dateimanager. Mit ihm lässt sich vereinfacht auf den anwendungsinternen Speicher zugreifen oder ein Standardverzeichnis auf der SD-Karte anlegen, um von dort zu lesen oder Dateien aus der Anwendung heraus zugänglich zu machen. Das Einlesen von GPS-Markern wird hier ebenso wie das Einlesen eines XML-Strings in ein Document- Objekt im DOM-Format erledigt. 4.5 Integration Tracker Autoren: Nils Lichtenberg und Florian Kathe Der Pipelinehandler arbeitet im selben Thread wie die AiRmobActivity. Das Tracken von Kamerabildern wird durch den Pipelinehandler stets in einem eigenen Thread aufgerufen. Damit arbeiten Tracker und Anwendung auf dem selben Heap. Sollte das Kamerabild also noch weiterverwendet werden, beispielsweise durch den Renderer als Hintergrundtextur, müssen keine Prozessgrenzen überwunden werden. Eine Alternative wäre es, das Tracking in einen Android-Service zu verlagern (siehe Abschnitt 2.1.3). Dadurch wäre es möglich, dem Tracker einen eigenen Speicherbereich durch einen eigenen Prozess zuzuweisen. Da das Framework aber Speicherplatz für zu verarbeitende Bilder vorreserviert, wurde darauf verzichtet. Sobald nun ein Bild getrackt und eine Kamera-Matrix ermittelt wurde, wird diese vom Pipelinehandler an den Renderer weitergegeben. Die Übertragung erfolgt mithilfe eines Objektes, das die entsprechenden Daten enthält. Zum Tracken stehen zwei Methoden zur Auswahl, einmal markerbasiert mit AndAR und featurebasiert mit AiRmobTracker. Bei AndAR werden die Kanten des Markers gesucht und aus den vier Schnittpunkten der Kanten und einem Referenzbild eine 3D-Pose berechnet. Das Referenzbild liegt in Form einer einfachen Textdatei vor. Im Falle von AiRmobTracker wird zunächst in einem Referenzbild nach Features gesucht. Dieses kann entweder vorgegeben werden oder zur Laufzeit durch einen Screenshot definiert werden. Während des Trackens wird im Kamerabild ebenfalls nach Features gesucht. Anschließend werden diese mit der Referenz verglichen und daraus die Pose des Referenzbildes im Kamerabild bestimmt. Der genaue Ablauf ist in der Arbeit von Florian Kathe nachzulesen. Die Anbindung eines Trackers an das Framework erfolgt, indem der Code in einer Spezialisierung der Klasse AiRmobTracker implementiert wird. 38

44 AiRmobTracker -mwidth : int -mheight : int -mcontext : Android.Context -cameraanglehorizontal : float -cameraanglevertical : float +init() +trackimage(eing. imgdata : byte[]) : CameraMatrizes Abbildung 23: AiRmobTracker im Detail Abbildung 23 zeigt den Inhalt der Klasse AiRmobTracker. Eine Instanz der Klasse wird über die Höhe und Breite der zu trackenden Bilder informiert und über die Öffnungswinkel der Kamera. Der Android Context der AiRmobActivity wird ebenfalls mitgeteilt, um einen Zugriff auf den Speicher der Anwendung zu ermöglichen. Das Framework ruft zu Beginn die Methode init() auf. Hier muss also die Vorbereitung des Trackers implementiert werden. Für jedes zu trackende Bild wird dann trackimage() aufgerufen. Das Bild wird als Byte-Array übergeben. Als Rückgabewert wird ein Objekt CameraMatrizes geliefert. Dieses soll das Ergebnis des Trackingvorgangs und damit die nötigen Matrizen für den Renderer enthalten. 4.6 Integration Renderer Autoren: Nils Lichtenberg und Axel Peter Ein Renderer wird unter Android innerhalb einer speziellen View-Klasse, der GLSurfaceView, realisiert. Diese ist zunächst mit einer normalen Surface- View vergleichbar, bietet aber zusätzliche Funktionen, die es ermöglichen, OpenGL-Inhalt darzustellen und diesen in einem gesonderten Thread zu produzieren, um den Hauptthread der Anwendung nicht zu beeinflussen (siehe [Andi]). Außerdem wird hier festgelegt, welche OpenGL-Version genutzt wird und mit welcher Farbtiefe gerendert werden soll. Die Farbtiefe ist im AiRmob-Framework aus Rücksicht auf die Performance standardgemäß auf 16 Bit eingestellt - hierbei wird ein Bit für den Alphakanal verwendet. Desweiteren kann das Rendern auf einen kontinuierlichen oder Rendern-auf-Anfrage -Modus eingestellt werden. Beim kontinuierlichen Rendern nutzt der Renderer all seine verfügbaren Ressourcen und wird nur durch die gerätespezifische vertikale Synchronisation eingeschränkt. Bei der alternativen Einstellung muss der Renderer stets zum Rendern eines neuen Bildes aufgefordert werden. Für diesen Fall bietet das Framework die Möglichkeit, für jedes getrackte Kamerabild ein Bild zu rendern. Darüber hinaus ist es dem Benutzer überlassen zusätzliche Renderanfragen zu integrieren. Das eigentliche Rendern übernimmt 39

45 eine Klasse, die das GLSurfaceView.Renderer-Interface implementiert. Eine solche Klasse kann an eine Instanz der GLSurfaceView gekoppelt werden, um gerenderte Bilder dort anzuzeigen. Der konkrete Renderer der AiRmob-Engine implementiert die abstrakte Superklasse AiRmobRenderer. Diese Superklasse stellt grundlegende Funktionalitäten zur Kommunikation mit dem restlichen Framework zur Verfügung. Dazu gehört die Verwaltung von Modellen, bei welcher die AiRmob-Engine und die AiRmob-Activity eng zusammenarbeiten. Dies ist nötig, damit auf in der Engine erstellte Objekte in der Activity zugegriffen werden kann. Hierfür legt man die Objekte erst in der Engine an und veröffentlicht sie dann mit einem Namen in einer HashMap. Auf diese kann von der Activity aus zugegriffen werden. Diese Funktionalität ist typunabhängig und deckt somit alle Implementationen von Objekten ab. Im konkreten Fall der AiRmob-Engine werden Objekte vom Typ Parent registriert und die zurückgegebenen Objekte müssen in der Activity dementsprechend nach Identifier oder Group gecasted werden. Diese implementieren die grundlegenden Funktionen der Manipulation von Modellen, wie Transformationen und Sichtbarkeit. Auf die Zusammenhänge dieser Objekte wird in der Ausarbeitung von Axel Peter genauer eingegangen. Ein weiterer wichtiger Aspekt der Kommunikation zwischen Framework und Engine stellen die Interaktionen von Benutzern mit dem von OpenGL erzeugten 3D-Raum dar. Als erstes ist hierbei das Picking zu nennen. Beim Picking tippt der Benutzer auf den Bildschirm des Gerätes, um ein Modell auszuwählen. Um dies zu ermöglichen, muss die Activity eine Anfrage mit den passenden Bildschirmkoordinaten, also an der Stelle, an welcher getippt wurde, an die Engine schicken. Die Engine registriert die Anfrage und speichert sie. Im nächsten Draw-Aufruf wird dann ein Bild gerendert, in dem alle Modelle einen eigenen Farbwert haben. Aus diesem Bild wird der Farbwert der Bildschirmkoordinate ausgelesen und der zugehörige Identifier wird an die Activity zurückgegeben. Da hier auf den nächsten Renderframe gewartet wird, läuft die Rückgabe asynchron ab. Dies wird durch die Verwendung des Runnable-Interfaces umgesetzt. Sobald ein Identifier gefunden wurde, wird die AiRmobActivity davon in Kenntnis gesetzt und eine Referenz auf den Identifier übertragen. Die Weiterverarbeitung wird dann in die Warteschlange der AiRmobActiviy angehangen und zu einem gegebenen Zeitpunkt durchgeführt. Wie dies im Detail funktioniert, wurde in Abschnitt beschrieben. Wie das Bild für das Picking erstellt und dem Farbwert ein Identifier zugeordnet wird, wird in der Arbeit von Axel Peter erläutert. Weitere Interaktionsmethoden werden von der AiRmob-Activity bereitgestellt. Hierzu zählen das Mappen von Bildschirmkoordinaten auf die Markerebene und das Rotieren von Modellen in Abhängigkeit von Bildschirmeingaben. Nötig sind dazu jeweils die aktuelle Projection- und Model-Matrix. Diese werden vom Renderer bereit- 40

46 gestellt. Die Umsetzung wurde in Abschnitt 4.4 bereits erwähnt Austauschbarkeit Autoren: Nils Lichtenberg und Axel Peter Neben der Verwendung der AiRmob-Engine ist es auch möglich, eigene Renderer in das Framework zu integrieren. Diese müssen dazu gewisse Konventionen einhalten, damit die Kommunikation mit dem Rest des Frameworks funktioniert. Abbildung 24 zeigt die Klasse AiRmobRenderer im Zusammenhang mit dem für sie relevanten Ausschnitt der AiRmobActivity. AiRmobRenderer -surfacecreateddone : Boolean -lastsynchframerate : int -lastrealframerate : int -cameraanglehorizontal : float -cameraanglevertical : float -mcontext : Context -availableobjects : HashMap -messagehandler : Handler +setmatrizes() +pick(eing. x : int, eing. y : int) : Object +setvideobackground(eing. bmop : Bitmap) +pickingactivated() +freezecamera(eing. freeze : Boolean) +renderercreateddone() +rendererchangeddone() +registerobject(eing. obj : Object, eing. name : string) +getobjectbyname(eing. name : string) : Object -enthält 1 1 -enthält 1 1 -enthält 1 1 -enthält 1 1 AiRmobActivity::RendererCreatedRunnable +run() AiRmobActivity::RendererChangedRunnable +run() AiRmobActivity::PickRunnable -id : Object +run() AiRmobActivity +onrenderercreated() +onrendererchanged() +onpick(eing. id : Object) Abbildung 24: kommunikationsrelevante Komponenten aus Renderer und Activity - Die Runnableklassen sind innere Klassen der AiRmobActivity Um Renderer im AiRmob-Framework verwenden zu können, müssen diese von der abstrakten Klasse AiRmobRenderer abgeleitet werden. Diese gibt einige Felder und Funktionen zur Kommunikation mit dem Framework vor. Bei der Initialisierung einer jeden so abgeleiteten Klasse werden der Android-Context und die Kameraöffnungswinkel dieser mitgeteilt. Der Context dient zum Zugriff auf das Dateisystem, während die Öffnungswinkel der Kamera bei der Berechnung einer eigenen Projectionmatrix genutzt werden können. In der HashMap availableobjects können 3D-Objekte mit der Methode registerobject mit einem Namen registriert werden, um der AiRmobActivity Zugriff auf diese zu ermöglichen. Diese fragt Objekte anhand der bei der Registrierung gewählten Namen mit der Methode getobjectbyname ab. Um eine korrekte Anzeige von FPS zu ermöglichen, müssen die Felder lastsynchframerate und last- RealFrameRate von einer Implementation entsprechend gesetzt werden. 41

47 Die Funktion setvideobackground wird vom Framework aufgerufen, wenn das Kamerabild als Bitmap an den Renderer weitergegeben werden soll. Mit freezecamera wird ein einziges Kamerabild an den Renderer geschickt. Dieses soll dazu genutzt werden ein Standbild anzuzeigen. Mit setmatrizes teilt das Framework dem Renderer die im Tracking ermittelten View- und Projectionmatrizen mit. Diese werden mit der Klasse CameraMatrizes übermittelt. Die Methode pick stößt, wie im vorigen Abschnitt beschrieben, einen asynchronen Aufruf unter Verwendung des PickRunnable an. In einer konkreten Implementation muss in dieser Methode das eigentliche Picking durchgeführt und das so gefundene Objekt durch Aufruf des Runnables in der AiRmobactivity zurückgegeben werden. Die zwei weiteren Runnables RendererCreatedRunnable und RendererChangedRunnable können dazu benutzt werden das Framework über den Abschluss der Methoden onsurfacecreated und onsurfacechanged zu informieren. Der Handler messagehandler wird dazu benutzt, die Runnables in die Warteschlange der AiRmobActivity einzugliedern. Eine Spezialisierung des AiRmobRenderers, die die genannten Vorgaben berücksichtigt, kann die Funktionalitäten des Frameworks im vollen Umfang ausnutzen und problemlos als Renderer in die Pipeline des Frameworks integriert werden. 4.7 AiRmob GPS Um den Umgang mit GPS-Ereignissen vereinfacht implementieren zu können, enthält AiRmob eine kleine Anwendung zum Erstellen und eine Hilfsklasse zum Benutzen von GPS-Ortsdaten. Diese werden im Folgenden beschrieben GPSgetter Wenn der Benutzer eine auf GPS-Ortsdaten basierte Funktion in seine Anwendung einbringen möchte, muss er festlegen können, an welchem Ort welche Aktion ausgelöst werden soll. Dazu ist die Kenntnis von Längenund Breitengraden notwendig. Das Bestimmen der Daten soll durch den AiRmob GPSgetter, einer einfachen Android-Anwendung, vereinfacht und intuitiv ermöglicht werden. Die Idee der Anwendung ist es, die Koordinaten nicht aus einer Karte auszulesen, sondern den gewünschten Ort selbst zu betreten und die dort registrierten GPS-Daten unter einer ID zu speichern. Abbildung 25 zeigt den Eingabebildschirm für die IDs. 42

48 Abbildung 25: Eingabeansicht Befindet sich der Nutzer an dem Ort, an dem in der Zielanwendung einmal eine bestimmte Aktion ausgelöst werden soll, kann er seine momentanen Ortsdaten abrufen. Für den so genannten GPS Marker kann eine ID und ein Toleranzwert gewählt werden. Der Toleranzwert sorgt dafür, dass der GPS Marker in einem Radius rund um seinen Ortspunkt herum reagiert. Die GPS Marker werden anschließend in eine XML-Datei gespeichert, welche vom AiRmob-Framework wiederum eingelesen werden kann. Das folgende Listing zeigt den Inhalt einer solchen XML Datei. 1 <root> Listing 1: GPS Marker als XML Datei 2 <GPSMarker markerid="a" l a t i t u d e =" " 3 longitude=" " radius=" 2 " /> 4 <GPSMarker markerid="b" l a t i t u d e =" " 5 longitude=" " radius=" 3 " /> 6 <GPSMarker markerid="c" l a t i t u d e =" " 7 longitude=" " radius=" 5 " /> 8 </root> GPS Alerts Das Framework enthält eine kleine Hilfsklasse GPSAlertCreator. Diese dient dazu, GPS-Marker, die mit dem GPSgetter erstellt wurden oder im entsprechenden XML-Format vorliegen, mit einer Anwendung zu verknüpfen. Einer Instanz der Klasse kann entweder die gesamte XML-Datei oder einzelne GPS-Marker übergeben werden. Wenn GPS-Ortung aktiviert ist, wird dafür gesorgt, dass die Anwendung informiert wird sobald ein Bereich eines GPS-Markers betreten oder verlassen wird. In der AiRmobActivity wird 43

49 in diesem Fall die Methode onreceivemarker ausgelöst. Als Parameter werden die Marker ID des aktivierten GPS-Markers und ein Bool scher Wert übergeben. Der Bool sche Wert gibt an, ob die Markerregion betreten oder verlassen wird. Anhand der IDs können in der onreceivemarker Methode die gewünschten Ereignisse implementiert werden, die bei Aktivierung eines GPS-Markers eintreten sollen. 5 Anwendungen In diesem Kapitel werden Anwendungen vorgestellt die mit dem AiRmob- Framework erstellt wurden. Die Programme greifen dabei sowohl auf Funktionen des Frameworks als auch auf das Android SDK zu. Der Aufbau einer solchen App sieht im allgemeinen wie folgt aus: Anwendungen starten als gewöhnliche Android-App mit einer Android- Activity. Das heißt, Menüführung, Verwaltung und andere Einstellungen werden auf Grundlage des reinen Android-SDKs erstellt. Sobald eine AR- Komponente zum Einsatz kommen soll, wird eine AiRmobActivity gestartet und die Initialisierung von Kamera, Renderer und Tracker werden vom Framework vorgenommen. Die AR-Anwendungslogik wird ebenfalls in der AiRmobActivity implementiert, diese wiederum greift aber auf das Android-SDK direkt zu. Eine grafische Darstellung ist in Abbildung 26 zu finden. Anwendung Android SDK AiRmob Framework Render Engine Shader Tracker Android OS & OpenGL ES 2.0 Abbildung 26: Aufbau einer AR-Anwendung mit AiRmob-Framework Abbildung 27 stellt den Aufbau als UML-Diagramm dar. Die dort genannten Methodenaufrufe sind als abstrakte Zusammenfassung des insgesamt 44

50 implementierten Codes anzusehen. Die Methode frameworkoperations() enthält diejenigen Operationen, die nötig sind, um eine Kommunikation des Renderers mit dem Framework zu gewährleisten. Um deren Funktionalität zu realisieren, muss der CustomRenderer einige Konventionen beachten (siehe Abschnitt 4.6.1). Diese sind in der AiRmob-Engine bereits vorhanden, sodass dieser nur noch die 3D-Szene mitgeteilt werden muss. Die restlichen genannten Methoden sind selbsterklärend. Das Attribut cameraattributes wird während der Frameworkinitialisierung ermittelt und versorgt Renderer und Tracker mit Bildschirmmaßen, um eine passende Darstellung auf dem Endgerät zu erreichen. Neben der CustomActivity können beliebige andere Klassen vorhanden sein, welche Aufgaben der Anwendungslogik übernehmen. Wenn GPS-Marker verwendet werden, müssen diese in der AiRmobActivity vorhanden sein, an welche diese ihre Ereignisnachrichten schicken sollen. «interface» GLSurfaceView.Renderer AiRmobRenderer -settings -cameraattributes +frameworkoperations() AiRmobActivity +initframework() AiRmobTracker -cameraattributes CustomRenderer +draw() 1 -rendersobjects * 3DObject -3DData CustomActivity CustomTracker enthält -enthält +applicationlogic() +trackimage() 1 -enthält 1 -enthält 0..1 * GPSMarker ArbitraryClass +additionalapplogic() Abbildung 27: UML-Aufbau einer AR-Anwendung mit AiRmob-Framework 5.1 Minimale Beispielanwendung In Abschnitt 3 wurde zu den Frameworks von AndAR und Qualcomm jeweils ein einfaches Nutzungsbeispiel beschrieben. Nun soll ebenfalls für das AiRmob-Framework eine Minimale Beispielanwendung beschrieben 45

51 werden, um einen Vergleich der Frameworks bezüglich der Einsteigerfreundlichkeit machen zu können. Wie zuvor ist das Ziel, ein einfaches Objekt auf dem Marker anzuzeigen. In diesem Fall ist dies eine transparente Markierung, die passend auf den quadratischen Marker gelegt wird. Das Vorgehen teilt sich in zwei einfache Schritte: Die Vorbereitung des Frameworks und das Integrieren eines Modells. Außerdem muss ein vordefiniertes Layout im entsprechenden Projektordner vorhanden sein. Das Layout wird dazu genutzt, Kamera und Renderer darzustellen und kann für komplexere Anwendungen erweitert werden. Für das Framework legt man eine Instanz der AiRmobActivity an. Mindestmaß an implementierten Methoden ist hier die oncreate-methode, welche beim Programmstart vom Betriebssystem aufgerufen wird. In dieser Methode werden lediglich der Renderer und der Tracker, welche benutzt werden sollen, festgelegt. Die Instanz des Renderers muss sich von AiRmobRenderer ableiten. In der AiRmob-Engine ist eine Methode putscene enthalten. Diese gilt es zu überladen, um so den AiRmobRenderer mit einem Modell zu versorgen. Eine minimale 3D-Szene besteht aus einem Scene- Objekt, einem 3D-Objekt und einer Lichtquelle. Alle drei Objekte können durch einen einfachen Befehl angelegt werden und 3D-Modell sowie die Lichtquelle müssen nun noch an die Szene angehangen werden. Je nach Definition des 3D-Modells muss noch eine Textur angegeben werden, die für das Objekt benutzt werden soll. Damit ist das minimale Beispielprogramm fertig. Das Ergebnis ist in Abbildung 28 zu betrachten. Das Framework hat nun automatisch eine niedrige, aber passende Kameraauflösung gewählt, um das Kamerabild nicht zu verzerren. Das Tracking startet, sobald die Engine das Modell geladen hat und die Anzeige des Objekts erfolgt, sobald das Tracken erstmals erfolgreich war. Um weitere Einstellungen vorzunehmen, die sich auf die Kamera oder die Trackingpipeline auswirken, können entsprechende Funktionen zusätzlich aufgerufen oder überladen werden. Der Code beider implementierter Klassen sieht folgendermaßen aus: 1 public c l a s s SampleActivity extends AiRmobActivity { 2 3 public void oncreate ( Bundle s a v e dinstancestate ) { 4 setrenderer (new SampleRenderer ( t h i s ) ) ; 5 s e t T r a c k e r (new BasicTracking ( t h i s ) ) ; 6 super. oncreate ( s a vedinstancestate ) ; 7 } 8 } 46

52 1 public c l a s s SampleRenderer extends Renderer { 2 3 Model3D samplemodel = n u l l ; 4 public Scene samplescene ; 5 public S t r i n g modelpath = " " ; 6 public I d e n t i f i e r modelid ; 7 8 public SampleRenderer ( Context context ) { 9 super ( context ) ; 10 modelpath = " markertest. obj " ; 11 } public void putscene ( ) { 14 samplescene = new Scene ( t h i s ) ; 15 t h i s. scene = samplescene ; 16 modelpath = " models/" + modelpath ; 17 samplemodel = 18 new ModelCustom ( t h i s, modelpath, ModelFileTypes. OBJ ) ; 19 modelid = samplescene. add ( samplemodel ) ; 20 Light t e s t L i g h t = new Light ( ) ; 21 samplescene. add ( t e s t L i g h t ) ; 22 } 23 } Abbildung 28: Ansicht der minimalen Beispielanwendung 47

53 5.2 Mensch ärgar dich nicht Mensch ärgar dich nicht ist eine Umsetzung des bekannten Brettspiels. Gespielt wird auf einem echten Spielfeld, die Figuren der Spieler werden jedoch durch die Anwendung auf das Spielfeld projiziert. Auch das Würfeln wird von der Anwendung übernommen. Abbildung 29: Mensch ärgar dich nicht - Menü Wie zu Beginn des Kapitels angesprochen, greift der Programmstart noch nicht auf das AiRmob-Framework zu. Das Hauptmenü (siehe Abbildung 29) wird durch eine einfache Android-Activity dargestellt. Die Auswahl der Spieleranzahl startet das Spiel. Abbildung 30: Mensch ärgar dich nicht - Spielszene In Abbildung 30 ist die laufende AiRmobActivity zu sehen. Die Spielfiguren werden in ihren entsprechenden Positionen auf das Spielfeld gesetzt, Würfeln geschieht durch Schütteln des Endgeräts. Hat ein Spieler gewürfelt und möchte eine Figur bewegen, so tippt er diese auf dem Display an und die Figur bewegt sich automatisch auf die nächste Position. 48

54 5.2.1 Aus Entwicklersicht Die Anwendung ist ein Beispiel für die Zusammenarbeit von Android- SDK und dem AiRmob-Framework. Reine Androidbestandteile wie Buttons oder der Beschleunigungssensor, welcher auf das Schütteln reagiert, interagieren direkt mit der Anwendungslogik, die in der AiRmobActivity implementiert wurde. Angefangen beim Würfeln wird zunächst eine zufällige Zahl für das Ergebnis ermittelt. Ab diesem Zeitpunkt werden die Figuren des aktiven Spielers auswählbar, sodass durch das Colorpicking des Frameworks eine Figur ausgewählt werden kann. Mit den Transformationsoperationen der Render-Engine wird dann eine einfache Animation realisiert, welche die Figur zum Ziel bewegt. Aus diesem Grund wird hier kontinuierliches Rendern angewandt. Die Positionierung der einzelnen Spielfelder ist in Abhängigkeit des Markers festgelegt. Da der Marker das Koordinatensystem aufspannt, bedeutet ein doppelt so großer Marker ein doppelt so großes Spielfeld. Eine mögliche Alternative ist die Verwendung eines Featuretrackings, womit das Spielfeld an sich zum Marker wird und sich damit keine Größenabhängigkeiten mehr ergeben. 5.3 Ballons Ballons ist ein simples Geschicklichkeitsspiel. Ziel des Spiels ist es, Ballons durch Antippen platzen zu lassen und so Punkte zu sammeln. Die Ballons vergrößern sich mit der Zeit und platzen nach einer bestimmten Zeit von selbst. Je größer ein angetippter Ballon ist, desto mehr Punkte erhält der Spieler. In Abbildung 31 ist eine Szene aus dem Spiel zu sehen. Die roten Ballons tauchen in zufälligen Zeitintervallen auf den grauen Sockeln auf. Abbildung 31: Ballons - Spielszene 49

55 5.3.1 Aus Entwicklersicht Bezüglich des Frameworks greift Ballons auf die ersten simplen Funktionen von AiRmob zurück. Bei den Ballons handelt es sich um ein und dasselbe Modell. Um mehrere Ballons zu erstellen, wird hier Multiinstanzierung genutzt, sodass nur einmal die Geometrie geladen werden muss. Die Anwendung zeigt, dass unter diesen Umständen eine individuelle Interaktion mit den einzelnen Objektinstanzen möglich ist. Eine einfache Eingabe am Display wird als Picking-Anfrage an den Renderer gesendet. Als Antwort gibt der Renderer eine Referenz auf eine der Ballon-Instanzen. 5.4 Techdemo Autoren: Philipp Brandt, Florian Kathe, Nils Lichtenberg und Axel Peter Die Techdemo dient dazu, die Fähigkeiten des Frameworks auf der technischen Ebene zu präsentieren. Hierzu gehören Funktionalitäten, die die AiRmobActivity direkt anbietet, verschiedene Shader, Leistungen der Engine und Trackingverfahren. Renderer und Tracker werden im Hauptmenü festgelegt und anschließend geladen. Je nach Renderer sind verschiedene Voreinstellungen der Shader möglich, zur Laufzeit können diese aber stets geändert werden. Es sind dabei verschiedene Renderer verfügbar, die jeweils von der Klasse Renderer der AiRmob-Engine abgeleitet sind und die Funktion putscene zum Anlegen der Szene überschreiben. Die Szenen und Einstellungen dieser Renderer sollen verschiedene Effekte und Vorgehensweisen der AiRmob-Engine demonstrieren. Im Folgenden sollen die verschiedenen auswählbaren Renderer und das, was sie jeweils demonstrieren sollen, kurz erläutert werden. Der zum Erzeugen dieser Renderer benötigte Quellcode sowie Screenshots der Ergebnisse werden in der Arbeit von Axel Peter dargelegt. Free Choice Nach der Auswahl dieses Renderers erscheint ein weiteres Menü. In diesem kann eines aus allen internen Modellen gewählt werden, die sich im Assets-Ordner models der Anwendung befinden. Dieses wird mit den Standardeinstellungen der AiRmob-Engine sowie einer Standardlichtquelle gezeichnet. Insbesondere können hier natürlich auch die OBJ- Dateien eigener Modelle schnell und unkompliziert getestet werden. Tres Amigos: Die Szene dieses Renderers besteht aus drei der vorgegebenen Modelle der AiRmob-Engine sowie einer Lichtquelle. Bei den Modellen handelt es sich um den Blender-Affenkopf Suzanne, den Utah-Teapot sowie einen einfachen Würfel, also Instanzen der Klassen modelsuzanne, modelteapot und modelcube. Diese werden in rot, grün und blau nebeneinander angezeigt. Hier soll der Umgang mit den vorgegebenen Modellen präsentiert werden. 50

56 Transparent Businesses: Die Modelle des vorherigen Renderers werden in diesem leicht versetzt hintereinander und transparent gezeichnet. Dabei würden sie von vorne nach hinten gezeichnet werden, falls die Sortierung nach Distanzen deaktiviert ist. Das würde zu Fehlern führen, die verdeckten Modelle wären nicht sichtbar. Bei aktivierter Sortierung nach Distanzen ist die Ansicht korrekt. Die Sortierung kann im Menü de-/aktiviert werden. Dementsprechend soll in diesem Renderer die Sortierung transparenter Objekte nach Distanzen demonstriert werden. 100 Monkeys: Dieser Renderer zeichnet 100 Instanzen der Klasse model- Suzanne, also des Blender-Affenkopfes, in einem Raster verteilt um den Marker. Hier können die verschiedenen Picking-Einstellungen verändert und getestet werden. Trackingtest: Es wird ein einfaches Rechteck in Markergröße gezeichnet. Darauf wird eine Textur gelegt die einen rötlichen Rahmen passend auf den Marker legt, sowie ein Kreuz in dessen Mitte. Animation: In diesem Renderer wird eine Animation importiert und angezeigt. Diese zeigt einen Würfel der sich Frame für Frame zu einer Kugel verändert. Durch tippen auf den Bildschirm lässt sich die Animation pausieren, sie befindet sich in einer Endlosschleife. Tres Amigos with multiple lights: Hier wird die Szene des Renderers Tres Amigos um mehrere Lichtquellen ergänzt. Dazu wird die maximale Anzahl der Lichtquellen erhöht und der Szene hinzugefügt. Bumpmapping: In diesem Renderer wird das Bumpmapping gezeigt. Es kann über die normalen Einstellungsmöglichkeiten zu Paralaxmapping umgestellt werden. Texts: In diesem Renderer werden die beiden Textarten präsentiert. Zum einen ist ein weißer Text der statisch zur Kamera gerichtet ist zu sehen. Zum anderen sind ein blauer und ein grüner Text im 3D-Raum sichtbar. Diese drei Texte können über das Menü zur Laufzeit durch Eingabe eines neuen Textes verändert werden. Neben den verschiedenen Renderern können wie bereits erwähnt auch verschiedene Tracker gewählt werden. Der markerbasierte Tracker von AndAR ist als Defaultwert festgelegt. Wählt man den AiRmob-Tracker, welcher auf Featuredetection basiert, muss diesem noch ein Imagetarget zugewiesen werden. Das kann entweder aus der Anwendung heraus und von der SD-Karte des Geräts geladen oder mit der Kamera selbst aufgenommen 51

57 werden. Schießt man ein neues Foto, kann dieses entweder komplett als Imagetarget verwendet oder per Hand zugeschnitten werden. Dazu werden im Originalbild vier Punkte definiert, die die Eckpunkte des Ergebnisbildes angeben. Abbildung 32 zeigt ein Beispiel. Das aufgenommene Bild wird zunächst auf Displaymaße gestreckt. Die Eckpunkte werden dann gegen den Uhrzeigersinn, beginnend in der oberen linken Ecke festgelegt. Zur Weiterverarbeitung werden die Punkte zuletzt von Display- auf Bildmaße umgerechnet. Abbildung 32: Zuschneiden eines Imagetargets Bevor eine Szene endgültig geladen wird, muss der Benutzer noch die Kameraauflösung einstellen. Dazu kann er entweder drei vom Framework vorgeschlagene Werte benutzen oder manuell einen Eintrag aus den von der Kamera unterstützten Einstellungen festlegen. In Abbildung 33 ist eine Beispielszene der Techdemo zusammen mit dem Optionsmenü zu sehen. Am oberen Bildschirmrand werden die Auflösung der Kamera und die in der Szene vorhandene Anzahl an Dreiecken, Vertices und Indices angezeigt. Am unteren Rand werden die aktuelle Tracking- und Framerate und die maximal mögliche Framerate ohne Synchronisierung sowie deren Durchschnittswerte angezeigt. Die Durchschnittswerte können vom Benutzer zu jeder Zeit zurückgesetzt werden, z. B. um passende Werte zu einer neuen Shadereinstellung zu erlangen. Diese Einstellungen sind ebenfalls im Optionsmenü zu erreichen. Durch Auswahl von ToggleFreeze wird das Kamerabild entweder angehalten oder wieder fortgeführt. Unter Pipeline können die vom Framework angebotenen Pipelinevarianten ausgewählt werden. Zuletzt ist unter Description eine Beschreibung der aktuellen Szene zu finden. 52

58 Abbildung 33: Optionen und Ansicht der Techdemo Um die Eingabeoperationen des AiRmob-Frameworks zu testen, kann ein 3D-Objekt angewählt und dann rotiert oder verschoben werden. Abbildung 34 zeigt das Auswahlmenü und im Hintergrund ist zu sehen, wie die Markierung bereits vom Marker wegbewegt und rotiert wurde. Abbildung 34: Objektinteraktion Die Techdemo dient aufgrund ihrer Eigenschaften als Testmittel im Abschnitt 6.1.1, um die Performance des Frameworks zu evaluieren. 53

59 6 Erreichte Ziele In diesem Abschnitt soll ein Blick auf die in der Arbeit erreichten Ziele geworfen und diese möglichst objektiv bewertet werden. Zunächst wird auf den Inhalt dieser Teilarbeit eingegangen und anschließend das Framework unter Berücksichtigung aller Komponenten beurteilt. 6.1 Evaluierung der eigenen Arbeit Es soll nun auf die in Abschnitt 4.2 festgelegten Anforderungen zurückgegriffen werden. Anschließend werden einzelne Komponenten dieser Teilarbeit noch einmal im Detail betrachtet. Das grundlegende Ziel der Arbeit wird ausgedrückt durch: Das Framework muss dem Benutzer das Verknüpfen von Renderer und Tracker erleichtern. Das Framework kann dem Benutzer das Verknüpfen von Renderer und Tracker abnehmen. Es ist möglich, einen entsprechend implementierten Renderer und Tracker mit zwei Befehlen an das System anzubinden und so eine Verarbeitungspipeline zu realisieren, welche die anliegenden Komponenten mit den nötigen Daten versieht, somit ist letztere Anforderung erfüllt. Die erste Anforderung kann als erfüllt angesehen werden, vorausgesetzt der Renderer und Tracker erfüllen ihrerseits die Vorgabe: Ein Renderer, der die AiRmob Oberklasse spezialisiert, soll automatisch Kameradaten empfangen. Ein Tracker, der die Airmob Oberklasse spezialisiert, soll automatisch Bilder als Trackingauftrag empfangen. Die Abschnitte 4.6 und 4.5 beschreiben, was nötig ist, um dies zu erfüllen. Es ist also noch vom Programmierer abhängig, ob eine Integration eines individuellen Renderers bzw. Trackers gelingt. Das Ableiten der Oberklassen allein garantiert keine fehlerfreie Funktionalität. Wenn die vorgegebenen Konventionen eingehalten werden, steht der Integration jedoch nichts im Wege. Die beiden Anforderungen wurden mit Abstrichen erfüllt. Der Benutzer muss bei Standardeinstellungen des Frameworks keine spezielle Konfiguartion vornehmen, damit eine AR-Pipeline zustande kommt. Wie die minimale Beispielanwendung gezeigt hat (siehe Abschnitt 5.1), verfügt das Framework über die nötigen Defaulteinstellungen, sodass ein Benutzer mit geringem Aufwand eine AR-Anwendung zum Laufen bringen kann. Die Anforderung ist erfüllt. Weitere Funktionalitäten und Einstellungen für das Framework sind dennoch vorhanden, aber optional. 54

60 Der Benutzer muss sich nicht um das Initialisieren der Kamera kümmern. Ebenfalls in der minimalen Beispielanwendung demonstriert ist, dass der Nutzer keine Einstellungen an der Kamera vornehmen muss, um diese in die Anwendung einzubinden. Er hat jedoch die Option, dies zu beeinflussen. Die Anforderung ist erfüllt. Das Framework muss ein Ausschlussverfahren für Marker in Abhängigkeit von GPS-Daten anbieten. Das Framework bietet zwar durch die GPSAlerts (siehe Abschnitt 4.7.2) eine Funktion, um auf GPS-Ortung zu reagieren, zielt damit aber nicht auf die Behandlung von Markern ab. Es können lediglich vordefinierte Ortsangaben unterschieden werden. Diese Anforderung wurde also nicht erfüllt. Die GPSAlerts passen hingegen eher in die folgende Anforderung: Das Framework kann dem Benutzer verschiedene Android-Funktionen vereinfacht zur Verfügung stellen. GPSAlerts übernehmen für den Benutzer die Verwendung des vom Android- SDK gebotenen BroadcastReceivers und vereinfacht so dessen Nutzung im Spezialfall der GPS-Verarbeitung. Die AiRmobActivity kapselt außerdem vereinfacht die Kamera, indem sie mehrere Befehle, die zu deren Kontrolle notwendig sind, in höhere Befehle zusammenfasst. An dieser stelle sind mit Sicherheit noch viele weitere Vereinfachungen denkbar, um dem Benutzer Arbeit zu ersparen und Programmcode übersichtlich zu halten. Es ist jedoch fraglich, ob eine zusätzliche Zusammenfassung des gut dokumentierten Android-SDK überhaupt Sinn macht. Denn durch das Kapseln von Funktionen geht auch immer ein Teil der Flexibilität verloren. Typische Funktionen, die bei AR-Anwendungen Verwendung finden, sollen vom Framework vereinfacht gekapselt werden. Die AiRmobActivity kann Displayeingaben sowohl auf die Markerebene als auch in eine Rotation relativ zu einem Referenzpunkt abbilden. Auch hier stellt sich die Frage, inwiefern eine Vorgabe solcher Funktionen sinnvoll ist. Das Abbilden auf die Markerebene ist sicherlich nützlich für eine Vielzahl von Anwendungen, alles weitere ist durch eine anwendungsspezifische Implementation aber durchaus effektiver. Das Framework beinhaltet also Elemente, die diese Anforderung erfüllen, es ist jedoch darüber nachzudenken, ob eine solche Anforderung überhaupt Anspruch eines AR- Frameworks sein sollte. Das Framework ist so aufgebaut, dass einzelne Teilfunktionen der Oberklassen leicht überladen oder überschrieben werden können. 55

61 Die Initialisierungsschritte innerhalb der AiRmobActivtiy sind in mehrere Methoden aufgeteilt. Dies fängt bei den Betriebssystemaufrufen des Activty- Lifecycle an und fährt mit Methodenaufrufen, wie onairmobinitialized, fort. Auf diese Weise ist es möglich, die Arbeitsweise der Activity an verschiedenen Stellen zu beeinflussen. Es muss aber beachtet werden, welche Funktionalität überladen oder überschrieben wird. Die Methoden sind deswegen entsprechend kommentiert, um den Benutzer zu informieren, an welcher Stelle sein neuer Code aufgerufen wird oder welche Funktionen durch Überschreiben einer Methode verloren gehen. Die Funktionsfähigkeit des Frameworks kann dann aber nicht mehr garantiert werden. Die Anforderung kann damit als teilweise erfüllt betrachtet werden Pipelinevarianten Jeder der Pipelinevarianten kann durchaus ihre Daseinsberechtigung zugesprochen werden, auch wenn dies stark von der Art und Weise der Anwendung abhängig ist. Die Unterscheidung zwischen kontinuierlichem Rendern und Rendern auf Anfrage kann sich für den Anwender nur optisch äußern, wenn Animationen Teil der grafischen Darstellung sind. Da der Renderer in einem eigenen Thread läuft, hat er durch verschiedene Frameraten keinen Einfluss auf andere Komponenten. Es ist jedoch davon auszugehen, dass das Rendern auf Anfrage dennoch kostengünstiger ist und so den Energieverbrauch geringfügig verringern kann, vorausgesetzt bei durchgehendem Rendern werden deutlich höhere Frame- als Trackingraten erreicht. Zusätzlich zu den nun genannten Verfahren ist es auch möglich, das Kamerabild als Textur an den Renderer weiterzugeben. Dadurch würde eine automatische Synchronisierung von Kamerabild und Renderergebnis stattfinden. Die Übergabe des Bildes ist im Framework zwar möglich, aber ineffizient implementiert. Da sich das Bildformat des eintreffenden Kamerabildes von dem OpenGL-unterstützten Format unterscheidet, ist eine Konvertierung notwendig. Diese ist momentan in Javacode implementiert und entsprechend langsam. Ein Grund dafür könnte die Speicherverwaltung von Java sein. Effizienter wäre wahrscheinlich eine Implementierung durch das NDK im C++ Code. Dies bietet das Framework jedoch nicht an. Dennoch wird das Kamerabild an nativen Code übergeben, damit es vom Trackingsystem verarbeitet werden kann. Möchte man also eine Lösung zur Nutzung des Kamerabildes als Hintergrundtextur realisieren, ist der Weg über den Tracker zu wählen, um das Bild zu konvertieren. Ein Blick in den Code von Programmbeispielen des Qualcomm-Frameworks zeigt eine Alternative. Hier wird das Kamerabild direkt im nativen Code empfangen, womit sich eine Übertragung über die Java - C++ Schnittstelle erübrigt. 56

62 x144, 2 Triangles FPS TPS 5 0 kontinuierliches Rendern kontinuierliches Rendern mit Buffer Rendern auf Anfrage Rendern auf Anfrage mit Buffer x144, 968 Triangles FPS TPS 0 kontinuierliches Rendern kontinuierliches Rendern mit Buffer Rendern auf Anfrage Rendern auf Anfrage mit Buffer x432, 2 Triangles FPS TPS 0 kontinuierliches Rendern kontinuierliches Rendern mit Buffer Rendern auf Anfrage Rendern auf Anfrage mit Buffer x432, 968 Triangles FPS TPS 2 0 kontinuierliches Rendern kontinuierliches Rendern mit Buffer Rendern auf Anfrage Rendern auf Anfrage mit Buffer Abbildung 35: Leistungsergebnisse Acer Iconia Tab A500 57

63 Abbildung 35 ist das Ergebnis eines Tests auf dem Acer Iconia Tab A500 mit Androidversion 3.2 Honeycomb (Leistungsmerkmale siehe [Ace]). Es wurden die verfügbaren Pipelinevarianten auf unterschiedlichen Bildschirmauflösungen und je mit einem Polygon, bestehend aus zwei Dreiecken und einem komplexeren Modell, getestet. In jeder Szene war eine Lichtquelle vorhanden und es wurde Phong-Shading eingestezt. Die ersten vier Diagramme nutzen den Kameralivestream sofort als Hintergrund, für das untere Diagramm wurde das Kamerabild immer als Textur an den Renderer mitgegeben und dort eingesetzt. Zunächst ist zu beobachten, dass zwischen Tracking mit und ohne Buffer ein deutlicher Unterschied erzielt werden kann. Die Anzahl der getrackten Bilder kann hier deutlich gesteigert werden, wodurch eine flüssigere Anpassung des Renderers an die reale Umgebung stattfindet. Auf die Verzögerung, die zwischen Empfangen des Kamerabildes und Rendern in entsprechender Pose stattfindet, hat diese Einstellung jedoch keine sichtbare Auswirkung. Es ist jedoch eher zu vermuten, dass das parallele Tracking die Zeit für einen einzigen Trackingvorgang sogar erhöht. Was man jedoch erkennt, ist dass das Kamerabild selbst mit einer größeren Verzögerung angezeigt wird, wenn kontinuierliches Rendern angewandt wird. Kontinuierliches Rendern und Rendern auf Anfrage machen auf dem Acer Iconia Tab ansonsten keinen nennenswerten Unterschied. Da die Trackingraten höher sind als die möglichen Frameraten, ist die Grafikhardware stets ausgelastet. Die Anzahl an Dreiecken in der Szene machen einen deutlichen Unterschied. Die FPS bei der komplexen Szene sind bis zu einem Drittel niedriger als bei der einfachen Szene Texturhintergrund FPS TPS x144 2 Triangles 176x Triangle 768x432 2 Triangles 768x x Triangle 2 Triangles 1280x Triangle Abbildung 36: Leistungsergebnisse Acer Iconia Tab A500 Betrachtet man nun das Rendern mit Texturhintergrund in Abbildung 36, so liefern beide Szenen fast identische Ergebnisse. Die jeweiligen Werte sind mit den Ergebnissen von Rendern auf Anfrage der anderen Diagramme zu vergleichen, da hier immer nur ein Bild getrackt und daraufhin die Szene gerendert wurde. Es ist sofort erkennbar, dass die Performance erheblich von der Pixelanzahl abhängig ist. Grund dafür ist, dass jedes Bild konvertiert werden muss und der Aufwand mit größeren Bildern entsprechend 58

64 steigt. Interessant ist jedoch, dass die Leistung im unteren Auflösungsbereich mit den anderen Pipelinevarianten vergleichbar ist. Der Renderer füllt den Bildschirm im Texturmodus vollkommen opak aus, womit das Verrechnen mit dem Livekamerastream wegfällt. Das könnte ein Grund für diese Beobachtung sein, müsste aber intensiver getestet werden. Eine solch niedrige Auflösung liefert aber kein zufriedenstellendes optisches Ergebnis, wie Abbildung 37 beweist. Abschließend lässt sich sagen, dass auf dem Acer Iconia Tab keine der Varianten Ergebnisse liefert, wie man sie von einem Echtzeitsystem erwarten würde. Die Trackingraten erreichen zwar ein Echtzeitmaß, die Grafikkomponente liegt jedoch weit darunter. Abbildung 37: Teapot vor Kameratextur mit minimaler Auflösung Als nächstes wurde der selbe Test auf dem Samsung Galaxy S2 durchgeführt (Leistungsmerkmale siehe [wikd]). Da es andere Kamerauflösungen unterstützt, ist es nicht eins zu eins mit dem vorigen Test zu vergleichen. Als allererstes fällt auf, dass die Frameraten erheblich höher sind. Das S2 hat den Grafikchip Mali-400 verbaut. Der Hersteller ARM nennt als eines der Features 3 effizientes Alphablending. Da der Kameralivestream immer mit dem Rendererergebnis verrechnet wird, könnte dies ein Grund für die höhere Leistung sein. Bei niedriger Auflösung ist die Trackingrate immer am Maximum von 30. Die Framerate wird beim Rendern auf Anfrage entsprechend heruntergesetzt. Werden zusätzlich Buffer eingesetzt, sieht man, dass die FPS leicht unter den TPS liegen können. Ursache dafür könnte sein, dass ein paralleler Trackingaufruf den Renderer zum Zeichnen anstoßen will, während dieser noch einen früheren Auftrag bearbeitet. Der letzte Aufruf geht dann verloren. Eine größere Anzahl von Triangles wirkt sich beim S2 ebenfalls auf die Trackingrate aus. 3 mp.php 59