Select Git revision
standdertechnik.tex 16.01 KiB
\chapter{Stand der Technik} \label{chap: stand der technik}
\section{Techniken zur Fahrspurerkennung}
Das Thema Fahrspurerkennung beschäftigt die Wissenschaft und auch die Automobilindustrie bereits seit einigen Jahren. Im Folgenden werden
daher die existierenden üblichen Ansätze zu diesem Thema erläutern. Dabei ist besonders interessant, wie diese in diese Arbeit einfließen.
\subsection{Geometrische und algorithmische Ansätze}
Bei den klassischen und ältesten Methoden wird an die Thematik mit mathe\-ma\-tisch-geo\-me\-trisch\-en Ansätzen herangegangen. Diese
werden zu Algorithmen verknüpft, um unterschiedliche Informationen herauszuarbeiten, zu verknüpfen und das Ergebnis zu verfeinern.
Grundlage bilden hierbei verschiedene Operationen, mit welchen sich Bilder verändern lassen. Solche Operationen verknüpfen eine bestimmte
Menge an Pixeln eines Ursprungsbildes mittels einer mathematischen Operation, um ein neues \gls{Pixel} für das Zielbild zu ermitteln. Ein
relativ simples Beispiel hierfür ist das Bilden eines Mittelwertes von jeweils drei Farbpixeln, um ein Schwarzweißbild zu erzeugen.
\cite{szelisk:computerVision-algos+application}
% Häufig kommen bei diesen Operationen sogenannten \gls{Kernel} zum Einsatz. Dabei handelt es sich um Matrizen, welche je nach Anwendung
% Werte enthalten. Um nun ein \gls{Pixel} des Zielbildes zu bestimmen, wird ein entsprechender Bildausschnitt im Ursprungsbild ausgewählt und
% jeder \gls{Pixel} mit einem Element des \glspl{Kernel} verrechnet. Danach wird die Ergebnis Matrix zum neuen Wert für das Zielpixel zusammen
% gefasst, häufig durch simples Summieren. Auf diese weise werden zum Beispiel viele Filterfunktionen umgesetzt.
% Der für diese Arbeit relevante \gls{gauss-filter} verwendet einen \gls{Kernel}, dessen Werte um den Kernel-Mittelpunkt Normalverteilt
% sind. Dieser wird für jeden \gls{Pixel} mit der entsprechend großen \gls{Pixelnachbarschaft} multipliziert und aufsummiert. Dadurch wird
% der gewichtete Mittelwert aller Nachbarpixel gebildet und das Bild geglättet.
Der sehr grobe Ablauf, welcher solche Operationen zu einem Algorithmus verknüpft, ist in \autoref{fig: genersich} skizziert. Dabei sind
die Einzelschritte in der Realität jedoch häufig sehr kompliziert. Begonnen wird eigentlich immer mit einem Vorbereitungs-Schritt, da die
Bilder einer Kamera nur selten direkt verwendet werden können. Teilweise ist eine solche Vorverarbeitung aber auch hardwareseitig oder in
vorgelagerten Programmteilen umgesetzt. Meisten wird das Bild außerdem in ein Schwarzweißbild umgewandelt, da so nur ein Drittel der
Pixel untersucht werden müssen, was die Performance verbessert.
\begin{figure}
\includegraphics[scale=.85]{svg/PAP_generisch_markerdetektion.pdf}
\caption{Generischer Ablauf von Fahrspurerkennung (nach \cite{laneDetection:aReview})}
\label{fig: genersich}
\end{figure}
\pagebreak
Bei den sogenannten Features handelt es sich um spezifische, möglichst eindeutige Muster im Bild. Im Fall von Fahrspurmarkierungen sind
dies meist Kannten und Ecken ebendieser. Häufig wird hier der \gls{canny} eingesetzt, der von John Canny
\cite{Canny:computationAlapproachEdgeDetection} entwickelt wurde. Dieser Algorithmus ist sehr gut zum Identifizieren von Kantenpixeln
geeignet und erzeugt ein Binärbild, in dem nur noch ein \gls{Pixel} dicke Umrisse verbleiben.
Das genaue Vorgehen um Features zu finden und zu verknüpfen, ist Gegenstand von Forschung und Entwicklung. In \cite{laneDetection:aReview}
werden Beispielsweise verschieden Möglichkeiten die Hough Transformation zu verwenden miteinander verglichen und
\cite{assistanceSystem:laneDetection-vehicleRecognition} verwendet zusätzlich eine Methode zum Kombinieren von einzelnen Liniensegmenten.
\cite{robustLaneMarkingDetection} demonstriert einen Ansatz, um direkt Mittellinien von Fahrspurmarkierungen anhand von bekannten
Größenparametern abzuleiten.
Das Ergebnis kann durch das Einbeziehen weiterer Informationen noch weiter verbessert werden. Oft wird hier das originale
Farbbild mit einbezogen (siehe \cite{laneDetection:aReview}), aber auch das Zurückgreifen auf das vorherige Bild, wie in
\cite{LaneDetection_basedOnRidge} eingesetzt, ist möglich.
\medskip
Da diese Techniken bereits langfristig erprobt und daher sehr stark optimiert sind, eignen sie sich besonders gut für den Einsatz in
dieser Arbeit. Auch der gezeigte Ablauf wird in dieser Arbeit so angewendet.
Insbesondere die gezeigten Methoden des \gls{canny} werden später noch einmal aufgegriffen. Die in vielen Quellen erwähnte Hough
Transformation wurde aber bereits im Voraus als zu rechenintensiv ausgeschlossen.
\subsection{Deep-Learning Ansätze}
Alternativ zu den traditionellen Ansätzen wird in den letzten Jahren vor allem an den sogenannten Deep-Learning-Methoden geforscht. Hier
werden Neurale Netze verwendet, um Lösungen für besonders schwierigen Situationen wie extremen Lichtverhältnissen oder stark verwitterte
Spurmarkierungen zu finden.
Diese Netzwerke können mittels eines großen Datensatzes an Bildern trainiert werden, um unter unterschiedlichsten, unvorhersehbaren Bedingungen noch Ergebnisse zu erhalten. Dabei gilt, je größer und vielfältiger der Trainingsdatensatz, umso wahrscheinlicher erzielt das
trainierte Netzwerk gute Ergebnisse. \cite{survey:deepLeraningInLanemarkerdetection} vergleicht frei verfügbare Datensätze und liefert
eine Übersicht für welche Anwendungen diese sich eigen.
Der generelle Detektierungsablauf ist auch bei Deep-Learning-Methoden der in \autoref{fig: genersich} dargestellte. Je nach Methode und
Netzwerk können aber mehrere Schritte vom selben Netzwerk erledigt oder mehrere Netzwerke für die einzelnen Schritte verwendet werden.
In den letzten Jahren wurden unterschiedlichste Arten von Neuralen Netzen für die Detektion von Spurmarkierungen entwickelt und erprobt.
Vier unterschiedliche Netzwerkarten, deren Verwendungszweck und Vorteile, sowie ein Vergleich der Ergebnisse ist in
\cite{review:landeDetectionMethodes-deepLearning} nachzulesen. Dort wurden Genauigkeiten von $97\,\percent$ erreicht, allerdings war die
Generalisierung der getesteten Modelle nicht immer zuverlässig.
Der in \cite{survey:deepLeraningInLanemarkerdetection} erstellte Vergleich kommt zu sehr ähnlichen Ergebnissen. Zusätzlich wurde hier die
Performance der Netzwerke untersucht und angegeben, wie viele Bilder pro Sekunde verarbeitet werden können. Hier haben sich einige
Methoden als sehr viel schneller herausgestellt.
\medskip
Ein großer Nachteil aller Deep-Learning-Methoden ist die benötigen hohe Rechenleistung. Bereist das Training der Netzwerke erfordert einen
existierenden, ausreichen großen Datensatz und viel Zeit und Rechenleitung. Aber auch zur Nutzung der fertig trainierten Netzwerkes ist
wieder einiges an Rechenleitung notwendig. Hier kann zwar die GPU zu Hilfe genommen werden, es ist aber ein Nachteil gegenüber den
traditionellen Ansätzen.
Dies ist insbesondere für den Anwendungsfall dieser Arbeit ein Problem. Die Ressourcen des JetBots sollen so wenig wie möglich belastet
werden, damit dieses mit weiten Anwendungen geteilt werden können. Da einige potenzielle Anwendungen auf die Verwendung von Neuralen
Netzen angewehten sind, ist insbesondere die GPU sehr sparsam zu benutzen.
Daher ist für diese Arbeit die Verwendung von Deep-Learning nicht sinnvoll und findet keine Anwendung.
\section{OpenCV} \label{sec: opencv}
Das Open-Source-Projekt \gls{OpenCV} (kurz für \emph{Open Source Computer Vision Library}) ist eine Sammlung von Softwaremodulen, die der
Bildverarbeitung und dem maschinellen Lernen dienen. Sie verfügt über mehr als 2500 optimierte Algorithmen mit denen Anwendungen wie
Objekterkennung, Bewegungserkennung und 3D-Modell Extraktion erstellt werden können. Daher ist sie eine der Standardbibliotheken, wenn es um
digitale Bildverarbeitung geht und wird fast immer zur Demonstration neuer Konzepte benutzt. Da sie sowohl in C/\gls{C++}, Java und Python
genutzt werden kann, ist sie außerdem sehr vielseitig und hat den Vorteil, dass Konzepte in einer abstrakten Sprache wie \gls{python} getestet
werden und später relativ simpel in eine hardwarenahe Programmiersprache übersetzt werden können. Weitere Informationen sind in der
Dokumentation des Projektes \cite{OpenCV:homepage} zu finden.
In dieser Arbeit wird diese Bibliothek daher insbesondere für die Entwicklungsphase verwendet. Da der Bibliothekscode jedoch auch viele
potenziell nicht benötigte Zusatzfunktionen mit bring, wird auch ein Wechsel auf eine eigene Implementierung mit besserer Performance in
Betracht gezogen.
\section{Das Robot Operating System} \label{sec: ros}
Das \glslink{ROS}{Robot Operating System} (kurz: ROS) ist eine Sammlung von Software Bibliotheken und Werkzeugen, die zum Erstellen von Roboter
Applikationen dienen. Es bietet eine eigene Paketverwaltung über die bestehende Bibliotheksfunktionen für die Verwendung
heruntergeladen werden können. Dabei handelte es sich um verschiedenste Anwendungen, angefangen Treibern, über fertige, direkt anwendbare
Algorithmen, bis zu nutzernahen Steueroberflächen und sogar (Lern-)Spiele. Die Webseite des Projektes \cite{ROS:homepage} bietet hierzu
weitere Informationen. Außerdem bietet \gls{ROS} Integrationen mit anderen bestehenden Projekten, wie zum Beispiel \gls{OpenCV}.
Auch wenn es sich bei \gls{ROS} genaugenommen um kein vollständiges Betriebssystem handelt, stellt es für ein solches typische
Funktionalitäten zur Verfügung. Beispiele hierfür sind Hardware-Abstraktion, tiefgehende Geräteverwaltung, Verwaltung von Prozessen sowie
Informationsweitergabe zwischen diesen und die eben genannte Paketverwaltung und damit verbundene Abstraktion von generischen, allgemein
benötigten Funktionen. \cite{ROS:whatsROS}
\medskip
Für diese Arbeit ist \gls{ROS} deshalb interessant, da sich die Ergebnisse so modular an potenzielle weitere Prozesse weitergeben lassen. Dies
wird durch \gls{ROS}\todo{ROS's ??} Fähigkeit möglich, Einzelprozesse als sogenannte \glslink{ROS Node}{ROS Nodes} zu erstellen. Jede
\gls{ROS Node} kann eigene Informationen als sogenannte \glspl{Topic} veröffentlichen und andere, parallel laufende \glspl{ROS Node} können
diese abonnieren.
Sobald eine Information in einem Prozess bereit ist, verpackt dieser sie in einem der definierten Datentypen als sogenannte \gls{ROS Message}.
Diese wird dann veröffentlicht und an alle Abonnenten des \glspl{Topic} verschickt. Diese können dann bei erhalt der \gls{ROS Message} auf
diese reagieren.
So lassen sich einzelne Komponenten dieser Arbeit abgekapselt voneinander umsetzen und stellen ihre Ergebnisse auf potenziellen, später noch
entwickelten Prozessen zur Verfügung.
\section{Der JetBot Roboter} \label{sec: JetBot}
Beim in für diese Arbeit verwendeten Roboter handelt es sich um einen JetBot v2.1 von der Firma Sparkfun. Im Folgenden werden seine
Komponenten und Einsatzmöglichkeiten für diese Arbeit näher beschrieben.
Der Roboter verwendet das von Nvidia produzierte Jetson Nano Entwicklerboard \cite{jetson-nano:homepage}. Hierbei handlet es sich um einen
Mini-Computer der speziell für Bildverarbeitung und Selbstlehrende Algorithmen entwickelt wurde. Es verfügt über einen 4-Kern ARM Prozessor
als CPU sowie, neben herkömmlichen Anschlüssen für PC-Peripherie, über Anschlüsse für 2 Kameras und mehre GPIO Pins. Dadurch eignet es sich
bereits sehr gut für eingebettet Anwendungen.
Was dieses Board für die Anwendung in der Bildverarbeitung aber besonders interessant mach, ist die integrierte, für die Größe leistungsstarke
GPU. Diese kann für grafikintensive Anwendungen, aber vor allem für das Arbeiten mit Neuralen Netzen genutzt werden. Da für diese Arbeit
explizit nicht mit Deep Learning gearbeitet wird, um diese Ressourcen für spätere Weiterentwicklung freizuhalten, ist dieses Feature aber
hier uninteressant.
Die Firma Sparkfun bietet für dieses Board den Bausatz \cite{jetbot:Sparkfun} an, um einen selbstfahrenden Roboter zu bauen. Dieser wird für
diese Arbeit verwendet. Er stattet das Board mit einer Kamera, zwei steuerbaren Motoren, einem LCD-Display und einer Batterie aus. Der fertig
aufgebaute Roboter ist in \autoref{fig: JetBot} zu sehen.
\begin{figure}
\includegraphics[width=.6\textwidth]{img/jetbot_sparkfun.jpg}
\caption{SparkFun JetBot AI Kit V2.1 \cite{jetbot:Sparkfun}}
\label{fig: JetBot}
\end{figure}
Für diese Arbeit wird der Roboter als funktionstüchtig und einsatzbereit vorausgesetzt. Die Aufbauanleitung ist aber unter
\cite{jetbot:Sparkfun} und die Anleitung zum Einrichten unter \cite{jetbot:docs} zu finden.
Zusätzlich wird ein fertiger Kameratreiber vorausgesetzt. Dieser wurde als \gls{ROS Node} mit dem Namen \lstinline{camera_driver} unter ROS
implementiert und stellt alle $0,2\,\s$ ein aktuelles Bild auf dem \gls{Topic} \lstinline{/img/raw} zur Verfügung.
\subsection{Performance Baseline} \label{sub: performance baseline}
Da die Leistungsfähigkeit des JetBots relativ eingeschränkt ist und eines der Ziele dieser Arbeit lautet, parallel zu anderen, zukünftigen
Prozessen laufen zu können, ist es wichtig möglichst Performant zu arbeiten. Daher wird ermittelt, wie sehr der JetBot vor Beginn dieser
Arbeit bereits ausgelastet ist.
Begonnen wird mit der Grundleistung ohne irgendwelche laufenden Prozesse unter \gls{ROS}. Das bedeutet, das nur das Betriebssystem und
seine Standard-Applikationen, wie zum Beispiel der SSH-Server, laufen. Dazu wird das Terminalprogramm \lstinline{jtop} verwendet, welches
viele Systeminformationen und Performance-Messwerte gesammelt anzeigt. Ein Screenshot ist in \autoref{fig: jtop baseline} gezeigt.
\begin{figure}
\includegraphics[width=.6\textwidth, trim={0 0 12px 31px}, clip]{img/jtop_baseline.png}
\caption{CPU Auslastung des JetBots ohne \gls{ROS}}
\label{fig: jtop baseline}
\end{figure}
Da alle in dieser Arbeit entwickelten Programme lediglich die CPU benutzen, ist dies der einzige relevante Messwerte. Trotze sind die
anderen Werte interessant und werden mit dokumentiert. Wie man im Screenshot sieht, ist das System in diesem Fall kaum belastet. Die
Auslastung ohne irgendwelche laufenden Prozesse liegt bei $\approx8.25\,\percent$.
Relevanter ist aber der Fall mit laufender Kamera, da dies die Voraussetzung für diese Arbeit ist. Wird die Kamera-\gls{ROS Node}
gestartet und erneut \lstinline{jtop} überprüft, ergibt sich die in \autoref{fig: jtop cam baseline} gezeigte Screenshot.
\begin{figure}
\includegraphics[width=.6\textwidth, trim={0 0 12px 31px}, clip]{img/jtop_camera.png}
\caption{CPU Auslastung mit laufender Kamera und ROS-Core}
\label{fig: jtop cam baseline}
\end{figure}
Dort ist die CPU-Auslastung deutlich höher und liegt bei $\approx38\,\percent$. Es ist allerdings zu beachten, dass dies nicht
ausschließlich auf die Kamera-\gls{ROS Node} zurückzuführen ist. Um überhaupt \glslink{ROS Node}{ROS Nodes} benutzen zu können, muss das
sogenannte ROS Core gestartet sein. Diese geschieht automatisch beim Starten der ersten Node. Es ist für den Großteil der zusätzlichen
Auslastung verantwortlich, sodass zusätzliche \glspl{ROS Node} die Auslastung nur geringfügig erhöhen werden.
\section{Aufgebaute Fahrbahnfläche} \label{sec: anlgae}
Zum Testen des JetBots für diese Arbeit und andere Projekt wurde eine Projektanlage aufgebaut. Diese besteht aus einer im Maßstab $1\!:\!18$
herunterskalierten Fläche mit aufgedruckter Fahrbahnfläche. Die folgende Abbildung zeigt die Testfläche. Diese hat eine Größe von $200\,\m^2$
und Abmessungen von $20\,\m\!\times\!10\,\m$. Weitere Informationen können dem Projektbericht \cite{bericht:FlächeAutonomesFahren} entnommen
werden.
\begin{figure}
\includegraphics[width=\textwidth]{img/Fläche_autonomes_Fahren.jpg}
\caption{Ansicht von oben auf die Fahrbahnfläche \cite{bericht:FlächeAutonomesFahren}}
\end{figure}