Verkürzen Sie die Time-to-Market – mit automatisierter Augmented-Reality

In der Einzelhandelsbranche macht die AR-Technologie das Einkaufen immersiver und befriedigender. Aus Sicht der Kund:innen unterstützt AR ihre Kaufentscheidung und verbessert ihr Einkaufserlebnis, indem sie die Produkte „sehen und anfassen“ können. In der Fertigung hilft AR, die Kosten für die Erstellung von Prototypen und den Ausschuss zu verringern. So können Produktdesigner das Endprodukt visualisieren, bevor sie Ressourcen für die Massenproduktion bereitstellen. Ein potenzieller Anwendungsfall für die medizinische Gemeinschaft ist die Möglichkeit für Ärzte, sich in der Verwendung neuer medizinischer Geräte zu schulen.

Im Onlinehandel macht AR das Shoppingerlebnis attraktiver bzw. befriedigender und erleichtert Kaufentscheidungen. Denn Kundinnen oder Kunden können Produkte im virtuellen Raum „sehen und anfassen“. In der Fertigung lassen sich mit AR Prototyping-Kosten und Ausschuss reduzieren. Produktentwickler können beispielsweise das Endprodukt visualisieren, bevor Ressourcen für die Mengenfertigung eingesetzt werden. Ein potenzieller Use Case in der Medizin sind Selbstlernangebote zur Verwendung neuer medizinischer Ausrüstung.

Der größte Pain am derzeitigen AR-Workflow

 Als Voraussetzung für AR müssen 3D-Modelle der physischen Produkte erstellt, optimiert und auf die Firmen-Server hochgeladen werden. Anschließend wird ein AR-Code generiert, den Nutzer mit ihren Mobilgeräten scannen können. Für OEMs ist die Erstellung von AR- aus 3D-Modellen häufig unproblematisch, da bereits interne Entwurfsunterlagen und/oder -dateien zu den Produkten vorliegen.

Liegen jedoch keine Daten vor, müssen Unternehmen 3D-Modellentwickler beauftragen und unter Einsatz von Modellierungssoftware wie 3DMax, AutoCAD oder Blender ein 3D-Modell aus Produktbildern erstellen. Der manuelle AR-Workflow sieht dann oft so aus:

• Bilder werden aufgenommen und an einen 3D-Modellentwickler gesendet.
• Der 3D-Modellentwickler erstellt unter Einsatz von 3D-Modellierungswerkzeugen ein AR-Modell.
• Das Modell wird in ein gängiges AR-Format wie glTF oder USDZ exportiert.
• Die Beteiligten prüfen das Modell zusammen mit dem Modellentwickler.
• Das Modell wird in die Plattform importiert/hochgeladen, wo die Kunden es sehen können.

Der manuelle AR-Workflow

Wir haben, basierend auf den genannten Punkten, die zu verbessernden Prozessschritte identifiziert. Das größte Optimierungspotenzial bietet sicherlich die manuelle Modellentwicklung. Wer sich mit 3D-Modellierung auskennt, weiß, dies viele Ressourcen und viel Zeit kostet: Erstellung, Prüfung und Iteration des Entwurfs für ein einzelnes Produkt oder Objekt können selbst bei einem hoch qualifizierten 3D-Modellentwickler mehrere Tage in Anspruch nehmen. Wer noch keinen Modellentwickler beschäftigt, müsste zudem erst einmal einen finden und einstellen.

Voraussetzung für die Automatisierung des Prozesses ist eine Integration in die Anwendungsprogrammierschnittstelle (Application Programmable Interface, kurz API). Da 3D-Modellierungs-Software in aller Regel proprietär ist, ist dies aber oft gar nicht zu realisieren. Und selbst wenn, müssen für APIs angepasste Softwaretools für die Integration entwickelt werden.

Nicht-OEMs mit begrenzten Ressourcen oder starkem Wettbewerbsdruck müssen den derzeitigen Workflow dringend verbessern, um Kosten und Arbeitseffizienz zu optimieren.

Wie lässt sich der bestehende Prozess optimieren?

Zur Automatisierung des aktuellen Workflows müssen Sie umdenken. Wenn Sie sich fragen „Lassen sich Bilder in 3D-Modelle umwandeln?“, dann lautet die gute Nachricht: „Ja, das geht!“

Der technologische Fortschritt macht es möglich, mit dem Verfahren der Fotogrammetrie ^[1] . Dabei werden mehrere Bilder des Zielobjekts aufgenommen, aus denen dann in einem Rechenvorgang das 3D-Modell erstellt wird.

Apple hat mit MacOS 12 eine Erweiterung des RealityKit-Frameworks  ^[2] herausgebracht, die die Umsetzung des Fotogrammetrieprozesses unterstützt. Entwickler können damit ohne aufwändige manuelle Bildverarbeitung oder die Integration in komplexe 3D-Modellierungs-Software programmgesteuert aus Bildern API-basierte AR-Modelle erstellen.

API-AR-Generierung

Mit dem Fotogrammetrie-Verfahren gestaltet sich der Workflow zur AR-Modellgenerierung nun wie folgt:

1. Mit einer App werden Bilder aufgenommen.
2. Diese Bilder werden in eine API zur Objekterfassung hochgeladen.
3. Die Bildverarbeitung wird gestartet.
4. Das generierte Modell wird mit der <model-viewer>-HTML-Seitenkomponente und der Anbindung an native Funktionen ausgegeben.

Dieser Weg ist deutlich einfacher, als Modelle manuell zu erstellen. Jeder, der sich mit Fotografie auskennt, kann die nötigen Bilder von Produkten für die AR-Modellgenerierung erstellen. Das AR-Modell ist nach wenigen Minuten fertig, sodass sich bei Bedarf im Handumdrehen neue Modelle erstellen lassen.

Wir haben einen Proof-of-Concept (PoC) ausgearbeitet, um diesen Ansatz zu veranschaulichen.

Die Entwicklung einer mobilen App

Da das RealityKit-Framework nur für Apple-Produkte verfügbar ist, wird, ausgehend von dem oben skizzierten Workflow, eine Lösung benötigt, die auf Apple-Hardware läuft und folgende Funktionen ermöglicht:

1. Mehrere Bilder eines Objekts aufnehmen und speichern
2. Nutzer bei der Bildaufnahme anleiten
3. Anhand der Bilder ein AR-Modell generieren

Die naheliegendste Option ist damit die Entwicklung einer iOS-App, die alle diese Kriterien erfüllt.

Nutzer laden die Bilder nach dem Aufnehmen über die App in einen Dienst hoch und lösen die AR-Modellgenerierung aus. Da die Generierung von AR-Modellen teuer ist, wird der Prozess in der mobilen App asynchron ausgeführt. Nach Abschluss wird eine Benachrichtigung gesendet.

Anschließend kann das Ergebnis überprüft werden. Erfüllt es die Erwartungen nicht, lassen sich die Generierungsparameter anpassen, um das Modell mit besseren Ergebnissen neu zu generieren.

Entwicklung einer Back-End-Anwendung zur Generierung von AR-Modellen

Mit der Objekterfassungsfunktion des RealityKit-Frameworks wird aus hochgeladenen Bildern ein AR-Modell generiert. Entsprechend den Informationen und dem Beispielcode von Apple setzt die Lösung jedoch Folgendes voraus:

• MacOS 12.0 oder höher
• Diskrete (von der Zentraleinheit oder der CPU getrennte) GPU auf dem Rechner
• Mindestens 4 GB dedizierter Raytracing-fähiger Video-RAM

Da iPhone und iPad diese Voraussetzungen nicht vollständig erfüllen, haben wir mit Swift einen Microservice entwickelt, der sich auf Apple-Computern und Arbeitsstationen mit AMD-GPU oder Apple-Chip ausführen lässt.

Da leider praktisch kein großer Cloud-Dienst die Provisionierung von M1-Macs ermöglicht, haben wir den Microservice für unseren PoC auf einem lokalen MacBook ausgeführt. Die mobile App kommuniziert mit unserem Back-End über eine Reihe von REST-APIs, die wir mit dem Vapor-Webframework entwickelt haben.

(AWS provisioniert aktuell nur Intel-VMs ohne GPU-Möglichkeit und M1 ist noch in der Preview-Phase. Wenige Dienste in der Cloud provisionieren M1-Rechner. In unserem Fall ist MacStadium eine mögliche Alternative.)

Der Implementierungsprozess im Detail

Wie können Unternehmen konkret bei der Umsetzung vorgehen? Diese Frage beantworten wir im folgenden Teil und blicken auf die Details bei der Gestaltung und Umsetzung.

Die Bedeutung des AR-Dateiformats

Auch die unterstützten Dateiformate sind ein wichtiger Aspekt bei der AR-Modellgenerierung. Es gibt eine Vielzahl an Dateiformaten für die AR-Modellierung, aber kein Universalformat wie JPEG für Bilder oder MPEG für Videos. Die folgenden beiden Formate sind jedoch am beliebtesten:

• glTF – mit Ausnahme von iOS universell erkannt
• USDZ – iOS-spezifisch

Format-Unterstützung im Vergleich

Die Unterstützung für glTF und USDZ im Vergleich:

Beim bloßen Blick auf die Tabelle konnte sich kein Format durchsetzen. glTF ist zwar stärker verbreitet, aber USDZ erlaubt im Gegenzug die iOS-Ausgabe in hoher Qualität. Darüber hinaus lassen sich Modelle mit dem Apple-ARKit schneller generieren, wenn auch mit der Einschränkung, dass nur USDZ-Modelldateien erstellt werden.

Hinweis: iOS-Geräte können glTF automatisch in USDZ umwandeln, jedoch mit Qualitätsabstrichen. Sofern möglich, ist die Bereitstellung der USDZ-Datei trotzdem vorteilhafter.

Unser Backend-Microservice im Detail

Der Backend-Microservice übernimmt mit dem Empfang und der Verarbeitung der Kundenbilder die zentrale Aufgabe bei der AR-Modellgenerierung. Das Diagramm unten veranschaulicht unser Konzept der Gesamtarchitektur:

API-Software-Komponente

Auf Basis weiterer Analysen haben wir folgenden Interaktionsfluss identifiziert:

1. Session starten und zugehörige Metadaten hochladen
2. Alle Dateien in die Session hochladen
3. Dateiverarbeitung starten
4. Modell validieren

API-Interaktionsabfolge

Wir wissen, dass für den Empfang von Kundenbildern RESTful-APIs benötigt werden. Kunden sollten über die APIs im Microservice die Modellgenerierung starten und das Modell anschließend für den Download und die Ausgabe speichern können.

Hier kommt ein Webframework ins Spiel. Wir haben uns hier für Vapor entschieden.

Das Vapor-Webframework

Vapor ist das ideale ressourcenschonende Webframework. Es erlaubt die beschleunigte Entwicklung von Web-Anwendungen mit RESTful-APIs und lässt sich auf Docker- und Linux-Rechnern bereitstellen. Für RealityKit benötigten wir jedoch eine MacOS-spezifische API-Lösung. Damit fallen Docker und Linux als Optionen aus.

Das alternative Kitura-Webframework kommt aber für uns nicht in Frage, da es nicht sehr aktiv weiterentwickelt wird.

Vapor wird hingegen nach wie vor aktiv weiterentwickelt und von Entwicklern unterstützt. Darüber hinaus mussten wir eine architekturübergreifende Anwendung entwickeln. Ein weiterer Vorteil von Vapor besteht darin, dass dieses Framework sowohl für x86-64- als auch für ARM64-Architekturen auf jedem beliebigen macOS entwickelt wurde.

Die große Bedeutung der Parallelität

Die AR-Modellgenerierung verbraucht erhebliche Mengen an CPU- und GPU-Leistung und kann mit Apple-Chips wie M1 SoC mehrere Minuten und mit Intel-Prozessoren auch länger dauern. Das beeinträchtigt die allgemeine Leistung und die Reaktionszeiten des Systems. Daher kann der Vorgang nicht im selben Thread wie die RESTful-API für den Bildempfang oder in der Ereignisschleife auf dem Hauptserver ausgeführt werden.

Wie lässt sich dieses Problem lösen?

Die Antwort: Parallelität und asynchrone Verarbeitung

Die AR-Modellgenerierung muss als parallele Ausgabe ausgeführt werden, die von der API oder einem anderen Mechanismus wie einem Zeitgeberauftrag ausgelöst wird. So können sich die APIs (wie z. B. die API zum Hochladen der Bilder) nach dem Fire-and-Forget-Prinzip („auslösen und vergessen“) verhalten.

Das bringt jedoch bestimmte Herausforderungen mit sich.

Bei der parallelen Verarbeitung erhält der Nutzende keine Updates zum aktuellen Verarbeitungsstatus über die API. Stattdessen lässt sich aber mit einer Benachrichtigung der Fortschritt der Aktivitäten in Prozent anzeigen. Zu unserer Lösung gehört daher ein Benachrichtigungssystem wie im Diagramm unten gezeigt.

Benachrichtigungen

Über das Benachrichtigungssystem informiert der AR-Generierungsprozess den Nutzenden auf unabhängigem Weg über Fortschritt und Status. Folgende Status werden unterstützt:

• Nicht vorhanden
• Wird verarbeitet – mit Prozentangabe
• Erstellt
• Fehler – mit entsprechender Meldung

Service Deployment

Unsere CI-Pipeline generiert eine architekturübergreifende ausführbare Datei, die sich auf M1- und Intel-Chips ausführen lässt.

Mit dem folgenden Befehl wird im Terminal eine architekturübergreifende ausführbare Datei generiert:

swift build --configuration release --arch arm64 --arch x86_64
 

Weitere Verbesserungen: Skalierung und Optimierung der Lösung

Die Generierung von AR-Modellen aus Bildern ist, wie bereits erwähnt, ein aufwändiger Prozess mit einem hohen Bedarf an Hardware-Ressourcen und spezifischer Hardware. Als Beispiel ist ein Szenario denkbar, bei dem innerhalb eines kurzen Zeitraums Bildstapel für mehrere Objekte erfasst und ins Backend hochgeladen werden müssen. Die Folge wäre eine Überlastung der Verarbeitungs-Pipeline.

Die Skalierbarkeit lässt sich effizienter verbessern, wenn die API von der Verarbeitungs-Pipeline getrennt, eine Meldungswarteschlange (Kafka, SQS usw.) verwendet und das Ergebnis automatisch ausgeglichen wird.

Da sich unser Ansatz noch in der Proof-of-Concept-Phase (PoC) befindet, ist die Skalierbarkeit der Lösung weitgehend unproblematisch. In der Praxis kann dies jedoch erhebliche Einschränkungen mit sich bringen und daher eine sorgfältig konzipierte Architektur und Bereitstellung erfordern.

Fazit

Wir haben die Anwendung mit verschiedenen Objekten in verschiedenen Umgebungen getestet. Die generierten Modelle haben bei guter Objekterkennung und ausreichender Genauigkeit gut abgeschnitten. Das Ergebnis ist allerdings stark umgebungsabhängig. Bei schlechtem Licht oder unruhigen Hintergründen sind die Resultate nicht immer ideal.

Unsere Tests haben ergeben, dass mindestens 20 Bilder eines Objekts nötig sind, damit RealityKit ein ausreichend gutes Modell generiert. Für hochwertigere Modelle und komplexere Objekte sind 25 bis 40 Bilder nötig.

Die Modellgenerierung beansprucht im Schnitt nur wenige Minuten, sodass bei der Aufnahme vieler Bilder innerhalb relativ kurzer Zeit ein unkompliziertes Ausprobieren möglich ist.

Mit dem RealityKit-Framework von Apple lassen sich automatisch Modelle mit voraussehbaren Ergebnissen und nachvollziehbaren Fehlern erstellen. AR-Technologie wird damit an breiterer Front verfügbar. Eine wesentliche Einschränkung ist jedoch die fehlende Möglichkeit, programmgesteuert glTF-Modelle aus USDZ-Modellen zu generieren bzw. generierte Modelle im glTF-Format auszugeben.

Wir sind davon überzeugt, dass unser Ansatz unter Rückgriff auf ein Fotogrammetrie-Framework den Zugang zur AR-Modellierung verbessert und interessante neue Geschäftspotenziale für diese Technologie eröffnet.

References

[1] ‘Fotogrammetrie’. Wikipedia [Online]. Available: https://en.wikipedia.org/wiki/Photogrammetry 

[2] ‘RealityKit’. Apple Inc. [Online]. Available: https://developer.apple.com/documentation/realitykit 

[3] P. Cozz and T. Parisi, ‘glTF specification 1.0’. Khronos Group, Nov. 03, 2016 [Online]. Available: https://github.com/KhronosGroup/glTF/tree/main/specification/1.0 

[4] S. Schechter, ‘Everything You Need to Know About USDZ Files’. 3D Cloud Marxent, Mar. 04, 2020 [Online]. Available: https://www.marxentlabs.com/usdz-files/