- abstract

- fazit
- bewertung sapos vs rtk2go fertig

070_resuemee.tex

@@ -11,14 +11,18 @@
 		\par
 		Bevor die Entwicklung der eigentlichen Navigation beginnen konnte, musst noch das Gyroskop dem Rover hinzugefügt werden. Ein konstruierter Halter befestigt dieses am Rover und die Verbindung wurde über den dafür bereitstehenden I2C-Bus hergestellt. Die Werte des Gyroskops werden über die Klasse der Sensorverwaltung verfügbar gemacht. Der Navigationsalgorithmus verfährt nach dem Schema, den Rover zunächst auf den Zielpunkt auszurichten und dann auf diesen zuzufahren, bis die Abweichung der Ausrichtung zu groß ist. In diesem Fall wird von vorn begonnen. Damit dem Navigationsalgorithmus Zielpunkte zur Verfügung stehen, welche nach einander abgefahren werden können, wurde die Erstellung und Verwaltung von Routen implementiert. Die Routen bestehen aus Punkten, welche die eigentlichen Koordinaten speichern. Die Verwaltung der Routen bietet neben anderen Funktionen die Möglichkeiten, einzelne Routen über eine API extern zu verwalten und damit immer wieder abrufbar machen.
 		\par
-		Nach der vollständigen Implementierung der geforderten Funktionalitäten konnten mit der Evaluation begonnen werden. Dabei wurden verschiedene Tests ausgeführt. Mit diesen sollte zunächst die Funktion der Implementierungen geprüft werden. Überdies wurde untersucht, ob sich ein unterscheidbares Verhalten einstellt, wenn die Quelle der Korrekturdaten von der errichteten Referenzstation auf den Sapos Dienst geändert wird. Die Erkenntnisse aus diesen Untersuchen werden im nächsten Abschnitt, dem Fazit, erläutert.
+		Nach der vollständigen Implementierung der geforderten Funktionalitäten konnten mit der Evaluation begonnen werden. Dabei wurden verschiedene Tests ausgeführt. Mit diesen sollte zunächst die Funktion der Implementierungen geprüft werden. Überdies wurde untersucht, ob sich ein unterscheidbares Verhalten einstellt, wenn die Quelle der Korrekturdaten von der errichteten Referenzstation auf den Sapos Dienst geändert wird. Die Erkenntnisse aus diesen Untersuchungen werden im nächsten Abschnitt, dem Fazit, erläutert.
 
 	\section{Fazit}
-		Ergebnisse eigene vs andere Station
-		Eigene Station sinnvoll?
-		Kompass erweiterung sinnvoll?
-		Navigationsleistung des Rovers. Nicht vollständig; Kommt noch.
-
+		Dieses Fazit misst sich an der Zielsetzung aus Abschnitt \ref{sec:zielsetzung}. Der Themenbereich rund um die Referenzstation wurde als erstes Ziel festgesetzt und daher auch zu Anfang dieser Arbeit umgesetzt. Dadurch weist dieser Teil die längste Erprobungszeit auf. Die Station entspricht den Erwartungen und erfüllt ihre Aufgabe. Ein Ausfall nach zweimonatiger Laufzeit zeigte mögliche Schwächen der Anlage bei hohen Temperaturen auf. Überdies wurden Informationen gewonnen, welche für Verbesserungen an der Referenzstation herangezogen werden können. Diese werden mit anderen Vorschlägen im nächsten Abschnitt \ref{sec:ausblick} dargelegt. Aus den vergleichenden Messungen in einem 40 km Radius zwischen dieser Station und dem Sapos Dienst ging ein kleiner Vorteil für die Lösung dieser Arbeit hervor. Dieser gemessene Vorteil kann allerdings nicht für jedes Einsatzszenario angenommen werden. Im Betrieb des Rovers ergeben sich keine funktionalen Unterschiede anhand der Korrekturdatenquelle. Deshalb ist die Referenzstation hauptsächlich durch nicht funktionale Aspekte von Vorteil. Aufgrund der Hardwarekontrolle ist keine Abhängigkeit zu anderen Dienstleistern gegeben. Es können eigene Projekte umgesetzt und alternative Übertragungsmöglichkeiten erprobt werden.
+		\par
+		Bei den Testungen des für den Rover implementierten Ntrip-Clients konnten beide Datenquellen mit der Revision 1 und 2 des Protokolls erfolgreich getestet werden.
+		\par
+		Die Erweiterungen des Rovers konnten alle ausgeführt werden, sodass der Rover nun autonom aufgezeichnete Routen abfahren kann. Die Navigation des Rovers greift dabei auf die Sensoren und die Implementierung der Routen zurück. Durch die Möglichkeit der Speicherung über die API konnte eine flexible Verwaltung der Routen erschaffen werden. Während der aktiven Navigation verfehlt der Rover gelegentlich die Zielpunkte, kann dies jedoch korrigieren. Die Funktionalität des Rovers ist von einer Internetverbindung und dem sauberen Empfang der GNSS-Signale abhängig und lässt sich daher als sehr vulnerabel betrachten.
+		\par
+		Der zusätzliche Sensor in Form des Gyroskops trägt dazu bei, den Rover mit weniger Aufwand während einer Navigation auszurichten und ist darüber hinaus weniger anfällig für Störungen als das Magnetometer. Dieses erleichtert jedoch die erste Ausrichtung des Rovers. Daher lassen sich beide Sensoren als sinnvoll eingesetzt betrachten.
+		\par
+		Zusammengenommen lässt sich aus der Bewertung schließen, dass das Projekt erfolgreich durchgeführt wurde und dabei Erkenntnisse für Verbesserungen und zukünftige Projekte gewonnen wurden.
 
 	\section{Ausblick}
 		\label{sec:ausblick}
@@ -50,3 +54,5 @@
 			Das Projekt \texttt{RTKBase} ist auf GitHub \cite[]{rtkbase} verfügbar. Dabei handelt es sich um eine Webapplikation, welche die Verwaltung einer Referenzstation vereinfachen soll. Dazu werden mehrere Services auf dem System gestartet, mit denen es möglich ist, die Korrekturdaten an mehrere Dienste weiterzugeben. Auf der Weboberfläche können diese Dienste verwaltet werden. Außerdem kann die Position der Antenne sowie die Pegel der empfangenen Satelliten angezeigt werden. Zusätzlich kann über das Terminal, die Verbindung zu dem GNSS-Modul freigegeben werden, sodass dieses etwa direkt im u-center über das Netzwerk eingebunden werden kann.
 			\par
 			Mit diesem Projekt könnte die Qualität der Referenzstation verbessert werden, weil so das Monitoring und die Wartbarkeit vereinfacht werden würden. Zusätzlich würde dadurch eine gewisse Erweiterbarkeit dem System hinzugefügt werden, da dadurch weitere Dienste mit Korrekturdaten versorgt werden könnten.
+
+		\subsection{Temperaturbeständigkeit der Referenzstation}