Augmented Reality

Optische Täuschung
Kommentare

Auf der Suche nach einer „Killerapplikation“ für mobile Geräte fällt häufig der Begriff Augmented Reality (AR). Was verbirgt sich hinter den spektakulären Videos von AR-Anwendungen? Dieser Artikel beschreibt die Einsatzmöglichkeiten dieser Technologie sowie Tools, mit denen Entwickler AR-Anwendungen entwerfen können.

Geht man von einer wörtlichen Übersetzung des Begriffes Augmented Reality aus, so handelt es sich dabei zunächst um eine erweiterte Realität. Eine solche Erweiterung kann auf vielfältige Weise entstehen. In der aktuell auf vielen Konferenzen zu mobilen Themen diskutierten und in diesem Artikel behandelten Ausprägung geht es um die computergestützte Erweiterung der visuellen Wahrnehmung. Konkret bedeutet das, dass bei der Benutzung von mobilen Geräten das aktuelle Kamerabild durch Zusatzinformationen überlagert wird. Es findet also eine Überlappung von realer Welt (Kamerabild) und virtueller Welt statt. Diese Zusatzinformationen können Texte, Fotos, Videos oder Animationen in Form von Änderungen einzelner Bestandteile des aktuellen Bildes sein, z. B. farbliche Hervorhebungen einzelner Objekte oder Einzeichnung von Comicfiguren, die „durch das aktuelle Bild laufen“. Der Begriff Augmented Reality ist schon wesentlich älter als die aktuell verfügbaren Smartphones. Erst in den letzten Jahren wuchs aber zusammen mit dem Siegeszug der Smartphones auch die Zahl der Ankündigungen von für den Massenmarkt verfügbaren AR-Anwendungen. So sorgte beispielsweise im Herbst 2009 eine AR-Anwendung des Fraunhofer Instituts nicht nur in Berlin für Aufsehen: Mit der aus Anlass des 20. Jahrestages des Mauerfalls entstandenen App wird die Berliner Mauer im aktuellen Kamerabild eines Mobilgerätes wieder sichtbar, wenn man im Zentrum von Berlin in der Nähe des früheren Mauerverlaufes steht.

Wie funktioniert nun eine solche AR-Anwendung aus der technischen Sicht eines Entwicklers? Das im Display sichtbare Bild besteht dabei aus zwei Schichten: Einerseits die Schicht mit dem aktuellen Kamerabild und darüber eine (virtuelle) Schicht mit den Zusatzinformationen. Die beiden Fragen, welche Informationen dargestellt werden sollen und wo genau im Display sie erscheinen sollen, können dabei auf zwei verschiedene Arten beantwortet werden. Bei Marker-gestützten AR-Applikationen reagiert die Anwendung auf durch mit Verfahren der Mustererkennung erkannten Markern im aktuellen Displaybild. Ein Beispiel zeigt Abbildung 1, in der ein vordefinierter Marker erkannt und durch eine 3-D-Figur überlagert wird. Bei Anwendungen die sich der Gruppe der Location-based Services zuordnen lassen, erfolgt die Bestimmung anhand der aktuellen Geoposition des mobilen Gerätes (Abb. 2).

abb1

Abb. 1: Erkennung eines vordefinierten Markers

abb2

Abb. 2: AR über Geoposition

 

An dieser Stelle erkennt man nun, warum die Smartphones so wichtig für den Erfolg von AR geworden sind: Sie sind durch GPS- und Kompassfunktionalität mit allem ausgestattet, was man für eine exakte Positionsbestimmung benötigt. Mit den ermittelten Informationen (geografische Position mit Longitude und Latitude sowie Richtung, in die das mobile Gerät aktuell gehalten wird) können auf dem Gerät oder einem zentralen Server (Abb. 3) alle für die Anwendung relevanten Punkte ermittelt werden, die aktuell im Display zu sehen sind. Wie auch in anderen GIS-Anwendungen (Geografische Informationssysteme) üblich, werden solche Punkte auch in der AR-Welt Points of Interest (POI) genannt. Bei der serverbasierten Lösung sendet der Backend-Server eine POI-Liste an das mobile Endgerät zurück, das die enthaltenen POIs dann an der passenden Stelle auf der virtuellen Schicht des Displaybildes einblenden kann.

abb3

Abb. 3: Systemarchitektur eines AR-Browsers

Einsatzgebiete

Die Liste möglicher Einsatzgebiete ist groß. Teilweise gibt es zu den im Folgenden kurz vorgestellten Themen bereits verfügbare Applikationen, der Phantasie sind hier aber keine Grenzen gesetzt. Mit einer guten Idee zum richtigen Zeitpunkt sind auch in der AR-Welt interessante Projekte denkbar. Die bereits erwähnten Location-based Services eignen sich aufgrund ihrer Zielrichtung für den mobilen Einsatz in vielen Fällen für eigene AR-Anwendungen oder die Erweiterung bestehender Applikationen um einzelne AR-Funktionen. An dieser Stelle seien dazu nur die beiden Bereiche Tourismus und Immobilien genannt.

Ein Beispiel für eine Tourismusanwendung ist die im September vorgestellte (iOS-)Ludwig-II-App der Bayerischen Staatsbibliothek, die an Orten, die mit König Ludwig II. in Verbindung stehen, durch Einblenden von Zusatzinformationen (Texte, Videos, Animationen) den Reiseführer ergänzen bzw. ganz überflüssig machen soll. Im Immobilienbereich sind beispielsweise Anwendungen für Architekten denkbar, mit denen diese ihre Entwürfe den Kunden nicht nur als Papierausdruck vorstellen können, sondern an Ort und Stelle auch durch Einblenden des Modells im realen Bild. Aber auch für Immobilienmakler kann es interessant sein, Miet- oder Kaufinteressenten bei einem Spaziergang durch die Straßen einer Stadt die Verfügbarkeit von Immobilienobjekten durch einen kleinen Hinweis im Displaybild zu signalisieren, der dann beispielsweise durch einen Link auf ein Exposee eines Immobilienportals ergänzt werden kann. Für „Spaziergänger mit Blick auf ein Handydisplay“ sind darüber hinaus noch weitere interessante Anwendungsfälle denkbar, beispielsweise Einblendung von aktuellen Sonderangeboten, sobald ein Geschäft im Display erscheint, oder Speisekarten von Restaurants in der unmittelbaren Umgebung.

Ein Beispiel für eine Anwendung, bei der bereits länger bestehende Technologie durch AR-Komponenten erweitert wird, ist „Wikitude Drive“. Dabei handelt es sich um eine Navigationssoftware, bei der die ermittelte Route nicht nur auf einer digitalen Karte dargestellt werden kann, sondern auch über das aktuelle Displaybild gelegt wird (Abb. 4).

abb4 

Abb. 4: AR in der Navigation

 

Ein Anwendungsbereich, bei dem viel Potenzial für AR-Erweiterungen gesehen wird, ist der Spielebereich. So genannte „AR Games“ oder „Mobile Reality Games” sind zwar in der Erstellung sehr aufwändig, versprechen aber durch die Verknüpfung von realer Welt mit der virtuellen Spielsituation interessante Effekte, insbesondere dann, wenn der Nutzer selber in das Geschehen integriert wird, z. B. durch Gestenerkennung oder indem er mit einer Hand in die virtuelle Welt eingreifen kann. Bei solchen High-End-Anwendungen kommen Entwickler von AR-Anwendungen allerdings schnell an die Grenzen des derzeit technisch Machbaren. Erweiterte Rechenpower durch neue mobile Prozessoren sowie Geräte mit zwei Kameras versprechen hier Besserung, z. B. durch die Möglichkeit, aus der Kombination beider Bilder räumliche Informationen besser verarbeiten zu können.

Browser vs. App

Wer nun eine gute Idee hat und sich an die Konzeption einer AR-Anwendung begibt, steht bei der Frage der Architektur der Anwendung vor zwei Alternativen: Browserlösung oder eigene App. Bei der Browserlösung handelt es sich nicht um eine Lösung innerhalb eines normalen Webbrowsers, sondern um einen speziellen AR-Browser, den inzwischen mehrere Anbieter zur Verfügung stellen. Innerhalb dieser Browser können unterschiedliche Kanäle angezeigt werden. Innerhalb eines Kanals, den man sich technisch wieder als eine Schicht im Displaybild vorstellen kann, werden Informationen zu einem bestimmten Thema angezeigt. Wer sich für so eine AR-Browser-basierte Lösung entscheidet, für den besteht die Realisierung des Projektes ausschließlich in der Zusammenstellung aller Informationen für den Kanal eines der Browseranbieter. Wie aus Abbildung 3 ersichtlich ist, werden diese Informationen in der Regel auf einem eigenen Server vorgehalten. Der Kanal selber muss dann beim Anbieter des AR-Browsers angemeldet werden, sodass im mobilen Einsatz die folgende 3-Schichten-Verarbeitung erfolgt: Der AR-Browser auf dem mobilen Endgerät übermittelt seine genaue Position zusammen mit einer Kennung für den gewünschten Kanal an den Server des AR-Browser-Anbieters. Dieser verifiziert die Anfrage und leitet sie dann an den passenden Server des Projektanbieters weiter. Diese erzeugt eine Liste von POIs, die zur übergebenen Position des Endgerätes passen und leitet diese über den mittleren Browserserver an das Endgerät weiter.

Wer sich allerdings nicht an die vom AR-Browser vorgegebene Funktionalität halten will, sollte die Erstellung einer eigenen App mit AR-Funktionalität in Erwägung ziehen. Diese bei der Implementierung – trotz der Verfügbarkeit von entsprechenden Tools und SDKs – wesentlich aufwändigere Lösung ermöglicht natürlich mehr Flexibilität durch den Einbau von individuellen Funktionen. Ein weiteres wichtiges Argument für die eigene App und gegen die Browserlösung ist die bei Einsatz von AR-Browsern erforderliche Internetverbindung. Diese ist zwar meistens vorhanden, trotzdem gibt es Situationen, in denen dies zum Hinderungsgrund für die Nutzung einer AR-Anwendung werden kann. Bei der oben bereits erwähnten Zielgruppe der Touristen findet man beispielsweise häufig auch ausländische Nutzer, die mangels bezahlbarer Roaming-Tarife auf mobile Internetnutzung verzichten wollen oder müssen. Ein anderes Beispiel sind Netzlücken oder nur sehr langsame Verbindungen in für Touristen- und/oder Navigationsanwendungen interessanten (ländlichen) Gebieten wie Gebirgen oder Inseln. Innerhalb von eigenständigen AR-Apps können die darzustellenden Zusatzinformationen lokal auf dem mobilen Gerät gespeichert werden, sodass die Anwendung – sofern sie keine dynamischen Informationen wie z. B. aktuelle Verkehrsmeldungen, Auslastungen von Parkhäusern etc. enthält – auch ohne Onlineverbindung lauffähig ist.

Auf der anderen Seite gibt es natürlich auch Gründe, die klar für die Browsertechnologie sprechen. Insbesondere sind dabei die wesentlich höheren Entwicklungskosten für die App-Lösung auf den verschiedenen mobilen Plattformen zu nennen. Bei einer Browserlösung dagegen reicht die Erstellung der eigenen POI-Daten, die anschließend in den bereits für alle relevanten Plattformen verfügbaren Browsern dargestellt werden können. Zu nennen ist an dieser Stelle natürlich auch die Fragmentierung im Android-Bereich, die bei der Erstellung von AR-Apps besonders relevant ist, da die unterschiedlichen Gerätefeatures in AR-Anwendungen intensiv genutzt werden.

Anbieter

Wer sich für die browserbasierte Lösung entscheidet, findet derzeit drei Anbieter von solchen AR-Browsern:

 

  • Junaio [1]
  • Layar [2]
  • Wikitude [3]

 

Alle drei arbeiten nach dem oben beschriebenen Prinzip: Wer AR-Inhalte anbieten will, legt auf den Servern der Anbieter einen Kanal (je nach Anbieter heißen diese Kanäle dort Channel, Layer oder Welt) an, verlinkt diese über einen URL auf einen in der Verantwortung des Inhalteanbieters betriebenen Server, auf dem die Daten dann in einem für den AR-Browser definierten Format bereitgestellt werden. Leider ist dieses Format nicht einheitlich, sodass man die AR-Inhalte für jeden AR-Browser in einem eigenen Format bereitstellen muss, falls man über alle AR-Browser erreichbar sein will.

Es fehlt also für die AR-Browser derzeit noch das Gegenstück zum HTML-Standard in den klassischen Webbrowsern. Einen ersten Versuch für einen solchen Standard hat Wikitude mit der Augmented Reality Markup Language (ARML) geschaffen, deren Version 1.0 aber bisher nur vom Wikitude-eigenen AR-Browser unterstützt wird [4]. ARML soll nun durch das Open Geospatial Consortium (OGC) zu Version 2.0 weiterentwickelt werden. Derzeit arbeiten die drei Anbieter von AR-Browsern auf einem XML- (Junaio und Wikitude) bzw. einem JSON-(Layar-)basierten Datenformat.

Tools

Hat man sich nun entschieden eine AR-Anwendung zu erstellen oder eine bestehende Anwendung um AR-Funktionalität zu erweitern, so stellt sich die Frage, ob man auf der berühmten grünen Wiese anfangen muss oder ob es Tools und/oder Open-Source-Projekte gibt, auf denen man aufsetzen bzw. anhand derer man sich tiefer in die technischen Details einarbeiten kann. Ist die oben erwähnte Frage „AR-Browser oder eigene App“ beantwortet, so ist man also entweder auf der Suche nach einem Tool zur Erstellung eigener Inhalte in AR-Browsern oder nach Bibliotheken, SDKs und Sourcecode-Beispielen für die Erstellung von Apps auf den verschiedenen mobilen Plattformen, also in der Regel iOS und/oder Android.

Das Angebot bei Tools zur Erstellung von AR-Apps reicht von kleineren Frameworks, die man unter Beachtung der jeweils zugrunde liegenden (Open-Source-)Lizenzen als Grundgerüst für eigene Anwendungen einsetzen kann, bis hin zu umfangreichen Software Development Kits (SDK). Im SDK-Bereich gab es auf der insideAR-Konferenz des Junaio-Anbieters Metaio im September 2011 die überraschende Ankündigung, dass das zuvor in einer Preisregion von 10 000 Euro erhältliche Mobile Software Development Kit (SDK) von Metaio ab dem vierten Quartal 2011 kostenlos angeboten wird. Neben einer um einige High-End-Funktionen erweiterten kostenpflichtigen Provariante steht damit nun auch eine kostenlose Edition zur Verfügung, mit der man AR-Applikationen erstellen kann. Das Mobile SDK eignet sich dabei insbesondere für Anwendungen, bei denen das zu überlagernde Objekt weder über die aktuelle Position noch über vordefinierte Marker, sondern ausschließlich über Mustererkennung von natürlichen Objekten im aktuellen Bild gefunden wird. Dieses so genannte markerlose Tracking ist eine der Stärken der Junaio-Plattform und über das Mobile SDK stehen diese Funktionen nun auch in einer kostenlosen Variante für Eigenentwicklungen zur Verfügung.

Ein Open-Source-Projekt unter GPLv3-Lizenz für iOS und Android, mit dem AR-Browser-Funktionalität entweder standalone oder als Teil einer eigenen App realisiert werden kann, ist Mixare [5]. Mixare bietet dazu als Grundlage zunächst eine eigenständige App an, mit der man die grundlegende AR-Browser-Funktionalität analog zu den drei oben beschriebenen Produkten nutzen kann; allerdings mit der Einschränkung, dass zunächst ausschließlich Daten von Wikipedia-Artikeln visualisiert werden können.

Um unter Android eine eigene Datenquellen über Mixare anzuzeigen, existieren mehrere Möglichkeiten. Die Original-Mixare-App kann entweder über einen URL-Aufruf mit passendem MIME Type (application/mixare-json) aus einem Webbrowser oder aus einer eigenständigen App durch Definition eines Intents der folgenden Art aufgerufen werden:

 

 

Intent i = new Intent();

i.setAction(Intent.ACTION_VIEW);

i.setDataAndType(

   Uri.parse("http://"), "application/mixare-json"); startActivity(i);

Gemäß den Android-Regeln wird die Mixare-App dann aufgrund der Angabe des MIME Type application/mixare-json automatisch vom Android-Betriebssystem mit den vom eigenen Web Service erzeugten JSON-Daten aufgerufen. Die dritte Möglichkeit schließlich ist, den Sourcecode von Mixare – unter Beachtung der GPLv3-Lizenzbedingungen – durch den Einbau von eigenen Features zu einer eigenen App zu erweitern.

Wer eine AR-Anwendung mit Marker-Tracking für die Android-Plattform erstellen will, der sollte einen Blick auf AndAR [6] werfen. Gemäß den Android-Programmierregeln muss bei der Erstellung einer eigenen App auf Basis von AndAR eine benutzerdefinerte Activity als Erweiterung der AndARActivity aus dem AndAR-Toolkit erstellt werden. Diese Activity besitzt damit dann bereits die Grundfunktionalität für AR-Anwendungen. Es verbleibt somit „nur“ noch die Aufgabe, die Marker (Abb. 1) in die Anwendung zu integrieren. Anweisungen zur Erstellung solcher Marker findet man auf den AndAR-Webseiten. Dort finden sich auch zwei kleine Apps [7] , mit denen man eine Marker-gestützte Einblendung von 3-D-Bildern testen kann.

Ist die Entscheidung allerdings gegen eine eigene App gefallen und will man stattdessen einen eigenen Kanal für die Anzeige in einem der erwähnten AR-Browser erstellen, so gibt es von den Herstellern dieser Browser ebenfalls Tools zur Erstellung dieser Daten im jeweils passenden Format. Bei Wikitude nennt sich dieses Tool ARchitect, für Junaio ist es der Junaio Creator bzw. Metaio Creator. Und wer Inhalte für Layar erstellen will, der kann dies mit einem der Tools tun, die auf den Layar-Webseiten zusammengestellt sind [8]. Zu beachten ist dabei, dass die Datenbereitstellung im Livebetrieb von einem eigenen Webserver erfolgen muss, der vom Server des jeweiligen AR-Browsers angefragt wird. Nur bei Wikitude gibt es zusätzlich die Möglichkeit, die Daten ohne Einbeziehung des eigenen Servers auch offline auf dem Wikitude-Server abzulegen. In diesem Fall müssen die Daten entweder im Wikitude eigenen ARML-Format oder im nativen Google-Earth-Format KML vorliegen.

Wie bereits erwähnt gibt es leider noch keinen Standard für das Format, in dem Objekte für die verschiedenen AR-Browser definiert werden müssen. Trotz Verfügbarkeit diverser Tools bleibt das also eine aufwändige Arbeit. Vergleichbar wäre dies mit einer Situation, in der man Webinhalte für jeden verfügbaren Webbrowser einzeln definieren müsste. Wer das im AR-Bereich nicht tun, aber trotzdem auf allen bekannten Plattformen dabei sein möchte, der sollte sich Hoppala Augmentation ansehen [9]. Hier wird eine Art Content-Management-System für AR-Inhalte angeboten, die gleichzeitig auch in der Hoppala Cloud gehostet werden können. Für jeden dort angelegten und mit eigenen Inhalten versehenen Kanal erhält man einen Hoppala-URL. Dieser URL wiederum muss dann nur noch bei den gewünschten Anbietern von AR-Browsern – nach einer Registrierung als Content-Anbieter – mit den erforderlichen Zusatzinformationen zum Kanal versehen angemeldet werden. Nach Freigabe des Kanals durch den Anbieter (bzw. bei Wikitude nach Eingabe des erhaltenen Developer Keys in den Einstellungen der Wikitude-App) können die eigenen Daten dann im AR-Browser angesehen werden. Die Daten für alle drei AR-Browser können hier also an einem zentralen Ort verwaltet werden – darüber hinaus entfällt die Notwendigkeit, einen eigenen Web Service betreiben zu müssen, der die Daten in unterschiedlichen proprietären Formaten online zur Verfügung stellt.

Fazit

Trotz spektakulärer Videos und interessanten ersten verfügbaren Anwendungen sind AR-Applikationen derzeit noch ein Nischenprodukt – aber das waren andere anfangs auch. Viele der aktuell verfügbaren AR-Anwendungen haben eher Marketing-Charakter mit dem Ziel, durch interessante Effekte den Begriff Augmented Reality bekannt zu machen. Eine richtige Killerapplikation fehlt derzeit noch, möglicherweise wird sie aber dann erscheinen, wenn die Spieleindustrie die Möglichkeiten von AR entdeckt und voll ausnutzt.

Der bereits länger existierende AR-Markt hat durch den Erfolg der Smartphones einen wichtigen Schritt nach vorne gemacht, da nun Endgeräte in ausreichender Menge verfügbar sind, bei denen die für AR-Anwendungen benötigten Funktionen zur Standardausrüstung gehören. Smartphones müssen aber nicht der letzte Schritt sein: AR-Brillen beispielsweise könnten in Zukunft die Überlagerung von realer und virtueller Welt noch einfacher machen, da dabei die Notwendigkeit entfällt, ständig ein mobiles Gerät mit den Händen in eine bestimmte Richtung halten zu müssen.

Aber auch in umgekehrter Richtung kann Augmented Reality hilfreich für die weitere Verbreitung von mobilen Geräten sein. Streng genommen sind nämlich AR-Applikationen eine der wenigen Anwendungen, die tatsächlich von allen Funktionen eines Smartphones Gebrauch machen: Kamera, Display, Positions- und Orientierungsbestimmung sowie Internetverbindung. Während manche simple (Marketing-)App auch auf einem stationären PC laufen könnte oder eine einfache Kopie einer mobilen Webseite ist, kann ein modernes Mobilgerät erst in einer AR-Anwendung zeigen, was alles in ihm steckt.

Es gibt also eine Reihe von Teilnehmern des boomenden mobilen Marktes, die an einem weiteren Ausbau der AR-Welt ein starkes Interesse haben. Somit besteht die berechtigte Hoffnung, dass AR in den kommenden Jahren weiter wachsen und zu einem festen Bestandteil der mobilen Welt werden wird.

Links & Literatur

[1] Junaio: http://www.junaio.com

[2] Layar: http://www.layar.com

[3] Wikitude: http://www.wikitude.com

[4] ARML-Spezifikation: http://www.openarml.org/wikitude4.html

[5] Mixare: http://www.mixare.org

[6] AndAR: http://code.google.com/p/andar

[7] AndAR-Beispiel-App: http://code.google.com/p/andar/wiki/AndARModelViewerInstructions

[8] Layar-Inhalte-Erstellung: http://www.layar.com/development/third-party-tools

[9] Hoppala Augmentation: http://augmentation.hoppala.eu

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -