Augmented Reality Darstellung von WLAN-Netzwerken

Universität Rostock Fakultät für Informatik und Elektrotechnik Institut für Informatik Lehrstuhl für Informations- und Kommunikationsdienste Augmented Reality Darstellung von WLAN-Netzwerken Bachelorarbeit Erstgutachter & Betreuer: Dr. Thomas Mundt Zweitgutachter : Dipl.-Inf. Martin Garbe vorgelegt von: Daniel Odebrecht Abgabedatum: 24/01/2012

INHALTSVERZEICHNIS 1 Einleitung... 3 2 Technische Grundlagen von Augmented Reality... 4 2.1 Darstellung... 5 2.1.1 Bildschirmdarstellung... 5 2.1.2 Head-Mounted-Display (HDM)... 6 2.1.3 Head-Up-Display (HUD)... 7 2.1.4 Kontaktlinse... 8 2.1.5 Mobile Geräte... 9 2.1.6 Video- Und Laserprojektion... 11 2.2 Tracking... 11 2.2.1 Trackingtechniken... 12 2.2.2 Nichtvisuelles Tracking... 12 2.2.3 Visuelles Tracking... 17 2.3 Softwareframeworks... 21 2.4 AR-Software für Smartphone's... 24 2.4.1 Browser... 24 2.4.1 Wikitude World Browser... 24 2.4.2 Layar Reality Browser... 27 2.4.3 Junaio... 28 3 Konzeption... 29 3.1 Die Opennet Initiative... 30 3.2 Architektur... 31 3.2.1 Die App... 33 3.2.2 Der Webservice... 34 4 Umsetzung... 36 4.1 Serverkomponenten... 36 4.1.1 Die Steuerskripte... 36 4.1.2 Die Transformation... 38 4.1.3 Der Webservice... 42 4.2 Die App... 43 5 Zusammenfassung... 51 6 Literaturverzeichnis... 54 2

1 EINLEITUNG Zu Beginn sollte der Ausdruck Augmented Reality(AR) erläutert werden, welcher mit erweiterter Realität übersetzt wird. Dies deutet bereits an, dass es sich hier um einen Zwischenraum handelt. Der Realität, wie wir sie wahrnehmen, steht hierbei eine virtuelle computergenerierte Realität gegenüber. Computergenerierte Welten sind seit Kinofilmen wie Toy Story wohl jedem bekannt und werden in der Unterhaltungsindustrie bis hin zur Ausbildung, z.b. von Piloten in Simulatoren, in vielen Bereichen genutzt. Nach Ron Azuma bildet die Augmented Reality nun einen Mittelbereich zwischen der völligen Synthetik der virtuellen Welt und der reellen Welt, in dem virtuelle Objekte mit der realen Welt kombiniert werden. [1] Dies erreicht man, indem mittels Kamera ein reales Bild aufgenommen wird, in das anschließend virtuelle Objekte eingefügt werden. Diese virtuellen Objekte sollten typischerweise einen Kontext zu den Inhalten des realen Bildes haben, da zum Beispiel der Batteriestatus einer Kamera, welcher in das Bild eingeblendet wird, hier nicht als Augmented Reality betrachtet wird. Die Anwendungen für AR müssen also zwischen den virtuellen Objekten und denen des realen Bildes eine sinnvolle Verbindung herstellen. Das kann geschehen durch Erkennen von Objekten und/oder durch Ortsbestimmung. So können dann zu den Objekten oder Orten bekannte Daten in das Bild integriert werden. Hieraus ergeben sich schon einige der typischen Anforderungen an ein AR-System. Kombination realer Bilder mit Computergrafik Erkennen von Objekten in Echtzeit Interaktion mit den erkannten Objekten anbieten Darstellung von kontextbezogenen Daten in Echtzeit [2] Positions- und Lagebestimmung sowie Einbinden ortsbezogener Daten Aufgrund der Anforderungen waren AR-Systeme meist speziell für den jeweiligen Anwendungsfall angepasst. Es wird oft viel Sensorik und Rechenleistung benötigt um die Grafiken passend in Echtzeit in das Bild einzufügen. Das Militär nutzte diese Technologie dann schon früh in Flugzeugcockpits, um z. B. den künstlichen Horizont einzublenden. 3

Die Sensoren waren alle vorhanden und die Anzeige konnte mittels Head-Up- Display direkt in das Sichtfeld hinein projiziert werden. Im zivilen Bereich möchte ich als weiteres Beispiel die Produktherstellung nennen. Dort werden "CAD/CAM- Daten direkt auf das Werkstück projiziert, wodurch Fertigungsfehler sofort erkennbar sind". [3] Inzwischen begegnet uns die Augmented Reality auch bei diversen Sportereignissen, wo Linien helfen sollen, ein Abseits beim Fußball oder eine Bestmarke beim Skiweitsprung schneller erkennen zu können. Ein aufstrebender Trend ist AR auf Smartphone's. Hier wird neben Display und Kamera inzwischen eine Vielzahl von Sensoren verbaut, um zum Beispiel die Position und Lage zu ermitteln, womit sich ortsbezogene AR-Anwendungen für eine Vielzahl von Inhalten umsetzen lassen. Die technischen Voraussetzungen für die jeweiligen AR-Anwendungsarten sollen in dieser Arbeit gezeigt werden sowie der Trend und Stand der Technik von AR-Anwendungen auf Smartphone's im Speziellen. Anschließend wird eine Applikation (App) implementiert, welche die AR-Technik einsetzt, um die Leistungsdaten eines freien Funknetzes einer Großstadt zu visualisieren. Anwendungen solcher Art finden sich in verschiedenen Bereichen. Hier dient sie zur Hilfe bei Montage oder Wartung. Ähnliche Anwendungen können auch im Alltag zur Orientierung in Großstädten oder als Infotainment z. B. bei Stadtrundfahrten genutzt werden. Mit steigender Leistung der mobilen Geräte, lassen sich auch AR-Anwendungen realisieren, die Markierungen oder Bilderkennung ohne Hilfsmittel einsetzen. Diese Techniken werden vorrangig bei Werbung und Unterhaltungssoftware verwendet, um Interaktivität mit dem Nutzer zu ermöglichen. 2 TECHNISCHE GRUNDLAGEN VON AUGMENTED REALITY Um ein AR-System zu realisieren, sind die zwei Aspekte Darstellung und Tracking nötig. Das Tracking dient dazu reale Objekte und deren Position zu erkennen. Die Darstellung visualisiert dazu, die virtuellen Elemente. Zu beidem gibt es eine Vielzahl von Technologien, über die nun eine Übersicht folgt. 4

2.1 DARSTELLUNG Je nach Anwendungsgebiet kommen unterschiedliche User-Interfaces(UI) zum Einsatz, welche zwischen einem Softwareprodukt und dem Endbenutzer, d.h. die von Seiten des Softwareprodukts vorgegebene Art und Weise der Interaktion (z.b. Führung des Benutzers, Möglichkeiten des Benutzers, selbst initiativ zu werden, Menütechnik, Maske) realisieren. [4] Abhängig vom UI werden verschiedene Verfahren benutzt, um die virtuellen Elemente hinein zu projizieren. Hierbei nennen [5] und [2] die folgenden Methoden. Bildschirmdarstellung Head-Mounted-Display (HDM) Head-Up-Display Kontaktlinse Mobile Geräte Video- oder Laserprojektion 2.1.1 BILDSCHIRMDARSTELLUNG Bei der Bildschirmdarstellung kommen handelsübliche Monitore oder Fernsehgeräte bei der Darstellung zum Einsatz. Als Beispiel sei hier nochmals die Fußballübertragung genannt, dabei können zusätzliche Informationen wie Abstände auf dem Platz eingeblendet werden. Denkbar wäre auch ein Heimrechner mit Webcam, der gemarkerte Objekte erkennt und mit vordefinierten Modellen überlagert. Die Kamera ist hier allerdings selten wirklich in Blickrichtung des Bildschirms ausgerichtet, sondern steht getrennt vom Display. Der Vorteil liegt hier bei den geringen Kosten der Komponenten, so dass dies zur Probe einlädt. Die resultierenden Systeme sind aber kaum interaktiv und durch das statische Display kommt es kaum zur Immersion. Es wird wie bei der Sportübertragung eher ein kurzer und knapper Informationsgewinn erzeugt. 5

2.1.2 HEAD-MOUNTED-DISPLAY (HDM) Bei einem Head-Mounted-Display ist der Bildschirm im Sichtfeld des Benutzers direkt am Kopf befestigt, ebenso wie die in Blickrichtung zeigende Kamera (siehe Abb. 1). Je nach Art der Überlagerung von realen und virtuellen Bildteilen muss hierbei zwischen video-see-through (VST) und optical-see-through (OST) unterschieden werden.[1][6] Bei VST-Systemen wird mittels der Kamera die reale Umgebung aufgezeichnet und versucht, passende Objekte in das Bild einzufügen, welches dann auf dem Display dargestellt wird. Die komplette Umgebung wird durch den Benutzer über das Display wahrgenommen. Im Gegensatz dazu werden bei OST-Systemen die virtuellen Objekte auf einen halbdurchlässigen Spiegel projiziert, so dass der Benutzer die reale Welt direkt wahrnimmt und die zusätzlichen Informationen im Sichtfeld entstehen. Die Überlagerung der Darstellungen erfolgt dann im Auge des Benutzers. Abb. 1 Head-Mounted-Display (Modell Vuzix Star 1200) Die Vorteile der HMDs liegen darin, dass der Benutzer sich sehr frei bewegen kann. Der Einsatz für solche Systeme ist damit breiter gefächert. Dem stehen einige Nachteile entgegen, wie z. B. die teurere Hardware, welche am Körper getragen werden muss. Die ersten Modelle mussten aufgrund ihres Gewichtes noch von 6

externen Hilfsmitteln gehalten werden, während inzwischen aber schon relativ handliche Hardware verfügbar ist. Bei dieser Art Anwendung steigt der Rechenaufwand enorm, da z.b. bei VST-Systemen zwischen Aufnehmen der Szene und Darstellung auf den Displays kaum Verzögerungen auftreten dürfen. Die zeitliche Differenz zwischen der Bewegung des Nutzers und der Darstellung führt sonst zu Orientierungsproblemen. Problematisch ist zudem, dass die Displays in fixer Entfernung zum Auge stehen, während die dargestellten Objekte sich weit weg befinden können. Das Auge fokussiert bei unterschiedlich fernen Objekten jeweils anders, muss hier aber aufgrund des nahen Displays konstant fokussiert sein. Dies kann zu Schwindelgefühlen und Kopfschmerzen führen. 2.1.3 HEAD-UP-DISPLAY (HUD) Wie schon in der Einleitung erwähnt, war das Head-Up-Display eine der ersten eingesetzten Anwendungen von Augmented Reality. Das Militär nutzt es, um Informationen wie Flughöhe und künstlichen Horizont in das Sichtfeld von Kampfjetpiloten einzublenden. Heute wird im zivilen Bereich versucht, diese Technologie für den Einsatz in Fahrzeugen zu nutzen, damit die Fahrer den Blick nicht mehr von der Straße nehmen müssen, um z.b. die Geschwindigkeit oder Navigationsinformationen abzulesen. [7] Die Technologie gleicht den OST- Systemen, welche in 2.1.2 beschrieben wurden. HUDs kommen bei festgelegten Blickrichtungen zum Einsatz, wo dem Nutzer ermöglicht werden soll, zusätzliche Informationen aufzunehmen, ohne den Blick abwenden zu müssen. 7

Abb. 2 Head-Up-Display (BMW, 2011) 2.1.4 KONTAKTLINSE Kontaktlinsen lassen sich mit winzigen Stromkreisen und LEDs ausstatten, so dass damit Einblendungen in das Sichtfeld möglich werden. (siehe Abb. 3) Diese Technologie ist noch nicht ganz bereit für echte AR-Anwendungen, da erste einige wenige LEDs aufgebracht werden können. Die Anzahl soll aber auf Hunderte erhöht werden, um damit in der Lage zu sein, Text, Tabellen und Bilder darzustellen. [8] Die Anwendungen wären vielfältig, je nachdem wie viel zusätzliche Sensorik und Elektronik eingesetzt wird. Parviz nennt zum Beispiel einen Glucosesensor, der es Diabetikern ermöglichen würde, ihren Glucosespiegel zu überwachen, ohne sich in den Finger zu stechen und messen zu müssen. Hier würden auch schon wenige Pixel reichen, die im Notfall als Indikator aufleuchten. 8

Abb. 3 Kontaktlinse (Parviz, University of Washington 2009) Die Herausforderung besteht darin, die natürliche Sicht durch die integrierten Komponenten nicht zu behindern. Die Herstellung der Linse ist ebenfalls recht schwierig, da z.b. Bestandteile der LED giftig sind, so dass diese speziell abgeschirmt werden müssen. Ein scharfes Bild direkt auf dem Auge zu erzeugen, ist ebenso problematisch und wird gelöst, indem vor den LEDs mehrere Minilinsen integriert werden, so dass die Darstellung erscheint, als würde sie je nach verwendeter Linse etwa einen halben Meter vor einem schweben. 2.1.5 MOBILE GERÄTE Die mobilen Geräte, allen voran Mobiltelefone, sind zu einer ernsthaften und verlockenden Plattform für mobile AR-Anwendungen geworden, da sie typischer Weise alles nötige Equipment für video-see-through AR-Anwendungen bereitstellen: Einen Computer [...], eine Kamera und ein Display. [9] Eine Kamera ist dabei meist auf der Gegenseite zum Display verbaut, so dass im wesentlichen wie bei HMDs als VST-System vorgegangen wird, nur dass das Gerät dabei in das Sichtfeld gehalten werden muss und nicht am Kopf getragen wird. Klein führt weiter an, dass mit der steigenden Qualität der Kameras und der Rechenleistung der verwendeten Prozessoren bald auch ein wesentlich besseres optisches Tracking, insbesondere 9

das Tracking ohne Verwendung von Markern [Anm. d. Verf.], möglich wird, was die Möglichkeiten für Augmented Reality noch wesentlich erweitern würde. Mobile Plattformen, zu denen auch noch Tablets zu nennen sind, beherbergen neben der Kamera auch noch eine große Anzahl weiterer Sensoren zur Orts- und Lagebestimmung, welche später beim Tracking noch beleuchtet werden. Abb. 4 AR-Anwendung auf Smartphone (Samsung Galaxy S Plus, 2011) Die Vorteile der mobilen Geräte sind vielfältig. Sie lassen sich wie HMDs benutzen, ohne aber alle Technik umständlich am Kopf tragen zu müssen. Es handelt sich um Massenware, wodurch der Preis relativ gering ist und es eine weite Verbreitung gibt. Die Vielfalt an Sensoren erlaubt viele Trackingtechniken und auch deren Verbindung, wodurch eine große Zahl an AR-Anwendungen denkbar ist. Als Nachteile werden kleine Displays und geringe Prozessorleistung genannt. [4] Mobile Geräte mit größeren Displays werden inzwischen als Tablet-PC immer verbreiteter. Die Leistung ist laut Klein [9] noch weit hinter der von Desktop-PCs, aber durch die Forscher konnte gezeigt werden, dass selbst diese schon für visuelles Echtzeittracking reicht. 10

2.1.6 VIDEO- UND LASERPROJEKTION Neben den bisher genannten Darstellungsformen gibt es noch eine weniger eingesetzte Methode, bei der die Informationen direkt auf die realen Objekte projiziert werden. Dabei ist zwischen Video- und Laserprojektion zu unterscheiden, welche verschiedene Vor- und Nachteile besitzen. Thomas Schilling[3] bietet dabei folgenden Vergleich: Videoprojektor: Vorteile: - Vollfarbendarstellung möglich - niedriger Anschaffungspreis - standardisierte Bildausgabe Laserprojektor: - die Darstellung ist auf der gesamten Projektionstiefe scharf - keine Linsenverzerrung Nachteile: - Unschärfen im Bild bei der Darstellung außerhalb des Fokusbereiches - Linsenverzerrung der Abbildung - relativ hohe Anschaffungskosten - derzeit nur mit Aufwand eine Vollfarbendarstellung möglich - stellt standardmäßig eine Liniengrafik dar (keine Vollflächengrafikausgabe) 2.2 TRACKING Wie zuvor genannt, zählt zu den grundlegenden Eigenschaften einer Augmented Reality Anwendung, dass zwischen den realen und virtuellen Objekten ein Zusammenhang hergestellt wird. Um dies zu erreichen, müssen die realen Objekte erkannt werden. Position und Lage müssen oft nicht nur für das Objekt bestimmt werden, sondern auch für das Gerät selbst. "Der Prozess der Lagebestimmung wird gemeinhin als Tracking bezeichnet." [10] Bei den dabei eingesetzten Methoden geht es vor allem um die Notwendigkeiten bei der Anwendung. AR-Anwendungen, die Chirurgen assistieren sollen, müssen 11

natürlich ungleich genauer sein, als eine mobile Anwendung zum Auffinden der nächsten U-Bahnhaltestelle. 2.2.1 TRACKINGTECHNIKEN Die Aufgabe des Tracking's kann mit verschiedenen Sensoren und deren jeweiliger Kombination gelöst werden. "Grundsätzlich können zwei verschiedene Verfahren unterschieden werden: Nichtvisuelles und visuelles Tracking." [5] Das visuelle bzw. optische Tracking teilt sich nochmal auf, je nachdem ob mit oder ohne künstlichen Markern gearbeitet wird. 2.2.2 NICHTVISUELLES TRACKING Es gibt eine Vielzahl an nichtvisuellen Trackingmethoden, so dass hier nur auf eine Auswahl eingegangen wird, welche sich aus den Quellen [5], [11], [12] und [13] zusammensetzt. GPS Gyroskope, Kompass Optische Sensoren Ultraschallsensoren magnetisches Tracking Accelerometer Positionsbestimmung per WLAN GPS Das Global Positioning System ist ein Satellitensystem, das zur Positions- und Zeitbestimmung genutzt werden kann. [15] Es wurde in den 1970er-Jahren vom US- Verteidigungsministerium entwickelt und aufgebaut. Seit den 1990er-Jahren ist es voll funktionsfähig. Neben der militärischen Nutzung war auch eine zivile Nutzung möglich, allerdings mit weniger Genauigkeit durch eine künstliche Verschlechterung des Signals. Diese Selected Availability wurde im Jahr 2000 deaktiviert und erlaubt nun eine genauere Ermittlung des Standortes. 12

Die Funktionsweise des Systems basiert auf Trilateration. Die Satelliten senden ständig ihre Position und Uhrzeit aus. Aus diesen Signallaufzeiten können die Empfänger dann ihre eigene Position berechnen. Für eine korrekte Positionsbestimmung werden 4 sichtbare Satelliten benötigt. Theoretisch reichen zwar 3 Satelliten, um die Position eines GPS-Empfängers aus den Laufzeiten zu ermitteln(siehe Abb.5), aber die Uhr des Empfängers ist ungenau und hat eine unbekannte Abweichung. Aus den Laufzeiten von vier Satellitensignalen kann die Zeitabweichung der Empfängeruhr bestimmt werden, womit eine korrekte Lösung des Gleichungssystems möglich ist. [11] Abb. 5 Trilateration eines Punktes (schematische Darstellung von hopf.com) Dabei werden mindestens 24 Satelliten gebraucht, um weltweite Erreichbarkeit zu gewährleisten. Die Anzahl der Satelliten ist allerdings höhe,r um Ausfallsicherheit und bessere Erreichbarkeit sicherzustellen. Abweichungen der Satellitenuhren und -bahnen werden durch ein Netz aus Bodenstationen korrigiert. Heute lässt sich die Position auf weniger als 10m genau bestimmen, was zur Navigation in Autos oder für die Ortsbestimmung eines Handys ausreicht. 13

Gyroskope/Kompass Gyroskope bzw. Kompasse helfen, die Lage und Ausrichtung im Raum nachzuvollziehen. Der Kompass basiert darauf, dass sich anhand des Magnetfeldes der Erde eine Orientierung ermitteln lässt. Elektronische Kompasse können die Himmelsrichtung sehr genau ermitteln. Gyroskope ermöglichen es, Neigungen und Rotationen zu detektieren. Es gibt sie in vielerlei Ausführungen. Die ersten mechanischen Gyroskope basieren darauf, dass rotierende Elemente aufgrund der Drehimpulserhaltung stabil sind. Wird das System extern rotiert, wirkt eine messbare Kraft. Mit 3 senkrecht zueinander ausgerichteten Gyroskopen kann man also alle Orientierungsänderungen im Raum nachvollziehen. Das Problem bei diesen Systemen ist der Drift, welcher entsteht durch minimale Abweichungen der Achsen zueinander. [11] Es lassen sich zuverlässigere optische Gyroskope bauen, indem man einen Laserstrahl mittels Spiegeln durch eine Ringbahn lenkt. (siehe Abb. 6) Durch Einsatz von halbdurchlässigen Spiegeln, wird der Strahl geteilt, so dass zwei Strahlen, welche entgegengesetzt durch die Ringbahn laufen, entstehen. In Ruhe treffen beide Strahlen gleich auf. Wird das System allerdings auf einer Normalenachse rotiert, kommt es zu einer messbaren Phasenverschiebung. Abb. 6 Ringlasergyroskop 14

Ultraschallsensoren Diese Sensoren können eingesetzt werden, um Entfernungen zu messen, indem in kurzen Zeitintervallen Ultraschallimpulse ausgesendet werden. [12] Die Zeit bis die Reflektion eintrifft, wird mittels Mikrofon gemessen. Bringt man mindestens 3 Sender, in einem bekannten Muster wie einem Dreieck, auf einem zu trackendem Objekt an und misst deren Signallaufzeiten, kann man sowohl Orientierung als auch Position des Objektes bestimmen. Als Vorteil gilt hierbei, dass die Sender klein und leicht sind. Nachteilig sind die Ungenauigkeiten, welche dadurch entstehen, dass der Schall temperatur- und druckabhängig ist. Außerdem nimmt die Signalstärke mit Entfernung ab, was keinen Einsatz über zu große Distanzen zulässt. [11] Optische Sensoren Als Beispiel wird hier Infrarotlicht behandelt. Mittels Pulsphasenmodulation lassen sich Nachrichten codieren, welche von einem Sensornetzwerk ausgewertet werden können. Sendet man kontinuierlich in festen Zeitabständen, lässt sich das sendende Objekt durch das Sensornetzwerk verfolgen. [14] Die Vorteile liegen dabei in den günstigen Komponenten. Als Nachteil zeigt sich, dass das Signal leicht unterbrochen werden kann und nur eine geringe Reichweite hat. Magnetisches Tracking Es werden Spulen am zu verfolgenden Objekt angebracht, welche orthogonal zu einander ausgerichtet sind. Um nun Lage und Position bestimmen zu können, wird der induzierte Fluss von einem Sensor gemessen. Da durch die drei Spulen ein Referenzsystem aufgestellt wurde, kann hieraus die Orientierung ermittelt werden. [12] Da magnetische Tracker billig, leicht und kompakt sind, werden diese gern eingesetzt. Die Reichweite der Systeme ist allerdings durch die Dämpfung des Signals begrenzt. [11] Aufgrund der Nebeneffekte des elektromagnetischen Feldes können die Signale nicht beliebig verstärkt werden. 15

Accelerometer Beschleunigungssensoren benutzen eine Masse, an welcher auftretende Trägheitskräfte gemessen werden. Die Masse kann z.b. auf einem piezoelektrischen Kristall befestigt werden. Durch eine Beschleunigung wird durch die Trägheit der Masse ein Druck erzeugt, welcher wiederum aufgrund des piezoelektrischen Kristalls einen messbaren elektrischen Effekt erzeugt. [11] Es gibt eine Vielzahl an Möglichkeiten, den Sensor zu realisieren. So können auch kapazitive Änderungen gemessen werden, wenn die Masse ein federnd gelagerter Metallstab ist oder man nutzt den Hall-Effekt, um Änderungen der Spannung zu messen, wenn die bewegte Masse sich durch ein Magnetfeld bewegt. [16] Aus Silizium lassen sich auch kleinste Systeme bauen, welche selbst gegen starke Änderungen der Beschleunigung resistent sind, wobei trotzdem eine hohe Messgenauigkeit gewährleistet werden kann. Solche Accelerometer sind billig, da sie inzwischen zur Massenware gehören und z.b. in Mobiltelefone eingebaut werden.[17] Sofern Anfangsposition und geschwindigkeit bekannt sind, lässt sich durch zweifache Integration über die Zeit auch die Position ermitteln. Positionsbestimmung per WLAN Ein grobe Positionsbestimmung wird durch WLAN gewährleistet, wenn man den Standpunkt eines Netzes kennt und dieses empfängt. Fertigt man hiermit eine Karte an, kann man aufgrund der an einem Standort sichtbaren Netze einen Rückschluss auf den ungefähren Aufenthaltsort fällen. Ein wesentlich genaueres Orten ermöglicht der Einsatz des RADAR genannten Systems. [18] Es wurde erforscht, um die Lücke zwischen groben Methoden wie GPS und GSM-Ortung und Kurzdistanzansätzen wie Infrarot-Licht-Systemen zu schließen. Verwendet wird handelsübliche Hardware um das WLAN zu betreiben. Zur möglichen Ortung sind generell zwei Phasen nötig. Dabei gibt es eine vorbereitende Offlinephase und eine Onlinephase, in der die eigentliche Ortung vorgenommen wird. Während der Offlinephase wird eine Karte erstellt. Dazu wird innerhalb des Netzes, welches mindestens drei Access Points (APs) haben sollte, 16

eine große Zahl an Messungen vorgenommen. Dabei werden Signalstärke und Signalrauschen zu den APs gemessen und zusammen mit Koordinaten in einer Datenbank gespeichert. In der Onlinephase wird nun versucht, tatsächlich eine Ortung durchzuführen, indem man wieder eine Messung der Signale der APs vornimmt und dann in der Datenbank nach einem ähnlichen Eintrag sucht. Bei mehreren in der Nähe befindlichen Referenzpunkten, gibt es keinen Grund nur den am besten passenden anzunehmen, sondern es wird ein Mittel über die nahen Referenzpunkte gebildet über das dann der Standpunkt angenommen wird. [18] Der Vorteil dieses Systems ist, dass es gut innerhalb von Gebäuden funktioniert, im Gegensatz zu anderen Ansätzen und nicht unter den Nachteilen von IR-Systemen, wie die starke Störung und kurze Reichweite, leidet. Getestet wurde das System allerdings in einer Etage. Durch die Erstellung einer eigenen Roadmap für jede Etage wird kann dieses Problem gelöst werden. [13] Die Genauigkeit des Systems wird je nach genutztem Algorithmus, der die Messdaten mit den Referenzdaten vergleicht, auf bis zu weniger als 3m angegeben. 2.2.3 VISUELLES TRACKING Bei visuellem Tracking wird mit einer Kamera ein Bild aufgenommen und auf bekannte Objekte untersucht. Diese Aufgabe ist sehr komplex, so dass zur Vereinfachung künstliche Marker eingeführt wurden. Diese Marker haben geometrische oder farbliche Eigenschaften und sind leicht in einem Videostream zu identifizieren. [9] Daher gilt es beim visuellen Tracking zwischen dem Tracking mit und ohne Nutzung künstlicher Marker zu unterscheiden. Bei visuellem Tracking wird in zwei Schritten vorgegangen. Im ersten Schritt wird das Bild bearbeitet, um die wesentlichen Informationen herauszufiltern und anschließend wird in einem zweiten Schritt die Position ermittelt.[5] Das visuelle Tracking ist dabei im Wesentlichen auf die verwendete Hardware angewiesen, da die Qualität des Bildes von der Kamera direkten Einfluss auf das Ergebnis hat. Farbtiefe, Rauschen und Verzerrungen beeinflussen die Fähigkeit des Trackers enorm. 17

Visuelles Tracking mit künstlichen Markern Die Nutzung künstlicher Marker ist in der Augmented Reality weit verbreitet und wird in absehbarer Zukunft auch noch nötig sein. Unter einem Marker versteht man ein zwei- oder dreidimensionales Objekt, das durch seine Art und Form leicht durch eine Kamera identifiziert (getrackt) werden kann. [5] Am meisten verbreitet sind quadratisch geformte Marker, da man vier Punkte hat, welche in bekannter Relation zu einander stehen, so dass hieraus leicht die Kamerakalibrierung mit einem einzigen Marker bewerkstelligt werden kann.[19] Zhang und Navab führen im weiteren verbreitete Marker an, von denen auch hier einige vorgestellt werden sollen: ATK-Marker des ARToolkits HOM-Marker des Hoffman Marker Systems IDG-Marker des Fraunhofer Institutes für graphische Datenverarbeitung SCR-Marker von Siemens Corporate Research ATK-Marker Das ARToolkit ist eine Softwarebibliothek zur Entwicklung von Augmented Reality Anwendungen. [20] Sie wurde von Dr. Hirokazu Kato entwickelt. Bereitgestellt wird Positions- und Orientierungstracking, Kamerakalibrierungscode und die Erkennung von Markern, welche einen schwarzen Rand haben und quadratisch sind. (siehe Abb. 7) Im Inneren befindet sich ein Muster. Dieses wird, mit in einer Datenbank gespeicherten, Schablone abgeglichen. Abb. 7 ATK-Marker der TU Dresden 18

HOM-Marker Der HOM-Marker wurde 1994 von C. Hoffman bei der Siemens AG für Fotogrammetrie entwickelt. Das System diente später für Dokumentations- und Wartungszwecke.[19] Um den Marker befindet sich noch ein Rahmen an dessen rechter Seite sich 6 zusätzliche Bits befinden, um die Erkennung des Markers zu verbessern. (siehe Abb. 8) IGD-Marker Abb. 8 HOM-Marker von Zhang und Navab[19] Das Fraunhofer-Institut für Graphische Datenverarbeitung hat Marker entwickelt für industrielle und touristische Zwecke. Im Rahmen des ARVIKA-Projektes [21], einem vom Bundesministerium für Bildung und Forschung gefördertem Projekt, wurden die Marker von den Partnern eingesetzt. Zielsetzung von ARVIKA und dem Folgeprojekt ARTESAS[22] war der Einsatz von Augmented Reality für industrielle Anwendungen wie Montage oder Entwicklung. Ein IGD-Marker ist ein in 6*6 kleinere Quadratstücke gleicher Größe unterteiltes Quadrat.(siehe Abb. 9) Die inneren 4*4 Quadrate werden genutzt um Orientierung und Code des Markers zu bestimmen. [19] Abb. 9 IGD-Marker von Zhang und Navab[19] 19

SCR-Marker Siemens Corporate Research entwickelte diese Marker für Lokalisierung und Tracking. Im Gegensatz zu den vorigen Markern werden statt Quadraten schwarze Kreise in einer 8*8 Matrix dargestellt., welche auf weißem Grund gezeichnet sind. (siehe Abb. 10) Weitere Marker Abb. 10 SCR-Marker von Zhang und Navab[19] Neben den hier vorgestellten Markern, welche sich durch dicken schwarzen Rand mit innerer Codierung auszeichneten, gibt es noch andere Modelle, wie z.b. Frame- Markern. Dabei wird im Rahmen des quadratischen Markers codiert, so dass die Innenfläche für andere Zwecke genutzt werden kann. Desweiteren gibt es Dot- Marker. Hierbei werden Punkte über einem Bild verteilt. Es gibt keine Codierung durch die Punkte, stattdessen werden Teilabschnitte des Bildes, welche durch die Punkte gebildet werden, mit einem Bildvergleich analysiert.[5] Visuelles Tracking ohne Marker In einigen Fällen ist das Anbringen der Marker schwierig oder die Nutzung von Markern schlicht unerwünscht. Dann muss versucht werden, Objekte nur anhand des von der Kamera aufgenommenen Bildes zu identifizieren. Hierbei wird ausgenutzt, dass oft einige in der Szene auftretende Elemente bekannt sind. Liegt zum Beispiel ein 3D-Modell eines Objektes vor, kann auf dem 2D-Videobild eine Mustersuche nach bekannten Schemen durchgeführt werden, um 2D-Orte mit 3D- Orten zu assoziieren. [23] Hat man so ein Objekt gefunden, lässt sich dessen 20

Orientierung und Position errechnen. Eine zweite Möglichkeit besteht darin, aus den gewonnenen Daten die Position und Ausrichtung der Kamera zu bestimmen. Anstatt vorgegebener 3D-Modelle lassen sich auch 2D-Daten verwenden. Diese texturierten flachen Ziele dienen dazu ein Trainingsset zu erstellen. [23] Mit dessen Hilfe können, nachdem das Bild auf Punkte, Kanten und Ecken untersucht wurde, sechs Freiheitsgrade (Position und Orientierung) bestimmt werden. Klein [24] nennt des weiteren Verfahren wie SLAM (Simultaneous Localization and Mapping) und PTAM (Parallel Tracking and Mapping). Beide kommen völlig ohne Vorkenntnisse aus. SLAM versucht, eine Karte zu erstellen und die eigene Position zu berechnen. Dies ist ein ausgesprochen komplexer Vorgang, der viel Rechenleistung benötigt und deswegen zur Zeit für mobile Endgeräte nur schwer zu leisten ist. Bei PTAM wird die Umgebung aus verschiedenen Perspektiven aufgezeichnet und versucht, daraus eine Lage innerhalb dieser Umgebung zu ermitteln. [5] Beide Verfahren sind sehr anfällig für verschwommene und unscharfe Bilder, was ihren Einsatz in Mobiltelefonen und ähnlichen Geräten zusätzlich erschwert. Markerbasiertes und markerloses Tracking lassen sich auch kombinieren. Bei diesem inkrementelles Tracking genannten Vorgang wird davon ausgegangen, dass sich um den Marker, der meist auf einer planen Fläche angebracht ist, noch eine texturierte Fläche befindet. Solange der Marker sichtbar ist, wird dieser als Grundwahrheit angenommen und markante Stellen, meist Features genannt, der Umgebung werden erfasst. Aufgrund der Annahme, dass sie in der gleichen Ebene wie der Marker liegen, kann ihre Position direkt berechnet werden. Sobald nun das Tracking des Markers versagt, wird begonnen die Features des aktuellen Frames mit denen des vorigen Frames mittels Schablonenabgleich zu vergleichen und das inkrementelle Tracking beginnt. [25] 2.3 SOFTWAREFRAMEWORKS Ein Überblick der im Augmented Reality Umfeld verwendeten Software soll hier dargestellt werden. Da die Anwendungen im Bereich AR lange sehr spezifisch 21

waren und von der jeweils verwendeten Hardware abhingen, war auch die zugehörige Software meist dafür maßgeschneidert. Inzwischen haben sich aber einige Produkte entwickelt, welche versuchen größere Bereiche abzudecken. Dabei reicht die Spanne von größeren kommerziellen Suiten bis hin zu freiverfügbaren Toolkits. Angelehnt an [5] soll hier ein Versuch einer kleinen Übersicht gegeben werden. Verglichen wurden in [5] die Produkte von Total Immersion [26], einer französischen Firma, welche als Marktführer genannt wird, von Metaio [27], einer deutschen Firma aus München, vom Fraunhofer IGD [28] und ARToolWorks [29] aus Seattle. Die folgende Tabelle vergleicht die Angebote: 22

Erkennung Tracking 3D-Rendering Internet-Features Betriebssysteme Flashanbindung Preisstruktur Beschreibung Total ARTool metaio IGD Immersion Works Realtime Bilderkennung Benutzung vorhandener Vorlagen zum Tracken X X X X SW-Marker-Erkennung Dezidierte Marker müssen vorhanden sein X X X Hand-Tracking Die Handbewegung wird als Marker erkannt X X Interfaces (Motion Capturing, etc.) Übertragung humanoider Bewegungen X X Pointing Detection Durch Verdecken bestimmter Flächenwerden Aktionen ausgelöst X X Face Tracking Gesichter werden als Marker erkannt X X 2D X Mimik Tracking Mimiken, Geschlecht und Alter werden erkannt X Markerbased Tracking Für Low Budget Anwendungen X X X X Markerless Tracking Für High Budget Anwendungen X X X X High Quality Rendering Qualitativ hochwertige Darstellung der virtuellen Objekte X X X X Physics Engine für nat. Interaktion Simulation natürlicher Reaktionen der Objekte untereinander X X Sicherer Inhalt durch Encrypting Für sichere Kontenbehandlung X Video- und Audioaufzeichnung Zur Verarbeitung des Erlebten über Social Networks X X Win X X X X Mac X X X Linux X X X Symbian X Android X X iphone X X Markerless Tracking X X Face Tracking Sicherer Inhalt durch Encrypting X Entwickler Tool X X X X Runtimelizenz X X X Nutzerlizenz pro Anwendung X Tabelle 1.: Vergleich von Augmented Reality Software (A. Mehler-Bicher[5])

2.4 AR-SOFTWARE FÜR SMARTPHONE'S Da im Rahmen dieser Arbeit eine Beispielsoftware für Smartphone's entwickelt werden soll, wird die Softwarelandschaft für diese Plattform etwas genauer betrachtet. Um Augmented Reality Anwendungen für mobile Geräte zu realisieren, gibt es mehrere Möglichleiten. Die aufwendigste ist dabei alles komplett selbst zu entwickeln. Dazu müsste man mittels der API des jeweiligen Betriebssystems alle nötigen Sensordaten auslesen. Hat man diese Daten vorliegen, müssen sie je nach Aufgabe der Anwendung nun mittels Tracking die eigene Position und Orientierung, sowie die der zu trackenden Objekte, bestimmen. Der Aufwand wäre offensichtlich enorm. Eine einfachere Variante wäre, eines der im Abschnitt Software vorgestellten Frameworks einzusetzen. Dort liegt Software zum Kalibrieren der Kamera, Tracking und Rendern der virtuellen Objekte bereits vor. Diese muss dann nach eigenen Vorstellungen in der Anwendung eingebunden werden. Der Aufwand hier ist schon wesentlich geringer. Für Anwendungen, die nicht so speziell sein müssen, gibt es bereits Softwarelösungen, welche es ermöglichen, mit einfachen Mitteln in das Kamerabild des Gerätes AR-Inhalte einzufügen. Diese Augmented Reality Browser bieten Overlays an mit gewissen Inhalten zur Umgebung. Je nachdem mit was man das Kamerabild erweitert haben möchte, wählt man ein Overlay, welches die Points of Interest (POI) genannten Inhalte einblendet. 2.4.1 BROWSER Als Vertreter der Gattung AR-Browser sollen hier Wikitude [30], Layar [31] und Junaio [32] vorgestellt werden. Es wird kurz auf Entstehungsgeschichte, Entwicklungsmethoden und Fähigkeiten der Browser eingegangen. 2.4.1 WIKITUDE WORLD BROWSER Wikitude ist seit den ersten Stunden von AR-Browsern auf dem Markt. Es wurde 2008 erstmals für Android Systeme vorgestellt. Inzwischen steht der Browser für

die Plattformen iphone, Android, BlackBerry, Symbian und Bada zur Verfügung. Die Inhalte für Wikitude werden Worlds genannt. Wikitude zeichnet sich durch die Breite der Entwicklungsmöglichkeiten besonders aus, da Worlds auf verschiedene Weisen erzeugt werden können. Eine einfache Möglichkeit wäre, die POIs in einem der unterstützten XML-Derivate KML oder ARML zu speichern und bei Wikitude hochzuladen. Die generelle Architektur der meisten Browser sieht vor, dass sie selbst keine Daten mitliefern, sondern nachdem der Nutzer gewählt hat, was er eingeblendet haben möchte, von einem Webservice diese nachzuladen. So können vom Anbieter die Daten aktuell gehalten werden und die Anwendung muss keine Datenbanken mitliefern und pflegen. Als Datenaustauschformat kommt dabei meist ein XML- Derivat zum Einsatz. Wikitude unterstützt dabei die folgenden zwei Formate. Die Augmented-Reality-Markup-Language (ARML) ist ein XML-Schema, das von der Wikitude GmbH (früher Mobilizy GmbH) vorgeschlagen wurde, als Standardformat für AR-Inhalte. Innerhalb eines W3C Projektes wird ARML weiterentwickelt. Gegenüber KML bietet ARML weitere Informationen zu den POIs, um mehr Interaktivität zu ermöglichen. So können zum Beispiel Telefonnummern und Webadressen hinterlegt werden. Die Keyhole-Markup-Language (KML) ist ein XML-Schema das geographische Informationen beschreibt. [2] Entwickelt wurde KML von der Keyhole Inc., welche später von Google aufgekauft wurde. Inzwischen ist KML ein Standard des Open Geospatial Consortium (OGC) und wird dort in Zusammenarbeit mit Google gepflegt. KML soll nun stellvertretend für diese Datenformate etwas genauer vorgestellt werden. KML ist eine von XML erweiterte Sprache zur Beschreibung und Visualisierung von geografischen Informationen und Inhalten. Solche Inhalte werden als Objekte definiert, wobei verschiedene Typen wie Vektor- und Rasterdaten genutzt werden können. Als Vektordaten können Placemarks dienen, die Punkte, Polygone oder 3D-Modelle mit geografischen Angaben referenzieren. Zu diesen Orten können dann zusätzliche Informationen gespeichert werden, wie der Name des Ortes und eine Beschreibung. Für Rasterdaten, wie Luft- oder Satellitenbilder, wird anstelle der Geometriebeschreibung ein Koordinatenauschnitt zur Referenzierung 25

angegeben. Als geodätisches Referenzsystem der Koordinaten dient das World Geodetic System 1984 (WGS84). Für eine Koordinatenangabe werden also Längen- und Breitengrad angegeben. Eine Höhenangabe über dem Referenzgeoid ist ebenfalls als dritte Komponente der Koordinaten möglich. Hier ein Beispiel einer sehr einfachen KML. <?xml version="1.0" encoding="utf-8"?> <kml xmlns="http://earth.google.com/kml/2.2"> <Document> <Placemark> <name>rostock KTV</name> <Point> <coordinates>12.113665,54.089275,0.000000</coordinates> </Point> </Placemark> </Document> </kml> KML wurde ursprünglich entwickelt, um geografische Daten in einem Programm zu visualisieren, dass nach Firmenaufkauf als Google Earth veröffentlich wurde. Mit dieser Software oder dem im Internet verfügbaren Google Maps lassen sich schnell aus markierten Punkten KMLs generieren. So erstellte Karten interessanter Punkte können direkt verwendet werden. Da diese Daten zu Wikitude hochgeladen werden, handelt es sich bei diesem Vorgehen um sehr statische Worlds. Möchte man mehr Kontrolle über die Inhalte, um diese dynamisch zu halten und bei Bedarf zu ändern, kann man sie selber hosten. Mittels Webservice können die Daten Wikitude dann zugänglich gemacht werden. Sollte man volle Kontrolle wünschen, bietet Wikitude auch eine API, um dessen Funktionalitäten den eigenen Anwendungen zugänglich zu machen. Um die Leistungsfähigkeit von Wikitude zu demonstrieren, soll hier IBM Seer [33] erwähnt sein. Diese App bietet AR-Inhalte rund um das Tennisturnier Wimbledon. (siehe Abb. 11) 26

Abb. 11 IBM Seer (nutzt Wikitude API) 2.4.2 LAYAR REALITY BROWSER Der Browser Layar wird von der gleichnamigen aus den Niederlanden stammenden Firma vertrieben und trat erstmals 2008 in Erscheinung. Nach Angaben des Unternehmens ist er auf 10 Millionen Geräten installiert und wird inzwischen schon auf vielen Geräten vorinstalliert mit ausgeliefert. Layar läuft auf dem iphone, Android, Symbian und Blackberry. Der Browser ist für Endnutzer frei erhältlich. Das Erstellen von POI-Karten ist ebenso kostenfrei. Diese Overlays werden bei Layar Layer genannt. Das Produkt Layar Vision ermöglicht neben den POI-Karten eine Objekterkennung durch Computer Vision. Dabei werden Objekte in einer Datenbank vorgehalten. Ein Layer kann solche Objekte neben POIs einbinden und entsprechende Augmentierungen wie 3D-Modelle, Audio- und Videoinhalte oder Interaktionsmöglichkeiten einblenden. Für einen Treffer, also das erfolgreiche Erkennen eines Objektes, ist ab einer gewissen Anzahl durch den Entwickler oder Publisher des Layers ein Entgelt an Layar fällig. Das Preismodell wird in Tabelle 2 gezeigt: 27

Erkannte Objekte pro Monat Nutzungsentgelt pro Monat 5.000 0 10,000 0 15.000 50 100.000 900 110.000 1000 200.000 1000 1.000.000 1000 Tabelle 2 : Layar Vision Preistabelle (www.layar.com) Entwickler eines Layers müssen den Inhalt selbst hosten. Die Daten werden von Layar über einen Webservice abgerufen. Ein Vorgehen, um einen Layer zur Verfügung zur stellen, sieht wie folgt aus. In einer SQL-Datenbank sammelt man POIs. Wird der gewünschte Layer angefordert, sendet Layar einen Request an die bei Layar für diesen Layer hinterlegte Adresse. Im Request sind verschiedene Parameter codiert, wie die Position des Nutzers und ein Radius in dem er POIs sucht. Ein PHP-Script kann diese Parameter extrahieren und aus der Datenbank in der Nähe liegende POIs berechnen. Diese werden Layar dann als Antwort zurück übermittelt. Neben dieser Variante ist es auch möglich, mittels Layar Player Layer direkt in der eigenen Anwendung anzeigen zu lassen, ohne den Browser von Layar nutzen zu müssen. Es gibt dazu ein Toolkit, so dass nach Einfügen einiger Zeilen Code, die Funktionalität in der eigenen App vorliegt. Zur Zeit der Entstehung dieser Arbeit war dies nur für iphone Apps möglich. Eine Version für Android soll folgen. Die Nutzung des Players ist für Endnutzer kostenfrei. Für Entwickler entstehen nur Kosten, wenn Layar Vision Inhalte genutzt werden, wobei das in Tabelle 2 angeführte Preismodell greift. 2.4.3 JUNAIO Der Browser junaio ist etwas jünger als beiden vorher genannten und wurde Ende 2009 veröffentlicht. Die Firma Metaio entwickelt ihn, welche schon im Abschnitt Software erwähnt wurde. Er ist für iphones, ipads und Androidsysteme verfügbar. Beim Start verstand sich junaio eher als AR Social Networking Browser, der es ermöglichte mit Freunden 3D-Objekte und Szenen an gewissen Orten zu teilen. Inzwischen ist daraus ein vollwertiger AR-Browser geworden. [2] Die verfügbaren 28

Overlays, hier Channel genannt, sind oft auf die momentane Umgebung des Nutzers beschränkt. Aufgrund der technologischen Erfahrungen von Metaio ist der Browser zu Natural Feature Tracking in der Lage. Um Inhalte bereit zustellen, müssen diese selbst gehostet werden. Junaio ruft dann diesen Webservice auf, der für einen Channel hinterlegt wurde. Die Anforderungen an diesen Webservice sind etwas spezieller, als bei den beiden vorher genannten Browsern, da z.b. ein eindeutiger Schlüssel hinterlegt wird, damit junaio als Sicherung den richtigen Webservice identifizieren kann. Mittels PHP-Skript wird eine Callback-Funktion realisiert. Da dem Skript verschiedene Parameter übergeben werden, kann dieses passende Inhalte suchen. Diese werden dazu in ein spezielles XML-Schema formatiert, welches für junaio entwickelt wurde. Für reine 2D-POI-Karten sind Tags und Struktur KML und ARML sehr ähnlich. Neben der Position lassen sich noch Extradaten wie Telefonnummer, E-Mailadresse und URL hinterlegen. Junaio unterstützt auch 3D-Modelle samt Animation, wofür dann noch eine Menge Tags zur Skalierung, Orientierung und Abspielverhalten hinzukommen. Zusätzlich werden in diesem XML-Schema Tags geboten, welche Distanzen für Objekte festlegen, ab denen diese angezeigt werden sollen. Sogar nach Genauigkeit, der durch GPS ermitteln Position kann gefiltert werden, ob ein Objekt eingeblendet werden soll, um Irritationen durch zu große Abweichungen zu vermeiden. 3 KONZEPTION Das Ziel des Softwareteils dieser Arbeit soll eine Augmented Reality Anwendung sein, die auf einem Smartphone läuft und dessen Kamera und Display wie bei der HUD-Technik (siehe Absatz 2.1.3) einsetzt, um ein WLAN und dessen Knotenqualität zu visualisieren. Ein Anwendungsfall wäre die Wartung bzw. der Ausbau eines Netzes. Dabei könnte vor Ort bei der Installation einer Richtantenne das Netz visualisiert werden, um die Ausrichtung zu verbessern oder zu überprüfen. Ein großes und somit auch potentiell interessantes WLAN für diese 29

Art Software wird in Rostock vom Verein Opennet Initiative e.v.[34] betrieben. Das Anliegen des Vereins und das Netz sollen im folgenden kurz vorgestellt werden. 3.1 DIE OPENNET INITIATIVE Da 2004 noch nicht in allen Stadtteilen Rostocks DSL verfügbar war, wurde überlegt, wie man dort Haushalte mit anbinden könnte. Zu dieser Zeit waren verschiedene Techniken zur drahtlosen Datenübertragung verfügbar, so dass eine Nutzung dieser zum Anschluss der Haushalte an einen DSL-verbundenen Endpunkt erörtert wurden. Interessenten wurden schnell gefunden und mit Hilfe von Mitarbeitern des Lehrstuhls für Informations- und Kommunikationsdienste der Rostocker Universität wurde ein Machbarkeitstest erfolgreich umgesetzt. Die Kosten für den Netzzugang sollten auf die nutzenden Mitglieder verteilt werden. So entstand der Verein "Opennet Initiative" Anfang 2005. Jetzt gegen Ende 2011 misst das Netz über 160 Teilnehmer. Abb. 12 Ausschnitt der aktuellen OpenNET Karte des Entstehungsgebietes Rostocker KTV 30

Technisch handelt es sich beim Opennet um ein WLAN, das im Ad-Hoc-Modus betrieben wird und Optimized Link State Routing (OLSR) als Routingprotokoll einsetzt. Ad-Hoc-Netze ermöglichen es, Knoten dynamisch einzugliedern oder den Ausfall eines Knotens zu kompensieren, indem neue Routen um den ausgefallenen Knoten gesucht werden. Die Daten werden dabei von Knoten zu Knoten gereicht, bis sie beim Empfänger eintreffen. Die Topologie des Netzes muss dabei jedem Knoten bekannt sein. Um dies zu gewährleisten, senden die Knoten zwei Arten von Nachrichten aus. Die HELLO-Nachrichten dienen dazu benachbarte Knoten, die ein oder zwei Hops entfernt sind, zu ermitteln. Die zweite Art heißt Topology-Control- Nachrichten, welche zur Verbreitung der so gewonnen Informationen dienen. Die beste Route ist im normalen OLSR dabei jene, die die wenigsten Hops benötigt. Bei Funknetzen hängt die Qualität allerdings stark von der Signalstärke zwischen zwei Knoten ab. Die Qualität wird daran gemessen, wie viel Paketverlust auftritt und Link Quality (LQ) genannt. Dabei wird direkt aus der Differenz der gesendeten und empfangenen Pakete ein prozentualer Wert ermittelt. Die LQ soll später in der Software ebenfalls visualisiert werden. Die Opennet Initiative veröffentlich in regelmäßigen Abständen von 5 Minuten den aktuellen Netzstatus in verschiedenen Datenformaten. Hieraus soll die Datengrundlage für die Software erstellt werden. 3.2 ARCHITEKTUR Als erste Idee stellt sich natürlich eine Applikation, die eben vorher genannte Ziele umsetzt. Als ungünstig erweist sich dabei, allerdings die Forderung die Netzhistorie auch darstellen zu können. Dazu müsste die Anwendung alle 5 Minuten eine Netzverbindung aufbauen, um den aktuellen Status zu speichern. Das würde einen konstanten Traffic für das Telefon bedeuten und den Speicher enorm belasten. Hinzu kommt, dass nur Daten erfasst würden, die seit dem Zeitpunkt der Installation der Software auf dem Telefon angefallen sind. Da die vorgestellten Browser mit datenvorhaltenden Webservices arbeiten, entschied ich mich ebenfalls dafür. Die zu entwickelnde Software unterteilt sich damit in die zwei Hauptbestandteile Webservice und Telefonapplikation (App). 31

Zur Verdeutlichung der Architektur soll folgende Darstellung dienen: Opennet Server Aktuelle Netzdaten Periodischer KML-Download XSL Transformation Server XML Datenbasis Webservice PHP-Skripte zur Bearbeitung der Requests Response mit XML-Datensatz HTTP-Request mit Timestamp App Zeitauswahl AR-Ansicht 32

3.2.1 DIE APP Die Entwicklung einer Augmented Reality Anwendung umfasst eine Vielzahl an Aufgaben. Gerade die Auswertung der Sensordaten und das Echtzeitrendering in den Videostream der Kamera schien an Aufwand den Rahmen zu sprengen. Daher sollte, um nicht bei null zu beginnen, eine Bibliothek oder ein Framework genutzt werden. Die AR-Browser sind bereits speziell für Smartphone s angepasst und bieten alle ein Software Development Kit (SDK) um deren Funktionalität in eigene Anwendungen zu integrieren. Begrenzungen gibt es hier allerdings zum Beispiel bei den unterstützten Plattformen, welche die verfügbare Programmiersprache festlegt. Zur Auswahl standen hier ios- und Android-basierte Telefone. Für das iphone wird für native Anwendungen Objective-C genutzt, welches dem Autor weniger geläufig ist, als das auf Android genutzte Java, wodurch die Wahl hier zu Gunsten des Letzteren ausfiel. Zum Zeitpunkt der Erstellung dieser Arbeit, wurde für Layar nur ein iphone SDK bereitgestellt, wodurch dieses ausschied. Zwischen Wikitude SDK und dem metaio mobile SDK (junaio) fiel die Wahl auf Wikitude, da dort ein klares Interface zum Erstellen von POIs angeboten wird und die nötigen Anpassungen in der Anzeige zum Darstellen der Qualitätsinformationen einfach schien. Der typische Nutzungsablauf soll dabei folgendermaßen aussehen. Man wählt nach dem Start der Anwendung das Datum und die Zeit aus für die der Netzstatus angezeigt werden soll und startet die AR-Ansicht, in welcher im Kamerabild die POIs eingefügt sind. Aus Datum und Uhrzeit wird in der App der Timestamp berechnet und mit diesem einen Aufruf an den Server geschickt. Dieser sendet daraufhin als Antwort eine einfache XML zurück in der der jeweilige Netzstatus abgebildet ist. Nachdem die Antwort geparst wurde, wird daraus eine Liste der Points of Interest erstellt, welche an die Wikitude Bibliothek übergeben wird, von welcher nun die AR-Ansicht mit dem entsprechenden Inhalt startbar ist. In der AR- Ansicht werden die Access Points (AP) mit Kreisen dargestellt, die je nach LQ unterschiedlich eingefärbt sind. 33

3.2.2 DER WEBSERVICE Der Webservice erfüllt im Wesentlichen 3 Aufgaben. Er bezieht periodisch die neusten Daten vom Server der Opennet Initiative. Diese Daten werden dann in das später an die App zu versendende XML-Format transformiert. Und ein Webservice wird gestellt, an dem die eingehenden Requests verarbeitet werden. Die aktuellen Netzdaten werden von der Opennet Initiative alle 5 Minuten in den Formaten KML, PNG und JPEG veröffentlicht. Zur automatischen Weiterverarbeitung eignet sich davon nur KML. Dieses Format wurde bereits etwas detaillierter vorgestellt. Das KML-Format ist relativ komplex und in den bereitgestellten Dateien finden sich zahlreiche überflüssige Informationen. Um den Parser später kompakt und schnell umzusetzen, entschied ich mich dafür, die KML in ein eigenes XML-Format zu transformieren. Um ein XML-Dokument in ein anderes XML-Dokument umzuwandeln, bietet sich XSL Transformation (XSLT) [35] an. XSLT steht hierbei für EXtensible Stylesheet Language Transformations und ist eine Programmiersprache zur Transformation von XML-Dokumenten. Während die Eingabe immer XML-Dokumente sind, kann das Zielformat beliebig sein. Der Ablauf sieht dabei vor, dass anhand von Regeln für bestimmte Muster innerhalb der Baumstruktur des Quelldokuments, im Zieldokument eine bestimmte Ausgabe erfolgt. Für diese Anwendung bedeutet dies, dass XSLT einmal als Filter zum Einsatz kommt und für überflüssige Teile keine Ausgabe erzeugt wird. Von der bereitgestellten KML wird etwa nur ein Drittel der Daten benötigt. Zusätzlich wird die vorige Baumstruktur verworfen und eine neue schlankere, konkret eine weniger tief verschachtelte, erstellt in der die für die POIs notwendigen Daten eingegliedert werden. Die so erzeugten XML-Dateien werden mit einem Timestamp benannt, um später mit wenig Aufwand die für die Anfrage zeitlich am nächsten gelegenen Daten zu finden. Für den letzten Schritt wird ein Webserver aufgesetzt. Ein Webserver dient dazu Dokumente und andere Daten in Netzwerken bereit zu stellen. Dabei lauscht der Server auf einem Port auf Anfragen. Die Auswahl an Lösungen ist hier groß, aber es gibt mit dem Apache HTTP Server auch einen Quasistandard, da dieser Server der 34

am meisten verbreitete ist und so wird er auch hier verwendet. Bei Webservern wird als Übertragungsprotokoll üblicherweise das Hypertext Transfer Protocol (HTTP) verwendet und auf Port 80 auf Anfragen gewartet. Bei HTTP werden zwischen Server und Client Nachrichten versendet. Dabei sendet der Client eine Anfrage (Request) und der Server eine Antwort (Response). Dem Client stehen verschiedene Arten von Requests zur Verfügung. Der gebräuchlichste ist der GET- Request mit dem Ressourcen vom Server unter Angabe eines Uniform Resource Identifier (URI) angefordert werden können. Dem Server können, sofern er dynamische Inhalte unterstützt, in der URI kodiert auch Argumente übergeben werden. Diese werden mit einem Fragezeichen eingeleitet, dem der Parametername und wert getrennt durch ein Gleichheitszeichen folgt. Werden mehrere Argumente übergeben, können diese mit einem & aneinander gereiht werden. Diesen Mechanismus soll die App nutzen, um dem Server die Anfrage zu schicken. Der gewünschte Zeitpunkt des Netzstatus wird dabei als Parameter mit gesendet. Eine Beispiel-URI zum aufrufen könnte so aussehen: http://serveradresse.com/getfile.php?timestamp=1322456789 Der Webserver muss an dieser Stelle dynamisch den Inhalt generieren, da keine Ressource direkt angefordert wird. Um den Parameter zu verarbeiten und die entsprechende Datei zurückzugeben, wird hier eine Skript- oder Programmiersprache nötig. Auch an dieser Stelle gibt es eine große Zahl an Lösungen. Da bereits bei der XSL Transformation PHP eingesetzt wurde (um die Transformation durchzuführen, benötigt man einen XSLT-Prozessor, welchen PHP mitliefert [siehe Absatz 4.1.2], findet es auch hier wieder Anwendung. PHP steht für das rekursive Akronym PHP Hypertext Preprocessor. Es handelt sich um eine im Syntax an C angelehnte Skriptsprache, die sehr weite Verbreitung bei der Erstellung von dynamischen Webseiten hat. Ein PHP-Skript kann den wie oben im Beispielaufruf mit einem Parameter angesprochen werden und diesen verarbeiten. Es sucht dann im Verzeichnis in dem die XML-Dateien lagern, die mit dem am nächsten liegenden Timestamp und schickt sie als Serverresponse zurück an den Client. 35

4 UMSETZUNG Die Realisierung der Softwarekomponenten folgte direkt dem vorigem Diagramm von der Beschaffung der Daten hin zur Verarbeitung innerhalb der App. Die Entwicklung der einzelnen Komponenten sowie auftretende Probleme oder Besonderheiten sollen hier nachvollzogen werden. 4.1 SERVERKOMPONENTEN Als erstes entstanden die Skripte und XSLT-Programme, um später bei der Entwicklung der App direkt mit den Daten arbeiten zu können. Unterteilen lassen sich die Aufgaben auf dem Server in Beschaffung der Daten, Transformation mittels XSL und die Bereitstellung der Daten über einen Webservice. 4.1.1 DIE STEUERSKRIPTE Auf der Website der Opennet Initiative wird alle 5 Minuten eine neue KML mit dem aktuellen Netzstatus veröffentlicht. Im gleichen Takt sollen diese Daten auf den Server geladen werden. Der Server wird mit der Linux-Distribution CentOS betrieben. Um regelmäßig wiederkehrende Aufgaben anzustoßen, bietet sich der cron-daemon (crond) an. Zur Steuerung der Aufgaben werden Tabellen (crontabs) benutzt. Die Tabelle besteht aus mehrere Spalten, wobei die ersten 5 Spalten die Zeitangabe wie Minute, Stunde bis hin zum Monat definieren. Alles folgende wird als Befehl interpretiert, der zur definierten Zeit ausgeführt werden soll. Mittels einiger Sonderzeichen kann die Taktung der Befehle noch präzisiert werden. Um alle 5 Minuten ein Skript auszuführen, das alle geforderten Aufgaben erledigt reicht im crontab folgende Zeile: */5 * * * * root /var/www/sh/getkml.sh Als nächstes wird das hier aufgerufene Skript kurz erläutert. 36

1 #!/bin/bash 2 # get kml 3 wget -t 10 -O /var/www/sh/current.kml http://heartofgold.opennetinitiative.de/topology/olsr/alfredi_output.kml 4 # remove kml tags 5 grep -v 'kml' /var/www/sh/current.kml >/var/www/sh/unkmled.xml 6 # apply xslt via php 7 php /var/www/sh/trans.php Listing 1 : getkml.sh Die erste interessante Zeile ist die Dritte. Das Tool wget kann über die Protokolle http, https und ftp Inhalte aus dem Internet herunterladen. Mittels vieler Parameter kann es dem jeweiligen Zweck angepasst werden und ist zum Beispiel in der Lage, komplette Webseiten samt der benötigten Ressourcen offline verfügbar zu machen. Das Programm wird benutzt um die aktuelle KML vom Server der Opennet Initiative auf den eigenen Server zu laden. Der Einsatz von grep an der KML ist auf ein Problem bei der Transformation zurückzuführen. Bei der Implementierung der Transformation wurde eine wesentlich verkleinerte KML zum Testen benutzt, da das Original weit über 7000 Zeilen enthält. Erst als gegen Ende das fertige Transformationsprogramm an der Original KML getestet wurde, zeigte sich, dass die äußersten umschließenden Tags <kml> und </kml> zu einem Abbruch durch den XSLT-Prozessor führten. Andere umschließende Tags und verschiedenste Tiefen der Baumstruktur machten keine Probleme, einzig kml -enthaltende Tags führten zum Abbruch. Die Umgestaltung der XSL, um diesem Fehler speziell zu begegnen, führte zu immer weiter gehenden Fehlern oder zu nicht gewünschten Ergebnissen. Als XSLT-Prozessor wurde, wie im folgenden Abschnitt beschrieben, der in PHP enthaltende eingesetzt. Um den Zeitplan und den Fortschritt der Arbeit nicht weiter zu behindern, wurde auf den Test mit anderen XSLT-Prozessoren verzichtet und sich mit grep beholfen. In der KML stehen die kml -Tags allein in einer Zeile. Im Zielformat werden sie nicht weiter benutzt, so dass ein einfaches Herausfiltern vor der eigentlichen Transformation ausreicht. Für diese Aufgabe eignet sich grep bestens, da es Zeilen nach vorkommenden Mustern durchsucht und nur jene ausgibt, die das entsprechende Muster aufweisen. In diesem Fall wird nach dem Muster kml gesucht, so dass nur die beiden Zeilen mit kml -Tag übrig bleiben. Durch 37

Invertieren der Ausgabe erhält man die ursprüngliche KML-Datei ohne die beiden Zeilen. In der letzten Zeile wird das PHP-Skript aufgerufen, welches die Transformation ausführt und nun aufgezeigt werden soll. 4.1.2 DIE TRANSFORMATION Zur Transformation der KML zu einem für diesen speziellen Zweck reduzierten XML dienen zwei Teile. Ein XSL-Programm beschreibt die Regeln nach denen das KML in das neue XML transformiert werden soll. Der zweite Teil besteht aus einem PHP-Skript, welches die XSL und die KML liest und an den XSLT-Prozessor übergibt, der die Transformation ausführt. Anschließend speichert das Skript das Ergebnis in einer XML und erzeugt die Datenbasis für den Webservice. 1 <?php 2 // init xslt processor and load stylesheet 3 $xp = new XsltProcessor; 4 $xsl = new DOMDocument; 5 $xsl->load('/var/www/sh/trans.xsl'); 6 $xp->importstylesheet($xsl); 7 8 // load source xml 9 $xml = new DOMDocument; 10 $xml->load('/var/www/sh/unkmled.xml'); 11 12 // apply xslt 13 $output = $xp->transformtoxml($xml) 14 or die('transformation error!'); 15 16 // create output file: 'timestamp'.xml 17 $ts=time(); 18 $outfilename='/var/www/xml/'.$ts.'.xml'; 19 $fh = fopen($outfilename, 'w') or die("can't open file"); 20 fwrite($fh, $output); 21 fclose($fh); 22?> Listing 2 : trans.php Das Skript soll nicht zu sehr im Detail betrachtet werden, da vieles zur Initialisierung dient und nicht weiterer Erläuterungen bedarf. Der XSLT-Prozessor 38

benötigt lediglich zwei Dinge zur Initialisierung, nämlich die Ausgangs-KML und die XSL-Datei, welche die anzuwendenden Regeln enthält. Nachdem beide Ressourcen geladen wurden, wird in Zeile 13 die Transformation durchgeführt und als Text gespeichert. Anschließend wird der aktuelle Zeitstempel gespeichert, welcher als Dateiname für die darauffolgend geschriebene Ausgabedatei dient. Bevor die XSL erläutert wird, soll zunächst die Eingabe und Ausgabe betrachtet werden. Die Eingabe bildet die KML, welche etwas detaillierter vorgestellt wird. Es lassen sich neben den strukturbildenden Tags drei Teile unterscheiden. Im ersten Abschnitt werden mehrere Style-Elemente definiert, welche später in den folgenden beiden Teilen für den URL-Style der POIs genutzt werden. 1 <Style id="colffff8800"> 2 <IconStyle><Icon><href>http://titan.www.opennetinitiative.de/topology/olsr/map_icons/208.png</href> </Icon></IconStyle> 3 <LineStyle><color>ffff8800</color><width>0.25</width> </LineStyle> 4 </Style> Listing 3 : Beispiel KML Abschnitt 1 In den Style-Elementen werden Farben, Linienstärken und Grafiken definiert, welche später die POIs entsprechend ihrer Link Quality optisch widergeben. Die Styles sind stark differenziert und für die spätere Verarbeitung nicht von Nutzen, so dass sie bei der Transformation herausgefiltert werden können. Die Abbildung der Link Quality mittels einer Farbskala für die APs wird später in der App realisiert. In den nächsten beiden Abschnitten werden Placemarks beschrieben. Damit werden in der KML POIs definiert, wobei der zweite Abschnitt die APs beschreibt, während im dritten Abschnitt die Verbindungen zwischen jeweils zwei Access Points erfasst werden. Die Informationen aus dem letzten Abschnitt zu visualisieren, wäre wünschenswert, aber leider mit dem SDK von Wikitude nicht zu realisieren. Dort können lediglich POIs dargestellt werden, aber keine Linien oder Informationen zwischen den POIs. Ein freies Zeichnen ist ebenso nicht möglich, so dass die Kenndaten einer Verbindung zweier APs sich nicht sinnvoll visualisieren ließen. Da die Daten über die Verbindungen nicht verwendet werden können, werden sie ebenfalls gefiltert. Es wird nun jeweils ein Beispiel aus den 39

beiden Abschnitten gegeben, um aufzuzeigen wie diese zum Transformieren unterschieden werden. 1 <Placemark> 2 <name>183</name> 3 <description> IP: 192.168.1.183 LQ: 0.964288 </description> 4 <styleurl>#colffff2600</styleurl> 5 <Point><coordinates>12.123091,54.090913,0</coordinates> </Point> 6 </Placemark> Listing 4 : Beispiel KML Abschnitt 2 Hier im zweiten Abschnitt werden abgesehen von dem styleurl-element alle Informationen in die neue XML übernommen. 1 <Placemark> 2 <name> 192.168.1.161 192.168.1.183</name> 3 <description>0.315769</description> 4 <styleurl>#colff00ffbb</styleurl> 5 <LineString> <coordinates> 6 12.123574,54.093115,0 12.123091,54.090913,0 7 </coordinates> </LineString> 8 </Placemark> Listing 5 : Beispiel KML Abschnitt 3 Offensichtlich sind hier einige Informationen an anderen Stellen gespeichert, interessant für die Transformation ist allerdings eher der Unterschied in der Struktur. Ob ein Placemark-Element ein Point- oder LineString-Kindknoten enthält, ist bei der Mustersuche der XSL Transformation der Ansatz zum Entscheiden, ob das Element übernommen oder herausgefiltert wird. Der konkrete Code dazu sieht wie folgt aus. 40

1 <xsl:stylesheet version = '1.0' xmlns:xsl='http://www.w3.org/1999/xsl/transform'> 2 <!-- apply rules for root --> 3 <xsl:template match="/"> 4 <myxml> 5 <xsl:apply-templates select='//placemark[point]'/> 6 </myxml> 7 </xsl:template> 8 <xsl:template match="placemark"> 9 <name><xsl:value-of select="name"/></name> 10 <desc><xsl:value-of select="description"/></desc> 11 <coord><xsl:value-of select="point/coordinates"/></coord> 12 </xsl:template> 13 </xsl:stylesheet> Listing 6 : trans.xsl Zuerst wird definiert, um was für ein Dokument es sich handelt. Nachdem es als XSL deklariert wurde, werden Regeln für die Transformationen erwartet. Da nur ein Abschnitt übernommen werden soll, indem alle Elemente die gleiche Art Knoten haben, wäre nur eine Regel nötig. Zur Überraschung bei der Entwicklung wurden dann allerdings auch die anderen Elemente in das Zieldokument übernommen. Der Grund hierfür liegt darin, dass ohne Angabe einer Regel für das root-element diese einfach implizit eingefügt wird und keine Einschränkungen enthält. Deswegen gibt es hier in Zeile drei die Regel für das root-element, in dem explizit angewiesen wird, ausschließlich die Regel anzuwenden für Placemark- Knoten, die ein Pointkindknoten haben. Zusätzlich werden noch umschließende Tags für das Zieldokument ausgegeben. Durch die konkrete Beschränkung werden alle anderen Inhalte herausgefiltert. In Zeile 8 wird eine Regel für Placemarks definiert. Hier ist eine genauere Musterdefinition nicht mehr erforderlich, da die vorige Einschränkung schon gilt. Im Zieldokument wird ein POI durch 3 auf einander folgende Tags <name>, <desc> und <coord> definiert. Dabei wird kein übergeordneter Knoten verwendet, um den Parser der App so einfach wie möglich zu halten. Die Elemente name und desc werden direkt mit den Informationen ihres Äquivalents aus der KML gefüllt. Für die Koordinaten wird die Struktur des übergeordneten Pointtags aufgelöst und diese direkt im Element coord gespeichert. 41

4.1.3 DER WEBSERVICE Die zuvor erstellte Datenbasis soll hier zugänglich gemacht werden. Ein Apache HTTP Server bildet die Basis, um Anfragen über Port 80 zu beantworten. Da die Anfragen einen Parameter übergeben, um eine XML für bestimmte Zeiten abzufragen, muss hier dynamisch eine Antwort generiert werden. Dazu wird die Skriptsprache PHP verwendet, welche bereits bei der XSL Transformation zum Einsatz kam. Das folgende Skript liefert bei Anfragen die entsprechenden Daten. 1 <?php 2 $ts=$_get["ts"]; 3 $dir = opendir ( '/var/www/xml/' ); 4 while (false!== ($file = readdir($dir))) 5 { 6 if ($file!= "." && $file!= "..") { 7 // retrieve filepart 8 $minstr=explode('.',$file); 9 $minstr=$minstr[0]; 10 // new minimum? 11 if(intval($min)>abs(intval($ts)-intval($minstr))){ 12 $min=(intval($ts)-intval($minstr)); 13 $minelem=$file; } 14 } } 15 closedir ($dir); 16 $myfile = '/var/www/xml/'.$minelem; 17 $fh = fopen($myfile, 'r'); 18 $output = fread($fh, filesize($myfile)); 19 fclose($fh); 20 echo $output; 21?> Listing 7 : appreq.php Aus Listing 7 wurden die Kommentare sowie einige Variableninitialisierungen entfernt, um den Umfang und den Inhalt auf das Wesentliche zu begrenzen. Zu Beginn wird der übergebene Parameter gespeichert und das Verzeichnis, welches die XML-Dateien enthält, geöffnet. Es folgt eine Iteration über alle Dateien. Dabei wird die Dateiendung abgeschnitten, so dass nur noch der Name übrig bleibt. Da dieser aus einem Timestamp besteht, wird er als Integer interpretiert und direkt mit dem übergebenen Parameter zur Bildung eines Minimums genutzt. Nach Iteration über alle Dateien steht so die XML-Datei fest, welche der Anfrage am nächsten liegt. Ab Zeile 16 wird diese geöffnet und eingelesen. Anschließend wird diese als angefragte Seite ausgegeben. 42

4.2 DIE APP Wie bereits in der Konzeption geklärt, dient als Plattform ein mit dem Betriebssystem Android laufendes Telefon. Applikationen für Android werden in Java geschrieben und es wird empfohlen, diese in Eclipse mit den notwendigen Plugins bzw. dem Android SDK zu entwickeln. Für eine Android-App müssen verschiedene XMLs und generierte Klassen erzeugt werden, welche zum Beispiel das Aussehen der Oberfläche und Ressourcen wie Strings und Styles beschreiben. Die wichtigsten Elemente sind dabei das Applikation Manifest, die Klassen zu den jeweiligen Activities und deren Layout beschreibende XMLs. Das Applikation Manifest ist eine XML, in der die grundlegenden Eigenschaften festgelegt werden. Es wird hier nur ein gekürzter Ausschnitt gezeigt. 1 <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="de.zynamite.ba01" android:versioncode="1"> 2 <uses-permission android:name="android.permission.internet" /> 3 <uses-sdk android:minsdkversion="10" /> 4 <application 5 android:icon="@drawable/ic_launcher" 6 android:label="@string/app_name" > 7 <activity 8 android:label="@string/app_name" 9 android:name=".mainactivity" > 10 </activity> 11 </application> 12 </manifest> Listing 8 : AndroidManifest.xml Neben dem Paketnamen werden vor allem Informationen wie benötigte Systemrechte und Mindestvoraussetzungen definiert. Für diese App wird z.b. die Berechtigung benötigt, dass Internet nutzen zu können, um die Anfragen an den Webservice zu senden. Fehlt die entsprechende Zeile im Manifest, wird der App diese Funktionalität verwehrt, so dass später im Code versuchte Verbindungen nicht erstellt werden können. Im Manifest werden auch die in der Applikation enthaltenen Activities aufgeführt. Für jeden auf dem Telefon angezeigten Screen bzw. jede Ansicht wird eine Activity programmiert. Bei Zuweisungen taucht in der XML das Muster @xxx/yyy auf. Mit derlei Zeichenketten werden Ressourcen 43

angesprochen, die in anderen XMLs definiert sind. Der Teil xxx bezieht sich dabei auf die XML und yyy auf das dort definierte Element. Die mehrfach angesprochene strings.xml sieht z. B. wie folgt aus. 1 <?xml version="1.0" encoding="utf-8"?> 2 <resources> 3 <string name="app_name">ba01</string> 4 <string name="btntext">starte AR View</string> 5 </resources> Listing 9 : strings.xml Diese in den XMLs definierten Ressourcen lassen sich im Code über die automatisch generierte Klasse R ansprechen. Die Funktionsweise wird später z. B. an den Grafiken demonstriert, welche zum Anzeigen der Link Quality dienen. Durch konsequentes Auslagern der Strings in die XMLs lassen sich später leichter lokalisierte Versionen der App erstellen. Im Code werden die Ressourcen gleich angesprochen, während das System zum Beispiel für die auf dem Telefon eingestellte Sprache, richtige strings.xml laden kann. Für eine Übersetzung der App muss dann nur eine lokalisierte strings.xml erstellt werden, ohne auch nur eine Zeile Code zu ändern. Die ebenfalls als wichtig bezeichneten XMLs, die das Layout bestimmen, sollen nun kurz vorgestellt werden. Hier ein wesentlich gekürzter Ausschnitt. 44

1 <?xml version="1.0" encoding="utf-8"?> 2 <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" 3 android:layout_width="fill_parent" 4 android:layout_height="fill_parent" 5 android:orientation="vertical" > 6 <TextView 7 android:id="@+id/datedisplay" 8 android:layout_width="match_parent" 9 android:layout_height="wrap_content" 10 android:text="" 11 android:textsize="16dp" /> 12 <Button 13 android:id="@+id/pickdate" 14 android:layout_width="match_parent" 15 android:layout_height="wrap_content" 16 android:text="ändere Datum" /> 17 <TextView 18 android:id="@+id/timedisplay" 19 android:layout_width="match_parent" 20 android:layout_height="wrap_content" 21 android:text="" 22 android:textsize="16dp" /> 23 </LinearLayout> Listing 10 : main.xml Die App besteht aus 2 Activities und somit auch aus 2 Screens. Im ersten, der hier definiert wird, kann über Eingabeelemente Datum und Zeit festgelegt werden, für die die Daten geladen werden sollen. Eine Checkbox aktiviert bzw. deaktiviert die Darstellung von inaktiven Knoten. Als solche gelten alle mit einer LQ von 0. Ein Button am unteren Ende der Darstellung startet die AR-Ansicht. Der im gekürzten Listing 10 dargestellte Ausschnitt, zeigt wie Oberflächenelemente definiert werden. Verschiedenste Typen solcher Elemente werden vom Android SDK bereitgestellt, welche durch das Einfügen eines entsprechend benannten Tags definiert werden. Über die Tagattribute können die Objekteigenschaften wie die Größe, Ausrichtung und Objektidentifikator festgelegt werden. Die Anordnung der Elemente wird durch beliebig tief verschachtelte Layoutelemente gesteuert. Aus einer so erstellten XML wird folgende Oberfläche generiert. 45

Abb. 13 Startmenü der App Die Logik hinter dieser Oberfläche verbirgt sich in der Activity - einer zu implementierenden Klasse für jeden Screen. Da eine Applikation auf dem Telefon jederzeit unterbrochen werden kann, z.b. wenn der Nutzer die Zurücktaste drückt, die Orientierung geändert wird oder ein Anruf eingeht, können dafür Methoden implementiert werden, um ein geregeltes Ende der App zu ermöglichen. Für verschiedene Stufen dieses Lebenszyklus einer Applikation werden Methoden bereitgestellt wie oncreate, onpause oder ondestroy. Sollte sich während des Laufens der App eine andere in den Vordergrund bringen, würde es ohne Datensicherung in einer implementierten onpause-methode zu Datenverlust kommen, wenn die eigene App wieder in den Vordergrund rückt. Unumgänglich ist die Implementierung der Methode oncreate, welche den Einstiegspunkt einer Activity bildet. Hier wird das zur Activity gehörende Layout geladen, später verwendete Variablen initialisiert und beispielsweise Methoden an die definierten Schaltflächen gebunden. Ein stark gekürzter Ausschnitt folgt. 46