Noch keinen Zugang? Dann testen Sie unser Angebot jetzt 3 Monate kostenfrei. Einfach anmelden und los geht‘s!
Angemeldet bleiben
Ausgewählte Ausgabe: 05-2017 Ansicht: Modernes Layout
| Artikelseite 4 von 6

AR-Unterstützung durch Steuerungshersteller

3.2 Server-Architektur

Auf dem Server kommt für die Bildanalyse die populäre OpenSource-Bibliothek „OpenCV“ zum Einsatz. Der Server überführt die ankommenden Bilder für die weitere Bildanalyse zunächst in ein Graustufen- und dann in ein Binärbild. Im Anschluss folgt abhängig von der eingesetzten Trackingtechnologie die Berechnung der rela- tiven Kameraposition und -orientierung. Werden beispielsweise quadratische Schwarz-Weiß-Marker verwendet, wird eine Kantenerkennung und ein anschließender Vergleich mit den hinterlegten Markern durchgeführt. Wurde ein gespeicherter Marker im Kamerabild erkannt, kann die Kamerapose geschätzt werden. Diese wird benötigt, um die virtuellen AR-Inhalte perspektivisch korrekt in das Bild einfügen zu können [6].
Grundsätzlich bestehen zwei Möglichkeiten für das anschließende Rendering der AR-Inhalte, aus denen der Nutzer je nach Rechenleistung seines Endgerätes auswählen kann:
- Der Server auf dem IPC kann die gewünschte Augmentierung direkt in das Bild rendern und das fertige Ergebnis an den Client senden, der das Bild dann nur noch ausgeben muss. Diese Vorgehensweise eignet sich vor allem für sehr leistungsschwache Endgeräte.
- Die Serverkomponente schickt die errechnete Kamerapose an den Client, die dieser wiederum verwenden kann, um mit Hilfe der WebGL-Technologie die Inhalte selbst ins Bild zu rendern – ausreichende Rechenressourcen vorausgesetzt.
Der gesamte Vorgang der Auslagerung ist nochmals in Bild 4 zusammengefasst. Dunkelblau markiert sind die Bestandteile der Pipeline, die auch in konventionellen, lokal ausgeführten AR-Anwendungen so oder in ähnlicher Form durchlaufen werden müssten, rot hingegen die, die die vorgestellte Architektur impliziert. Hellrote Schritte sind grundsätzlich optional, einen Sonderfall stellt allerdings das Rendering dar, das bisher clientseitig aus- geführt wurde, nun jedoch auch auf dem Server stattfinden kann. Auf die Kodierung und Dekodierung wird im folgenden Kapitel noch genauer eingegangen.

Bild 4 AR-Pipeline für die Auslagerung von Einzelbildern

Bild 4
AR-Pipeline für die Auslagerung von Einzelbildern

4 Echtzeitverhalten

Auf einen Aspekt muss bei AR-Anwendungen besonderes Augenmerk gelegt werden. Zwischen einem Zeitpunkt X in der Realität und dessen augmentierter Darstellung auf dem Display dürfen nur wenige Hundertstelsekunden vergehen. In der Literatur finden sich Angaben, dass die meisten Menschen beim Tragen eines HMD-Gerätes Verzögerungen ab 20 Millisekunden wahrnehmen können [7]. Bei Nicht-Erfüllung dieser Anforderung kann es neben einer bescheidenen User-Experience zu Kopf- und Augenschmerzen oder gar Übelkeit bei den Nutzern kommen.
Die beschriebene Architektur induziert durch die Notwendigkeit der Datenübertragung (Videobild von Client zu Server, augmentiertes Videobild bzw. berechnete Kamerapose von Server zu Client) eine zusätzliche Latenzquelle. Um die entstehenden Verzögerungen möglichst gering zu halten, muss je nach Bandbreite der zur Verfügung stehenden Übertragungsstrecke entschieden werden, ob Video- bilder kodiert oder unkodiert übertragen werden sollen. Verschickt man das Kamerabild nicht-komprimiert, resultiert daraus eine sehr hohe Netto-Datenrate, die gegenwärtige Funklösungen kaum bewältigen können. Die zugehörige Formel lautet:

 Bei einer Auflösung von 960 x 720 Pixeln, einer Farbtiefe von 24 Bit und einer Framerate von 30 Frames pro Sekunde ergibt sich daraus bereits eine Datenrate von knapp 500 MBit pro Sekunde.
Durch Kompression der Einzelbilder beispielsweise mit JPEG kann die Datenrate jedoch deutlich reduziert werden (siehe Bild 5).

Bild 5 Einzelbildgrößen bei verschiedenen Auflösungen und Kompres-sionsstufen

Bild 5
Einzelbildgrößen bei verschiedenen Auflösungen und Kompres-sionsstufen

Seite des Artikels
Autoren

M. Sc. Michael Schneider

Bosch Rexroth AG
Bgm.-Dr.-Nebel-Str. 2
97816 Lohr am Main
Tel.: 0 93 52/18–50 84
E-Mail: michael.schneider10@boschrexroth.de
www.boschrexroth.de

Prof. Dr. Didier Stricker

Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI)
Trippstadter Straße 122
67663 Kaiserslautern
Tel.: 06 31/2 05 75–35 00
E-Mail: didier.stricker@dfki.de
www.dfki.de

Verwandte Artikel

Bildverarbeitung im Automobilbereich boomt

Qualitätsprüfung von zylindrischen Blechteilen durch optische Inspektion

Automobilindustrie profitiert von Machine Vision

Wenn Bildverarbeitung und Pneumatik zusammenarbeiten