Vor ein paar Monaten kündigte Google mit ARCore, seinen direkten Konkurrenten zu Apples ARKit, an. Offensichtlich ist das eine gute Nachricht für die Augmented-Reality-(AR-)Industrie, aber was bedeutet das wirklich für Entwickler und Konsumenten?
Ist ARCore nicht einfach nur Tango-lite?
Ein Entwickler, mit dem ich scherzhaft sprach, sagte: „Ich habe mir gerade das ARCore SDK angeschaut und sie einfach in Tango-SDK umbenannt, den Code der Depth Kamera kommentiert und ein Compiler-Flag geändert.“ Ich vermute, es ist ein bisschen mehr als das, aber nicht viel mehr. Beispielsweise sind die neuen Web-Browser, die ARCore unterstützen, fantastisch für Entwickler, aber sie sind von der Kern-SDK getrennt. In meinem letzten ARKit-Post fragte ich mich, warum Google vor 12 Monaten keine Version von Tango VIO veröffentlicht hatte, da viele Komponenten teilweise komplett übernommen wurden.
Das ist eine großartige Nachricht, weil ARCore eine sehr ausgereifte und gut getestete Software ist und es eine reichhaltige Roadmap von Funktionen gibt, die für Tango entwickelt wurden und die nicht alle von 3D Depth Data abhängen.
Abgesehen von der Bezeichnung, wenn Sie die Hardware für die Depth Kamera-Sensorik zu einem mobilen Endgerät hinzugefügt haben, auf dem ARCore läuft, dann haben Sie ein Tango-Gerät. Jetzt hat Google einen viel einfacheren Weg, um eine breite Akzeptanz des SDK zu erreichen, indem es in der Lage ist, es auf den Flagschiff-Smartphones mit anzubieten. Niemand würde ein großartiges Android-Handy für ein schlechteres mit AR aufgeben. Jetzt kaufen die Konsumenten das Smartphone, das sie sowieso gekauft hätten und ARCore erhalten Sie kostenlos dazu.
Ich fand es schon immer interessant, dass Tango bereits lange Zeit als „ein mobiles Endgerät, dass seinen Standort kennt“ beschrieben wurde. Ich habe nie eine einzige getroffen, die davon beeindruckt war. Ich assoziiere mit Tango eher ein Endgerät, welches mit Google Maps ausgerichtet wurde. AR ist eher ein nachträglicher Gedanke. Mit der neuen Bezeichnung ist es immer AR.
Aber was ist mit der ganzen Kalibrierung, über die Sie gesprochen haben?
Um ARKit felsenfest zu gestalten, realisierte Apple insgesamt 3 Arten von Hardware und Software Kalibrierung: Geometrisch (einfach), Photometrisch (hart) für die Kamera und IMU-Fehlerentfernung (verrückt hart). Von großer Bedeutung ist auch die Uhrensynchronisation der Sensoren.
Kalibrierung ist keine binäre „ja, es ist kalibriert“ oder „nein, es ist nicht“ Situation. Es sind Statistiken und mehr Schritte, um das System stabil genug für den Anwendungsfall zu machen. Je „kalibrierter“ das System ist, desto länger wird es dauern, bis die Fehler in den Posenberechnungen bemerkbar werden. Hier ist etwas, was Google meiner Meinung nach getan hat:
Erstens sind sie sehr vorsichtig, was die Geräte angeht, die sie unterstützen. Vorerst sind es das Samsung Galaxy S8 und Google Pixel. Auf beiden Plattformen arbeiteten die Google-Ingenieure bereits an der Unterstützung der Sensorkalibrierung für Inside-Out-Tracking für Daydream-VR. Google hatte vor kurzem Ingenieure, die mit Samsung in Südkorea an der Kalibrierung und Abstimmung von Sensoren in ihren nächsten mobilen Endgeräten arbeiteten, um Daydream vollständig zu unterstützen, so dass es nicht völlig undenkbar ist, einen Teil dieser Arbeit auf das S8 zu übertragen. Wir haben also zwei Geräte, bei denen die Kameras und IMUs bereits einigermaßen gut kalibriert und getaktet sind (für Daydream).
Google hatte in diesem Jahr viel Zeit damit verbracht, die Tango- und Daydream-SDKs zusammenzuführen. Ende August 2016 wurde ein Großteil der Low-Level-Arbeit erledigt, was bedeutet, dass das Tango/ARCore VIO-System die Vorteile der Daydream-Sensor-Integration bereits nutzen könnte.
Schließlich werden die wirklichen Vorteile der Kalibrierung an den äußeren Grenzen der Systemleistung sichtbar. Sowohl ARKit als auch ARCore können beide recht gut über viele Meter laufen, bevor der Benutzer einen Drift bemerkt. Ich habe keine Kopf-an-Kopf-Tests gesehen, die über lange Zeiten/Entfernungen durchgeführt wurden, aber es ist nicht wirklich wichtig. Entwickler sind immer noch dabei, ihre Köpfe rund um das Setzen von AR-Inhalten direkt vor Ihnen zu bewegen. Der Benutzer kann kaum begreifen, dass er frei über ziemlich große Entfernungen laufen kann. Was die tatsächliche Nutzung von AR-Anwendungen angeht, so sind Unterschiede in der Kalibrierung so gut wie unmöglich zu erkennen. Bis die Entwickler die Grenzen der SDKs überschreiten, setzt Google darauf, dass es eine neue Gerätegeneration auf dem Markt geben wird, bei der die Sensorkalibrierung in der Fabrik weitaus enger integriert ist.
Zum Beispiel haben wir diese Woche mit einem der größten IMU-OEMs über dieses Thema gesprochen und er sagte, dass ihre Handy-IMUs nur werkseitig auf eine einzige Betriebstemperatur kalibriert sind, um die Kosten zu senken. Das bedeutet, dass die IMU-Hardware so abgestimmt ist, dass sie bei dieser einen Temperatur die geringsten Fehler liefert. Wenn Sie das Smartphone weiterhin benutzen, wird es heißer & dies wird dazu führen, dass sich die IMU etwas anders verhält, als sie kalibriert ist und es werden Fehler auftreten. Dies ist für die meisten IMU-Anwendungsfälle in Ordnung, aber für VIO, sobald sich das Gerät erwärmt hat, werden die IMU-Messungen für die Berechnung des Dead Reckoning unzuverlässig und die Trackingdaten werden dadurch verzerrt. Dieser OEM kann leicht damit beginnen, für mehrere Temperaturbereiche zu kalibrieren, wenn sie gefragt werden, was bedeutet, dass dies eine Fehlerquelle weniger ist, als der ARCore VIO-Code von Google, der Gerätetyp für Gerätetyp eliminieren muss. Apple könnte diese Herausforderungen viel schneller bewältigen, während Android auf die Änderungen warten muss, um durch ein Ökosystem zu filtern.
Lighting.
Sowohl ARKit als auch ARCore liefern eine einfache Schätzung des natürlichen Lichts in der Szene. Dies ist eine Schätzung für die Szene, unabhängig davon, ob die reale Welt mit Umgebungslicht oder mit scharfen Scheinwerfern beleuchtet wird. ARKit liefert Intensität und Farbtemperatur an den Entwickler zurück, während ARCore entweder einen einzelnen Pixel-Intensitätswert oder einen Shader liefert. Beide Ansätze scheinen aus frühen Demos heraus ähnliche Ergebnisse zu liefern. Subjektiv sehen Googles Demos für mich etwas besser aus, aber das mag daran liegen, dass Tango-Entwickler schon länger daran arbeiten. Allerdings hat Google bereits gezeigt, was bald kommt, nämlich die Fähigkeit, virtuelle Shader und Reflexionen dynamisch an die Bewegungen der realen Weltlichter anzupassen. Dies wird einen enormen Auftrieb in der Gegenwart geben, wo wir unbewusst glauben, dass der Inhalt „wirklich da“ ist.
Mapping.
Mapping ist ein Bereich, in dem ARCore heute einen klaren Vorteil gegenüber ARKit hat. Mapping ist das „M“ in SLAM. Es bezieht sich auf eine Datenstruktur im Speicher, welche eine Menge Informationen über die 3D-Real-World-Szene enthält, die der Tracker verwenden kann, um sie zu lokalisieren. Lokalisieren heißt lediglich nur, herauszufinden, wo ich mich in der Karte befinde. Wenn ich dir die Augen verbunden habe und dich in der Mitte einer neuen Stadt mit einer Papierkarte fallen ließ, dann ist das der Prozess, den du machst, indem du dich umsiehst, dann die Karte betrachtest und dann wieder herumschaust, bis du herausgefunden hast, wo auf der Karte du bist … das ist Lokalisierung. Auf seiner einfachsten Ebene ist eine SLAM-Map ein Diagramm von 3D-Punkten, die eine spärliche Punktwolke darstellt, wobei jeder Punkt den Koordinaten eines optischen Merkmals in der Szene entspricht. Sie haben in der Regel auch eine Menge zusätzlicher Metadaten, z.B. wie „zuverlässig“ dieser Punkt ist, gemessen an der Anzahl der Frames, die kürzlich in den gleichen Koordinaten erkannt wurden. Einige Karten enthalten „Keyframes“, die nur ein einzelnes Videobild sind, das alle paar Sekunden in der Map gespeichert wird und dazu dient, dem Tracker zu helfen, die Welt mit der Map in Einklang zu bringen. Andere Maps verwenden eine dichte Punktwolke, die zuverlässiger ist, aber mehr GPU und Speicher benötigt. Sowohl ARCore als auch ARKit verwenden momentan ausbaufähige Maps.
Es funktioniert folgendermaßen: Wenn Sie eine ARCore-/ARKit-App starten, prüft der Tracker, ob es eine Map gibt, die vorinstalliert und einsatzbereit ist, so dass der Tracker eine neue Map initialisiert, indem er eine Stereoberechnung durchführt, wie ich es in meinem letzten Beitrag geschrieben habe. Das bedeutet, dass wir jetzt eine nette kleine 3D-Map haben, die zeigt, was sich im Sichtfeld der Kamera befindet. Wenn Sie anfangen, sich zu bewegen und neue Teile der Hintergrundszene in das Sichtfeld wandern, werden der Map mehr 3D-Punkte hinzugefügt und sie wird größer und größer. Das war früher nie ein Problem, weil die Tracker so schlecht waren, dass sie unbrauchbar wegdriften würden, bevor die Map zu groß wurde, um Sie zu verwalten. Das ist nicht mehr der Fall und die Verwaltung der Map ist der Ort, an dem ein Großteil der interessanten Arbeit in SLAM stattfindet. ARKit verwendet ein „Schiebefenster“ für seine Map, was einfach bedeutet, dass es nur einen variablen Betrag der letzten Vergangenheit in der Map speichert und alles Alte wegwirft. Die Annahme lautet, dass Sie nie wieder gegen die Szene von vor einer Weile relokalisieren müssen. ARCore verwaltet eine größere Map, was bedeutet, dass das System zuverlässiger sein sollte.
Die Pointe ist also, dass mit ARCore, selbst wenn Sie das Tracking verlieren, es sich besser erholen wird und Sie nicht beeinträchtigt werden.
Sowohl ARCore als auch ARKit verwenden ein ausgekühgeltes Konzept mit der Bezeichnung „Anchors“, um der Map das Gefühl zu geben, dass sie einen größeren physischen Bereich abdeckt als sie es tut. Ich habe dieses Konzept zuerst bei Hololens gesehen, die wie üblich ein Jahr oder mehr voraus sind… Normalerweise verwaltet das System die Map völlig unsichtbar für den Benutzer oder App-Entwickler. Anker erlauben es dem Entwickler, dem System zu kommunizieren: „Merken Sie sich diesen Teil der Map hier, werfen Sie ihn nicht weg.“ Die körperliche Größe des Ankers ist 1m x 1m Quadratmeter. Der Entwickler lässt normalerweise einen Anker fallen, wenn Inhalte an einem physischen Ort platziert werden. Das bedeutet, dass, wenn der Benutzer dann vor Anker wandert, die Map um den physischen Ort, an dem der Inhalt existieren soll, weggeworfen wird und der Inhalt verloren geht. Mit Anchors bleibt der Inhalt immer dort, wo er sein sollte, wobei der schlimmste UX-Effekt ein möglicher kleiner Fehler im Inhalt ist, wenn das System neu lokalisiert und springt, um die akkumulierte Drift zu korrigieren.
Der Zweck der Map ist es, dem Tracker auf zwei Arten zu helfen: Die erste ist, dass, während ich mein Handy hin und her bewege, die Map aus der anfänglichen Bewegung aufgebaut wird und auf dem Rückweg können die in Echtzeit erkannten Merkmale mit den gespeicherten Merkmalen in der Map verglichen werden. Dies trägt dazu bei, das Tracking stabiler zu machen, indem nur die zuverlässigsten Features aus der aktuellen & vorherigen Ansicht der Szene in der Posenberechnung berechnet werden.
Die zweite Möglichkeit, wie die Map hilft, besteht darin, Tracking zu lokalisieren. Es wird eine Zeit kommen, in der du die Kamera abdeckst, dein Handy fallen lässt oder dich zu schnell bewegst oder etwas Zufälliges passiert und wenn die Kamera als nächstes die Szene sieht, stimmt es nicht mit dem überein, was das letzte Update der Map meint, dass sie sehen sollte. Es wurde mit verbundenen Augen und an einem neuen Ort abgesetzt. Das ist die Definition von „I`ve lost Tracking“, die bahnbrechende AR-Entwickler in den letzten Jahren etwa 1000 Mal am Tag sagen würden. An dieser Stelle kann das System 2 Dinge tun:
einfach alle Koodinatensysteme zurücksetzen und von vorne anfangen. Das ist es, was ein reines Odometriesystem macht. Was Sie erleben, ist, dass alle ihre Inhalte in eine neue Position springen und dort bleiben. Es erzeugt keine gute User Experience.
Oder das System kann die Menge der 3D-Features, die es im Moment sieht, nehmen und die gesamte Map durchsuchen, um eine Übereinstimmung zu finden, die dann als die richtige virtuelle Position aktualisiert wird und Sie können die Anwendung weiter verwenden, als ob nichts passiert wäre. Es gibt hier zwei Probleme: 1) je größer die Map wird, desto länger dauert dieser Suchprozess, desto wahrscheinlicher ist es, dass sich der Nutzer wieder bewegen kann, was bedeutet, dass die Suche erneut beginnen muss… und 2) die aktuelle Position des Telefons stimmt nie genau mit der Position überein, die das Telefon in der Vergangenheit hatte, so dass dies auch die Schwierigkeit der Mapsuche erhöht und die Berechnung und die Zeit der Relokalisierung erhöht. Also im Grunde genommen sogar mit Mapping, wenn man sich zu weit von der Map entfernt, ist man gef… und das System muss zurückgesetzt und neu gestartet werden.
Beachten Sie, wenn ich mich auf eine große Map für mobile AR beziehe, bedeutet das ungefähr eine Map, die den physischen Bereich eines sehr großen Zimmers oder einer sehr kleinen Wohnung abdeckt. Beachten Sie auch, dass dies bedeutet, dass wir für Outdoor-AR über eine völlig neue Art des Mappings nachdenken müssen.
Robustes Relokalisieren gegen eine Map ist ein sehr hartes Problem und wird von niemandem bis zu einem Konsumenten-UX-Level noch IMO gelöst. Jeder, der behauptet, Multiplayer- oder persistente AR-Inhalte anbieten zu können, wird seine UX durch die Fähigkeit eines neuen Telefons, sich von einem Kaltstart in eine Map zu verlagern, die entweder von Player 1 erstellt oder von der Cloud heruntergeladen wurde, stark eingeschränkt haben. Sie werden feststellen, dass Spieler 2 ziemlich nah an Spieler 1 stehen muss und ihr Handy ungefähr auf die gleiche Art und Weise halten muss. Dies ist ein PITA für Anwender. Sie wollen einfach nur auf der Couch gegenüber von ihnen sitzen und ihr Telefon einschalten und sofort sehen, was Sie sehen. Oder irgendwo innerhalb weniger Meter von einer vorherigen Position zu stehen und den „permanenten“ AR-Inhalt zu sehen.
Beachten Sie, dass es app-spezifische Workarounds für Multiplayer gibt, die Sie auch ausprobieren können, wie z.B. die Verwendung eines Markers oder die harte Kodierung einer entfernten Startposition für P2 usw. Technisch gesehen können sie funktionieren, aber Sie müssen dem Benutzer immer noch erklären, was er tun soll und ihr UX könnte getroffen oder verfehlt werden. Es gibt keine magische „it just works“-Lösung , die es ihnen ermöglicht, die VIO-Tracking-Funktionalität von ARKit/ARCore so zu nutzen, dass Sie sie einfach nur verwenden können.
Dieses Niveau der Relokalisierungsrobustheit ist aber leider nicht möglich. Dies gilt sowohl für AFAIK, andere heutige, gängige Relokalisierer und sogar für welche, die in der Forschung veröffentlicht wurden. Es ist eines dieser Probleme wie VIO, das nur eine sehr kleine Anzahl von Menschen lösen kann. Ich kenne nur ein unveröffentlichtes System, das Berichten zufolge die Robustheit der Verbraucherklasse unterstützen kann und hofft, Anfang 2018 auf den Markt zu kommen.
Der iPhone-8- Leitgedanke.
Ich bin ziemlich beeindruckt von demjenigen, der innerhalb von Google so schnell auf ARKit reagiert hat und den bestmöglichen Spoiler für Apples iPhone 8 Keynote gefunden hat. ARCore hat:
gerade genug zusätzliche Funktionen als ARKit, bei denen Apple nicht einfach behaupten kann, dass sie auf dem Papier besser sind.
Ein paar Jahre Content-Experimente von Tango & Daydream, die mit ARCore arbeiten und sichtbar reifer sind, als das, was Entwickler in ein oder zwei Monaten ARKit-Arbeiten aufbauen könnten.
Genug OEMs in der Pipeline, dass sie eine ähnliche Reichweite „real soon“ beanspruchen können.
ARKit veröffentlichte analog zu ARCore zahlreiche Videos bei Youtube. Diese sind von der Qualität aber nicht besser als die Videos von Google. Der Aspekt des technischen Durchbruchs von ARKit Messaging wird ein wenig gedämpft.
Es ist zu erwarten, dass die Popularität von ARKit steigen und dass es damit das erste und beste AR-System überhaupt wird. Apple ist in marketingtechnischen Fragestellungen einzigartig und konnten das in der Vergangenheit auch schon mehrfach unter Beweis stellen. Aber immerhin kann Google jetzt auf ARCore hinweisen und damit zeigen, dass Sie auch schon in dieser Richtung tätig sind.
OEMs haben noch Vorbehalte.
Es scheint ganz so, dass ARCore zu früh auf den Markt gebracht wurde und lediglich eine Neuverpackung der vorhandenen Assets darstellt so gibt es z.B. noch kein ARCore Logo. Es bestehen immer noch Vorbehalte der OEMs gegenüber Tango als Hardware und Android-Lock-In. ARCore eliminiert die Probleme mit der Hardware-Kommodifizierung der Kamera-Stacks und die Kostenprobleme bei den Stücklisten mit dem Tango-Hardware-Referenzdesign. Es sieht danach aus, als ob Google hier eine gewisse strategische Kontrolle eingeräumt hat, obwohl man zum Schluss kommen kann, dass alles sehr schnell ging, so dass diese Gespräche noch nicht ernsthaft stattgefunden haben.
Aber Google besteht darauf, dass ARCore Teil von Google Mobile Services (GMS) für Android ist. Diese Tatsache missfällt vielen OEMs. Wenn AR wirklich „die nächste Plattform“ ist, dann ist es eine Gelegenheit die Energiebilanz im Ökosystem zurückzusetzen. ARCore ist nicht nur ein neues Feature wie z.B. ein neues GUI-Widget. Bisher wurde noch keinem StartUp kommuniziert, dass es nicht mehr notwendig ist über SLAM zu reden, weil Google das Problem der Hardware-Anforderungen bereits gelöst hat. Die Gespräche über die Entkopplung von AR und GMS sind noch im Gange.
Gerade in China, dem größten Markt für OEMs, stößt GMS auf großen Widerstand und ist nicht willkommen. Sie wünschen sich eine AR-Softwarelösung, die global funktioniert (wie jeder Entwickler und AR-Werkzeugmacher).
Sollte man jetzt auf ARCore bauen?
Arcore macht Sinn, wenn Sie Android-Fan sind und bereits über ein Samsung Galaxy S8 und Pixel verfügen. Wenn Sie aber eher auf iPhones stehen, dann wird sich der Umstieg sicher nicht lohnen. Entwickler sollten sich zum aktuellen Zeitpunkt auf das Erstellen von AR-Apps konzentrieren, da dies weiterhin eine große Herausforderung darstellt. Es wird weitaus weniger Aufwand sein, zu lernen, wie man auf ARKit und ARCore aufbaut, als die Mühe, zu lernen, was man baut. Sie sollten immer daran denken, dass ARKit/ARCore SDK`s Version 1.0 sind. Sie sind wirklich grundlegend (VIO, Flächendedektion, Grundbeleuchtung) und werden in den nächsten Jahren wesentlich umfangreicher werden (3D-Szenenverständnis, Okklusion, Multiplayer etc.). In naher Zukunft werden Entwickler und Konsumenten in diesen Bereichen viel dazulernen. Zum aktuellen Zeitpunkt sollten Sie sich auf das Lernen konzentrieren, was schon hart genug ist und halten Sie sich an das, was als zugrundeliegende Technik bekannt ist (Android, iOS Xcode etc.). Sie müssen natürlich vor dem Hintergrund relevanter Faktoren wie z.B. die Marktreichweite, AR-Feature-Support, Monetarisierung etc. eine Entscheidung bezüglich der Plattform für die Markteinführung treffen.
Ist ARCore besser als ARKit?
Sie werden als technische Lösung sehr nah an der Grenze der technischen Leistungsfähigkeit sein. Benutzer können heute kaum effektiv unterscheiden, wenn es um die User Experience geht, die Sie heute erstellen können. ARKit hat einige technische Vorteile rund um die Hardware/Software-Integration und zuverlässigeres Tracking. ARCore hingegen bietet einige Vorteile in Bezug auf Mapping und zuverlässigeres Recovery. Beide Vorteile sind meistens nur für Computer Vision Ingenieure spürbar, welche genau wissen, worauf es ankommt.
Apple hat einen klaren Go to Market-Vorteil mit einer großen Basis von Geräten, die sofort auf das neueste iOS aufrüsten, das ARKit erhalten wird. Die Nutzer von Apple geben in der Regel mehr Geld aus, so dass AR Apps mittelfristig besser auf ARKit monetarisieren sollten. Androids Vorteil waren schon immer die Rahmenbedingungen. Es wird mindestens 12 Monate dauern, bis das Android Ökosystem alle Teile zusammen hat und die Geschäfte abgeschlossen sind, damit ARCore von der Hardware in den meisten neuen Geräten unterstützt wird.
ARCore hat einen netten Vorteil in der Pipeline von Tango R&D, welche sofort eingesetzt werden kann und von denen viele zumindestens einige wenige Benutzer-/Markttests durchlaufen haben. Es wird Spaß machen, zu sehen, wie schnell sich diese Systeme nach der Schaffung der Grundlagen in den nächsten 12 bis 24 Monaten entwickeln werden.
Die Technologie ist zum aktuellen Zeitpunkt endlich (gerade) gut genug, um Anwendungen für die breite Masse zu bauen. Sollten Sie ein AR-Entwickler sein und noch keinen Senior Product/Interaction Designer in ihrem Team haben, müssen Sie sich ernsthaft über die Einstellung einer weiteren Person Gedanken machen.
Die Frage, ob ARKit oder ARCore zu präferieren ist, hängt im Wesentlichen von den persönlichen Vorlieben und Zielen des Entwicklers ab. Beide Systeme haben ihre Stärken und Schwächen, aber was wichtig ist, ist, dass beide eine ausreichend gute Konsumerfahrung ermöglichen können, die Entwickler mit großen Freiräumen erforschen können.
Vielen Dank fürs Lesen.