MasterarbeitLatex/VorlageTeX/methoden.tex

\chapter{Methodik}
In diesem Kapitel geht es nun um die Umsetzung der Navigation des Roboters. Zunächst wird auf Vorarbeiten im Bereich der Indoor-Roboternavigation mittels Machine Learning eingegangen, danach folgt ein Überblick über Hardware, verwendete Technologien und Frameworks. Darauf folgend wird die technische Umsetzung erklärt und anschließend die Evaluierung der Navigation mitsamt Ergebnissen vorgestellt.

\section{Verwandte Arbeiten}
\label{RelatedWork}
Einige Vorarbeiten im Bereich der Roboternavigation mittels Machine Learning im Indoor-Bereich basieren auf Klassifizierung der Eingabebilder nach Steuerbefehlen, z.B. \cite{Kim.11152015} und \cite{Liu.2017}. Ein großer Nachteil der Arbeiten in \cite{Kim.11152015} und \cite{Liu.2017} ist die sehr große Anzahl an Trainingsdaten von mehreren tausend Bildern. \\
Ein weiterer Ansatz für die Roboternavigation ist der Einsatz von Reinforcement Learning \cite{Zhu.2016}. Großer Nachteil hier ist das umfangreiche Vortraining in einer Simulation. Danach muss das Modell nochmal einem Feintuning in der realen Welt unterzogen werden \cite{Zhu.2016}. \\
In \cite{Macias-GarciaDetection.2020} nutzen die Autoren für die Navigation ein \gls{CNN}, das durch RGB-Bilder die Objektdetektion und Hinderniserkennung durchführt. Zusätzlich wird durch den Einsatz einer Stereokamera Tiefeninformation gewonnen und diese Daten mit den Daten aus der Objektdetektion zusammengeführt. Aus dieser Zusammenführung wird eine Trajektorie für den Fahrtweg berechnet \cite{Macias-GarciaDetection.2020}. \\
Die Arbeiten \cite{Nalpantidis.2009} und \cite{PireStereoVision.2012} basieren auf einer Hindernisvermeidung mittels Algorithmen auf Tiefenkarten aus Stereokameras. \\
In \cite{Zhang.2019}, \cite{Chakravarty.2017}, \cite{Alvarez.2016}, \cite{Hatch.2020} und \cite{Yang.2017} realisieren die Autoren die Navigation mittels \gls{CNN}'s, die eine Depth Estimation durchführen, also eine Tiefenkarte aus RGB-Bilder erzeugen und hieraus dann Steuerbefehle ableiten.

\section{Hardware}
In diesem Kapitel wird die Hardware vorgestellt, die in dieser Arbeit zum Einsatz kommt. Als Erstes wird auf die Hardware des Roboters eingegangen, danach auf die Hardware für den Einsatz des Machine-Learning-Modells während der Inferenz.

\subsection{Roboter mit Arduinoboard und Bluetooth-Modul}
Abbildung \ref{fig:Roboterhardware} zeigt den Roboter mit angebundenem Smartphone. Der Roboter hat die Bezeichnung Ubbo Maker v3 und stammt von einem französischen Hersteller. Der Roboter wurde in der Vergangenheit von der codemanufaktur GmbH aufgebaut und war mittels Android-App fernsteuerbar. Die Aktoren des Roboters werden von einem Arduino Mega 2560 und dazugehörigen Shield Mega Sensor V2.4 angesteuert. Das DF-Bluetooth v3 als Bluetooth Bee 2.0 bietet eine Bluetooth-Verbindung zum Arduino-Board.

\begin{figure}[htbp]
  \centering  
  \includegraphics[scale=0.1]{img/Roboter.jpg}
  \caption{Roboter mit Smartphone}
  \label{fig:Roboterhardware}
\end{figure}

\subsection{Anforderungen und Lösungsansätze bezüglich Hardware}
Die Umsetzung zum autonom fahrenden Roboter sollte so einfach wie möglich gestaltet werden und am besten auf die Bluetooth-Verbindung ansetzen. Folgende Anforderungen und Bedingungen müssen berücksichtigt werden:
\begin{itemize}
\item Umsetzung soll kostengünstig erfolgen
\item Echtzeitfähigkeit
\item Kamera für RGB-Bildaufnahme
\item Steuersignale sollten per Bluetooth oder USB-Verbindung ans Arduino-Board gesendet werden, da kein WLAN-Modul am Arduino-Board vorhanden ist
\item Latenz zur Signalübertragung zum Arduino-Board sollte gering sein
\item genügend Rechenkapazität für die Inferenz
\end{itemize}
Nach der Recherche von den Möglichkeiten von TensorFlow Lite \cite{TensorFlow.8202021} (Unterkapitel \ref{sec:TensorFlowLite}), der Anforderung einer Kamera und der bevorzugten Signalübertragung mittels Bluetooth wurde die Lösung mit Smartphone favorisiert. Wie in Abbildung \ref{fig:Roboterhardware} zu sehen ist, ist auch die Montage des Smartphones an den Roboter einfach. Das Smartphone wird mit einem Gummiband an die Tablethalterung des Roboters befestigt. Folgende Alternativen sind technisch möglich, hätten aber die Umsetzung verteuert oder kompliziert:
\begin{itemize}
\item Raspberry Pi mit Kamera: Nachteile in Bezug auf Rechenkapazität und Montage von Board und Kamera. Erforderliche Powerbank für Stromversorgung
\item Inferenz auf Laptop: Nachteile von Konnektivität (kein WLAN-Modul am Roboter) zwischen erforderlicher Webcam, Laptop und Arduino-Board. Alternativ komplizierte Montage des Laptops an den Roboter
\item \gls{KI}-Board Nvidia Jetson Nano mit Kamera: Nachteil der Montage der Kamera und erforderliche Powerbank für Stromversorgung des Jetson Nano
\end{itemize}


\subsection{Hardware für die Inferenz des Machine-Learning-Modells}
Als Hardware für die Inferenz, Bildaufnahme und Übertragung der Steuerbefehle per Bluetooth wird ein Mittelklasse-Smartphone auf Android-Basis vom Typ Samsung Galaxy A32 4G verwendet. Tabelle \ref{tab:Smartphone} zeigt die technischen Daten.

\begin{table}[htbp]
\centering
\begin{tabularx}{\textwidth}{p{0.25\textwidth}|X}
\hline
Android Version & 11\\
\hline
CPU-Modell	& MT6769T Mediatek Helio G80\\
\hline
CPU-Kerne	& 8, 2x2,0 GHz Cortex-A75 und 6x1,8 GHz Cortex-A55\\
\hline
Prozessor-Architektur	& arm64\\
\hline
GPU-Modell	& Mali-G52 MC2\\
\hline
RAM-Typ	& LPDDR4X Dual-channel\\
\hline
RAM-Größe	& 4 GB\\
\hline
\end{tabularx}
\caption{Technische Daten des Samsung Galaxy A32 4G}
\label{tab:Smartphone}
\end{table}

Alternativ lässt sich auch mit einem iPhone mit dem Betriebssystem iOS die Inferenz durchführen. Hier steigen dann jedoch die Hardwarekosten und der Aufwand der Portierung der App auf das iPhone.

\subsection{Hardware für das Training des Machine-Learning-Modells}
Ein Teil des Machine Learnings wurde mit einem Dell Laptop mit den technischen Daten aus Tabelle \ref{tab:DellLaptop} durchgeführt. Ein großer Nachteil hier ist die fehlende dedizierte Grafikkarte, denn Garfikkarten sind sehr effizient und können schneller viele Berechnungen parallel ausführen im Vergleich zur CPU \cite[494-497]{Goodfellow.2018}.

\begin{table}[htbp]
\centering
\begin{tabularx}{\textwidth}{p{0.25\textwidth}|X}
\hline
Betriebssystem Version & Windows 10 Pro 21H2\\
\hline
CPU-Modell	& Intel Core i7-10850H CPU\\
\hline
CPU-Kerne	& 6, Basistakt 2,71 GHz\\
\hline
Threads	& 12\\
\hline
Prozessor-Architektur	& x64\\
\hline
GPU & Intel UHD Graphics\\
\hline
RAM-Größe	& 16 GB\\
\hline
\end{tabularx}
\caption{Technische Daten des Dell Laptops}
\label{tab:DellLaptop}
\end{table}

Aufgrund der fehlenden Grafikkarte und der dadurch erheblich langen Trainingszeit von mehreren Stunden wurde das Training später auf Google Colab \cite{Colab.1072021} durchgeführt. Vorteil hier ist eine Laufzeitumgebung in der Cloud mit Nutzung von Grafikkarten und der Anbindung des eigenen Google Drive Speichers. Tabelle \ref{tab:GoogleColabGrafikkarte} zeigt die Daten bezüglich der Grafikkarte und der CUDA Version der Laufzeitumgebung in Google Colab.

\begin{table}[htbp]
\centering
\begin{tabularx}{\textwidth}{p{0.25\textwidth}|X}
\hline
Google Colab Version & Colab Pro\\
\hline
GPU-Modell	& Nvidia Tesla P100-PCIE\\
\hline
CUDA Version	& 11.2\\
\hline
\end{tabularx}
\caption{Daten der genutzten GPU der Laufzeitumgebung in Google Colab}
\label{tab:GoogleColabGrafikkarte}
\end{table}

Durch die Nutzung der Grafikkarte in Google Colab fallen die Trainingszeiten auf unter 1 Stunde, teilweise auf unter 30 Minuten je nach Modellgröße.

\section{Navigation}
Der Ansatz für die Navigation orientiert sich an den Vorarbeiten \cite{Macias-GarciaDetection.2020}, \cite{Zhang.2019}, \cite{Chakravarty.2017}, \cite{Alvarez.2016}, \cite{Hatch.2020} und \cite{Yang.2017}, die im Kapitel \ref{RelatedWork} vorgestellt wurden. Die Navigation wird in zwei Teilbereiche aufgegliedert, in eine Zielerkennung / Zielverfolgung und eine separaten Hindernisvermeidung / Hindernisumfahrung. Für die Zielerkennung  werden als Ziel Bürotüren in der codemanufaktur GmbH ausgewählt. Grund hierfür ist, dass Türen Ein- und Ausgangspunkte von Räumen darstellen und somit die Navigation erweitert werden kann über mehrere Räume eines ganzen Areals. Nachfolgend werden diese beiden Teilbereiche näher erläutert.

\subsection{Zielerkennung als Türdetektion mittels Objektdetektion}
Die Zielerkennung wird als Türerkennung mittels Objektdetektion realisiert. Über die Geometrie der Bounding Box wird die Fahrtrichtung, das Losfahren und Stoppen des Roboters gesteuert. Beispielsweise wird der Roboter nach links fahren, falls die Bounding Box im linken Bereich des Kamerabildes liegt und analog andersherum. Falls die Bounding Box klein ist, suggeriert dies eine weite Entfernung der Tür und der Roboter fährt los. Im Fall, dass die Bounding Box groß ist, wird dies als nah interpretiert und der Roboter stoppt.


\subsection{Hindernisvermeidung durch Depth Estimation}
Es soll eine generelle Hindernisvermeidung implementiert werden. Die Vielzahl an variablen Objekten, die als Hindernis dienen können, machen eine Hindernisvermeidung über Objekterkennung schwierig. Daher wird als Methode die Depth Estimation, also die Abschätzung einer Tiefenkarte aus einem RGB-Bild, implementiert. Aus dem Tiefenbild kann dann pixelweise auf nahe Objekte geschlossen werden, da die Werte jedes Pixels als Disparität (Disparity) interpretiert werden. Die Disparität ist proportional zur Distanz (Distance) und stammt aus der Stereovision mittels Stereokameras \cite{PireStereoVision.2012}. Abbildung \ref{fig:DistanceDisparity} zeigt das Prinzip zwischen Disparität und Distanz. Dieses Prinzip kann ein Machine-Learning-Modell erlernen und als Output eine Tiefenkarte generieren, wobei die Disparitätswerte jedes Pixels zwischen 0 und 1 normiert werden. 

\begin{figure}[htbp]
  \centering  
  \includegraphics[scale=0.4]{img/Distance_Disparity.png}
  \caption{Darstellung der Distanz zur Disparität \cite{PireStereoVision.2012}}
  \label{fig:DistanceDisparity}
\end{figure}

\section{Frameworks für technische Umsetzung}
In diesem Kapitel geht es um die verwendeten Frameworks, um das Machine Learning so einfach wie möglich umzusetzen. Als Erstes wird auf das Framework TensorFlow eingegangen, dann auf die Object Detection API, die auf TensorFlow aufsetzt, und zum Schluss wird TensorFlow Lite vorgestellt.

\subsection{TensorFlow}
TensorFlow ist ein Open-Source-Framework von Google zum Implementieren und Ausführen von Algorithmen des Machine Learnings \cite[425]{Raschka.2018}, \cite{TensorFlow.832021}. Für diese Arbeit wird die TensorFlow Python-API mit TensorFlow 2.0 verwendet. TensorFlow 2.0 teilt sich zudem in eine Low-Level-API und den High-Level-API's TensorFlow Layers und Keras auf \cite[426]{Raschka.2018}. Für diese Masterarbeit wurde ausschließlich die Low-Level-API von TensorFlow 2.0 verwendet. TensorFlow unterstützt zudem das Training und die Inferenz von Modellen auf der CPU sowie der GPU, wobei die Berechnungszeiten auf einer GPU wesentlich schneller ablaufen \cite[425]{Raschka.2018}. Ein wichtiger Grund für die schnellere Berechnung auf der GPU ist, dass GPU's viele parallele Fließkommaoperationen pro Sekunde ausführen \cite[424]{Raschka.2018}.

\subsection{TensorFlow Object Detection API}
Neben TensorFlow 2.0 wurde auch die Object Detection API \cite{GitHub.1062021} für die Erstellung und das Training der Modelle für die Türerkennung verwendet. Die Object Detection API ist nicht in TensorFlow 2.0 enthalten und muss über ein Git-Repository bezogen und zusätzlich über die eigene Python-Umgebung mittels Python-Package-Installer pip installiert werden. Alternativ wird auch eine Installation mittels Docker angeboten. Die Object Detection API enthält zudem einen sogenannten Model Zoo \cite{GitHubDetectionZoo.11152021}, in dem vortrainierte Netze enthalten sind und zusätzlich heruntergeladen werden können. Diese Netze wurden mit dem COCO 2017 Datensatz \cite{coco.8252021} mit 90 Objektklassen trainiert. Die Anzahl der 90 Objektklassen lässt sich in den config-Files nachlesen. Für die Masterarbeit wurde die Objekt Detection API TensorFlow 2 für das Training der Türdetektion und der TensorFlow 2 Model Zoo für das Herunterladen von vortrainierten Netzen verwendet.

\subsection{TensorFlow Lite}
\label{sec:TensorFlowLite}
TensorFlow Lite \cite{TensorFlow.8202021} ist ein Framework, um die Inferenz von Machine-Learning-Modellen auf mobilen Geräten wie Smartphones und eingebetteten / \gls{IoT}-Geräten zu ermöglichen. Dazu wird das Modell in ein FlatBuffer-Format umgewandelt \cite{FlatBuffer.852021}. Hierbei wird das Machine-Learning-Modell  in ein binäres Format serialisiert, um auf verschachtelte Objekte wie Structs, Tables, Vectors, etc ohne Kopien und Parsing Zugriff zu bekommen \cite{FlatBuffer.852021}. Vor allem Tables werden über vtables auf Speichergröße und Zugriff optimiert \cite{FlatBuffer.852021}. Zudem werden Objekttypen über Schemas organisiert, um das Parsen zu vermeiden \cite{FlatBuffer.852021}. Mit dem FlatBuffer-Format wird somit erheblich die Inferenz und Modellgröße optimiert.  

\subsection{Android Studio}
Für die Entwicklung der App zur Inferenz auf dem Smartphone und somit zur Steuerung des Roboters wird die Entwicklungsumgebung Android Studio mit der Programmiersprache Java verwendet. Die TensorFlow Lite Interpreter API unterstützt neben der Programmiersprache Java, auch C++ und Python. Als Orientierung der Android-App dient das Repository \cite{GitHubTensorFlowAndroidExample.11222021}, das eine Implementierung einer Beispiel-App für die Objektdetektion auf einem Android-Smartphone zeigt.

\section{Machine Learning}
In diesem Kapitel wird nun das Machine Learning der Türdetektion erläutert. Zuerst werden die verwendeten Netzarchitekturen vorgestellt, danach wird der Datensatz besprochen. Darauf folgend wird dann das Training, die Validierung und der Test erklärt, und zum Schluss wird die Konvertierung der trainierten Modelle zum TensorFlow-Lite-Format gezeigt. Die Machine-Learning-Modelle der Depth Estimation werden direkt als fertigtrainierte Modelle aus den Quellen \cite{GitHub.1062021b} und \cite{GitHub.1062021c} als TensorFlow-Lite-Modelle bezogen

\subsection{Netzarchitekturen}
Die Entscheidung über die verwendeten Netzarchitekturen wurden anhand des Model Zoo der TensorFlow 2 Object Detection API \cite{GitHubDetectionZoo.11152021} getroffen. Die durch den COCO-Datensatz vortrainierten Netze ermöglichen ein deutlich schnelleres und einfacheres Training, da die Gewichte und Bias-Parameter schon auf High-Level-Merkmale trainiert sind. Ohne diese vortrainierten Netze würde das Training deutlich aufwändiger und länger werden. Die Methode, vortrainierte Netze für ein eigenes Training zu verwenden, wird auch als Transfer Learning bezeichnet, weil effektiv nur die letzten Schichten des Netzes für andere High-Level-Merkmale umtrainiert werden. \\
Eine wichtige Einschränkung gibt es bei der Auswahl der Modelle aus dem Model Zoo. Für Modelle, die später als TensorFlow-Lite-Modelle für die Objektdetektion verwendet werden, können nur \gls{SSD}-Modelle ausgewählt werden, andere Detektoren werden im TensorFlow Lite Framework noch nicht unterstützt. \\
Tabelle \ref{tab:VortrainierteNetze} zeigt die Modelle mit Auflösung der Eingabeschicht, Inferenzzeit und der \gls{mAP}, die für die Türdetektion ausgewählt wurden \cite{GitHubDetectionZoo.11152021}.

\begin{table}[htbp]
\centering
\begin{tabularx}{\textwidth}{p{0.45\textwidth}|X|X}
\hline
\textbf{Modell-Name} & \textbf{Inferenzzeit (ms)} & \textbf{COCO mAP (\%)}\\
\hline
SSD MobileNet V2 320x320 & 19 & 20,2\\
\hline
SSD MobileNet V2 FPNLite 320x320 & 22 & 22,2\\
\hline
SSD MobileNet V2 FPNLite 640x640 & 39 & 28,2\\
\hline
SSD ResNet50 V1 FPN 640x640 & 46 & 34,3\\
\hline
\end{tabularx}
\caption{Vortrainierte Netze für die Türdetektion \cite{GitHubDetectionZoo.11152021}}
\label{tab:VortrainierteNetze}
\end{table}

Bei der Auswahl wurde unter anderem auf die Inferenzzeit geachtet, aufgrund der Anforderung der Echtzeitfähigkeit der Roboternavigation. Je geringer die Inferenzzeit ist, desto weniger Verzögerung gibt es bei der Steuerung. Deshalb wurden auch keine Modelle mit noch höherer Auflösung der Eingabeschicht ausgewählt, da sonst die Inferenzzeit und Trainingszeit mit der Parameteranzahl / Modellgröße ansteigt \cite{GitHubDetectionZoo.11152021}. 


\subsection{Datensatz}
Die Daten für das Training der Türdetektion wurden einerseits automatisiert aus der Google-Bildersuche durch ein Python-Skript mit dem Package Selenium und andererseits durch eigene Fotoaufnahmen von Türen gesammelt. Bei der Google-Bildersuche wurden mehrere Arten von Türen gesammelt, zudem \gls{TN}(True Negative)-Bilder von Fenster, Bilderrahmen und Schranktüren. Alle Bilder sind im jpg-Format und haben unterschiedliche Größen / Auflösungen. Zudem sind alle Bilder durch das Seitenverhältnis im Portrait-Modus und die selbst aufgenommen Bilder per Kamera im 3:4 Format. Das Resizing der Bilder für die Netze wird im Training über die Object Detection API übernommen, wobei hier aufgepasst werden muss bezüglich des \gls{Exif}. Das \gls{Exif} kann beim Resizing die Bilder vom Portrait-Modus in den Landscape-Modus umwandeln, und dadurch zu Bounding Boxen führen, die nicht mehr ins Bild passen. Dies verursacht vor allem Fehler bei Validierung und Test durch die Object Detection API mittels COCO-Metrik. \\ 
Die Türdetektion wird mit zwei Datensätzen trainiert. Einem Datensatz für eine allgemeine Türdetektion und eine Türdetektion speziell für die Türen der codemanufaktur GmbH, um die beiden Türdetektionen zu vergleichen. Die nachfolgenden Abschnitte zeigen die beiden Datensätze auf. Danach wird auf das Labeln der Bilder, also der Ground Truth der Daten eingegangen.

\subsubsection{Datensatz für allgemeine Türdetektion}
Tabelle \ref{tab:BilderdatenGeneral} zeigt den Datensatz für die allgemeine Türdetektion.

\begin{table}[htbp]
\centering
\begin{tabularx}{\textwidth}{p{0.4\textwidth}|X|X|X}
\hline
\textbf{Kategorie} & \textbf{Anzahl für Training} & \textbf{Anzahl für Validierung} & \textbf{Anzahl für Test}\\
\hline
Schränke & 90 & 10 & 0\\
\hline
Bürotüren & 86 & 10 & 0\\
\hline
Glastüren & 43 & 5 & 0\\
\hline
Bilderrahmen & 25 & 3 & 0\\
\hline
Schiebetüren & 43 & 5 & 0\\
\hline
Spind & 13 & 2 & 0\\
\hline
Fenster & 26 & 3 & 0\\
\hline
Holztür & 43 & 5 & 0\\
\hline
Türen der codemanufaktur & 0 & 0 & 137\\
\hline
Türen vom Erlangen Arcaden, TH Nürnberg und Supermärkten & 143 & 17 & 0\\
\hline
\textbf{Gesamt} & \textbf{512} & \textbf{60} & \textbf{137}\\
\hline

\end{tabularx}
\caption{Bilder für die Daten der allgemeinen Türdetektion}
\label{tab:BilderdatenGeneral}
\end{table}

\FloatBarrier

\subsubsection{Datensatz für spezielle Türdetektion für die codemanufaktur GmbH}
Tabelle \ref{tab:BilderdatenCodemanufaktur} zeigt den Datensatz zum Training auf die Türen des Einsatzortes in der codemanufaktur GmbH.

\begin{table}[htbp]
\centering
\begin{tabularx}{\textwidth}{p{0.4\textwidth}|X|X|X}
\hline
\textbf{Kategorie} & \textbf{Anzahl für Training} & \textbf{Anzahl für Validierung} & \textbf{Anzahl für Test}\\
\hline
Schränke & 90 & 10 & 0\\
\hline
Bürotüren & 86 & 10 & 0\\
\hline
Bilderrahmen & 25 & 3 & 0\\
\hline
Spind & 13 & 2 & 0\\
\hline
Fenster & 26 & 3 & 0\\
\hline
Türen der codemanufaktur & 123 & 14 & 0\\
\hline
Türen vom Erlangen Arcaden, TH Nürnberg und Supermärkten & 0 & 0 & 160\\
\hline
\textbf{Gesamt} & \textbf{363} & \textbf{42} & \textbf{160}\\
\hline
\end{tabularx}
\caption{Bilder für die Daten der Türdetektion in der codemanufaktur}
\label{tab:BilderdatenCodemanufaktur}
\end{table}

\FloatBarrier

\subsubsection{Labeln der Bilder für die Ground Truth}
Für das Training der Objekt Detektion müssen die Bilder gelabelt werden. Dies wurde mit der Open-Source-Software labelImg \cite{GitHub.1062021d} im PascalVOC-Format vorgenommen. Im PascalVOC-Format wird jedem Bild eine xml-Datei zugeordnet, die die Ground Truth Informationen enthält. Diese Informationen enthalten die Bildgröße in Höhe und Breite, die Anzahl der Kanäle des Bildes (bei RGB sind es 3 Kanäle), die Bounding Box mit den xmin-, xmax-, ymin-, ymax-Koordinaten, und den Namen des Objekts \cite[9]{EveringhamDevelopmentKit.2012}. Die Einheit der geometrischen Größen sind die Pixel des Bildes. Neben den genannten Informationen bietet das PascalVOC-Format noch die Optionen truncated und difficult. Truncated bedeutet, dass die Bounding Box das Objekt abschneidet. Difficult ist eine Annotationsmöglichkeit, um schwer zu erkennende Objekte zu klassifizieren, die bei der Evaluierung ignoriert werden \cite[9]{EveringhamDevelopmentKit.2012}.				


\subsection{Training, Validierung und Test}
Bevor die vortrainierten Modelle trainiert werden können, muss der gelabelte Datensatz in ein tf-record-Format umgewandelt werden. Das tf-record-Format beinhaltet den Datensatz in einer binären und seriellen Form, die den Speicherbedarf für die Hardware während des Trainings deutlich verringert. Zudem muss eine Label Map angelegt werden, die die Objektklassen einer ID zuordnet. Hierbei ist die ID = 0 für die Background-Klasse (Hintergrund) reserviert. Für die Trainingskonfiguration muss zudem die Konfigurationsdatei (config-File) der Object Detection API von den vortrainierten Netzen für das Transfer Learning angepasst werden. Diese Konfigurationsdatei dient dazu die Hyperparameter des Netzes für das Training anzupassen. Zudem werden weitere wichtige Informationen und Einstellungen für das Training festgelegt, wie das Resizing, die maximale Anzahl der Objektklassen, die Dateipfade zu den tf-record-Dateien für Training, Validierung und Test, den Dateipfad zum Checkpoint des vortrainierten Netzes, den Dateipfad zur Label Map, sowie die Evaluierungs-Metrik.


\subsubsection{Einstellungen der Hyperparameter}
Tabelle \ref{tab:ConfigHyperparameter} zeigt einige eingestellte Hyperparameter aus den Konfigurationsdateien der verwendteten Netze. Die config-Datei enthält folgende Hyperparameter:
\begin{itemize}
\item SSD-Modell-Hyperparameter
\begin{itemize}
\item Anzahl der Objektklassen
\item Image Resizer: Verringerung der Auflösung des Eingabebildes nach Breite und Höhe
\item Backbone-Netz- / Feature Extractor-Hyperparameter
\item Box Coder: Koordinatenumrechnung der Boxkoordinaten bezogen auf das Zentrum der Box zur oberen linken Ecke der Feature Map, da hier der Ursprung (0,0) ist
\item Matcher: Definiert den Schwellwert (Threshold) für ein \gls{TP} (Match)
\item Similarity calculator: Überprüfung von gleichen / doppelten Boxen
\item Box Predictor: Hyperparameter der Netzschichten nach dem Backbone-Netz
\item Anchor Generator: Einstellungen der Standardboxen
\item Post processing: Einstellungen zur Non-Max-Suppression
\item Einstellungen zur Kostenfunktion wie Localization Loss und Classification Loss
\item Hintergrund als Rejectionklasse mit der id=0 belegen
\end{itemize}

\item Trainingskonfiguration
\begin{itemize}
\item Batch size
\item Data augmentation
\item Momentum optimizer: Einstellungen zum Verlauf der Lernrate während des Trainings (Default ist ein Cosine Decay) und des Momentum-Parameter
\item Fine tune checkpoint: Dateipfad zum Checkpoint des vortrainierten Netzes bei dem das Training für das neue Netz starten soll. Hierbei werden die Werte der Gewichte und Biases vom vortrainierten Netz als Initialisierung verwendet.
\item Anzahl der Steps des gesamten Trainings unabhängig von den Steps der Lernratenkurve
\item Begrenzung der Bounding Boxen: Default sind 100
\item Fine tune checkpoint type: Einstellungen, ob es sich um eine Objektdetektion oder Klassifizierung handelt
\end{itemize}
\item Train input reader: Dateipfade zur Label Map und der tf-record-Datei für das Training
\item Evaluierungskonfiguration: Default ist die COCO Detection Metrik, die auch verwendet wurde
\item Eval input reader: Dateipfade zur Label Map und der tf-record-Datei für die Validierung oder Test
\end{itemize}

Beim Modell SSD MobileNet V2 320x320 ohne FPN-Bezeichnung sind noch zwei zusätzliche Punkte zu beachten. Die Bezeichnung 320x320 ist tatsächlich falsch, es handelt sich tatsächlich um ein Mobilenet mit einer Eingabeschicht von 300x300 Pixel. Zudem kann in den Netzschichten nach dem Backbone-Netz des SSD MobileNet V2 320x320 zusätzlich ein Dropout aktiviert werden. Dies wurde auch bei diesem Modell genutzt. Die anderen Modelle unterstützen diese Einstellung in der config-Datei nicht.\\
Die Einstellungen für das Training der Türdetektion für die Türen der codemanufaktur mit der allgemeinen Türdetektion unterscheidet sich nur anhand der Anzahl der Training-Steps und der Steps der Lernratenkurve:
\begin{itemize}
\item Allgemeine Türdetektion: 5000 Steps
\item Türdetektion auf die Türen der codemanufaktur: 10000 / 25000 Steps
\end{itemize}

Die 25000 Steps im Training der Türdetektion für die Türen der codemanufaktur sind zu hoch. Eine geringere Stepzahl hätte hier auch gereicht, da der Zuwachs an der \gls{mAP} gering ausfällt und auch der Total Loss und Validation Loss nicht mehr weiter signifikant abfällt. Bei einer zu hohen Stepanzahl steigt sogar das Risiko eines Overfittings. Es wurden zudem einige Einstellungen an der Lernrate ausprobiert. Hier konnte aber keine signifikante Verbesserung des Trainings- und Validierungs-Loss bewirkt werden. Sollte die Lernrate zu hoch eingestellt sein steigt der Trainings-Loss sogar an. Ansonsten wurden die Einstellungen der Hyperparameter aus den vortrainierten Netzen übernommen, da für das Machine Learning eher die Qualität und Anzahl der Trainingsdaten entscheidend ist \cite[473]{Goodfellow.2018}. Außerdem wurden die vortrainierten Netze mit diesen Voreinstellungen mit guten Resultaten auf den COCO-Datensatz trainiert.

\begin{table}[htbp]
\centering
\begin{tabularx}{\textwidth}{p{0.3\textwidth}|X|X|X|X}
\hline
\textbf{Hyperparameter} & \textbf{SSD MobileNet V2 320x320} & \textbf{SSD MobileNet V2 FPNLite 320x320} & \textbf{SSD MobileNet V2 FPNLite 640x640} & \textbf{SSD ResNet50 V1 FPN 640x640}\\
\hline
Image resizer & 300x300 (Fehler in der Bezeichnung des Netzes) & 320x320 & 640x640 & 640x640\\
\hline
Depth multiplier des Backbone-Netz & 1,0 & 1,0 & 1,0 & 1,0\\
\hline
L2-Regularisierungsparamter des Backbone-Netz & 3,99e-5 & 3,99e-5 & 3,99e-5 & 0,000399\\
\hline
Aktivierungsfunktion des Backbone-Netz & ReLU6 & ReLU6 & ReLU6 & ReLU6\\
\hline
matched threshold & 0,5 & 0,5 & 0,5 & 0,5\\
\hline
L2-Regularisierungsparamter & 3,99e-5 & 3,99e-5 & 3,99e-5 & 0,000399\\
\hline
Aktivierungsfunktion & ReLU6 & ReLU6 & ReLU6 & ReLU\\
\hline
use Dropout & true / false & nicht verfügbar & nicht verfügbar & nicht verfügbar\\
\hline
Dropout keep probability & 0,8 (20\% Dropout) & - & - & -\\
\hline
Non-Max-Suppression IoU-Threshold & 0,6 & 0,6 & 0,6 & 0,6\\
\hline
Batch Size & 8 & 8 & 8 & 8\\
\hline
Augmentation & Random horizontal flip, random crop & Random horizontal flip, random crop & Random horizontal flip, random crop & Random horizontal flip, random crop\\
\hline
Anfangslernrate & 0,013 & 0,026 & 0,026 & 0,013\\
\hline
Maximale Lernrate & 0,08 & 0,08 & 0,08 & 0,04\\
\hline
Warm Up Steps des Trainings & 2000 & 1000 & 1000 & 2000\\
\hline
Maximale Steps der Lernratenkurve & 5000 & 5000 & 5000 & 5000\\
\hline
Maximale Steps des Trainings & 5000 & 5000 & 5000 & 5000\\
\hline
Momentum-Parameter & 0,899 & 0,899 & 0,899 & 0,899\\
\hline
Evaluierungsmetrik & COCO detection metric & COCO detection metric & COCO detection metric & COCO detection metric\\
\hline
Evaluierungs-Epochen & 1 & 1 & 1 & 1\\
\hline

\end{tabularx}
\caption{Einige Einstellungen der Hyperparameter für die allgemeine Türdetektion}
\label{tab:ConfigHyperparameter}
\end{table}

\FloatBarrier

\subsubsection{Test- und Validierungs-Ergebnisse des Machine Learnings}
Nachfolgend werden die Ergebnisse des Test- und Validierungsdatensatzes der Türdetektion anhand der COCO-Metrik dargestellt. 

\begin{table}[htbp]
\centering
\begin{tabularx}{\textwidth}{p{0.2\textwidth}|X|X|X|X|X}
\hline
\textbf{Modell} & \textbf{mAP} & \textbf{mAP@IoU von 0,5} & \textbf{mAP@IoU von 0,75} & \textbf{AR@1} & \textbf{AR@10}\\
\hline
SSD MobileNet V2 320x320 & Test:0,4027, Val:0,6257 & Test:0,6387, Val:0,901 & Test:0,4645, Val:0,6809 & Test:0,3937, Val:0,5585 & Test:0,5816, Val:0,7321\\
\hline
SSD MobileNet V2 320x320 Dropout & Test:0,4324, Val:0,6092 & Test:0,6723, Val:0,887 & Test:0,4834, Val:0,6689 & Test:0,4209, Val:0,566 & Test:0,5861, Val:0,7151\\
\hline
SSD MobileNet V2 FPNLite 320x320 & Test:0,5116, Val:0,7179 & Test:0,7494, Val:0,9467 & Test:0,6108, Val:0,8255 & Test:0,5127, Val:0,6226 & Test:0,638, Val:0,7698\\
\hline
SSD MobileNet V2 FPNLite 640x640 & Test:0,534, Val:0,7084 & Test:0,7406, Val:0,9292 & Test:0,6311, Val:0,7883 & Test:0,5171, Val:0,6396 & Test:0,6411, Val:0,7491\\
\hline
SSD ResNet50 V1 FPN 640x640 & Test:0,4764, Val:0,7152 & Test:0,6871, Val:0,9465 & Test:0,5624, Val:0,7843 & Test:0,4658, Val:0,6264 & Test:0,6278, Val:0,7679\\
\hline

\end{tabularx}
\caption{Ergebnisse der allgemeinen Türdetektion nach der COCO-Metrik}
\label{tab:AllgemeineDetektionResultateCOCO}
\end{table}

\begin{figure}[htbp]
  \centering
\begin{tikzpicture}
\begin{axis}[
	xbar, xmajorgrids=true, xmin=0, xmax=0.6, width=11cm, height=10cm, enlarge y limits=0.2, xlabel={\textbf{mAP}}, symbolic y coords={SSD MobileNet V2 320x320, SSD MobileNet V2 320x320 Dropout, SSD MobileNet V2 FPNLite 320x320, SSD MobileNet V2 FPNLite 640x640, SSD ResNet50 V1 FPN 640x640}, y tick label style={anchor=east,text width=5cm,align=right},ytick=data, nodes near coords, nodes near coords align={horizontal},
	]
\addplot coordinates
	{(0.4027,SSD MobileNet V2 320x320)(0.4324,SSD MobileNet V2 320x320 Dropout) (0.5116,SSD MobileNet V2 FPNLite 320x320) (0.534,SSD MobileNet V2 FPNLite 640x640) (0.4764,SSD ResNet50 V1 FPN 640x640)};
\end{axis}
\end{tikzpicture}
\caption{Ergebnisse des Testsets der allgemeinen Türdetektion nach der COCO-Metrik}
  \label{fig:BalkendiagrammAllgemeinCOCO}
\end{figure}


\begin{table}[htbp]
\centering
\begin{tabularx}{\textwidth}{p{0.2\textwidth}|X|X|X|X|X}
\hline
\textbf{Modell} & \textbf{mAP} & \textbf{mAP@IoU von 0,5} & \textbf{mAP@IoU von 0,75} & \textbf{AR@1} & \textbf{AR@10}\\
\hline
SSD MobileNet V2 320x320 & Test:0,1622, Val:0,7728 & Test:0,3198, Val:0,9637 & Test:0,1602, Val:0,8927 & Test:0,1745, Val:0,6677 & Test:0,3113, Val:0,8323\\
\hline
SSD MobileNet V2 FPNLite 320x320 & Test:0,2393, Val:0,8678 & Test:0,4839, Val:0,9969 & Test:0,2471, Val:0,959 & Test:0,2236, Val:0,7516 & Test:0,3726, Val:0,8935\\
\hline
SSD MobileNet V2 FPNLite 640x640 & Test:0,2162, Val:0,8161 & Test:0,4013, Val:0,9723 & Test:0,2245, Val:0,9254 & Test:0,2335, Val:0,6839 & Test:0,3608, Val:0,871\\
\hline

\end{tabularx}
\caption{Ergebnisse der Türdetektion für die codemanufaktur nach der COCO-Metrik}
\label{tab:CodemanufakturDetektionResultateCOCO}
\end{table}


\begin{figure}[htbp]
  \centering
\begin{tikzpicture}
\begin{axis}[
	xbar, xmajorgrids=true, xmin=0, xmax=0.6, width=11cm, height=6.5cm, enlarge y limits=0.3, xlabel={\textbf{mAP}}, symbolic y coords={SSD MobileNet V2 320x320, SSD MobileNet V2 FPNLite 320x320, SSD MobileNet V2 FPNLite 640x640}, y tick label style={anchor=east,text width=5cm,align=right},ytick=data, nodes near coords, nodes near coords align={horizontal},
	]
\addplot coordinates
	{(0.1622,SSD MobileNet V2 320x320) (0.2393,SSD MobileNet V2 FPNLite 320x320) (0.2162,SSD MobileNet V2 FPNLite 640x640)};
\end{axis}
\end{tikzpicture}
\caption{Ergebnisse des Testsets der codemanufaktur Türdetektion nach der COCO-Metrik}
  \label{fig:BalkendiagrammCodemanufakturCOCO}
\end{figure}



\FloatBarrier

\subsubsection{Trainings-Ergebnisse des Generalisierungsfehlers des Machine Learnings}
Die nachfolgenden Tabellen zeigen die Ergebnisse des Classification-, Localization- und Total Loss aus dem Machine-Learning-Training an. Hieraus lässt sich die Generalisierungsfähigkeit der trainierten Netze abschätzen.

\begin{table}[htbp]
\centering
\begin{tabularx}{\textwidth}{p{0.2\textwidth}|X|X|X}
\hline
\textbf{Modell} & \textbf{Classification Loss} & \textbf{Localization Loss} & \textbf{Total Loss}\\
\hline
SSD MobileNet V2 320x320 & Test:0,6382, Val:0,2473, Train:0,2469 & Test:0,1966, Val:0,1253, Train:0,07865 & Test:0,9552, Val:0,4931 Train:0,446\\
\hline
SSD MobileNet V2 320x320 Dropout & Test:0,5824, Val:0,2541, Train:0,1005 & Test:0,203, Val:0,1006, Train:0,05682 & Test:0,9102, Val:0,4795, Train:0,2822\\
\hline
SSD MobileNet V2 FPNLite 320x320 & Test:0,4605, Val:0,2023, Train:0,03997 & Test:0,1727, Val:0,07645, Train:0,01214 & Test:0,7802, Val:0,4258 Train:0,1991\\
\hline
SSD MobileNet V2 FPNLite 640x640 & Test:0,5613,Val:0,235, Train:0,03561 & Test:0,1931, Val:0,06567, Train:9,9128e-3 & Test:0,8991, Val:0,4454, Train:0,1902\\
\hline
SSD ResNet50 V1 FPN 640x640 & Test:0,5942, Val:0,242, Train:0,03345 & Test:0,1525, Val:0,08062, Train:7,6636e-3 & Test:0,9437, Val:0,5196, Train:0,2381\\
\hline

\end{tabularx}
\caption{Ergebnisse der allgemeinen Türdetektion}
\label{tab:AllgemeineDetektionResultate}
\end{table}



\begin{table}[htbp]
\centering
\begin{tabularx}{\textwidth}{p{0.2\textwidth}|X|X|X}
\hline
\textbf{Modell} & \textbf{Classification Loss} & \textbf{Localization Loss} & \textbf{Total Loss}\\
\hline
SSD MobileNet V2 320x320 & Test:1,622, Val:0,1437, Train:0,04133 & Test:0,4797, Val:0,05379, Train:0,01276 & Test:2,216, Val:0,3119 Train:0,1684\\
\hline
SSD MobileNet V2 FPNLite 320x320 & Test:1,451, Val:0,1484, Train:0,02067 & Test:0,3947, Val:0,04495, Train:1,4115e-3 & Test:1,929, Val:0,2769 Train:0,1057\\
\hline
SSD MobileNet V2 FPNLite 640x640 & Test:1,374, Val:0,2921, Train:0,02359 & Test:0,4033, Val:0,05568, Train:2,6841e-3 & Test:1,899, Val:0,4694, Train:0,1479\\
\hline

\end{tabularx}
\caption{Ergebnisse der Türdetektion für die codemanufaktur}
\label{tab:CodemanufakturDetektionResultate}
\end{table}




\FloatBarrier

\subsubsection{Dauer des Machine Learnings}
Aus Tabelle \ref{tab:DauerTraining} lässt sich die Trainingsdauer der Netze mit GPU und CPU ablesen.

\begin{table}[htbp]
\centering
\begin{tabularx}{\textwidth}{p{0.2\textwidth}|X|X|X|X}
\hline
\textbf{Modell} & \textbf{Dauer bei 5000 Steps mit GPU} & \textbf{Steps per Sekunde mit GPU} & \textbf{Dauer bei 10000/25000 Steps mit CPU} & \textbf{Steps per Sekunde mit CPU}\\
\hline
SSD MobileNet V2 320x320 & 17 Minuten 10 Sekunden & 4,797 & 4 Stunden 39 Minuten 4 Sekunden bei 10000 Steps & 0,5927\\
\hline
SSD MobileNet V2 320x320 Dropout & 23 Minuten 29 Sekunden & 3,472 & - & -\\
\hline
SSD MobileNet V2 FPNLite 320x320 & 29 Minuten 56 Sekunden & 2,716 & 15 Stunden 45 Minuten 35 Sekunden bei 25000 Steps & 0,437\\
\hline
SSD MobileNet V2 FPNLite 640x640 & 43 Minuten 31 Sekunden & 1,879 & 21 Stunden 0 Minuten 53 Sekunden bei 10000 Steps & 0,1311\\
\hline
SSD ResNet50 V1 FPN 640x640 & 45 Minuten 21 Sekunden & 1,804 & Nach 8 Stunden 4 Minuten 22 Sekunden bei Step 1300 abgebrochen & 0,04126\\
\hline
\hline
\end{tabularx}
\caption{Dauer des Trainings}
\label{tab:DauerTraining}
\end{table}



\FloatBarrier

\subsubsection{Plots des Trainings des SSD MobileNet FPNLite 320x320}

Folgende Abbildungen \ref{fig:AllgemeinLoss}, \ref{fig:AllgemeinLernrateStepsProSekunde}, \ref{fig:AllgemeinCOCO}, \ref{fig:Loss}, \ref{fig:LernrateStepsProSekunde}, \ref{fig:COCO} zeigen die Plots des Trainings und der Validierung des SSD MobileNet V2 FPNLite 320x320.

\begin{figure}[htbp]
  \centering  
  \includegraphics[scale=0.21]{img/ssdMobilenetFPNLiteCSV/TotalLoss.pdf}
  \includegraphics[scale=0.21]{img/ssdMobilenetFPNLiteCSV/ClassificationLoss.pdf}
  \includegraphics[scale=0.21]{img/ssdMobilenetFPNLiteCSV/LocalizationLoss.pdf}
  \includegraphics[scale=0.21]{img/ssdMobilenetFPNLiteCSV/RegularizationLoss.pdf}
  \caption{Trainings- und Validierungs-Loss der allgemeinen Türdetektion des SSD MobileNet V2 FPNLite 320x320}
  \label{fig:AllgemeinLoss}
\end{figure}


\begin{figure}[htbp]
  \centering  
  \includegraphics[scale=0.21]{img/ssdMobilenetFPNLiteCSV/Lernrate.pdf}
  \includegraphics[scale=0.21]{img/ssdMobilenetFPNLiteCSV/StepsProSekunde.pdf}
  \caption{Lernkurve nach Cosine Decay und Steps pro Sekunde der allgemeinen Türdetektion des SSD MobileNet V2 FPNLite 320x320}
  \label{fig:AllgemeinLernrateStepsProSekunde}
\end{figure}


\begin{figure}[htbp]
  \centering  
  \includegraphics[scale=0.21]{img/ssdMobilenetFPNLiteCSV/mAP.pdf}
  \includegraphics[scale=0.21]{img/ssdMobilenetFPNLiteCSV/mAP50.pdf}
  \includegraphics[scale=0.21]{img/ssdMobilenetFPNLiteCSV/mAP75.pdf}
  \includegraphics[scale=0.21]{img/ssdMobilenetFPNLiteCSV/Recall1.pdf}
  \includegraphics[scale=0.21]{img/ssdMobilenetFPNLiteCSV/Recall10.pdf}
  \caption{Ergebnisse der Validierung nach der COCO-Metrik der allgemeinen Türdetektion des SSD MobileNet V2 FPNLite 320x320}
  \label{fig:AllgemeinCOCO}
\end{figure}





\begin{figure}[htbp]
  \centering  
  \includegraphics[scale=0.21]{img/ssdMobilenetFPNLiteCCSV/TotalLoss.pdf}
  \includegraphics[scale=0.21]{img/ssdMobilenetFPNLiteCCSV/ClassificationLoss.pdf}
  \includegraphics[scale=0.21]{img/ssdMobilenetFPNLiteCCSV/LocalizationLoss.pdf}
  \includegraphics[scale=0.21]{img/ssdMobilenetFPNLiteCCSV/RegularizationLoss.pdf}
  \caption{Trainings- und Validierungs-Loss der codemanufaktur Türdetektion des SSD MobileNet V2 FPNLite 320x320}
  \label{fig:Loss}
\end{figure}


\begin{figure}[htbp]
  \centering  
  \includegraphics[scale=0.21]{img/ssdMobilenetFPNLiteCCSV/Lernrate.pdf}
  \includegraphics[scale=0.21]{img/ssdMobilenetFPNLiteCCSV/StepsPerSec.pdf}
  \caption{Lernkurve nach Cosine Decay und Steps pro Sekunde der codemanufaktur Türdetektion des SSD MobileNet V2 FPNLite 320x320}
  \label{fig:LernrateStepsProSekunde}
\end{figure}


\begin{figure}[htbp]
  \centering  
  \includegraphics[scale=0.21]{img/ssdMobilenetFPNLiteCCSV/mAP.pdf}
  \includegraphics[scale=0.21]{img/ssdMobilenetFPNLiteCCSV/mAP50.pdf}
  \includegraphics[scale=0.21]{img/ssdMobilenetFPNLiteCCSV/mAP75.pdf}
  \includegraphics[scale=0.21]{img/ssdMobilenetFPNLiteCCSV/Recall1.pdf}
  \includegraphics[scale=0.21]{img/ssdMobilenetFPNLiteCCSV/Recall10.pdf}
  \caption{Ergebnisse der Validierung nach der COCO-Metrik der codemanufaktur Türdetektion des SSD MobileNet V2 FPNLite 320x320}
  \label{fig:COCO}
\end{figure}

\FloatBarrier



\subsection{Konvertierung des Modells zu TensorFlow Lite}
Die Konvertierung der trainierten Modelle in Tensorflow-Lite-Modelle erfolgt in mehreren Schritten. Nachfolgend sind die einzelnen Schritte aufgezeigt:
\begin{itemize}
\item Umwandlung der aus dem Training generierten Checkpoints in ein Saved-Model
\item Umwandlung des Saved-Model in ein Saved-Model als TFLite-Graph
\item Umwandlung des Saved-Model als TFLite-Graph in ein (quantisiertes) TFLite-Model als tflite-Datei (optimiertes Flatbuffer-Format)
\item Hinzufügen von Meta-Daten (Beschreibungsdaten) zur tflite-Datei
\end{itemize}

In Bezug auf die Checkpoints stellen diese Speicherpunkte der Parameter des Modells dar und werden beim Training alle 1000 Steps angelegt. Mit dem Saved-Model-Format können die Modelle dann wiederum in der TensorFlow-Low-Level-API oder der TensorFlow-High-Level-API Keras geladen werden, da diese die Modell-Architektur und die trainierten Parameter enthalten. Für eine Konvertierung zum TensorFlow-Lite-Format muss das Saved-Model in ein Saved-Model mit TFLite-Graph konvertiert werden. Schließlich kann dann dieses Saved-Model in ein TensorFlow-Lite-Modell mit oder ohne Quantisierung mittels TensorFlow-Lite-Konverter über die Python-API von TensorFlow umgewandelt werden \cite{TensorFlow.8102021}, \cite{TensorFlow.8122021}.\\
Die Quantisierung wandelt die Parameter des Modells vom Float32-Datentyp in ganzzahlige Datentypen vom Typ Integer von 8-Bit um \cite{TensorFlow.8122021}, \cite[2-3]{Jacob.12152017}. Formel \ref{eq:Dequantisierung} zeigt die Dequantisierung durch Annäherung von 8-Bit-Werten zu Gleitkommawerten \cite{TensorFlow.8122021}, \cite[4-5]{Krishnamoorthi.2018}, \cite[2-3]{Jacob.12152017}. Formel \ref{eq:Quantisierung} zeigt die Quantisierung von Gleitkommawerten zu 8-Bit-Ganzzahlwerten \cite[4-5]{Krishnamoorthi.2018}. 


\begin{align}
	r\:{=}\: (q - Z) \cdot S
    \label{eq:Dequantisierung}
\end{align}

\begin{align}
	q\:{=}\: round\Bigl(\frac{r}{S}\Bigr) + Z
    \label{eq:Quantisierung}
\end{align}

Bei den Formeln \ref{eq:Dequantisierung} und \ref{eq:Quantisierung} werden ein Nullpunkt \gls{Nullpunkt} als int8-Wert und ein Scale \gls{Scale} als Float32-Wert festgelegt \cite[2-3]{Jacob.12152017}. Der Scale gibt die Schrittweite der Quantisierung an \cite[2-3]{Jacob.12152017}, \cite[4-5]{Krishnamoorthi.2018}. \gls{Ganzzahl} gibt den quantisierten Ganzzahlwert, \gls{Floatzahl} den Gleitkommawert an. Sowohl für Gewichte als auch Aktivierungen kann die Quantisierung angewendet werden. Folgende Übersicht zeigt die Unterschiede zwischen der Quantisierung von Gewichten und Aktivierungen an:
\begin{itemize}
\item Gewichte pro Achse (Kanal) oder pro Tensor, durch int8-Zweierkomplementwerte im Bereich [-127, 127] mit Nullpunkt \gls{Nullpunkt} gleich 0
\item Aktivierungen/Eingaben pro Tensor, durch int8-Zweierkomplementwerte im Bereich [-128, 127], mit einem Nullpunkt \gls{Nullpunkt} im Bereich [-128, 127]
\end{itemize}

Es gibt unterschiedliche Stufen der Quantisierung in TensorFlow Lite. Tabelle \ref{tab:Quantisierung} zeigt die Quantisierungsmethoden. 

\begin{table}[htbp]
\centering
\begin{tabularx}{\textwidth}{p{0.3\textwidth}|X|X}
\hline
\textbf{Technik} & \textbf{Leistung} & \textbf{Hardware}\\
\hline
Quantisierung des Dynamikbereichs & 4x kleineres Modell, 2x-3x Beschleunigung / schnellere Inferenzzeit & Zentralprozessor (CPU)\\
\hline
Vollständige ganzzahlige Quantisierung & 4x kleineres Modell, 3x+ Beschleunigung / schnellere Inferenzzeit & CPU, Edge-TPU, Mikrocontroller\\
\hline
Float16-Quantisierung & 2x kleiner, GPU-Beschleunigung & CPU, GPU\\
\hline

\end{tabularx}
\caption{Quantisierungsmethoden \cite{TensorFlow.8122021}}
\label{tab:Quantisierung}
\end{table}

Quantisierung des Dynamikbereichs bedeutet die Quantisierung der Gewichte und Bias. Eine vollständige Quantisierung beinhaltet neben der Quantisierung der Gewichte auch die Quantisierung von Aktivierungen, Eingabe- und Ausgabeschichten \cite{TensorFlow.8122021}. \\
Modelleingaben, Aktivierungen und Modellausgaben sind im Gegensatz zu Gewichten und Bias variable Tensoren (variable mehrdimensionale Arrays), bei denen der min-max-Bereich der Gleitkommawerte nicht im Vornherein geschätzt oder kalibriert werden kann. Hier muss für eine Schätzung eine Inferenz des Modells mit einer Teilmenge des Trainingsdatensatzes durchgeführt werden \cite{TensorFlow.8122021}. Für die trainierten Modelle dieser Arbeit wurde die TensorFlow-Lite-Konvertierung mit und ohne Quantisierung vorgenommen. Tabelle \ref{tab:QuantisierungModelle} zeigt die Quantisierungsmethoden der trainierten Netze.


\begin{table}[htbp]
\centering
\begin{tabularx}{\textwidth}{p{0.3\textwidth}|X|X|X}
\hline
\textbf{Modell} & \textbf{Technik} & \textbf{Modellgröße in Kilobyte (KB)} & \textbf{Hardware}\\
\hline
SSD MobileNet V2 320x320 & Unquantisiert & 18036 & CPU, GPU\\
\hline
SSD MobileNet V2 320x320 & Quantisierung des Dynamikbereichs & 5015 & CPU\\
\hline
SSD MobileNet V2 320x320 & Quantisierung des Dynamikbereichs und der Eingabeschicht & 5090 & CPU\\
\hline
\hline
\hline
SSD MobileNet V2 FPNLite 320x320 & Unquantisiert & 11233 & CPU, GPU\\
\hline
SSD MobileNet V2 FPNLite 320x320 & Quantisierung des Dynamikbereichs & 3524 & CPU\\
\hline
SSD MobileNet V2 FPNLite 320x320 & Quantisierung des Dynamikbereichs und der Eingabeschicht & 3673 & CPU\\
\hline
\hline
\hline
SSD MobileNet V2 FPNLite 640x640 & Unquantisiert & 11832 & CPU, GPU\\
\hline
SSD MobileNet V2 FPNLite 640x640 & Quantisierung des Dynamikbereichs & 4123 & CPU\\
\hline
SSD MobileNet V2 FPNLite 640x640 & Quantisierung des Dynamikbereichs und der Eingabeschicht & 4273 & CPU\\
\hline
\hline
\hline
SSD ResNet50 V1 FPN 640x640 & Unquantisiert & 197944 & CPU, GPU\\
\hline
SSD ResNet50 V1 FPN 640x640 & Quantisierung des Dynamikbereichs & 51023 & CPU\\
\hline
SSD ResNet50 V1 FPN 640x640 & Quantisierung des Dynamikbereichs und der Eingabeschicht & 51184 & CPU\\
\hline

\end{tabularx}
\caption{Quantisierungsmethoden der trainierten Modelle}
\label{tab:QuantisierungModelle}
\end{table}

Wie in Tabelle \ref{tab:QuantisierungModelle} zu sehen, sind die Modelle ohne Quantisierung deutlich größer (um circa den Faktor 3 bis 4). Die Modellgröße hat dementsprechend auch eine große Auswirkung auf die Inferenzzeit. Zudem muss beachtet werden, dass ein quantisiertes Modell auf der GPU nicht mit Integer-Berechnungen ausgeführt werden kann. GPU's rechnen immer mit Gleitkommawerten.\\
Nach der Quantisierung werden zu den TensorFlow-Lite-Modellen noch Beschreibungsinformationen in Form von Meta-Daten hinzugefügt, um eine Fehlermeldung beim Ausführen der Modelle zu verhindern. Über das Open Source Tool Netron \cite{GitHub.1282021b} lässt sich die Netzarchitketur der TensorFlow-Lite-Modelle visualisieren und die Eingabe- und Ausgabeschicht nach Größe und Datentypen kontrollieren.


\section{Implementierung der Navigation mittels Android App}
In den nachfolgenden Abschnitten wird auf die Einbindung der TensorFlow-Lite-Modelle, die Algorithmen für die Türdetektion und Hindernisvermeidung und deren Zusammenführung mittels Zustandsautomaten in einer Android-App eingegangen.

\subsection{Einbindung der trainierten Netze}
Die Einbindung der Modelle als TensorFlow-Lite-Modelle erfolgt über die TensorFlow Lite Interpreter API mittels der Programmiersprache Java. Über die Interpreter API können folgende Optionen für die Inferenz der Modelle definiert werden:
\begin{itemize}
\item NnApiDelegate(): Standardmäßige Inferenz über CPU
\item setNumThreads(numThreads): Anzahl der Threads über die CPU, die für Operationen verwendet werden sollen, sofern sie Multithreading unterstützen
\item GpuDelegate(): Inferenz über die GPU
\item setUseXNNPACK: (Experimentell) Optimierte Ausführung von Gleitkommaberechnungen auf Gleitkomma-CPU-Kernels
\end{itemize}

Die Inferenz über die TensorFlow Lite Interpreter API mittels Java wird dann bei einem Eingang und einem Ausgang über den Funktionsaufruf \textit{interpreter.run(inputImageBuffer, outputByteBuffer)} ausgeführt. Bei mehreren Eingängen und Ausgängen wie bei der Objektdetektion, wo die Ausgabe mehrere Werte wie Bounding Box Koordinaten, Confidence, Anzahl der Detektionen und Name der Objekte enthält, wird der Funktionsaufruf \textit{interpreter.runForMultipleInputsOutputs(inputArray, outputMap)} verwendet.\\
Die Aufnahmen als einzelne RGB-Bilder der Smartphone-Kamera als Input für die Modelle werden mittels der Android Camera API verarbeitet. Die Camera2 API wird vom Smartphone nicht unterstützt. Die Bildwiederholrate (Frames per Second) schwankt zwischen 15 und 20 Bilder pro Sekunde. Theoretisch wären durch die Smartphone-Kamera maximal 30 Bilder pro Sekunde möglich, jedoch nehmen die Umwandlung vom Kamerabild im Format YUV420SP zu RGB Performance weg. Zusätzlich müssen die Eingangsdaten, die als RGB-Bilder vorliegen, für die unquantisierten Modelle, die Float32-Werte verarbeiten, standardisiert werden:
\begin{itemize}
\item Unquantisierte Modelle der Türdetektion: Image\_Mean=127,5; Image\_Std=127,5
\item MiDAs für Depth Estimation: Image\_Mean = 115,0; Image\_Std = 58,0
\item PyDNet für Depth Estimation: Image\_Mean=0,0; Image\_Std=255,0 
\end{itemize}

Die RGB-Bilder liegen als 8-Bit-Werte im Bereich [0; 255] vor. Die Image\_Mean entspricht dem Mittelwert \gls{MittelwertX}, die Image\_Std der Standardabweichung \gls{StandardabweichungX}. Nun kann anhand von Formel \ref{eq:Standardisierung} aus Kapitel \ref{StandardisierungNormierung}, die Standardisierung durchgeführt werden. Für die unquantisierten Modelle der Türdetektion ergibt sich nach der Standardisierung ein Bereich von [-1,0; 1,0]. \\
Die Inferenz der Türdetektion und Depth Estmation laufen beide in einem Background-Thread, wobei als erstes die Türdetektion-Inferenz und danach die Depth Estimation-Inferenz ausgeführt wird. Dadurch addieren sich die Inferenzzeiten der Türdetektion und Depth Estimation in diesem Background-Thread.


\subsection{Algorithmus der Zielnavigation mittels Türdetektion}
Die Türdetektion und Zielnavigation zur Tür basiert auf der Breite, Höhe und Position der Bounding Box, skaliert auf die Bildschirmauflösung des Smartphones und der Sensororientierung der Smartphone-Kamera im Potrait-Modus, da das Smartphone vertikal an den Roboter befestigt ist. Algorithmus \ref{alg:Zielnavigation} und Abbildung \ref{fig:Zielnavigation} zeigen die Zielnavigation mittels der Größe und Position der Bounding Boxen der Türdetektion bezogen auf die Auflösung des Smartphone-Bildschirms. Zur Erklärung in Algorithmus \ref{alg:Zielnavigation} für die Fälle, dass die Höhe und Breite der Bounding Box größer als 90 \% der Höhe und Breite der Auflösung des Smartphone-Screens sind, soll dies als Fehldetektion eingestuft werden. Dieses Vorgehen soll Fehldetektionen im Algorithmus abfangen.

\SetKw{Or}{or}
\SetKw{And}{and}
\SetKwInOut{Input}{input}
\SetKwInOut{Output}{output}

\begin{algorithm}[htbp] 
\SetAlgoLined 
\Input{List<TrackedRecognition> trackedObjects, List<Pair<Float, Detector.Recognition> > rectsToTrack}
\Output{String commandMessage}
\If{rectanglesToTrack.isEmpty()}{
	commandMessage $\leftarrow$ No door\;
}
\ForEach{recogonizedElement in trackedObjects}{
	\If{recognizedElement.title.equals(Door)}{
		rgbFrameToScreen.mapRectangle(detectionScreenRectangleNav, recognizedElement.location)\;
		\If{detectionScreenRectangleNav.width() $>$ (maxWidthScreen * $0.9$)}{
			commandMessage $\leftarrow$ No door\;
	 	}
	 	\If{detectionScreenRectangleNav.width() $>$ (maxHeightScreen * $0.9$)}{
			commandMessage $\leftarrow$ No door\;
	 	}
	 	\If{detectionScreenRectangleNav.width() $<$ (maxWidthScreen * $0.6$)}{
			commandMessage $\leftarrow$ Door not reached\;
	 	}
	 	\uElseIf{detectionScreenRectangleNav.width() $>$ (maxWidthScreen * $0.6$) \And detectionScreenRectangleNav.width() $<$ (maxWidthScreen * $0.7$)}{
	 		commandMessage $\leftarrow$ Door reached\; 
	 	}
	 	\If{detectionScreenRectangleNav.centerX() $<$ (maxWidthScreen / $4$) \And detectionScreenRectangleNav.width() $<$ (maxWidthScreen * $0.5$)}{
			commandMessage $\leftarrow$ Door left\;
	 	}
	 	\uElseIf{detectionScreenRectangleNav.centerX() $>$ (maxWidthScreen * $0.75$) \And detectionScreenRectangleNav.width() $<$ (maxWidthScreen * $0.5$)}{
	 		commandMessage $\leftarrow$ Door right\; 
	 	}
	}
}
\caption{Zielnavigation mittels Türdetektion} 
\label{alg:Zielnavigation}
\end{algorithm}


\begin{figure}[htbp]
  \centering  
  \begin{tikzpicture}
 
\node[rectangle,
    draw = lightgray,
    minimum width = 1cm, 
    minimum height = 2cm] (r) at (0,0) {Tür};
    
\node[rectangle,
    draw = lightgray,
    minimum width = 1cm, 
    minimum height = 2cm] (s) at (4,0) {Tür};
    
\node[rectangle,
    draw = lightgray,
    minimum width = 1cm, 
    minimum height = 2cm] (t) at (8,0) {Tür};
    
\node[rectangle,
    draw = lightgray,
    minimum width = 3cm, 
    minimum height = 6cm] (u) at (4,-5) {Tür};
    
\draw[-latex] (3,0) -- (r.east) node[midway, above] {Turn left};
\draw[-latex] (5,0) -- (t.west) node[midway, above] {Turn right};

% Labels
\node[below=0.9cm, scale=1.0] at (s){Forward};
\node[below=0.8cm, scale=1.0] at (u){Stop};
 
\end{tikzpicture}

  \caption{Veranschaulichung der Zielnavigation}
  \label{fig:Zielnavigation}
\end{figure}

\FloatBarrier

\subsection{Algorithmus der Hindernisvermeidung}
Die Hindernisvermeidung wird mittels Depth Estimation (Kapitel \ref{DepthEstimation}) realisiert und der Ansatz für den Algorithmus aus \cite{PireStereoVision.2012} und \cite{Nalpantidis.2009} übernommen und angepasst. Dazu wird anhand der Tiefenkarte (Depth Map) aus dem neuronalen Netz heuristisch untersucht, ob Objekte vor der Smartphone-Kamera im Weg stehen. Hierzu wird zunächst die Ausgabe des Netzes als Float-Array ausgelesen und die Werte in den Bereich [0,0; 255,0] anhand von Formel \ref{eq:Normierung} normiert. Danach wird das normierte Float-Array mit den Disparitätswerten im Bereich [0,0; 255,0] auf Integer gecastet und in eine Bitmap überführt. Diese Bitmap wird dann in der Breite in 4 gleiche große Bereiche mit einem Rand geteilt. Die zwei mittleren Bereiche werden dann als zentralen Bildbereich (Central screen) zusammengefasst neben dem linken und rechten Bereich der Bitmap. Abbildung \ref{fig:Bitmap} zeigt die Aufteilung der Bitmap. Anschließend wird der Algorithmus \ref{alg:Hindernisvermeidung} zur heuristischen Analyse für die Hindernisvermeidung angewendet, in dem die Anzahl der Pixel \textit{p} über einen bestimmten Schwellwert \textit{T} des Disparitätswert \textit{D} gezählt werden. Diese Anzahl im Verhältnis zur gesamten Anzahl der Pixel im zentralen Bereich der Bitmap wird wiederum über einen Schwellwert \textit{r} ausgewertet und signalisiert, ob ein Hindernis im Weg ist. Falls ein Hindernis im Weg ist, werden im linken und rechten Bereich der Bitmap die durchschnittliche Disparität berechnet und dadurch die Ausweichrichtung bestimmt. Für die Schwellwerte wurden folgende Werte empirisch festgelegt:

\begin{itemize}
\item Schwellwert T=160
\item Schwellwert r=0,1
\end{itemize}

Kleine Schwellwerte erhöhen die Sensitivität der Hindernisvermeidung und können die Geradeausfahrt behindern. Größere Schwellwerte erhöhen das Risiko einer fehlgeschlagenen Hindernisvermeidung.

\begin{figure}[htbp]
  \centering  
  \begin{tikzpicture}

\node[rectangle,
    draw = lightgray,
    minimum width = 2cm, 
    minimum height = 4cm] (r) at (0,0) {Left};
    
\node[rectangle,
    draw = lightgray,
    minimum width = 2cm, 
    minimum height = 4cm] (s) at (2,0) {Central};
    
\node[rectangle,
    draw = lightgray,
    minimum width = 2cm, 
    minimum height = 4cm] (t) at (4,0) {Central};
    
\node[rectangle,
    draw = lightgray,
    minimum width = 2cm, 
    minimum height = 4cm] (u) at (6,0) {Right};
    
\draw (-1.5,2.5) -- (7.5,2.5) -- (7.5,-2.5) -- (-1.5,-2.5) -- (-1.5,2.5);
 
\end{tikzpicture}

  \caption{Veranschaulichung der Aufteilung der Bitmap zur Hindernisvermeidung}
  \label{fig:Bitmap}
\end{figure}


\begin{algorithm}[htbp] 
\SetAlgoLined 
\Input{Depth map as a bitmap}
\Output{String obstacleMessage}
\ForAll{the pixels p of the central window}{
	\If{D(p) $>$ T}{
		counter++\;
	}
	numC++\;
}
\eIf{counter $<$ r[0,1] of numC}{
	obstacleMessage $\leftarrow$ No obstacle\; 
}{ 
	\ForAll{the pixels p of the left window}{
	sumL =+ D(p)\;
	numL++\;
	}
	\ForAll{the pixels p of the right window}{
	sumR =+ D(p)\;
	numR++\;
	}
	avL = sumL / numL\;
	avR = sumR / numR\;
	\eIf{avL $<$ avR}{
		obstacleMessage $\leftarrow$ Obstacle right\; 
	}{ 
		obstacleMessage $\leftarrow$ Obstacle left\;  
	}
}
\caption{Hindernisvermeidung} 
\label{alg:Hindernisvermeidung}
\end{algorithm}

\FloatBarrier

\subsection{Zustandsautomat zur Zusammenführung der Türdetektion und Hindernisvermeidung}
Um die Navigation des Roboters aus Zielnavigation und Hindernisvermeidung zusammenzuführen, wird ein Zustandsautomat (State Machine) in der Android App verwendet. Dieser Zustandsautomat wird alle 100 Millisekunden in einer Schleife im Main (UI)-Thread ausgeführt. Abbildung \ref{fig:Zustandsautomat} zeigt den Zustandsautomaten.

\begin{figure}[htbp]
\centering  
  
\begin{tikzpicture} [draw=cyan!70!black, node distance = 11cm, on grid, auto,
    every loop/.style={stealth-}]
 
% State START 
\node (START) [state, initial, accepting, scale=0.6, initial text = {start}] {START};
 
% State DOOR    
\node (DOOR) [state, scale=0.6, below right of = START] {DOOR};

% State FINDDOORAGAIN    
\node (FINDDOORAGAIN) [state, scale=0.6, below of = DOOR] {FINDDOORAGAIN};

% State OBSTACLE    
\node (OBSTACLE) [state, scale=0.6, below right of = FINDDOORAGAIN] {OBSTACLE};

% State PASSOBSTACLE    
\node (PASSOBSTACLE) [state, scale=0.6, below left of = FINDDOORAGAIN] {PASSOBSTACLE};

% State END    
\node (END) [state, accepting, scale=0.6, right of = DOOR] {END};
 
% Arrows
\path [-stealth, thick]
	(START) edge [loop above, scale=0.7]  node [scale=0.7] {No door, Left turn for search door} ( )
    (START) edge[bend left] node [scale=0.7] {Door is detected}   (DOOR)
    (DOOR) edge [loop above]  node [scale=0.7] {Door not reached, no obstacle, Forward} ( )
    (DOOR) edge[bend right] node [scale=0.7] {Door reached, Stop}   (END)
    (DOOR) edge [loop left]  node [scale=0.7] {Door left, no obstacle, Left turn} ( )
    (DOOR) edge [loop right]  node [scale=0.7] {Door right, no obstacle, Right turn} ( )
    (DOOR) edge[bend left] node [scale=0.7] {Obstacle left/right, Stop}   (OBSTACLE)
    (DOOR) edge[bend left] node [scale=0.7] {No door}   (FINDDOORAGAIN)
    (OBSTACLE) edge[bend left] node [scale=0.7] {No obstacle, Forward} (PASSOBSTACLE)
    (OBSTACLE) edge [loop below]  node [scale=0.7] {Obstacle left, Right turn} ( )
    (OBSTACLE) edge [loop above]  node [scale=0.7] {Obstacle right, Left turn} ( )
    (PASSOBSTACLE) edge node [scale=0.7] {Obstacle left/right, Stop} (OBSTACLE)
    (PASSOBSTACLE) edge [loop below] node [scale=0.7] {State Time $<$ 3000 ms, Forward} ( )
    (PASSOBSTACLE) edge[bend left] node [scale=0.7] {State Time $>$ 3000 ms} (FINDDOORAGAIN)
    (FINDDOORAGAIN) edge[loop left] node [scale=0.7] {No door, obstacle was left, Left turn} ( )
    (FINDDOORAGAIN) edge[loop right] node [scale=0.7] {No door, obstacle was right, Right turn} ( )
    (FINDDOORAGAIN) edge[loop below] node [scale=0.7] {No door, no obstacle was on the way, Forward} ( )
    (FINDDOORAGAIN) edge[bend left] node [scale=0.7] {No door, obstacle right/left, Stop} (OBSTACLE)
    (FINDDOORAGAIN) edge[bend left] node [scale=0.7] {Door is detected} (DOOR)
    (END) edge[loop below] node [scale=0.7] {Door reached, Stop} ( );
\end{tikzpicture}

  \caption{Zustandsautomat der Roboternavigation}
  \label{fig:Zustandsautomat}
\end{figure}

\section{Evaluierung der Navigation durch Experiment}
Die Evaluierung der Roboternavigation dient dafür die Zielnavigation mittels allgemeiner- und codemanufaktur-Türdetektion zu vergleichen und die Hindernisvermeidung mittels Depth Estimation zu untersuchen.
Die Evaluierung gliedert sich in die Bereiche Türdetektion / Zielnavigation, Hindernisvermeidung und der kompletten Roboternavigation. Die Evaluierung wird als Experiment in den öffentlichen Büroflächen der codemanufaktur GmbH durchgeführt. Vor allem der Bereich der Cafeteria wird für die Evaluierung der Hindernisvermeidung und der kompletten Navigation, aufgrund des ausreichenden Platzbedarfs genutzt. Die Evaluierung wird mit den Modellen der allgemeinen Türdetektion und der speziell auf die Türen der codemanufaktur GmbH trainierten Modelle durchgeführt.

\subsection{Fernsteuerung und Spiegelung des Smartphone-Screens}
Für die Evaluierung wird dazu noch das Open Source Tool scrcpy von Genymobile \cite{GitHub.1282021} für die Spiegelung des Screens und die Fernsteuerung des Android-Smartphones verwendet.

\subsection{Evaluierung der Türdetektion}
Die Evaluierung der Türdetektion wird anhand der Detektion der verschiedenen Türen der codemanufaktur und der Zielnavigation des Roboters zu den Türen, sowie der Inferenzzeit der Modelle durchgeführt. Außerdem wird das Experiment mit dem SSD Mobilenet V2 FPNLite 320x320 durchgeführt, aufgrund der besten \gls{mAP} nach Tabellen \ref{tab:AllgemeineDetektionResultateCOCO} und \ref{tab:CodemanufakturDetektionResultateCOCO} neben dem SSD Mobilenet V2 FPNLite 640x640. Das SSD Mobilenet V2 FPNLite 640x640 hat den großen Nachteil des erhöhten Rechenaufwands bezüglich der doppelten Auflösung der Eingabeschicht und der daraus resultierenden höheren Inferenzzeit von circa 203 ms bei der quantisierten Variante. Tabelle \ref{tab:InferenzzeitModelle} zeigt die Inferenzzeiten der einzelnen Modelle auf dem verwendeten Smartphone mit CPU bei 4 Threads. Das quantisierte SSD Mobilenet V2 FPNLite 320x320 hat eine Inferenzzeit von circa 50 ms.

\begin{table}[htbp]
\centering
\begin{tabularx}{\textwidth}{p{0.3\textwidth}|X|X|X}
\hline
\textbf{Modell} & \textbf{Technik} & \textbf{Modellgröße in Kilobyte (KB)} & \textbf{Inferenzzeit in Millisekunden (ms)}\\
\hline
SSD MobileNet V2 320x320 & Unquantisiert & 18036 & 63\\
\hline
SSD MobileNet V2 320x320 & Quantisierung des Dynamikbereichs & 5015 & 93\\
\hline
SSD MobileNet V2 320x320 & Quantisierung des Dynamikbereichs und der Eingabeschicht & 5090 & 42\\
\hline
\hline
\hline
SSD MobileNet V2 FPNLite 320x320 & Unquantisiert & 11233 & 102
\\
\hline
SSD MobileNet V2 FPNLite 320x320 & Quantisierung des Dynamikbereichs & 3524 & 144\\
\hline
SSD MobileNet V2 FPNLite 320x320 & Quantisierung des Dynamikbereichs und der Eingabeschicht & 3673 & 50\\
\hline
\hline
\hline
SSD MobileNet V2 FPNLite 640x640 & Unquantisiert & 11832 & 352\\
\hline
SSD MobileNet V2 FPNLite 640x640 & Quantisierung des Dynamikbereichs & 4123 & 485\\
\hline
SSD MobileNet V2 FPNLite 640x640 & Quantisierung des Dynamikbereichs und der Eingabeschicht & 4273 & 203\\
\hline
\hline
\hline
SSD ResNet50 V1 FPN 640x640 & Unquantisiert & 197944 & 5116\\
\hline
SSD ResNet50 V1 FPN 640x640 & Quantisierung des Dynamikbereichs & 51023 & 2080\\
\hline
SSD ResNet50 V1 FPN 640x640 & Quantisierung des Dynamikbereichs und der Eingabeschicht & 51184 & 1670\\
\hline

\end{tabularx}
\caption{Inferenzzeiten der trainierten Modelle}
\label{tab:InferenzzeitModelle}
\end{table}

Die Minimum Confidence für die Verarbeitung der Werte aus den Tür-Detektionen-Modellen in der Smartphone-App wird wie folgt eingestellt:
\begin{itemize}
\item Allgemeine Türdetektion, Minimum Confidence: 0,5
\item codemanufaktur Türdetektion, Minimum Confidence: 0,8
\end{itemize}

Grund für die Unterschiede ist, dass die Netze, die mit den codemanufaktur-Türen trainiert wurden, eine viel höhere Confidence (Wahrscheinlichkeit) der Detektion auf die Türen der codemanufaktur GmbH aufweisen. Für die Netze der allgemeinen Türdetektion sind die Türen der codemanukatur GmbH bisher unbekannt und daher die Confidence (Wahrscheinlichkeit) der Detektion geringer.

\FloatBarrier

\subsubsection{Voruntersuchung der Detektion}
Für die Voruntersuchung der Türdetektion wurde das Smartphone in die Hand genommen und die Smartphone-Kamera an die verschiedenen Türen der codemanufaktur GmbH gerichtet, um zu überprüfen ob die Türen detektiert werden. Hierbei wurde ausschließlich das SSD Mobilenet V2 FPNLite 320x320 in den unterschiedlichen Quantisierungsvarianten verwendet.

\subsubsection{Evaluierung der Zielnavigation}
Für die Evaluierung der Zielnavigation wurde das Smartphone an den Roboter mit einem Gummiband befestigt (siehe Abbildung \ref{fig:Roboter}) und vom verwendteten Laptop mittels scrcpy ferngesteuert. Die Anfangsentfernung zur Tür wurde gemessen und der Roboter in einem Winkel von -30° versetzt zur Tür aufgestellt. In einen noch größeren Winkel konnte der Roboter nicht aufgestellt werden, da ansonsten eine andere Tür und nicht die gewünschte Tür angefahren wird. Abbildung \ref{fig:ZielnavigationRoboter} zeigt die Initialstellungen des Roboters zu den Türen. \\
Untersucht wird die Zielnavigation auf die Glasschiebetür in der Cafeteria, eine Holztür und zwei Glastüren, siehe Abbildung \ref{fig:ZielnavigationRoboter}. Für das Experiment werden 10 Läufe durchgeführt und ausgewertet, wie oft der Roboter an der jeweiligen Tür ankommt und im besten Fall auch direkt vor der Tür stehenbleibt. Zudem werden in einigen Läufen mittels scrcpy Videoaufzeichnungen des Smartphonescreens aufgenommen. Das grafische Interface der Smartphone-App ist in Abbildung \ref{fig:SmartphoneInterface} dargestellt.


\begin{figure}[htbp]
  \centering  
  \includegraphics[scale=0.07]{img/BilderExperiment/RoboterCafeteriaSchiebetuer.jpg}
  \includegraphics[scale=0.07]{img/BilderExperiment/RoboterMassband.jpg}
  \includegraphics[scale=0.07]{img/BilderExperiment/RoboterHolzTuer.jpg}
  \includegraphics[scale=0.07]{img/BilderExperiment/RoboterGlasTuer.jpg}
  \caption{Initialstellung des Roboters für die Zielnavigation}
  \label{fig:ZielnavigationRoboter}
\end{figure}

\begin{figure}[htbp]
  \centering  
  \includegraphics[scale=0.2]{img/SmartphoneScreen/ScreenshotDoor1.jpg}
  \caption{Grafisches Interface der Smartphone-App}
  \label{fig:SmartphoneInterface}
\end{figure}

\FloatBarrier

\subsection{Evaluierung der Navigation mit Hindernisvermeidung und kompletter Navigation}
Für die Evaluierung der Hindernisvermeidung und der kompletten Navigation wird grundsätzlich ein ähnliches Setting wie in der Evaluierung der Zielnavigation gewählt mit dem Unterschied, dass ein Hindernis auf dem Weg zur Tür gelegt wird. Aufgrund des Platzbedarfs für das Ausweichen des Hindernisses wurde hierfür ausschließlich die Glasschiebetür im Cafeteria-Bereich ausgewählt. Auch hier werden pro Hindernis 10 Läufe durchgeführt. Folgende Hindernisse werden evaluiert:
\begin{itemize}
\item Zwei Getränkekästen aufeinander gestappelt
\item Stuhl
\item Bürostuhl
\item Pflanzenvase
\item Person
\end{itemize}

Abbildung \ref{fig:HindernissenavigationRoboter} zeigt die verwendteten Objekte  ohne Person als Hindernisse. Abbildung \ref{fig:HindernisvermeidungSetting} zeigt den Versuchsaufbau mit der Pflanzenvase als Hindernis.


\begin{figure}[htbp]
  \centering  
  \includegraphics[scale=0.07]{img/HindernisExperiment/Beverage.jpg}
  \includegraphics[scale=0.07]{img/HindernisExperiment/Stuhl.jpg}
  \includegraphics[scale=0.07]{img/HindernisExperiment/BueroStuhl.jpg}
  \includegraphics[scale=0.07]{img/HindernisExperiment/Pflanzenvase.jpg}
  \caption{Hindernisse der Evaluierung der Hindernisvermeidung ohne Person}
  \label{fig:HindernissenavigationRoboter}
\end{figure}

\begin{figure}[htbp]
  \centering  
  \includegraphics[scale=0.07]{img/HindernisExperiment/SettingHindernisvermeidung.jpg}
  \includegraphics[scale=0.07]{img/HindernisExperiment/HindernisBeverage.jpg}
  \includegraphics[scale=0.07]{img/HindernisExperiment/HindernisStuhl.jpg}
  \caption{Versuchsaufbau der Hindernisvermeidung mit Pflanzenvase als Hindernis}
  \label{fig:HindernisvermeidungSetting}
\end{figure}

Die Inferenzzeit der Depth Estimation Modelle zeigt Tabelle \ref{tab:InferenzzeitDepthEstimation}. Die Hindernisvermeidung und Gesamtnavigation wurde ausschließlich mit dem MiDaS-Modell durchgeführt, da aus Zeitgründen die Anpassung der Schwellwerte T und r des Algorithmus \ref{alg:Hindernisvermeidung} nur mit dem MiDaS-Modell aufgrund der deutlich besseren Inferenzzeit möglich war. Für das PyDNet-Modell müssten die Schwellwerte aus Algorithmus \ref{alg:Hindernisvermeidung} empirisch neu eingestellt werden. Mit der Evaluierung der Hindernisvermeidung wird gleichzeitig auch die Gesamtnavigation evaluiert.

\begin{table}[htbp]
\centering
\begin{tabularx}{\textwidth}{p{0.2\textwidth}|X|X|X|X}
\hline
\textbf{Modell} & \textbf{Technik} & \textbf{Modellgröße in Kilobyte (KB)} & \textbf{Device} & \textbf{Inferenzzeit in Millisekunden (ms)}\\
\hline
MiDaS & Unquantisiert & 64784 & GPU & 183\\
\hline
MiDaS & Unquantisiert & 64784 & CPU bei 4 Threads & 304\\
\hline
PyDNet & Unquantisiert & 7730 & GPU & 330\\
\hline
PyDNet & Unquantisiert & 7730 & CPU bei 4 Threads & 485\\
\hline

\end{tabularx}
\caption{Inferenzzeiten der Depth Estimation}
\label{tab:InferenzzeitDepthEstimation}
\end{table}