MasterarbeitLatex/VorlageTeX/diskussion.tex

\chapter{Diskussion}
Nachfolgend werden die Ergebnisse aus der Evaluierung zusammengefasst und interpretiert. Zudem werden die Grenzen aus den Ergebnissen und mögliche Anknüpfungspunkte für weitere Forschung aufgezeigt.

\section{Zusammenfassung der Ergebnisse}
Im Rahmen dieser Arbeit sollte eine Roboternavigation basierend auf Machine Learning mit einer allgemeinen und speziell auf die Umgebung trainierten Türdetektion und einer allgemeinen Hindernisvermeidung untersucht werden. Die Ergebnisse verdeutlichen, dass die Methodik für eine Roboternavigation mit Türdetektion und Depth Estimation, Algorithmen zur Zielnavigation und Hindernisvermeidung und deren Zusammenführung durch einen Zustandsautomaten im Prinzip funktioniert. Es hat sich jedoch deutlich gezeigt, dass die codemanufaktur-Türdetektion deutlich besser, als die allgemeine Türdetektion funktioniert, siehe Tabellen \ref{tab:ErgebnisseAllgemeineDetektionMidas} und \ref{tab:ErgebnisseCodemanufakturDetektionMidas}. Zudem ist festzustellen, dass es keine relevanten Unterschiede in der Genauigkeit zwischen einem quantisierten und einem unquantisierten Modell gibt, jedoch Unterschiede bezüglich der Navigation wegen der erhöhten Inferenzzeit des unquantisierten Modells und den daraus resultierenden Ergebnissen aus Tabelle \ref{tab:ErgebnisseCodemanufakturDetektionUnquantisiert}. Bezüglich den Inferenzzeiten der Modelle hat sich auch gezeigt, dass das SSD MobileNet V2 FPNLite mit höherer Auflösung eine bessere Genauigkeit hat als das gleiche Netz mit niedrigerer Auflösung, jedoch die höhere Inferenzzeit die Latenz (Verzögerung) der Navigation erhöht, siehe Tabelle \ref{tab:InferenzzeitModelle}. Gleiches gilt für die Gegenüberstellung der Depth Estimation Modelle. Das MiDaS-Modell hat eine deutlich geringere Inferenzzeit als das PyDNet trotz viel größerer Modellgröße, siehe Tabelle \ref{tab:InferenzzeitDepthEstimation}. Für die Evaluierung der Hindernisvermeidung konnte zudem nur das MiDaS-Modell untersucht werden, da für das PyDNet-Modell die Schwellwerte für den Algorithmus der Hindernisvermeidung (Algorithmus \ref{alg:Hindernisvermeidung}) empirisch neu ermittelt hätten werden müssen. \\
Im Bereich des Machine Learnings der Türdetektion-Modelle wurde festgestellt, dass die Average-Recall-Werte (\gls{AR}) hoch sind und neuere Modelle mit neueren Technologien bessere Mean-Average-Precision-Werte (\gls{mAP}) aufweisen, siehe Tabelle \ref{tab:CodemanufakturDetektionResultateCOCO} und \ref{tab:AllgemeineDetektionResultateCOCO}. Zudem zeigt sich aus dem Loss und Validation Loss, dass ein Overfitting über alle trainierten Modelle auftritt, siehe Tabellen \ref{tab:AllgemeineDetektionResultate}, \ref{tab:CodemanufakturDetektionResultate} und Abbildungen \ref{fig:AllgemeinLoss}, \ref{fig:Loss}. Auffällig ist zudem die schlechtere Mean-Average-Precision (\gls{mAP}) des SSD ResNet50 V1 FPN im Vergleich zum SSD MobileNet V2 FPNLite, siehe Tabelle \ref{tab:AllgemeineDetektionResultateCOCO} und \ref{tab:CodemanufakturDetektionResultateCOCO}. Außerdem ist eine Differenz zwischen den Mean-Average-Precision-Werten (\gls{mAP}) zwischen Validierung und Test festzustellen. Die \gls{mAP}-Werte der Testsets sind geringer als die \gls{mAP}-Werte des Validierungssets.

\section{Interpretation der Ergebnisse}
Die Ergebnisse aus dem Machine Learning zeigen, dass die trainierten Modelle auf bekannte Türen oder ähnliche Türen wie aus dem Trainingsdatensatz eine sehr gute Türdetektion bewerkstelligen. Mit unbekannten Türen oder Türen, die eine große Abweichung zu den Türen im Trainingsdatensatz haben, müssen die Modelle viel stärker den Input generalisieren und hier vermindert sich die Zuverlässigkeit der Türdetektion. Dies resultiert aus den Ergebnissen in den Tabellen \ref{tab:CodemanufakturDetektionResultateCOCO} und \ref{tab:AllgemeineDetektionResultateCOCO}. Die \gls{mAP}-Werte anhand des Testsets sind geringer als vom Validierungsset. Ein Grund hierfür ist, dass sich die Türen aus den Testdatensätzen sehr stark von den Türen aus den Trainingsdatensätzen und Validierungsdatensätzen unterscheiden. Trainingsdaten und Validierungsdaten haben den gleichen Ursprung. Die Ursprungsdaten wurden in einem 90:10-Split in einen Trainingsdatensatz und einen Validierungsdatensatz aufgeteilt. Eine allgemeine Türdetektion zu entwickeln stellt grundsätzlich eine große Herausforderung dar, aufgrund einer sehr großen Vielfalt von Türen. Das Hauptaugenmerk bei dieser Arbeit lag auf der Detektion von Bürotüren. Für eine bessere Generalisierung der Netze muss eine noch größere Datenmenge von Türen unterschiedlichster Art als Trainingsdaten verwendet werden \cite[473-475]{Goodfellow.2018}, \cite[266\psq]{Goodfellow.2018}. Eine weitere Möglichkeit besteht im Anpassen der Hyperparameter (Regularisierung), um eine bessere Generalisierung zu erreichen \cite[475-480]{Goodfellow.2018}. Ein Machine-Learning-Modell mit einer hohen Kapazität (Anzahl der lernbaren Parameter) neigt eher zum Overfitting, wenn die Trainingsdatenmenge nicht ausreichend für dieses Modell ist \cite[121\psqq]{Goodfellow.2018}, \cite[253\psqq]{Goodfellow.2018} und \cite[475\psqq]{Goodfellow.2018}. Dies zeigt sich sehr schön am Netz des SSD ResNet50 V1 FPN, das eine niedrigere \gls{mAP} nach dem Training aufweist wie das SSD MobileNet V2 FPNLite, siehe Tabellen \ref{tab:CodemanufakturDetektionResultateCOCO} und \ref{tab:AllgemeineDetektionResultateCOCO}. Grund hierfür ist die hohe Parameteranzahl des SSD ResNet50 V1 FPN im Vergleich zum SSD MobileNet V2 FPNLite, wie man auch an der Modellgröße der TensorFlow-Lite-Modelle sehen kann, siehe Tabelle \ref{tab:QuantisierungModelle}. Das ResNet50 V1 FPN braucht daher eine größere Trainingsdatenmenge oder eine stärkere Regularisierung durch die Hyperparameter, um die Validierungs- und Testergebnisse zu verbessern. Generell hätte man anstatt der L2-Regularisierung eine L1-Regularisierung wählen können. Die L1-Regularisierung führt zu einer Netzarchitektur, die dünnbesetzter ist und somit einige Parameter einen optimalen Wert von 0 aufweisen. Dies lässt sich zur Merkmalsauswahl verwenden und reduziert die Kapazität des Modells \cite[262]{Goodfellow.2018}. Eine weitere Möglichkeit wäre die Einstellung der Lernrate. Hier wurden aber im Laufe des Trainings einige Einstellungen ausprobiert und dies hat zu keiner Verbesserung geführt. Insbesondere, wenn die Lernrate zu hoch eingestellt wird, werden die Ergebnisse der Validierung schlechter, somit auch die Testergebnisse beziehungsweise die Regularisierung. \\
Im Bereich der Depth Estimation fällt auf, dass das MiDaS-Modell eine deutlich bessere Inferenzzeit und Optimierung als das PyDNet-Modell aufweist, trotz größerer Modellgröße. Eine Erklärung hierfür wäre, dass das PyDNet noch unter der Vorgängergeneration des TensorFlow 2.0 Frameworks erstellt wurde, nämlich TensorFlow 1.0 \cite{GitHub.1062021c}. Zudem müssen für die Inferenz des PyDnet auch ältere Versionen der TensorFlow-Lite-Bibliotheken genutzt werden, die aktuellen Versionen von TensorFlow Lite sind nicht kompatibel zum PyDNet. Das MiDaS-Modell läuft wie die Modelle der Türdetektion auf den neuesten Versionen der eingebundenen TensorFlow-Lite-Bibliotheken in Android Studio mittels dem Buildsystem Gradle. \\
Im Bereich der Navigation zeigt sich die Wichtigkeit der Inferenzzeit und guten Detektion der Türdetektion-Modelle. Deshalb ergibt sich aus dem quantisierten SSD MobileNet V2 FPNLite 320x320 mit dem MiDaS-Modell die beste Gesamtnavigation des Roboters. Sobald die Inferenzzeiten steigen, nimmt auch die Verzögerung zu und hat damit negativen Einfluss auf die Algorithmen der Zielnavigation und Hindernisvermeidung. Dies ist auch der Grund, warum der Roboter bei Einsatz des unquantisierten SSD MobileNet V2 FPNLite 320x320 zur Tür hinfährt, aber nicht rechtzeitig vor der Tür stoppt. Die Inferenzzeit ist so hoch, dass das Intervall des If-Befehls des Algorithmus \ref{alg:Zielnavigation} für das Stoppen anhand der Breite der Bounding Box verpasst wird. Eine weitere wichtige Beobachtung ergibt sich aus den hohen Average-Recall-Werten, die zu einer hohen Sensitivität der Türdetektion führen. Dadurch entstehen einige Fehldetektionen, also zu falsch Positiven (\gls{FP}) an Objekten, die einen Rahmen beinhalten \cite[157]{Grus.2020}, siehe auch Abbildungen \ref{fig:AllgemeineDetektionScreenshots}, \ref{fig:codemanufakturDetektionScreenshots} und \ref{fig:codemanufakturDetektionUnquantisiertScreenshots}. Somit war das Hinzufügen von richtig Negativen (\gls{TN}) wie Bilder von Schranktüren, Fenstern und Bilderrahmen zum Trainingsdatensatz nicht erfolgreich. Ein Lösungsansatz wäre hier eine feinere Merkmalsextraktion des Basisnetzes vom \gls{SSD}, um Türen von Objekten mit Rahmen besser zu unterscheiden. Eine aufwendigere Lösung wäre der Versuch neben der Klasse Tür weitere Klassen für Objekte mit Rahmen anzulegen und hier zu untersuchen, ob die Fehldetektionen sich verringern. Die Fehldetektionen hängen aber auch von der Generalisierungsfähigkeit des Netzes der Türdetektion zusammen, und für eine bessere Generalisierung würde eine größere und vielfältigere Trainingsdatenmenge helfen.\\
Eine weitere Beobachtung wurde am Einsatz der allgemeinen Türdetektion gemacht. Es scheint so, dass die allgemeine Türdetektion bei künstlichem Licht, also bei Beleuchtung der Räume, besser die Türen detektiert als bei Tageslicht. Ein Grund hierfür könnte sein, dass viele Trainingsdatenbilder für die allgemeine Türdetektion, die selbst aufgenommen wurden, bei künstlichem Licht in den Abendstunden gemacht wurden. Hier hätte man mit den passenden Augmentation-Optionen diesen Effekt verringern können. \\

\section{Limitierungen}
Bezüglich des Machine Learnings fehlte eine dedizierte Grafikkarte, die das Training schon von Anfang an beschleunigt hätte. Es wurde erst beim Training der allgemeinen Türdetektion auf Google Colab mit einer Laufzeitumgebung mit Grafikkarte gesetzt, siehe auch Tabellen \ref{tab:DauerTraining}. Zudem bestand zu Beginn die Annahme, dass Bilder von Türen aus der Google-Bildersuche für eine funktionierende Türdetektion ausreichend wären. Dies stellte sich jedoch als falsch heraus, da die Türen in diesen Bildern meistens stark im Fokus des Bildes stehen. Somit führte dies zum Effekt, dass Türen nur in unmittelbarer Nähe, wenn man direkt die Kamera des Smartphones vor die Tür hielt, erkannt wurden. Daher musste der Trainingsdatensatz mit selbst aufgenommenen Fotos von Türen aus verschiedenen Perspektiven ergänzt werden. Diese Maßnahme ermöglichte eine Türdetektion aus weiterer Entfernung. Um auf selbstgefertigte Aufnahmen zu verzichten, hätte man die Google-Bilder einer Augmentation-Option unterziehen müssen, die die Objekte mit ihren Bounding Boxen skaliert. Eine Möglichkeit, die die Entwicklung der Türdetektion beschleunigt hätte, wären öffentlich vorhandene gelabelte Datensätze von Türen. Den einzigen gelabelten Datensatz mit Türen enthält jedoch nur der Open Images Datensatz \cite{OpenImages.6252021}, der jedoch häufig Außentüren von Gebäuden beinhaltet und zu keinen zufriedenstellenden Trainingsergebnissen für Bürotüren beziehungweise Innentüren geführt hat. Zudem beinhaltet dieser Datensatz nicht nur Außentüren von Gebäuden, sondern auch Türen von Möbeln, Geräten, Maschinen und Fahrzeugen. Somit mussten alle Bilder aus der Google-Bildersuche und die selbstaufgenommenen Bilder selber mit dem Open Source Tool labelImg \cite{GitHub.1062021d}  gelabelt werden. \\
Beschränkungen gibt es auch beim Algorithmus \ref{alg:Hindernisvermeidung} der Hindernisvermeidung. Die Schwellwerte \textit{T} und \textit{r} des Algorithmus \ref{alg:Hindernisvermeidung} müssten für die Erkennung von kleinen Hindernissen wie einer einzelnen Getränkekiste sowie für das PyDNet-Modell empirisch neu eingestellt werden. Dies ist sehr aufwendig und wurde aus Zeitgründen nicht weiterverfolgt. Zudem wird bei immer kleiner werdenden Schwellwerten, die Hindernisvermeidung sensibler und dadurch eine Geradeausfahrt erschwert. \\
Eine weitere Limitierung ist die Hardware zur Inferenz der Machine-Learning-Modelle. In dieser Arbeit wurde ein Mittelklasse-Smartphone verwendet, das in seiner Rechenkapazität limitiert ist.

\section{Weitere Forschungsansätze}
Aus diesen Erkenntnissen sind Anwendungen auf anderen Hardwareplattformen und Variationen in den Algorithmen ableitbar. Anstatt des Smartphones könnte ein KI-Computer wie der Nvidia Jetson Nano \cite{NVIDIA.11262021} mit separater Kamera für den Roboter eingesetzt werden. Zudem könnte die Zielnavigation und Hindernisvermeidung auch auf Drohnen und Logistikfahrzeugen angewendet werden. Auch könnte der Algorithmus \ref{alg:Hindernisvermeidung} der Hindernisvermeidung durch einen Algorithmus ohne Einstellung von Schwellwerten ausgetauscht werden. Eventuell könnten sogar durch einen besseren Ansatz die Algorithmen \ref{alg:Zielnavigation} der Zielnavigation, sowie der Hindernisvermeidung (Algorithmus \ref{alg:Hindernisvermeidung}) durch Machine-Learning-Ansätze ersetzt werden. Zusätzlich müsste ein noch stärkerer Fokus auf die Data Augmentation gesetzt werden. In dieser Arbeit wurden mittels der TensorFlow Object Detection API nur zwei Augmentation-Optionen genutzt, nämlich: 
\begin{itemize}
\item random\_horizontal\_flip
\item random\_crop\_image
\end{itemize}
Unter \cite{GitHub.12122021} lassen sich die Augmentation-Optionen der TensorFlow Object Detection API einsehen.