\section{Tests}
	\label{sec:tests}
	Die folgenden Tests beschäftigen sich alle mit dem Rover und sollen die einzelnen implementierten Komponenten sowie deren zusammenwirken überprüfen. Die Tests sind in der Reihenfolge so sortiert, dass für den jeweils nächsten Test der vorherige erfolgreich abgeschlossen sein muss.

	\subsection{Route aufzeichnen}
		Für die Aufzeichnung muss der Rover zunächst in den \texttt{Capture Route} Modus versetzt werden. Dadurch wird automatisch der Ntrip-Client gestartet und es muss gewartet werden, bis das GNSS-Modul die eingestellte Genauigkeit erreicht hat. Dies kann im Menü überprüft werden. Währenddessen kann der Rover bereits verfahren  und somit an den Startpunkt der Route gefahren werden. Anschließend wird der Befehl zur Speicherung des aktuellen Punktes über den Joystick gegeben. Nach jedem Speicherbefehl wird das Ergebnis im Menü überprüft. Sollte der aktuelle Punkt nicht gespeichert worden sein, liegt dies meistens an einer mangelhaften Positionsgenauigkeit. In diesem Fall wird gewartet bis diese wieder den Anforderungen entspricht.
		\par
		Es wurde für diesen Test eine Route, bestehend aus sechs Koordinatenpaaren, erfolgreich aufgezeichnet.

		\subsubsection{Koordinaten Plausibilität}
			Die Koordinaten wurden in der Webversion von Google Earth markiert und miteinander verbunden, siehe Abbildung \ref{fig:roverRouteGoogleEarth}. Während der Aufzeichnung der Route wurde darauf geachtet, markante Punkte, welche auch auf Satellitenbildern zu erkennen sind, zu benutzen. Deshalb wurden hauptsächlich Regenwassereinläufe als Positionen genutzt. Diese sind auf der Abbildung als kleine Rechtecke unter den Markierungen zu erkennen. Unter der Bedingung, dass die Positionierung der Bilder in Google Earth der Realität entspricht, treffen die aufgezeichneten Koordinaten die gewählten Punkte und können daher als plausibel betrachtet werden.

			\begin{figure}[ht]
				\centering
				\includegraphics[width=\linewidth]{img/roverRouteGoogleEarth.png}
				\caption{Abbildung einer aufgezeichneten Route in Google Earth\protect\footnote[3]{Quelle Google Earth. (2024) Bild eines Parkplatzes der an der Emil-Figge-Straße in Dortmund, Deutschland {[51.496567 N 7.418032 E]} Zugriff am 19.08.24, von \url{https://earth.google.com/web/}}}
				\label{fig:roverRouteGoogleEarth}
			\end{figure}

	\subsection{Routen Management}
		Die Verwaltung der Routen kann getestet werden, indem die einzelnen Aktionen zur Routenverwaltung ausgeführt werden. Als Vorbereitung muss eine Route aufgezeichnet werden, dementsprechend muss der vorausgegangene Test \texttt{Route aufzeichnen} erfolgreich abgeschlossen worden sein. Für den Umfang dieses Tests wurde festgelegt, dass die Route 10 Punkte beinhalten soll. Die Anzahl der bereits aufgezeichneten Punkte kann im Menü des Aufzeichnungsmodus verfolgt  und abschließend im Menü \texttt{Route} überprüft werden. In diesem Menü können die einzelnen Koordinaten der Punkte betrachtet werden. Diese werden wieder notiert, um die Richtigkeit der Daten im Verlauf des Tests prüfen zu können.

		\subsubsection{Route exportieren}
			Nach Abschluss der Vorbereitung kann die Route exportiert werden. Dafür muss der zugehörige Menüpunkt aufgerufen werden. In diesem muss eine \texttt{ID} für die Route vergeben werden. In diesem Fall wird dafür die Zahl \(98\) gewählt. Nach der Bestätigung wird der Ausgang des Exports mitgeteilt. In diesem Fall erscheint die Meldung \glqq \texttt{Export complete}\grqq\ mit dem Code \(201\). Zur Überprüfung der gespeicherten Daten kann die Route über die folgende URL abgerufen werden: \url{https://rover.kleiax.de/api/98}. Die empfangenen Daten des Endpunktes der API entsprechen den übermittelten Daten.
			\par
			Ein erneuter Versuch, die Route mit derselben \texttt{ID} zu exportieren, schlägt richtigerweise mit dem Code \(419\) fehl, da die \texttt{ID} bereits verwendet wird und dadurch sichergestellt werden kann, dass diese nicht durch eine fehlerhafte Eingabe überschrieben oder verfälscht wird.

		\subsubsection{Route importieren}
			Um überprüfen zu können, ob die exportierte Route bei dem folgenden Test auch tatsächlich wieder geladen wird, muss zunächst die zwischengespeicherte Route gelöscht werden. Dafür existiert der Menüeintrag \glqq\texttt{Clear}\grqq\ oder der Rover wird neu gestartet. Für den Test wurde ein Neustart über das Menü ausgeführt. In dem Menüeintrag \texttt{Points} kann zusätzlich überprüft werden, ob eine Route vorhanden ist. Der eigentliche Test besteht darin, über den Menüpunkt \texttt{import} die zuvor gewählte \texttt{ID} zu selektieren und anschließend durch die Bestätigung den Import auszuführen. Bei einem Erfolg wird die Meldung \glqq \texttt{Import Complete}\grqq\ mit dem Code \(202\) erwartet.
			\par
			Nach dem Erhalt der Erfolgsbestätigung wurden die importierten Koordinaten mit den exportierten Koordinaten abgeglichen und es wurde Gleichheit festgestellt. Der Versuch eine nicht existierende Route zu importierten, schlägt erfolgreich mit dem Code \(418\) fehl.

		\subsubsection{Route löschen}
			Die Löschung konnte ebenfalls erfolgreich getestet werden, indem der passende Menüeintrag ausgewählt und wieder die \texttt{ID} \(98\) ausgewählt wurde. Die Rückmeldung lautete \glqq \texttt{Delete complete}\grqq\ mit dem Code \(202\). Der Versuch, die bereits gelöschte ID erneut zu löschen, wird mit dem Fehlercode \(418\) quittiert. Zur Überprüfung, ob die Daten gelöscht wurden, kann die API-URL aus dem ersten Test aufgerufen oder es kann versucht werden, die gelöscht Route zu importieren. Beides schlägt wie erwartet mit dem Code \(418\) fehl.

	\subsection{Route abfahren}
		Die Zielfunktion des Rovers wurde mit einer Route vor einem Gebäude der FH Dortmund getestet. Die Punkte der Route ergeben miteinander verbunden ein Fünfeck. Der Rover konnte die aufgezeichnete Route abfahren. Dabei fiel auf, dass der Rover besonders einen Punkt verfehlte und um diesen zu erreichen, wendete und ihn dann traf. Dieses Verhalten trat bei jeder Runde auf. Ansonsten verlief der Test den Anforderungen entsprechend und zeigte, dass Fehler während der Navigation korrigiert werden können. Im Anhang \ref{cha:cd} wird der Pfad zu einer Videoaufzeichnung des Tests angegeben.
		\par
		Der Test wurde einige Stunden später erneut ausgeführt. Dabei wurde beobachtet, dass sich die ganze Route um ungefähr 20 cm von dem Gebäude entfernt hat. Aufgrund der Tatsache, dass alle Punkte gleichermaßen von diesem Phänomen betroffen waren, wird davon ausgegangen, dass das GNSS-Modul durch die Abschattung des Gebäudes einem Offset unterlag.

		\subsubsection{Genuigkeitsprüfung}
			Der Rover soll die autonome Navigation unterbrechen, sobald die verfügbare Genauigkeit des GNSS-Moduls einen Schwellwert unterschreitet. Dieses Verhalten wurde getestet, indem das W-LAN, welches die Internetverbindung für den Rover bereitstellt, abgeschaltet wurde. Der Rover fuhr anschließend etwa 16 Sekunden weiter und blieb dann stehen. Die Verzögerung ist dadurch zu erklären, dass das GNSS-Modul auch ohne neue Korrekturdaten zeitweise die geforderte Genauigkeit bereitstellen kann. Deshalb passt das Ergebnis zu dem erwarteten Verhalten.
			\par
			Zusätzlich konnte durch Wiederherstellen des W-LANs getestet werden, ob die Navigation wieder fortgesetzt wird, sobald die Genauigkeit den Anforderungen entspricht. Dieser Test konnte ebenfalls mit einem positiven Ergebnis abgeschlossen werden. Der Rover benötigte ungefähr 27 Sekunden, um die Navigation fortzusetzen. Diese Zeit ergibt sich zum einen aus den Warteschleifen, welche die Verbindungsversuche begrenzen und zum anderen durch das GNSS-Modul, welches die Korrekturdaten zunächst verarbeiten muss.


\section{Rover}
	Während der Nutzung im Zuge der Entwicklung und der Tests sind allgemeine Erkenntnisse zu dem Rover erlangt worden. Diese werden im Folgenden thematisiert und beziehen sich hauptsächlich auf die Handhabung und die Umweltanforderungen, welche durch die Architektur des Rovers gestellt werden.

	\subsection{W-LAN}
		Durch die benötigten Korrekturdaten für das GNSS-Modul, welche über das Internet übertragen werden, muss der Rover stets auf eine Internetverbindung zugreifen können. Der Vorteil dieser Übertragungsmethode liegt in der Verfügbarkeit im Gegensatz zu spezielleren Lösungen. Dadurch wird nicht zwingend eine eigene Basisstation benötigt. Das Problem liegt darin, wie die Verbindung hergestellt wird. Im aktuellen Ausbau verfügt der Rover lediglich über W-LAN. Den bereits in Kapitel \ref{ssec:wlan-description} beschriebenen Spezifikationen, kann die Reichweite von W-LAN Netzwerken entnommen werden. Mit den vom Rover unterstützen \(2,4 GHz\) Band, mit der besten Reichweite, ist eine Abdeckung des Einsatzgebietes sehr aufwendig. Außerdem ist die Konfiguration des Rovers für Änderungen des W-LANs durch Konfiguration oder Standortwechsel anfällig.
		\par
		Die aktuelle Lösung besteht darin, ein Mobilfunktelefon mit aktivierten W-LAN Access Point in der Nähe des Rovers zu halten oder dieses in dem Rover mitfahren zu lassen. Allerdings werden dadurch nicht alle zuvor genannten Probleme behoben, daher wäre an dieser Stelle eine Optimierung, welche diesen Umweg überflüssig werden lässt, angebracht.

	\subsection{Handhabung}
		Die Steuerung des Rovers ist an die Fernbedienung gebunden, welche ebenfalls das \(2,4 GHz\) Band nutzt und damit denselben Reichweiten Einschränkungen unterliegt. Für den aktuellen Entwicklungsstand des Rovers reicht dies aus, insbesondere weil das Bedienkonzept zu diesem Zeitpunkt den Sichtkontakt zu dem Rover für viele Aktionen voraussetzt.
		\par
		Des Weiteren gibt es nur wenige Fehler, auf welche der Rover reagieren kann, wie der Verlust der Korrekturdaten oder eine zu geringe Spannung des Akkus. Alle anderen Fehler können nicht detektiert werden. Die erkennbaren Fehler können dem Nutzer nur mitgeteilt werden, wenn sich dieser mit der aktivierten Fernbedienung in Reichweite befindet und der Nutzer sich in dem richtigen Menüpunkt befindet. Lediglich die Abschaltung des Rovers aufgrund eines zu geringen Ladestands wird auf dem Display ohne Benutzereingabe angezeigt.

	\subsection{mehr?}