3D Objekterkennung mit AR Kit

von Maximilian von Detten und Kevin Pakula

Kontext des Projekts

Augment Reality kennt jeder, ob es nun Spiele wie Pokémon GO, Designapps wie Ikeas Raumgestalter oder Google Maps mit Fußgänger Funktion sind; Bisher waren die AR-Funktionen meist noch ein Gimmick, um Kunden anzuziehen, oft spielt man damit ein wenig herum, genießt wenige kurzweilige Minuten mit den Applikationen, bis man diese letztendlich deinstalliert oder die AR Funktionen gänzlich ignoriert.

Gründe dafür gibt es viele, zum einem funktioniert die AR-Integration nur mit deutlichen Einschränkungen, welche einen zwingen eine Oberfläche zu finden welche vom Gerät möglichst genau erkannt werden kann oder sogar einen QR Code benötigen, zum anderen sind die Funktionen sehr ungewohnt und nicht alltagstauglich. Eigentlich stellt man sich bei dem Begriff “Augment Reality“ großes vor, Interaktionen zwischen der Welt und genutzten Geräten, erweiterte Realitäten, welche Übergangslos zwischen Bildschirm und Objekt aufrechterhalten werden. Doch die Wirklichkeit sieht anders aus, meistens reicht eine leichte Änderung des Winkels oder Lichts und die Illusion bricht zusammen. Interaktionen ohne Objekte oder Geräte, welche spezifisch dafür gestaltet worden sind stellen sich immer noch als Problem heraus. Doch woran liegt das? Ist AR für immer verdammt nur ein Gimmick zu sein oder gibt es Möglichkeiten in Zukunft mehr aus dieser faszinierenden Technologie herauszuholen?

Diese Fragen haben wir uns vor dem Projekt gestellt, nachdem wir uns mit verschiedenen AR-Integrationen beschäftigt hatten. Unser Ziel war es herauszufinden, was mit AR möglich ist und welche Zukunftsweisenden Technologien es mit sich führt oder zu welchen es führen kann. In Zukunft wird es bessere AR Integrationen geben, wie beispielweise Brillen, welche früher oder später alltagstauglich werden. Um diese nutzen zu können muss noch viel an AR gearbeitet werden. Um herauszufinden, was möglich ist wollten wir dieses Projekt machen.

Da wir nicht weit verbreitete Technologien nutzen wollten, sondern an die aktuellen Grenzen von AR gelangen wollten, fiel die klassische 2D-Bilderkennung heraus. Generell mussten wir für unser Projekt einen Ansatz finden, welcher es ermöglicht den Gebrauch und die Funktionalität von AR zu prüfen. Daher beschlossen wir auf der Basis von 3D Objekterkennung, eine Bauanleitung für Steckbausteinsysteme, mit Darstellung des nächsten anzubringendem Elementes, zu entwickeln.

Hintergrundinformationen AR

Die Ursprünge von Augmented Reality gehen zurück bis in die 60er, in welchen die ersten Konzepte zu Head-Mounted Displays entstanden sind. Die ersten industriellen Entwicklungen gab es folgend in den 90ern, dabei wurde das Anzeigen von manuellen Herstellungsprozessen bei Boeing behandelt; hierbei kam es ebenfalls zur Namensgebung der „Augmented Reality“. In den frühen 2000er Jahren wurde AR immer weiter erschlossen und für Enthusiasten nutzbar gemacht, beispielweise gab es bereits im Jahr 2000 AR Quake, welches als erstes AR Computerspiel gilt und die darauffolgenden Jahre boten verschiedene kleinere AR Implementationen, wie AR Tennis und das Nutzen von AR in Werbekampagnen. Auch aus dem Gebiet der VR-Technologie gibt es inzwischen Geräte wie die Oculus Quest, welche beginnen den Bereich der AR-Technologie mit zu nutzen. An spezifischer Hardware für AR wie zum Beispiel der HoloLens oder den diskutierten Apple Glasses wird mittlerweile von verschiedenen Unternehmen gearbeitet, daher ist es nur noch eine Frage der Zeit bis AR effektiv zu unserem Alltag dazugehören wird und nicht nur eine Spielerei darstellt oder Enthusiasten vorenthalten wird. Mit modernen Smartphones wurden mehr Möglichkeiten erschlossen AR zu implementieren, welches von verschiedenen Apps erfolgreich umgesetzt wurde. Durch verschiedene Trends wie zum Beispiel Pokémon GO fiel AR dazu immer mehr in den Fokus der Gesellschaft; laut Bitkom hat 2019 jeder fünfte bereits AR Anwendungen ausprobiert. Dabei werden Firmen wie Apple eine große Rolle spielen, schon heute kann man in ihren Smartphones Innovationen sehen, welche eine solche Zukunft ankündigen, von mehreren Kameras bis zum Nutzen von LiDAR Scannern. Durch die bessere Bilddaten und das 3D Abtasten des Raumes wird mittlerweile eine immer bessere und genauere Einbindung verschiedener AR Features ermöglicht. Inzwischen ist es möglich, in Echtzeit, mithilfe einer App virtuelle Objekte vor oder hinter realen Objekten darzustellen, ohne Erkennungsprobleme zu haben. Daran kann man leicht sehen, dass genutzte Hardware immer besser den Ansprüchen von AR angepasst wird. Die Entwicklung an AR ist ebenfalls leichter geworden, mit Frameworks wie ARKit oder ARCore, womit jeder eigene Apps entwickeln kann. Jedoch gibt es ebenfalls Probleme, welche mit dem Nutzen von AR eingehen, dabei kann es sich nicht nur um Soft und Hardwareprobleme handeln, auch das Behandeln von Daten und Privatsphäre ist ein Gebiet, welches betrachtet werden muss, um den Erfolg dieser Technologie zu garantieren.

Es gibt verschiedenste Einsatzgebiete von AR, von Spielen bis zur Vermessung ist alles zu finden. Es gibt Apps, welche Sternbilder, Objekte und sogar Satelliten am Himmel anzeigen können, genauso wie Maßbänder, welche über die Kamera Objekte vermessen und spezifische Daten herausgeben. Ebenso kommt AR in der Medizin zum Einsatz, beispielweise durch das Anzeigen von Blutgefäßen oder CT Scans. Professioneller Einsatz ist genauso im Ingenieurswesen wie auch in der Luftfahrt möglich, durch das Einblenden von Stromkreisen in Wänden aber auch Rundumblick im Cockpit und HUD für Piloten. Für den Freizeiteinsatz gibt es mittlerweile immer mehr Spielereien, so ist Pokémon GO eine sehr bekannte AR Anwendung, ein sehr kreativer Einsatz wäre Mario Kart Live Home Circuit, welches kleinen Rennautos mit Kameras nutzt, welche einen Raum in eine Rennstrecke verwandeln. Die Rennstrecke als auch Hindernisse werden dabei digital generiert.

Die Implementierung von AR kann über verschiedene Wege Erfolgen. Man kann zum Beispiel spezielle Marker oder flache Oberfläche nutzen, worauf eine Darstellung erfolgt. Mittlerweile kann man aber auch komplexere Erkennung von Objekten für gewünschte Funktionen nutzen, jedoch sind diese Ansätze deutlich aufwendiger. Dafür gibt es verschiedene Möglichkeiten. Zwei davon wären zum einem die Verwendung von Deep Neural Networks, welche mithilfe von Bilderkennung die Objekte erkennen, wie zum Beispiel Vuforia, ein AR SDK. Eine andere Möglichkeit wäre Apples ARKit, einem Framework, welches das Erstellen von AR Apps für Apple Geräte ermöglicht. Dieses produziert intern eine Repräsentation des 3D Objektes, welches versucht wird in der Welt wiederzuerkennen.

Das Nutzen von Augmented Reality setzt bestimmte Bedingungen voraus, so ist es kaum möglich in sehr dunklen Umgebungen zu arbeiten, da unter diesen Umständen keine Objekte erkannt werden können. Jedoch gibt es Hardware, welche spezifisch für AR genutzt werden kann, um auch unter schlechten Bedingungen verwendbar zu sein und generell bessere Leistung zu ermöglichen. So baut Apple seit der aktuellen 12. Hardwaregeneration einen LiDAR Scanner in iPhones und iPads der Spitzenklasse ein. LiDAR steht für Light Detection and Ranging; mithilfe von Lasern kann damit räumliche Tiefe ermittelt werden, indem der Abstand von Objekten in bis zu fünf Metern gemessen wird. Dadurch kann man deutlich präzisere Ergebnisse bei Vermessung und Tiefenerkennung erhalten. Die Leistung von AR kann ebenfalls durch das Nutzen der multiplen Kameras verbessert werden, wodurch beispielweise die Zeit der Raumabtastung reduziert werden kann. Diese Features bieten schnellere und genauere Ergebnisse bei der Raumerkennung, komplexerer Räume, was bisher die größte Barriere beim Nutzen von AR Features darstellte. Dadurch wird nun präzise 3D Repräsentationen nicht nur einer professionellen Umgebung vorenthalten, welche spezifisch dafür entwickelte Developer Hardware nutzt.

Struktur

Grundlegend wollten wir erfahren, an welche Grenzen der normale Verbraucher beim Nutzen von AR stößt; dabei wollten wir uns mehr mit verfügbaren Technologien befassen und wie man diese effektiv einsetzen kann. Zudem wollten wir herausfinden, ob es zum aktuellen Zeitpunkt sinnvoll wäre AR zu verwenden, anstatt einen herkömmlichen Ansatz zu wählen. Da wir bisher nur Erfahrung in 2D Bilderkennungs-AR hatten, mussten wir zuerst erforschen, mit welcher Technik man zu tun hat und welche Voraussetzungen es für die Entwicklung an AR gibt.

Daraufhin setzten wir uns als Ziel 3D Objekterkennung zu verwenden, um ein Steckbausteinmodell zu erkennen und mithilfe der App fehlende Teile anzeigen zu lassen. Der Gedanke dahinter war, dass man dadurch 3D Objekterkennung testen kann, sowie verschiedene Einschränkungen, wie zum Beispiel fehlende Teile oder dem Verdecken von Teilen des Objektes testen kann. Zudem kann man dadurch die Einschränkungen auf Größe und Detailreichtum analysieren, um einen geeigneten Scan zu erzeugen.

Für das Projekt wurde Unity und ARKit genutzt, für das Gestalten von Objekten wurde Blender gebraucht, für den Buildprozess wurde zuletzt XCode verwendet.

Unity wurde gewählt da dies die einfachste Möglichkeit bot, um virtuelle 3D-Objekte darzustellen und per Skript zu modifizieren. Zudem gibt es native Unterstützung von ARCore und ARKit als auch 3rd-Party-Support von Vuforia.

Um XCode zu verwenden war ein Macbook notwendig, die AR Funktionalität wurde auf einem iPhone 11 Pro getestet. Ein iPhone 12 wurde angedacht, jedoch war es während des Projekts nicht möglich dieses zu erhalten.

Am Anfang des Projektes war es geplant eine App auf Android zu entwickeln. Dazu war es angedacht ARCore von Google zu verwenden. Jedoch ist selbst in der aktuellen Variante von ARCore keine Funktionalität zum Object Tracking gegeben. Die einzigen gegebenen Möglichkeiten sind die Plane Detection zum Erkennen von flachen Flächen, welche auch verwendet werden, um den Raum zu erkennen, als auch die Bilderkennung. Wir versuchten die Bilderkennung auszunutzen, indem wir ein Foto des Objektes aufnahmen und anhand dessen versuchten das Objekt aus demselben Winkel wieder zu erkennen. Dies schlug jedoch fehl, da die Bilderkennung zuerst darauf wartet, dass eine flache Fläche von der Plane Detection erkannt wird, um dann auf dieser nach dem Bild zu suchen.

Vuforia wurde von Vorhinein ausgeschlossen, da es einerseits keine frei verfügbare Technologie nutzt, sondern hinter einer Paywall ist, andererseits ist der Ansatz der Erkennung aus 2D Bildmaterial mit Deep Neural Networks nicht zukunftsfähig, da die Erkennung einfach nur mit roher CPU-Leistung erfolgt. Da die Steigerung der CPU-Fähigkeiten in absehbarer Zukunft vorerst abflachen wird besitzt dieser Ansatz keine langfristige Zukunftstauglichkeit.

Deswegen beschlossen wir Apples ARKit zusammen mit einem geeigneten mobilen Apple Gerät zu verwenden, da dieses native Unterstützung von 3D-Objekt Tracking seit ARKit 3 besitzt. Nachteile daran waren, dass man zum Aufsetzen der App einen Mac benötigt, welcher ausgeliehen werden musste. Wir wollten ein iPhone 12 oder äquivalentes iPad nutzen, um den LiDAR Scanner zusätzlich nutzen zu können, als dies nicht möglich war versuchten wir an anderen iPhones zu gelangen. Die uns zur Verfügung stehenden Geräte waren schlussendlich ein iPhone SE und iPhone 11 Pro. Sofern ein iPhone 12 pro gegeben wäre, hätten wir dieses ebenfalls versucht in unsere Tests einzubinden.

Als wir die Hard und Software festgelegt hatten, ging es daran Scans von Objekten herzustellen, um die 3D Objekterkennung zu testen. Dazu nutzten wir eine von Apple gegebene App zum Scannen von 3D Objekten. Nachdem wir grundlegende Bedingungen für einen erfolgreichen Scan feststellen konnten, versuchten wir diese Informationen dann zu verwenden, um einen Scan, von einem Modell, für unsere Bauanleitung, zu erstellen. Um an diesem Scan die Phantomsteckbausteine darstellen zu können, modellierten wir einen Teil des Modells in Blender nach und platzierten dieses digital an dem Scan. Schlussendlich testeten wir, wie genau die Position des Scans erfasst wird, um die Virtuellen Bauteile darzustellen. Anhand dessen versuchten wir die Ergebnisse auszuwerten und gegebenenfalls die Positionen anzupassen. Zuletzt teilten wir die Bauanleitung in die einzelnen Schritte auf, um das Modell mithilfe der App aufbauen zu können.

Nachdem die App fertig entwickelt war, testeten wir noch weiter die Performance der Erkennung unter verschiedenen Bedingungen und versuchten den initialen Scan noch weiter zu verbessern.

Implementation und Basic Setup 

Aufsetzen des 3D Scanners

Um 3D-Objekterkennung testen zu können ist es möglich verschiedene Applikationen zu nutzen. Eine der besten Umsetzungen davon findet man bei der Apple Developer Dokumentation:

https://developer.apple.com/documentation/arkit/content_anchors/scanning_and_detecting_3d_objects

Hier kann man einen 3D Objektscanner testen. Zum Verwenden muss man das Beispielprojekt herunterladen und mithilfe von XCode builden. Dazu benötigt man ein geeignetes Gerät, welches mindestens einen A9 Prozessor oder höher besitzt, wie in unserem Beispiel ein iPhone 11 Pro. Wenn man das Projekt aufsetzt besteht die Möglichkeit, dass ein Fehler zum Code-Signing geworfen wird; um diesen zu beheben muss man über das Projektverzeichnis auf „Signing and Capabilities“, dort kann man dann ein Team zuweisen.

Die Scanner App funktioniert wie folgt:

In dem ersten Schritt setzt man eine Box um das zu scannende Objekt und sofern alle Maße stimmen kann man den Scan starten und beobachten, wie an allen Seiten Punkte definiert werden, welche zu Objekterkennung dienen. Nach dem Scan kann man entweder einen neuen Scan starten und diesen mit vorherigem Kombinieren oder fortfahren. Beim Kombinieren ist zu beachten, dass unter Umständen das Resultat nicht mehr genau genug ist und beim Nutzen des Scans dadurch Zittern und Anzeigeprobleme entstehen. Zuletzt kann man den Ursprung des Objektes anpassen und es als ARReferenceObject exportieren. Ein ARReferenceObject wird definiert als die digitale Repräsentation eines realen 3D Objektes, welches von ARKit verlangt wird, um es in der Umgebung zu erkennen. Dieses besteht aus den einzelnen Featurepoints und dem dazugehörigen Ursprung.

Umsetzung und Aufsetzen unserer App

Im ersten Schritt muss im Package Manager die für AR nötigen Pakete installiert werden.

Um diese anzuzeigen muss man links oben „Packages: All“ auswählen, und um eine ausreichend aktuelle Version zu erhalten rechts oben die Preview Packages auswählen.

Man benötigt ARFoundation 4.+, ARSubsytems 4.+, und ARKit XR Plugin 4.+.

Unter den Build Settings (File -> Build) muss die Plattform auf iOS gewechselt werden.

Bei den Player Settings muss unter dem Punkt „XR-Plugin“ ARKit aktiviert werden.

Zudem muss ARKit als „required“ angegeben und FaceTracking deaktiviert werden.

Bei dem Unterpunkt „Player“ muss ein Bundle Identifier angegeben werden und in der Camera Usage Description etwas angegeben werden, damit Zugriff auf die Kamera möglich ist.

Zunächst erstellt man unter XR eine Reference Object Library.

Zudem fügt man den erstellten Scan dem Projekt hinzu. Wenn alles richtig aufgesetzt wurde, gibt es zu diesem ein Vorschaubild.

In der Reference Object Libary fügt man ein neues Objekt hinzu, gibt diesem einen Namen und referenziert den Scan. Dieser Scan steht nun zur Verfügung.

Als nächste wählt man die Kamera in der Szene aus und verwandelt diese zu einem XR Rig.

Diesem XRRig fügt man ein AR Session Origin und ein AR Tracked Object Manager hinzu. Dem AR Session Origin gibt man die Referenz zu der Kamera, und dem AR Tracked Object Manager die Referenz der erstellten Reference Object Library.

Zudem erstellt man ein leeres Spielobjekt und fügt diesem eine ARSession und einen AR Input Manager hinzu.

Der Kamera fügt man einen ARCameraBackground hinzu, damit der Kamerafeed als Skybox verwendet wird.

Schlussendlich erstellt man das Objekt, welches man an dem Scan dargestellt haben will. In diesem Tutorial verwende ich dafür einen Default Cube. Diesen speichert man als Prefab ab.

Dieses Prefab referenziert man im AR Tracked Object Manager, der sich an dem XRRig befindet. Damit ist die Szene bereit, um mit AR Objekterkennung zu arbeiten.

Nachdem die App erstellt wurde, wird das im AR Tracked Object Manager angegebene Prefab an der Position des erkannten Scans erzeugt, sobald das gescannte Objekt in dem Kamerablickfeld erkannt wird. Diese Position wird auch weiterhin aktualisiert, solange das Gerät das Objekt weiterhin erkennt. Insofern das Objekt vom Scan nicht erkannt wird, bleibt das Prefab an der zuletzt erkannten Position und bleibt an seiner Position im Raum zurück.

Funktionen und Ablauf unserer App

Bei unserer App richtet man die Kamera auf ein Lego Modell aus, welches als Referenzobjekt gespeichert wurde, sobald das Modell erkannt wird werden die fehlenden Teile auf dem Modell angezeigt. Die Teile wurden auf den korrekten Positionen gespeichert, jedoch ist in verschiedenen Tests aufgefallen, dass diese nicht in jedem Durchlauf gleich angezeigt werden. Daher haben wir Knöpfe eingebaut, welche die Position oder Rotation auf den Achsen anpassen können. Sobald die initiale Position stimmt kann man das gewünschte Teil platzieren und danach mithilfe der Pfeiltasten zum nächsten Teil wechseln. Dieses wird dann an seiner entsprechenden Position angezeigt.

Ergebnisse und Probleme

Zeit und Offset der Erkennung

Ablauf unserer Tests:

Um die Performance der 3D-Objekterkennung zu testen bauten wir einen simplen Versuchsaufbau auf. Dazu verwendet wurden eine Softbox, welche an einem Stativ aufgehängt wurde, ein Handystativ, neutralgraue Pappe, dem iPhone 11 Pro und das Scan-Testobjekt.

Die Pappe wurde als Untergrund genutzt, da wir den Scan nicht mit Umgebungsdetails verfälschen wollten, darauf wurde das Objekt platziert. Über diesem wurde die Softbox an einem Stativ angebracht, um gleichmäßige Lichtverhältnisse zu garantieren, welche ohne Schatten von einer Seite aus sein sollten. Zudem wurde das Handy einmal an einem Stativ angebracht, das andere Mal wurde es Handheld genutzt.

Getestet wurden Zeit zur Erkennung, Position (X, Y, Z) und Rotation (X, Y, Z) der virtuellen Bauteile, im Vergleich zum Ursprung. Dazu wurde die Kamera des Handys auf das Objekt gerichtet und nach dem Starten der App die Zeit gemessen, bis das Objekt erkannt wurde. Daraufhin wurden die Position und Rotation der virtuellen Bauteile manuell an die korrekte Stelle des Modells verschoben. Die einzelnen Tests verliefen einmal von einem festen Punkt aus, wozu ein Handystativ genutzt wurde, das andere Mal wurde das Handy in der Hand gehalten und auf das Objekt gezielt.

Ergebnisse unserer Tests:

Diese Tabelle stellt die Messwerte für Stativ und Handheld Messung da


Aus den Ergebnissen der Tabelle können folgende Boxplots und Diagramme erstellt werden:

Schlussfolgerungen unserer Tests:

In den, aus den Tests gezogenen Werten, gab es einige aussagekräftige Muster. Wenn man Position und Rotation betrachtet, schwanken die Werte beim Handheld Gebrauch deutlich mehr, während beim Stativ diese Werte konsistenter sind. Wir vermuten, dass dies daran liegt, dass beim Stativ die Position nie geändert werden musste und daher immer dieselben Punkte zur Erkennung dienen konnten. Beim Handheld Gebrauch veränderten sich diese Werte durch das leichte Schwanken der Hand und dem dadurch veränderten Blickwinkel.

Auffällig bei Position und Rotation sind zum einen, dass durch das Drehen des Objektes oder Veränderung der Kameraposition die Position und Rotation sehr stark beeinflusst werden. Da andere Punkte des Objektes für das Tracking genutzt werden kann dies starke Auswirkungen auf die virtuelle Darstellung haben. Dies ist uns bei allen unserer Scans aufgefallen. Dies könnte an der Art und Weise des Scannens liegen, da man einen Würfel nutzt, um die Punkte der Objekte zu sammeln und daher die Punkte anhand der 5 sichtbaren Seiten ausgerichtet sind. Anhand der starken Positionsschwankungen zwischen den einzelnen Handheld Versuchen, trotz nahezu identischer Position, kann man erkennen, dass die Scans keine exakte Repräsentation des realen Modells sind, sondern in sich verzogen ist, was zur Folge hat, dass je nach Blickwinkel das Objekt an einer leicht veränderten Position erkannt wird. Der stärkste Unterschied tritt hierbei auf wenn man von einer Scanseite zu einer anderen wechselt.

Betrachtet man nun die Zeit anstelle der Position fällt auf, dass bis auf kleinere Ausnahmen Handheld das Objekt schneller erkannt wird als par Stativ, dies ist uns genauso während unserer Entwicklung aufgefallen, da das Objekt schneller erkannt wurde, wenn man die Kamera nicht statisch hat. Wir vermuten, dass dies daran liegt, dass durch Bewegen des Gerätes mehr Punkte erkennbar gemacht werden und daher die Erkennung schneller erfolgt.

Bei diesem Versuch haben wir nur eine Seite des Objektes betrachtet, dies erschwerte die Platzierung an der genauen Position, da keine Tiefenwahrnehmung auf dem Bildschirm möglich war. Da jedoch der Scan in jedem Fall in sich verzogen ist, war es nicht möglich durch Triangulation die fehlende Tiefenwahrnehmung zu ersetzen.

Einfluss Licht und Abdeckung

Optimale Lichtbedingungen für den Scan wurden von Apple zwar angegeben, bei unseren Tests konnten wir jedoch weitere Eigenschaften feststellen. Uns ist aufgefallen, dass das beste Licht umfassendes Tageslicht wäre, da dadurch die Objekte gut ausgeleuchtet werden und weder viele Schatten noch Reflektionen auftreten. Einer Softbox ist eine Alternative, hierbei ist jedoch zu beachten, dass durch den stärkeren direkten Lichteinfall es zu auffälligeren Schatten und Reflektionen kommen kann, diese sollten wenn möglich vermieden werden. Auch das Verwenden von mehreren, in unserem Fall 8, normalen Lampen, die direkt von verschiedenen Winkeln auf das Modell gerichtet sind, führt zu akzeptablen Scanergebnissen.

Sobald der Scan erkannt wurde besteht die Möglichkeit, dass das Objekt nicht vollständig ist oder von anderen Objekten verdeckt wird und dennoch erkannt wird. Dabei ist uns aufgefallen, dass beim initialen Erkennen das Objekt möglichst genau erkennbar sein sollte, dazu zählt auch ausreichende Beleuchtung, jedoch nach dem Erkennen die Position verändert werden kann und das Objekt zum Teil verdeckt werden kann und es dennoch weiterhin verfolgt wird. Diese Verfolgung benötigt jedoch je nach Scanqualität und Lichtverhältnissen ein paar Millisekunden bis zu einzelnen Sekunden. Genaue Angaben wurden in unseren Versuchen jedoch nicht getestet.

Optimale Objekte

Optimale Objekte müssen viele Details besitzen, da dadurch mehr Punkte genau gesetzt werden können welche für das Tracking genutzt werden können. Eine Weiße Fläche zu Beispiel enthält keine Stellen, welche als Punkte genutzt werden können in Abhängigkeit zum restlichen Objekt. Diese Details müssen zudem einzigartige Punkte sein, da sich wiederholende Muster durch die wiederholende Struktur nicht als Einzigartig eingeordnet werden können. Dadurch ist es möglich, dass Probleme beim Platzieren und Erkennen der Punkte entstehen. Die Objekte sollten zudem keine reflektierenden Oberflächen enthalten, da diese zu anderen Umgebungsbedingungen ein anderes Erscheinen haben und damit das Aussehen des Modells verändern. Dies erschwert die Erkennung jedoch stark, teilweise ist die Erkennung sogar unmöglich.

Als Featurepoints zählen Kanten, Texturwechsel, Übergänge und Ähnliches. Ein beispielweise nahezu Ideales Objekt ist eine Ananas. Diese besitzt eine sehr detaillierte Struktur mit vielen Kanten, viele Farbwechsel auf der Oberfläche, als auch eine gänzlich Matte Oberfläche.

Schlusswort

Mit heutigen Möglichkeiten lässt sich bereits vieles mit AR machen, sei es mit 2D oder 3D Tracking. Für beide Möglichkeiten gibt es verschiedene Umsetzungsmöglichkeiten, welche teilweise rechenlastig und andere hardwareabhängig sind. Mit Optimalen Bedingungen und Objekten kann man bereits heute spektakuläre Dinge erreichen, jedoch muss an der Präzision noch viel gearbeitet werden. Uns hätte es gefreut, wäre Hardware mit LiDAR Scannern verfügbar gewesen, dadurch wären präzisere Ergebnisse möglich gewesen, jedoch können wir zum aktuellen Zeitpunkt nur spekulieren, wie stark der Einfluss davon wäre. Wahrscheinlich wären Messungen präziser, da der Erkennung neben den zweidimensionalen Bilddaten noch die dritte Dimension als Tiefendaten zur Verfügung steht. Auch ohne diese Technologie konnten wir ein Prototyp erstellen, welcher einem bei kleineren Bauanleitungen helfen kann und die Eigenschaften von AR gut nutzen kann. Der Umstieg davon, anhand von 2D Bildern 3D Objekte zu analysieren, und Objekte per Abtastung direkt dreidimensional zu erkennen kann ein großer Sprung für Augmentive Reality sein; In Zukunft können dadurch Projekte wie die Apple Glasses möglicherweise einen ähnlichen Einfluss ausüben wie zum Beispiel Smartwatches einen Weg in unseren Alltag finden.

Referenzen:

AR bei Apple:

https://www.apple.com/de/newsroom/2020/03/apple-unveils-new-ipad-pro-with-lidar-scanner-and-trackpad-support-in-ipados/

https://www.apple.com/de/augmented-reality/

https://developer.apple.com/augmented-reality/arkit/

https://developer.apple.com/documentation/arkit/content_anchors/scanning_and_detecting_3d_objects

Vuforia – 3D Objekterkennung:

https://library.vuforia.com/

AR Spiel in der Geschichte:

http://www.tinmith.net/arquake/

https://ir.canterbury.ac.nz/bitstream/handle/10092/2342/12605408_2006-SIGGRAPH-ARTennis.pdf?sequence=1

https://www.pokemongo.com/de-de/

https://mklive.nintendo.com/

Praktische Anwendungen AR:

https://tweakers.net/files/upload/329676148-Augmented-Reality-An-Application-of-Heads-Up-Display-Technology-to-Manual-Manufacturing-Processes.pdf

https://redshift.autodesk.com/augmented-reality-in-construction/

https://www.airspacemag.com/military-aviation/super-helmet-180964342

https://pubs.rsna.org/doi/full/10.1148/radiol.2401040018

Datenschutz und AR:

https://www.analyticsinsight.net/spiking-augmented-reality-draws-flak-augmented-privacy/

Statistik zur AR Nutzung:

https://www.bitkom.org/Presse/Presseinformation/Fuenfte-Augmented-Reality-Anwendungen-ausprobiert

Verkehrserkennung mit Neuronalen Netzen

Einleitung

Hast du beim Lernen auch schon einmal gelangweilt aus dem Fenster geschaut und die vorbeifahrenden Autos gezählt? Auf wie viele Autos bist du dabei genau gekommen und war diese Zahl vielleicht auch vom Wochentag oder der Uhrzeit abhängig?
In unserem Projekt haben wir versucht diese Frage zu beantworten.
Dafür haben wir mittels Maschinellem Lernen, auch als “Machine Learning” bezeichnet, ein Neuronales Netz trainiert, welches bei einer Videoaufzeichnung einer Kreuzung verschiedene Verkehrsteilnehmer erkennen kann. 
Unser Ziel war es, durch eine Zählung bestimmen zu können, wie viele und welche Art von Fahrzeugen die Kreuzung in einem bestimmten Zeitraum passieren.

Problemstellung

Wie viele Autos passieren eine Kreuzung? Handelt es sich hauptsächlich um Autos oder gibt es auch andere Fahrzeuge, die die Kreuzung passieren und wie hoch ist die dadurch resultierende potentielle Lärmbelastung? Um all diese Fragen klären zu können, wäre es von Vorteil, wenn man wüsste, wie viele Fahrzeuge an der ausgesuchten Teilstrecke vorbeifahren. Wir haben probiert, genau das, nur mit Hilfe von Videos, herauszufinden.

Lösungsansatz

Wir entschieden uns, ein vortrainiertes Neuronales Netz auf Basis der YOLO-Architektur anzupassen und mit unseren Daten weiter zu trainieren. YOLO ist ein Echtzeit-Objekterkennungssystem, welches ein einzelnes Neuronales Netz auf ein komplettes Bild anwendet [1].

Vorverarbeitung der Bilder bzw. Videos

Nacht-Videos aussortieren und verteilen 

Um das Projekt durchführen zu können, hatten wir einige Videoaufnahmen einer Kreuzung von Herrn Prof. Kriha erhalten. Die Aufnahmen zeigen eine Kreuzung, wie in Abbildung 1 zu sehen, welche zu unterschiedlichen Uhrzeiten gefilmt wurde. Wir entschieden uns, das Netz erst einmal mit Aufnahmen bei Tag zu trainieren, da die Fahrzeuge auf diesen Aufnahmen deutlicher zu erkennen sind und damit besser zuordenbar. Aus diesem Grund sortierten wir alle Nachtaufnahmen aus und verteilten die restlichen Videos auf alle Teilnehmer der Projektarbeit, um den Aufwand für das spätere Labeln der Bilder untereinander aufzuteilen.

Abbildung 1: Kreuzung ohne Fahrzeuge

Bilder aus Videos extrahieren

Da man das Neuronale Netz nicht mit Videoaufnahmen trainieren kann, mussten wir aus den Videos zunächst einzelne Bilder generieren. Dazu erstellten wir über 500 Screenshots, welche die verschiedenen Fahrzeuge an unterschiedlichen Positionen zeigen.

Labeln der Bilder

Um das Netz trainieren zu können, muss man die Bilder zunächst labeln. Hierfür verwendeten wir die Software “VGG Image Annotator” [2]. Direkt zu Beginn des Projektes einigten wir uns auf alle Fahrzeugtypen, die unser Netz erkennen sollte. Hierzu gehören:

  • PKW
  • LKW
  • Traktor
  • Motorrad
  • Fahrrad
  • Sonstiges (z. B. E-Scooter, Inlineskater)

Abbildung 2: Annotator Attributauswahl

In der Software kann man verschiedene Labels anlegen, welche nach den Fahrzeugkategorien benannt sind. In Abbildung 2 sieht man, wie die verschiedenen IDs, also die Label-Kategorien, angelegt werden. Ein Objekt kann man kennzeichnen, indem man mit Hilfe der Software ein Rechteck auf das Objekt legt und die jeweilige Bezeichnung – durch Klicken auf den passenden Radiobutton – angibt. Die Positionen der Rechtecke werden dann zusätzlich zu den Bildern als CSV abgespeichert und können so später fürs Training verwendet werden.

Augmentation

Da es nicht möglich ist, für jedes Szenario in der realen Welt ein Bild zu kreieren, mit dem man später trainieren kann, behalfen wir uns hier der Bild-Augmentation, um den aktuellen Trainingssatz zu diversifizieren. Dabei werden alle Bilder auf eine quadratische Größe von 512 x 512 Pixel skaliert und der Kontrast normalisiert. Im Anschluss gibt es eine 50 prozentige Chance, dass ein Bild horizontal und/ oder vertikal gespiegelt wird. Bei diesen Arten der Augmentation muss man aufpassen, dass die Label-Rechtecke korrekt mit skaliert und -rotiert werden. In Abbildung 3 sieht man ein Beispiel eines augmentierten Bildes.

Abbildung 3: Augementiertes Bild

Der Datensatz wurde anschließend in einen Trainingssatz und einen Testsatz aufgespalten. Wie der Name bereits impliziert, wird der Trainingssatz lediglich zum Trainieren des Netzes verwendet. Den Testsatz bekommt das Netz während des Trainings nie zu sehen. Erst am Ende wird dieser zur Verifizierung und Bewertung der Ergebnisse verwendet. 

Neuronales Netz

Ein Neuronales Netz ist ein Verbund von Neuronen, dessen Parameter durch Training angepasst werden. Übliche Trainingsziele sind die Klassifikation, Replikation oder allgemein die Abstraktion der Eingangsdaten. Besonders die Klassifikation spielt in unserem Fall der Objekterkennung eine besondere Rolle.

Architektur

Bei der Entscheidung, welche Netzarchitektur wir für unser Projekt verwenden wollten, gab es die Auswahl zwischen dem Region Based Convolutional Neural Network (R-CNN) und dem “You Only Look Once” Netz (YOLO). Ein R-CNN durchläuft ein Bild zweimal. Im ersten Durchlauf schlägt es “Regions of Interest” vor, welche im zweiten Durchlauf verfeinert und klassifiziert werden. YOLO geht einen völlig anderen Weg und schaut nur ein einziges Mal auf ein Bild. Dabei wird das Bild in Zellen unterteilt welche anschließend sogenannte Bounding Boxes vorhersagen, die ein Objekt umschließen sollen. Auch wird die “confidence” angeben, die zeigt, wie sicher das Netz ist, wirklich ein Objekt umschlossen zu haben. Parallel dazu erstellt jede Zelle eine Klassifikation. In unserem Fall wäre es die Unterscheidung, ob es ein PKW, LKW oder ein anderes Fahrzeug ist. Im letzten Schritt werden beide Ergebnisse miteinander vereinigt und es entsteht die finale Vorhersage (siehe Abbildung 4).

Abbildung 4: Modell des YOLO-Netzes [3]

Wir haben uns für die YOLO Architektur entschieden, weil sie im Vergleich zum R-CNN schneller arbeitet, auch wenn sie nicht so präzise ist. Das zu analysierende Material sind Videos mit 25 Bildern pro Sekunde und wenn man es in Echtzeit verarbeiten wollte, ist die Geschwindigkeit wichtiger als die Genauigkeit.

Um nicht komplett von Null anzufangen, übernahmen wir eine YOLOV2-Implementierung mit bereits trainierten Gewichten basierend auf dem COCO Datensatz. Die letzte Schicht des Netzes wurde dann mit unseren eigenen Trainingsbildern trainiert.

Training

Das verwendete Netz, basierend auf der YOLO Architektur [4], wird überwacht trainiert. Während des Trainings erzeugt es für jede Bildeingabe eine Ausgabe pro erkanntem Objekt, welche aus den vier Koordinaten der Bounding Box und einem Label, das angibt, um was für ein Vehikel es sich handelt, besteht. Diese Ausgabe wird nun mit den zuvor gelabelten Rechtecken des Eingabebildes verglichen und ein Loss-Wert errechnet. Mittels Backpropagation werden der Gradient von jedem Neuron neu berechnet und die Gewichte angepasst. Nach jeder Wiederholung des Prozesses mit denselben Eingabebildern, sollte sich die Ausgabe den wahren Werten immer weiter annähern. Das Netz lernt.

In Abbildung 5 ist ein Trainingsvorgang veranschaulicht. Die Y-Achse zeigt den Loss-Wert an, die X-Achse die Epochen. Eine Epoche ist ein gesamter Durchlauf mit allen Trainingsbildern. Der orange Graph zeigt den Loss-Wert der Testbilder mit den zum Zeitpunkt x errechneten Gewichten des Netzes an, während der blaue Graph für den Loss-Wert auf den Trainingsbildern steht. Man kann erkennen, dass der Loss in den ersten Epochen sehr schnell abnimmt und sich ab der 200. Epoche kaum noch verbessert.

Abbildung 5: Loss-Verlauf bei Training mit 1.000 Epochen

Dem fertig trainierten Netz übergaben wir einige Testbilder, um zu sehen, ob es vernünftige Ausgaben liefern konnte. Wie in den Abbildungen 6 bis 9 zu sehen ist, kann das Netz verschiedene Vehikel erkennen und auch die Klasse richtig einordnen. Des Weiteren ist es in der Lage, verdeckte Objekte wie die Autos in Abbildung 7 und 8, welche teilweise von Pflanzen verdeckt werden, zu identifizieren. 

Es bleibt noch anzumerken, dass die Ausgabe der Rechtecke nicht ganz unseren Erwartungen entsprach. Zwar wurden die Vehikel mit großer Wahrscheinlichkeit erkannt und korrekt zugeordnet, jedoch waren die Bounding Boxen zu groß und entsprachen nicht unseren gelabelten Trainingsbildern. Dennoch konnten wir mit den Ergebnissen weiterarbeiten, weil nur der Mittelpunkt der Rechtecke für die Zählung wichtig ist. Diesen Mittelpunkt kann man aus den Eckpunkten des Rechtecks berechnen, dabei spielte es keine Rolle wie groß die Dimensionen sind.

Zählung der Fahrzeuge

Bevor wir beginnen konnten die vorbeifahrenden Fahrzeuge zu zählen, mussten wir in der Lage sein, ein bestimmtes Fahrzeug während des Vorbeifahrens zu tracken. Das ist nötig, da das neuronale Netz eigentlich keine Videos direkt verarbeiten kann. Stattdessen wird das Video in die einzelnen Bilder zerlegt und Bild für Bild verarbeitet. In einem ersten Schritt haben wir dabei jeweils die vorher erwähnten Mittelpunkte eines jeden erkannten Fahrzeugs in passender Farbe, je nachdem welcher Typ erkannt wurde, in jedes einzelne Bild gezeichnet und anschließend wieder zu einem Video zusammengesetzt. Das Ergebnis zeigt, dass das Netz in der Lage ist, ein Fahrzeug zu “verfolgen” wie in Video 1 zu sehen.

Video 1: Fahrzeug-Tracking mit unserem Netz

Um ein vorbeifahrende Auto als nur ein einziges Fahrzeug zu werten und zu zählen, verglichen wir die Mittelpunkte der erkannten Fahrzeuge zwischen zwei nachfolgenden Bildern eines Videos und ordneten diese, wenn möglich, einem bereits im ersten Bild erkannten Fahrzeug zu. Hierfür verwendeten wir einen Centroid (z. Dt. Schwerpunkt, hier der Mittelpunkt der erkannten Fahrzeuge) Tracking-Algorithmus [5]. Dieser ordnet Fahrzeuge auf einem neuen Bild zu bereits erkanntem Fahrzeugen zu oder registriert sie als neue Fahrzeuge. Dieser merkt auch, wenn Fahrzeuge wieder verschwunden sind und löscht diese aus den als “aktuell im Bild befindlich” registrierten Fahrzeugen. 

Nachdem wir in der Lage waren, ein vorbeifahrendes Fahrzeug über den Zeitraum, in dem es im Video auftaucht, als ein einziges Fahrzeug zu werten, musste als nächstes festgelegt werden, wann wir ein Fahrzeug zählen. Zwar konnten wir Fahrzeuge relativ genau zuordnen, würde man jedoch einfach die Zahl aller einzigartig erkannten Fahrzeuge betrachten, so wäre die Zahl viel zu hoch. Das liegt daran, dass Fahrzeuge am Rand der Bilder teils nicht so gut erkannt werden oder z. B. lang genug von einem anderen verdeckt sind und anschließend als neues Fahrzeug registriert werden. Das lässt sich nicht wirklich verhindern. Auch werden bei großen Fahrzeugen manchmal fälschlicherweise zusätzlich Fahrzeuge erkannt (siehe Abbildung 10). So wird, auch wenn ein zusätzliches Fahrzeug nur in einem einzelnen Bild erkannt wurde, die Zahl der insgesamt erkannten Fahrzeuge hochgetrieben.

Abbildung 10: Das Netz erkennt zusätzlich zum Traktor noch zwei LKWs

Es ergibt also Sinn, an einer Stelle zu zählen, an der alles gut sichtbar ist und das Netz sehr genau Fahrzeuge erkennt, damit diese möglichst genau gezählt werden. Dafür haben wir relativ mittig im Bild einen runden Bereich definiert, den die Fahrzeuge durchqueren müssen, um gezählt zu werden, siehe Abbildung 11.

Abbildung 11: Kreis, in dem Fahrzeuge gezählt werden und Fahrtverlauf aller Autos

Jedes erkannte Fahrzeug bekommt in unserem Tracking-Algorithmus dabei eine Variable, die den Status des Fahrzeug angibt. Dabei wird unterschieden zwischen “ist nicht im Kreis”, “ist im Kreis” und “war im Kreis”. Nach jedem Update, also nach jedem verarbeiteten Bild, wird für jedes in diesem Moment erkannte Fahrzeug überprüft, ob es sich im Kreis befindet und der Status entsprechend angepasst. Wechselt dieser dabei von “ist im Kreis” zu “war im Kreis”, dann wird das Fahrzeug gezählt, also beim Verlassen des Kreises. Um sicherzustellen, dass alle Fahrzeuge auch “durch den Kreis” fahren, liegt dieser zwangsweise an einer Stelle an, bei der Fahrzeuge von Pflanzen verdeckt werden können. Dies hat zur Folge, dass manche Fahrzeuge bereits nicht mehr erkannt werden, obwohl sie den Kreis noch nicht verlassen haben und folglich nie gezählt werden. Daraus folgte die Entscheidung, auch Fahrzeuge zu zählen, die verschwinden, während sie sich im Kreis befinden. Das führt dazu, dass im Schnitt zu viele Fahrzeuge erkannt werden, siehe Video 2. Allerdings ist in unseren Tests die Anzahl der gezählten Fahrzeuge dadurch sehr viel näher an der tatsächlichen Anzahl der vorbeifahrenden Fahrzeuge.

Video 2: Ein Auto wird fälschlicherweise drei Mal gezählt

Sobald ein Fahrzeug gezählt wird, werden Informationen wie der genaue Zeitpunkt und die Art des Fahrzeugs in eine Liste geschrieben und zur Weiterverarbeitung als CSV-Datei gespeichert. Zur Veranschaulichung haben wir auch die Counter der verschiedenen Fahrzeuge mit in das Video eingefügt, siehe Video 3.

Video 3: Ausschnitt eines fertig verarbeiteten Videos

Ergebnis

Wir konnten die Ziele, welche wir uns am Anfang gesetzt haben, erfolgreich umsetzen. Das Netz ist in der Lage, verschiedene Verkehrsteilnehmer zu erkennen und zu kategorisieren. Zusätzlich wäre es performant genug, die Erkennung und Zählung in Echtzeit durchzuführen.

Die Klassifizierung der Fahrzeuge hat zwar generell funktioniert, aber wäre durch mehr gelabelte Bildern von nicht-PKWs vermutlich sehr viel besser gewesen. Eine weitere Sache, die sich im Nachhinein als suboptimal herausstellte, ist, dass wir bei Landwirtschaftsfahrzeugen jeweils nur das Zugfahrzeug labelten. Das führte dazu, dass das Netz Probleme hatte, Anhänger zu erkennen und oft zusätzlich mehrfach LKWs erkannte, siehe Abbildung 10. 

Die Zählung wäre abgesehen von teils fehlerhafter Klassifizierung und dem Erkennen zusätzlicher nicht vorhandener Fahrzeuge, einfacher und potenziell genauer gewesen, wäre die Kreuzung aus einem anderen Winkel gefilmt worden. Der Umstand, dass ein für die Zählung relevanter Bildteil direkt an eine “Bildkante”, an der Fahrzeuge verschwinden, angrenzt, erschwert die genaue Zählung immens. Wenn Teile einer Pflanze im Kreis hingen, führte das oft dazu, dass ein Fahrzeug nicht mehr erkannt wurde, während es verdeckt war, dann aber erneut erkannt und anschließend aufgrund unsere Entscheidung im Bild, verschwindende Fahrzeuge zu werten, doppelt gezählt wurde.

Wie lässt sich das Projekt fortführen?

Nach dem Abschluss des Projektes gibt es noch eine Vielzahl an Möglichkeiten, das Projekt weiterzuführen. Zum einen kann man den gesamten Video-Datensatz des Netzes bearbeiten lassen, danach durchgehen und anschließend statistisch auswerten.

Es wäre auch möglich, das Netz mit dem Videomaterial einer anderen Straße zu trainieren. Oder unseren Datensatz mit nicht-PKWs zu erweitern und bspw. die nicht optimal gelabelten Traktoren zu ersetzen. Ein anderer Ansatz wäre, alle Fahrzeuge mit dem gleichen Label zu versehen und damit das Netz zu trainieren. Anschließend könnte man bewerten, wie sich das Ergebnis verändert.

Neben der YOLO-Architektur gibt es auch noch die Single Shot Detector-Architektur, welche eine ähnlich Performance bietet. Es wäre interessant herauszufinden, was für diese Problemstellung besser ist, sei es in Sachen Geschwindigkeit oder Präzision. 

Referenzen

[1] https://deepdataocean.ai/de/deep-learning/yolo
[2] https://annotate.officialstatistics.org/
[3] https://towardsdatascience.com/yolo-you-only-look-once-real-time-object-detection-explained-492dc9230006
[4] https://github.com/jmpap/YOLOV2-Tensorflow-2.0
[5] https://www.pyimagesearch.com/2018/07/23/simple-object-tracking-with-opencv/

Danke an alle Teammitglieder

  • Niklas Henrich
  • Florian Huynh
  • Lukas Joraschek
  • Anke Müller
  • Leah Fuchs

Monitoring with the Elastic Stack

Netflix, stackoverflow and Linkedin are just a few of the companies activly using the Elastic Stack. Use cases include performance and security monitoring or log analytics. [1] The Elastic Stack consists of different products with the most popular ones being Elasticsearch, Kibana, Logstash and Beats. This article will introduce the different products and explain the architectural concepts behind Elasticsearch that make it the scaleable and high available search engine which it is today.

READ MORE NOW

Project NewsDrop – Gaming News App for Android

newsdrop logo

Introduction

Why NewsDrop?

All of us know, bad web apps. Especially for news environments. With their bad user interface and incorrect behavior. We do too.Therefore we created NewsDrop. 

Different roles

NewsDrop consisted of three main parts. Firstly, the front-end, including our Android app and web application, which we wanted to provide the user with a pure app experience. Secondly, our editorial team, which created content and then delivered it to users. And last but not least, our backend, which was completely implemented with Firebase components, including Firebase authentication and Firestore.

Goals

Our main goal was to create a good looking and functional native News-/Entertainment App, which is focused on the gaming sector.We wanted to create a clean app, which had all necessary information “for gamers from gamers”. An additional goal was to release the app on the Google Play Store and make experience with these and other important steps of the process like crashlytics. 

Features

In our Android app, we considered different gaming articles. We embedded written text, images, twitter posts and YouTube videos. Each article provided metadatas which included platforms, tags and cover images. We started the project without any clear business model. We oriented too strong on the different business models of other news platforms and missed our strive for something innovative, therefore we made the choice for some changes.

Architecture 

We did set up two Firebase projects to be able to develop and use simultaneously the applications. The first firebase project was the staging environment, where bugs were reproduced and new features implemented. The second Firebase project was the production environment, where the actual android app from the Playstore and the editorial team were using.

The android application was an abstract version of our ideas to get a minimum viable product that can be published as the first version of the app. Therefore, the application consisted only of an authentication screen (not included in the following visualisation), an articles overview and preview screen, an user profile screen, app settings, an about screen and a privacy webview.

The web application was also structured very simply providing abstracted access to content creation and editing. The data models that could be manipulated were:

  • Drafts
  • Articles
  • Games
  • Platforms
  • Contributors

The web application did implement a workflow for creating and reviewing articles with the 4-eyes principle including multiple steps before a draft turned into a complete article and was published in the end.

Firebase

Firebase provides tools and infrastructure via a software development kit that enable us as developers to provide functions more easily and efficiently using programming interfaces on various platforms. 

What does Firebase offer: 

  • Crashlytics
  • User authentication 
  • Cloud storage
  • Firebase Functions
  • Real-time database 
  • and even more

Anyone who has worked with mobile apps knows that it always gets tricky on launch day. Keeping an eye on stability, growth and sales can keep the whole team pretty busy. To manage the stability of our app, we used Crashlytics so we could get real-time alerts about crashes. The information about the crashes was very accurate.

We also used Firebase storage to store images that we needed either as lead stories or as content for our articles. However, storage is limited to 5 GB even with the free Firebase version. For this reason, we downsized our images before uploading them. In the future, we will certainly have to pay for an increase in storage to be able to manage our content to a reasonable extent.  

However, there is one particular feature of Google that is unbeatable: the Firebase functions!

With this, we were able to run backend code in response to all kinds of inputs or events, such as responding to user actions, analytics and authentication events, without having to start a server. Just a bit of code and the definition under which the function should be executed, and we could do “anything” we wanted.

Here is an illustration of how we sended event-based notifications to our users very easily via the Firebase functions.

The real problem was that we could not use this function because we did not have a credit card. However, this is needed if you want to use the full range of Firebase functions. The bottom line is that we were forced to write more Firebase rules.

These rules work by matching a pattern to database paths and then applying custom conditions to allow data access and keep it consistent.  However, we had to write hundreds of lines of code to manage the complexity of our web application as well as our app according to its functionality.

Our Firebase rules became more and more extensive as the app became more complex and new features were added. Unfortunately, all Firebase errors thrown, for example, when implementing our Angular frontend, were more or less pointless. Often we got a “permission denied” error and we couldn’t find the problem without actually looking into our rules and checking them for hours. For this reason, we need Firebase functions in the future to avoid this effort.

Challenges

Google Play Store

Overall the biggest challenge we faced with NewsDrop so far was publishing our Android app to the Google Play Store. The publication process took multiple attempts. The first few times our app got rejected because of regulations regarding news apps. More specifically because apparently we did not provide our contact information at the correct place inside the app. In the end we solved it by changing the genre of our app from news to entertainment. Our app got approved immediately and now our app is available in the Google Play Store. You can find our app through the following QR code:

Cross platform development

We had difficulties deciding between native app development and cross-platform development. In the end, we decided to develop the app natively first and start with an Android app. The reasons for this are limitations with cross-platform frameworks and a lack of know-how within our team. The biggest disadvantage, however, is that iOS users currently have no access to NewsDrop, although the demand for an iOS app was high.

Editorial team size

Currently, our editorial team consists of two editors who are responsible for the content of our app. For this reason, an enormous amount of time had to be invested in each individual article – it was not even possible to sufficiently cover the entire variety of games with only two editors. Large games websites employ numerous staff members who are responsible for creating the content. In addition, it is not uncommon for each individual editor to be responsible for specific games. This ensures that each individual author has a certain know-how, since in the best case he or she has already played the game – an important prerequisite for being able to write an authentic and credible review, for example. As a university project, this setting was unfortunately denied to us, so that unfortunately only a small section of news from the “world of games” could be covered.

Conclusion

Current state of our application

Since creating an appropriate amount of content is as personnel-intensive as it is time-consuming, we as a team have now agreed to go new ways. So far, our news has been written in great detail and sometimes almost passed for a report or even a commentary. In the future, we would like to concentrate more on pure facts and figures and thus do better justice to our “gamer” target group, which experience has shown to be rather lazy readers. In order to find our unique selling point and not become just another of the numerous websites for gaming news, we have to offer readers and subscribers real added value.

Future plan 

Therefore, it was and is particularly important for us to take into account the current developments in the media landscape. In recent years, the news industry has increasingly developed in the direction of alternative, cross-media forms of content presentation, which are mostly presented in direct form on social media. Therefore, as a first step, pure information should take precedence over the creativity of the individual editor. Not too detailed, but “short and crisp” will be our motto in the future.

The brainstorming process has already brought numerous ideas to light. Overall, we want to offer more forms of content that make us less dependent on individual authors, so that they don’t have to know every last detail about a particular game or have already played it themselves. In a further step, however, we plan to archive the existing contributions in the form of longer texts or even comments and make them available to interested groups. While one person just wants to know when the latest Nintendo game will be released, another might want to know more about the new Fortnite update and needs background information for this, which first has to be researched in detail. Ultimately, we want to meet the needs of both sides within our app.

Team:
  • Christos Malliardis 
  • Tim Schaal 
  • Maximilian Staudenmaier
  • Felix Arnold
  • Lewon Güler

Black Swans in IT-Systemen und Ausfälle 2020

Seit über einem Jahr sorgt die Coronapandemie für tägliche Berichterstattung und vielerlei Einschränkungen. Kontakte werden auf ein Minimum begrenzt, Gastronomien und Großteile des Einzelhandels geschlossen und Freizeit- sowie Kulturveranstaltungen abgesagt. Mehr Zeit als je zuvor verbringen die Menschen in ihren eigenen vier Wänden und nutzen IT-Systeme, um im Home-Office zu arbeiten, über Lernplattformen zu lernen oder durch Videokonferenzsysteme soziale Kontakte herzustellen. Auch die dafür benötigten, cloudbasierten IT-Systeme erfahren dadurch Auslastungen, die zuvor nur schwer vorstellbar waren. Dieser Mehraufwand und die dafür erforderliche Skalierung der Systeme, sorgte im vergangenen Jahr 2020 für Ausfälle (Outages), von welchen auch die “Big-Player” des Cloud-Computings nicht verschont blieben. Einer Microsoft Azure Einschränkung im März folgte im November der Ausfall einiger AWS-Dienste des Cloud-Marktführers Amazon, ehe im Dezember zahlreiche Google-Dienste wie YouTube oder GoogleDrive für einige Stunden unerreichbar waren. Mögliche Ursachen solcher Ausfälle wurden bereits 2018 in Laura Nolans USENIX-Konferenzbeitrag “What Breaks Our Systems: A Taxonomy of Black Swans” thematisiert und in sechs Muster kategorisiert [2]. Der folgende Blogbeitrag stellt diese Kategorien, die Ursachen schwarzer Schwäne in IT Systemen dar (Seite 1), ordnet einige Ausfälle aus dem vergangenen Jahr in diese ein (Seite 2) und zeigt mögliche Präventionsmaßnahmen auf (Seite 3).

Continue reading

KISS, DRY ‘n SOLID — Yet another Kubernetes System built with Ansible and observed with Metrics Server on arm64

This blog post shows how a plain Kubernetes cluster is automatically created and configured on three arm64 devices using an orchestration tool called Ansible. The main focus relies on Ansible; other components that set up and configure the cluster are Docker, Kubernetes, Helm, NGINX, Metrics Server and Kubernetes Dashboard. Individual steps are covered more or less; the whole procedure follows three principles:

Continue reading

How to Scale Jitsi Meet

Person sitting on their bed, having a video conference on their laptop

In today’s world, video conferencing is getting more and more important – be it for learning, business events or social interaction in general. Most people use one of the big players like Zoom or Microsoft Teams, which both have their share of privacy issues. However, there is an alternative approach: self-hosting open-source software like Jitsi Meet. In this article, we are going to explore the different scaling options for deploying anything from a single Jitsi server to a sharded Kubernetes cluster.

Continue reading

How to Scale: Real-time Tweet Delivery Architecture at Twitter

There is a lot to say about Twitters infrastructure, storage and design decisions. Starting as a Ruby-on-Rails website Twitter has grown significantly over the years. With 145 million monetizable daily users (Q3 2019), 500 million tweets (2014) and almost 40 billion US dollar market capitalization (Q4 2020) Twitter is clearly high scale. The microblogging platform, publicly launched in July 2006, is one of the biggest players in the game nowadays. But what’s the secret handling 300K QPS (queries per second) and provide a real-time tweet delivery? Read about how Redis Clusters and Tweet Fanouts revolutionized the user’s home timeline.

Continue reading

Sensor Fusion

Geschrieben von Konstantin Rosenberg

Einleitung

Stell dir vor du fährst in deinem autonom Fahrenden Auto die Straße entlang. Plötzlich erscheint, hinter einem parkenden Auto, ein Fußgänger und tritt direkt vor dir auf die Fahrbahn. Du erschrickst, doch das Auto kommt elegant vor dem unachtsamen Spaziergänger zu stehen. Während du dir gerade nicht einmal sicher bist was passiert ist, hat dein selbstfahrendes Auto einen Unfall verhindert. Aber was genau ist hier eigentlich passiert?

Im 21. Jahrhundert gibt es autonome Autos und Drohnen liefern Pakete direkt vor deine Haustür. Dabei haben Drohnen und autonom fahrende Autos eine Sache gemeinsam. Sie beide sind mit vielen verschiedenen Sensoren ausgestattet, um ihre Umgebung wahrzunehmen und auf Ereignisse zu reagieren. Gerade beim autonomen Fahren sind hohe Zuverlässigkeits- und Sicherheitsanforderungen an die Systeme gestellt, da schließlich Leben von den richtigen Entscheidungen des Systems abhängen. Um richtige Entscheidungen zu gewährleisten ist es unabdingbar, dass ein System möglichst präzise, zuverlässige Daten erhält. Es ergibt sich demnach die Frage, wie die Aufnahme und Verarbeitung von Sensorinformationen dahingehend verbessert werden kann, sodass der Entscheidungsprozess eines autonomen Systems ein akzeptables und zuverlässiges Niveau erhält. Eine der Antworten auf diese Frage lautet: „Sensor Fusion“.

Datenverarbeitung in autonomen Systemen

Um Sensor Fusion zu verstehen betrachten wir zunächst die Datenverarbeitung in einem Autonomen System. Autonome Systeme verwenden Sensorik, um ihre Umwelt wahrzunehmen und entsprechend der Umstände zu agieren. Im Beispiel aus der Einleitung bemerkte das autonome Auto den Fußgänger und leitete deshalb einen Bremsvorgang ein. Dieser hier beschriebene Vorgang aus Wahrnehmung und Handeln lässt sich für ein System in die folgenden Schritte unterteilen.

  1. Informationen aufnehmen
  2. Informationen interpretieren
  3. Aktion planen
  4. Aktion ausführen

Damit autonome Autos ihre Umgebung wahrnehmen können, werden in deren Systeme Sensoren integriert. Wenn man so will sind die Sensoren die Augen und Ohren des Systems, denn ohne diese würde das System nicht verstehen was gerade um es herum passiert. Sensoren kommen in den unterschiedlichsten Farben und Formen vor, je nachdem welchen Zweck sie erfüllen. Es gibt Kamerasensoren für das erheben von Bildinformationen, Infrarotsensoren für Abstandsmessungen, Gyroskopische Sensoren um die Lage im Raum festzustellen etc. Im Falle eines autonomen Fahrzeugs werden Kamerasensoren und zusätzliche Sensoren für die Abstandserkennung benutzt und somit der Wahrnehmung der Verkehrslage dienen.
Die über Sensorik aufgenommenen Informationen müssen anschließend noch vom System ausgewertet und interpretiert werden. Dazu versucht das System die gesammelten Umgebungsinformationen zu verstehen. Das autonome Auto fragt sich also beispielsweise: Was sehe ich hier? Ist ein Mensch zu erkennen oder doch nur der Schatten eines Baumes? Oder ist es wohlmöglich ein anderes Auto?
Wurden die Informationen dann interpretiert, reagiert das System entsprechend und führt eine Handlung aus. Werden die aufgenommenen Sensorinformationen, wie im Falle unseres Beispiels, als Fußgänger interpretiert, bremst das Auto ab.

Sensor Fusion

Nun da wir den Ablauf in einem autonomen System genauer verstehen, können wir Sensor Fusion als Teil dieses Ablaufs betrachten.

Eigentlich verhält es sich mit Sensor Fusion wie mit unseren Sinneseindrücken. Wir hören, sehen und fühlen verschiedene Reize, welche wie aus unserer Umwelt aufnehmen. Das Gehirn wiederum verarbeitet diese Informationen zu einem gesamtheitlichen Eindruck. Genau so funktioniert auch Sensor Fusion. In einem System werden nicht nur die Daten eines einzelnen Sensors für den Interpretationsschritt verwendet, sondern gleich mehrere. Dadurch verbessert sich der gesamtheitliche Eindruck über die Umgebung. Sensor Fusion ist demnach ein Teil des Aufnahme- und Interpretationsschritts in einem autonomen System, da mehrere Sensorinformationen aufgenommen und auch gemeinsam verarbeitet werden.

Vorteile von Sensor Fusion

Die Aufnahme und Verarbeitung mehrerer Sensorinformationen bietet gleich mehrere Vorteile wie:

Genauere Daten

Mithilfe von Sensor Fusion kann die Genauigkeit und Qualität der, über Sensorik erfassten Informationen, verbessert werde. Da die von Sensoren aufgenommenen Informationen nie 100% korrekt sind, sondern Ungenauigkeiten und Störsignale enthalten, wird Sensor Fusion eingesetzt, um diese Inkorrektheiten abzuschwächen. Werden mehrere Sensoren der gleichen Art verwendet ist es möglich die fehlerhaften Informationen herauszufiltern, indem die aufgenommenen Informationen miteinander verrechnet werden. Dazu kann der Durchschnitt der beiden Sensorinformationen ermittelt werden, um den Noise zu herauszurechnen. Genauso wie bei den menschlichen Augen der blinde Fleck durch das zweite Auge ergänzt und das Blickfeld vervollständigt wird, werden bei Sensor Fusion mehrere Sensoren verwendet, um Ungenauigkeiten oder Fehlende Informationen durch weitere Sensoren zu beseitigen.

Verlässlichere Daten

Ein weiter Vorteil von Sensor Fusion ist eine erhöhte Verlässlichkeit der Sensorinformationen. Werden mehrere unterschiedliche Sensoren für die Erfüllung einer Aufgabe verwendet, können die Sensordaten gegeneinander abgeglichen werden, um die Plausibilität der Daten zu überprüfen. Fallen Sensoren aus, oder liefern aus diversen Gründen komplett falsche Informationen, stehen immer noch die Daten anderer Sensoren für die Erfüllung einer Aufgabe zur Verfügung.
Fallen bei einem autonomen Auto die Sensoren für die Geschwindigkeitsermittlung aus, besitzt das System noch weitere Sensoren, wie beispielsweise das GPS, um die Geschwindigkeit festzustellen. Zwar kann die Genauigkeit der der Daten darunter leiden, aber die Information der Geschwindigkeit geht nicht komplett verloren.

Zusätzliche Zustandsinformationen

Durch Sensor-Fusion ergeben sich außerdem viele neue Möglichkeiten, um zusätzliche Informationen über die Systemumgebung zu erhalten. Werden z.B. zwei Sensoren für die Erhebung von Bildinformationen verwendet, kann dadurch zusätzlich die Entfernung zu den erkannten Objekten berechnet werden. Genau wie unser Gehirn mithilfe der Bildinformationen von zwei Augen dazu fähig ist die Entfernung zu den Objekten zu berechnen.

Sensor Fusion Algorithmen

Wir haben nun einen Überblick über Sensor Fusion und darüber welche Vorteile das Verwenden mehrerer Sensorinformationen für den Entscheidungsprozess eines autonomen Systems haben kann. Im Weiteren schauen wir uns an wie Sensorinformationen aus verschiedenen Quellen am besten interpretiert werden können. Dafür betrachten wir die allgemeine Vorgehensweise von Sensor Fusion Algorithmen, deren Ziel es ist den physischen Zustands eines System oder Objekts abzuschätzen.
Im Prinzip kombinieren Sensor Fusion Algorithmen Dinge die über einen Vorgang bekannt sind mit den Daten die von Sensoren erfasst werden. Konkret sind in den Sensor Fusion Algorithmen dazu physikalische Gleichungsmodelle als Ausgangspunkt verwendet. Diese Gleichungsmodelle heißen „Motion model“ und sind in ein sogenanntes „prediction model“ integriert. Prediction models sind Gleichungen die der Vorhersage von Systemzuständen dienen. Mithilfe des prediction model werden also anhand von bekannten physikalischen Gleichungen Vorhersagen über den zukünftigen Zustand eines Systems gemacht. Diese Vorhersage kann dann mithilfe eines sog. „update model“ um die tatsächlich, von Sensoren gemessenen Daten, korrigiert werden. Das Ergebnis beinhaltet damit eine Mischung aus Vorhersage und tatsächlich gemessenen Werten. Falsche Messwerte werden also schon durch das Prinzip dieses Vorhersagevorgangs abgeschwächt, da sich das System nicht komplett auf Sensorinformationen verlässt. Außerdem wird die Plausibilität von Sensorinformationen überprüfbar, weil eine Vorhersage den Rahmen für mögliche Werte vorgibt und Messfehler dadurch erkannt werden können. Klingt alles etwas kompliziert, schauen wir uns das doch einmal in einem Beispiel an.

Beispiel Lokalisation

Stellen wir uns wir fahren über eine Landstraße und möchten nun die Position unseres Autos anhand von Sensorinformationen bestimmen. Registriert der Geschwindigkeitssensor eines Fahrzeugs z.B die Geschwindigkeit von 10m/s, so kann die Annahme getroffen werden, dass sich das Fahrzeug nach einer Sekunde 10 Meter weiter vorne befindet, falls sich die Richtung des Fahrzeugs nicht ändert. Nun wird die vorhergesagte Position mit den Sensorinformationen verglichen und verrechnet. Es ergibt sich die vom System registrierte neue Position des Fahrzeugs. Die festgestellt Position und alle weiteren Zustandsinformationen(Geschwindigkeit usw.) werden anschließend als Ausgang für die nächste Vorhersage verwendet und der Vorgang beginnt von neuem.

Hier einmal die Positionsbestimmung durch Sensorfusion Bildlich dargestellt:

Vorhersage der zukünftigen Position anhand des prediction model

Die Gelbe Linie beschreibt die Vorhersage der Position anhand der aktuellen Position und dem Zustand unseres System. Diese Informationen werden durch das prediction model verarbeitet und es kommt zu einer Vorhersage . Der Systemzustand beinhaltet Informationen wie z.B Geschwindigkeit, Position, Karten Daten usw. die als Grundlage für die Vorhergesagt Position dienen. Wie ihr seht ist die Vorhersage nicht perfekt sondern etwas neben der Straße. Es wird auch keine vollständige Korrektheit erwartet, denn die Vorhersage wird jetzt noch durch Sensorinformationen ergänzt.

Über die Sensorik des Systems festgestellte Position

Die rote Linie beschreibt die festgestellte Position anhand von Sensordaten. Unser System hat zwischen den Messungen eventuell die Geschwindigkeit oder Richtung geändert, deshalb bekommen wir ein etwas anderes Ergebnis als das prediction model. Aber auch hier ist die Position nicht richtig, da die Sensoren nicht perfekt funktionieren sondern Störsignale beinhalten und eventuell falsche Informationen aufnehmen. Deshalb werden im Folgenden schritt die Vorhersage und die gemessenen Sensordaten zu einer finale Lokalisation verrechnet.

Berechnung des Systemzustands aus Sensordaten und Vorhersage

Die Lila Kurve stellt Lokalisation anhand der Vorhersage und der Sensorinformationen dar. Die Berechnung der Position fällt zwischen die Gelbe und die rote Linie und im optimal Fall möglichst nah an die tatsächliche Position des Fahrzeugs.

Kalman Filter

Einer der bekanntesten Sensor Fusion Algorithmen ist wohl der Kalman Filter. Vor allem bietet sich diese Technologie für die Vorhersage anhand mehrerer Sensorinformationen mit hohem Rauschanteil an. Der Kalman Filter geht dabei von einer Gaußverteilten Welt aus und ist optimal für Lineare Problemstellungen. Somit eignet er sich für Aufgaben wie Lokalisation. Oft wird der Kalman Filter mit Sensor Fusion gleichgesetzt obwohl es auch andere Möglichkeiten für die Verrechnung von Sensorinformationen wie z.B. neuronale Netze gibt.

Wie geht’s weiter?

Wir haben in diesem Blogeintrag das grundlegende Prinzip hinter Sensor Fusion betrachtet. Sensor Fusion bietet viele Vorteile für autonome Systeme durch die Kombination von Sensorinformationen sind Umgebungseinschätzungen präziser und zuverlässiger . Es gibt viele mögliche Anwendungsfälle für Sensor Fusion wie Lokalisation, Hinderniserkennung, Abstandserkennung usw. In Zukunft werden viel autonome Systeme Sensor Fusion verwenden, um intelligentere, sicherere und zuverlässigere Entscheidungen zu berechnen. Es lohnt sich also das Thema auch weiterhin zu verfolgen.

Referenzen:

  1. https://algorithmsbook.com/#
  2. https://www.researchgate.net/publication/332997416_Multi-Sensor_Data_Fusion_Algorithm_Based_on_Trust_Degree_and_Improved_Genetics
  3. https://www.udacity.com/blog/2020/08/sensor-fusion-algorithms-explained.html
  4. https://towardsdatascience.com/wtf-is-sensor-fusion-part-2-the-good-old-kalman-filter-3642f321440
  5. https://www.sciencedirect.com/science/article/abs/pii/S1367578802000457
  6. https://www.researchgate.net/profile/Wilfried-Elmenreich/publication/267771481_An_Introduction_to_Sensor_Fusion/links/55d2e45908ae0a3417222dd9/An-Introduction-to-Sensor-Fusion.pdf