added evaluation requirements

045_anforderungen.tex

@@ -1,4 +1,5 @@
 \chapter{Anforderungen}
+	\label{cha:anforderunge}
 	In diesem Teil der Arbeit werden die Anforderungen an die verschieden Komponenten des Gesamtsystems beschrieben. Dabei wird zunächst auf die Anforderungen der Referenzstation eingegangen, neben den funktionalen Anforderungen sind die durch den Installationsort gegebenen nicht funktionalen Anforderungen besonders bei der Hardwareauswahl zu beachten.
 	\par
 	Darüber hinaus werden Anforderungen zur Erweiterung des Rovers definiert.
@@ -21,7 +22,7 @@
 			Die Energieversorgung ist durch ein vorhandenes Ethernetkabel mit PoE++ gegeben. Das Kabel versorgt das vorhandene Lora-Gateway mit Energie und stellt die Netzwerkverbindung her. Dieses Kabel muss so genutzt werden, dass damit die Energieversorgung und die Netzwerkverbindung für die Referenzstation und das Lora-Gateway hergestellt werden kann.
 
 		\subsection{Server}
-			Die Daten des GNSS-Moduls müssen verarbeitet werden, dafür und um eine Remote-Konfiguration des Moduls vornehmen zu können wird ein Computer benötigt für welcher die folgenden Spezifikationen erfüllen muss:
+			Die Daten des GNSS-Moduls müssen verarbeitet werden, dafür und um eine Remote-Konfiguration des Moduls vornehmen zu können wird ein Computer benötigt für welcher die folgenden Spezifikationen gelten müssen:
 
 			\setlist{noitemsep}
 			\begin{itemize}
@@ -36,13 +37,14 @@
 			Darüber hinaus müssen die bereits zuvor allgemein definierten Anforderungen erfüllt werden. Der Server selbst soll ebenfalls über das Netzwerk administriert werden können.
 
 	\section{Rover}
-		Die vorhandene Software des Rovers soll um einige Komponenten erweitert werden. Diese Komponenten sollen den Rover im allgemeinen um die Funktion erweitern mittels GNSS eine Route abzufahren, die zuvor manuell abgefahren wurde. Die Erweiterungen sollen sofern möglich an dem vorhandene Softwaredesign angepasst sein. Im folgenden werden die dazu nötigen Anforderungen zu definieren.
+		\label{sec:rover_req}
+		Die vorhandene Software des Rovers soll um einige Komponenten erweitert werden. Diese Komponenten sollen den Rover im allgemeinen um die Funktion erweitern mittels GNSS eine Route abzufahren, die zuvor manuell abgefahren wurde. Die Erweiterungen sollen sofern möglich an das vorhandene Softwaredesign angepasst sein. Im folgenden werden die dazu nötigen Anforderungen zu definieren.
 
 		\subsection{NTRIP-Client}
 			Der Rover muss das GNSS-Modul mit Korrekturdaten versorgen um die benötigte Genauigkeit zu erreichen. Dafür soll der ESP32 über einen NTRIP-Client verfügen, welcher sich mit dem Caster verbindet und die Korrekturdaten empfängt. Es wird davon ausgegangen, dass eine Internetverbindung über WLAN vorhanden ist. Die Empfangenen Daten müssen an das GNSS-Modul weitergeleitet werden, dies muss durch die vorhandene Anbindung über SPI geschehen. Der Verbindungsstatus des Clients soll für andere Komponenten verfügbar gemacht werden können, um beispielsweise mit einer Navigationspause während eines Verbindungsabbruches reagieren zu können. Sollte die Verbindung zum WLAN und oder zu dem Caster verloren gehen, sollen diese sofern möglich automatisch wieder aufgebaut werden.
 
 		\subsection{Route}
-			Eine Route soll aus einer Anzahl von Punkten bestehen. Die Punkte sollen die Koordinaten für Längen- und Breitengrat enthalten, zusätzlich können Metadaten wie die geschätzte Genauigkeit der Koordinaten mit gespeichert werden. Die Punkte müssen in einer festen Reihenfolge gespeichert werden. Die Strecken zwischen den Punkten müssen Geraden sein.
+			Eine Route soll aus einer Anzahl von Punkten bestehen. Die Punkte sollen die Koordinaten für Längen- und Breitengrad enthalten, zusätzlich können Metadaten wie die geschätzte Genauigkeit der Koordinaten mit gespeichert werden. Die Punkte müssen in einer festen Reihenfolge gespeichert werden. Die Strecken zwischen den Punkten müssen Geraden sein.
 
 			\subsubsection{Aufzeichnen}
 				Die Aufzeichnung einer Route soll ausschließlich von dem Benutzer gesteuert werden. Dazu soll der manuelle Fahrmodus des Rover genutzt werden, der eine Steuerung mit dem Joystick der Fernbedingung ermöglicht. Sofern das aufzeichnen der Route begonnen hat soll mit Drücken des Joystick-Buttons ein neuer Punkt der Route hinzugefügt werden. Der hinzuzufügende Punkt soll zuvor auf eine ausreichende Genauigkeit und einen Mindestabstand zu dem, falls vorhanden, vorherigen Punkt geprüft werden. Ob die aktuelle Position der Route hinzugefügt wurde soll dem Nutzer als Feedback zur Verfügung stehen.

060_implementierung.tex

@@ -243,6 +243,7 @@
 				\end{itemize}
 
 		\subsection{Routen Management}
+			\label{ssec:route_management}
 			Die Implementierung der Routen Verwaltung erfolgt über die \mintinline{c++}|class Route|, welche eine Liste zur Speicherung der Punkte nutzt. Die Punkte sind Instanzen der \mintinline{c++}|class Point|. Es herrscht also eine 1 zu n Beziehung zwischen \mintinline{c++}|class Route| und \mintinline{c++}|class Point|.
 
 			\subsubsection{Postionen mit \mintinline{c++}|class Point|}
@@ -291,6 +292,7 @@
 				\end{itemize}
 
 		\subsection[Navigation]{\mintinline{c++}|class Navigation|}
+			\label{ssec:navigation_implementation}
 			Diese Klasse vereinigt die Verwaltung der Route mit den Sensorwerten wie die Positionsdaten und Ausrichtung um die eigentliche Navigation bereitzustellen. Außerdem werden die Anforderungen an die Genauigkeit überwacht. Die Navigation wird von den Modi zur Aufzeichnung und Abfahrt der Route benötigt.
 			\par
 			Es wurde ein \mintinline{c++}|enum Status| implementiert, welcher von einigen Funktionen der Klasse genutzt wird um Informationen über den Ausgang des Funktionsaufrufes zu informieren. Es kann mitgeteilt werden ob die Genauigkeit unzureichend ist, keine Änderungen erfolgt sind, etwas geändert wurde und ob die etwas abgeschlossen wurde. Des weiteren wird in der selben Header-Datei das \mintinline{c++}|struct CourseCorrection| definiert um die Distanz und die anzuwendende Kurskorrektur zum Zielpunkt in einem Datentypen zu vereinen.
@@ -305,6 +307,7 @@
 			Der Modus wird über einen Menüeintrag gestartet. Während der Modus aktiv ist, werden im Menü neben Informationen über Sensorwerte und die bisher aufgezeichnete Route auch Einstellungen zu der geforderten Genauigkeit geboten.
 
 		\subsection{Modus - Route abfahren}
+			\label{ssec:route_drive}
 			Die Funktionalität, erfasste Routen abzufahren erfordert die Zusammenarbeit mehrerer Komponenten. Zunächst wird beschrieben wie die Navigationsklasse den Kurs zum Zielpunkt berechnet und die Navigationsanweisungen gibt und bestimmt ab wann ein Punkt als erreicht gilt. Die Anweisungen müssen von dem Autopiloten umgesetzt werden, dafür muss sich dieser auf den Zielpunkt Ausrichten und die Strecke mit angepasster Geschwindigkeit zurücklegen.
 			\par
 			Der letztendlich ausführende Modus nennt sich \texttt{Autopilot} und wird wie \texttt{CaptureRoute} in das System eingebunden, da dieser Modus, um den Rover an die Startposition der Route fahren zu können, ebenfalls von dem Modus zum manuellen Verfahren erbt. Während der Autopilot die Steuerung übernimmt, werden keine Eingaben von dem Joystick zum verfahren des Rovers akzeptiert. Wenn der Autopilot verfügbar ist kann er durchs betätigen der Aktions-Taste aktiviert werden und auch wieder deaktiviert werden.

065_bewertung.tex

@@ -1,7 +1,47 @@
 \chapter{Bewertung}
+	Im vorletzten Kapitel dieser Arbeit werden die umgesetzten Implementierungen und Aufbauten bewertet. Dafür werden zunächst die gestellten Anforderungen betrachtet und ausgewertet, im Anschluss wird auf die Referenzstation und die durch den Aufbau errungenen Erkenntnisse eingegangen. Abgeschlossen wird dieses Kapitel mit Einschätzungen zu den Implementierungen, welche im Zuge der Erweiterung des Rovers vorgenommen wurden und einigen Testszenarien. Diese sollen Aufschluss über die Funktionalität des Gesamtsystems geben.
+
+	\section{Anforderungsauswertung}
+		Die Anforderungen aus Kapitel \ref{cha:anforderunge} wurden im groben auf die zwei Abschnitte Referenzstation \ref{sec:referenzstation_req} und Rover \ref{sec:rover_req} aufgeteilt, diese werden hier ebenso benutzt um zwischen den Anforderungen zu unterscheiden.
+
+		\subsection{Referenzstation}
+			Die Anforderungen an die Referenzstation wurden nach dem aktuellen Stand erfüllt. Die Einmessung der Antenne konnte wie gefordert im Millimeterbereich ausgeführt werden, siehe hierzu Anhang \ref{cha:auswerungObservation}. Seit dem 07. Juni 2024 bis \today \ läuft die Anlage ohne Störungen und erfüllt damit die Anforderung an einen durchgehenden Betrieb mit minimalen Wartungsaufwand.
+			\par
+			Die Anforderungen an die Gebäudesicherheit wurden durch Absprache und Begleitung der Installation sicher gestellt. Das Kapitel \ref{cha:Hardwareauswahl} Hardwareauswahl hat sich mit den durch die Umwelt und Infrastruktur gegebenen Anforderungen an die Hardware auseinandergesetzt und konnte damit die Energieversorgung leisten sowie die Langlebigkeit der Anlage durch ausreichende Betriebstemperaturbereiche und Regenwasserschutz gewährleisten.
+			\par
+			Der Installationsort der Antenne unterlag der Bedingung, dass diese eine freie Sicht auf den Himmel innehat. Durch eine Erhöhung der Antenne mit einem C-Profil um der Abschattung durch den Lüftungskanal zu entgehen, konnte die freie Sicht erreicht werden.
+
+			\subsubsection{Server}
+				Der Server musste einige Spezifikationen aufweisen. Der USB-Port zwar zwingend erforderlich für die Verbindung zu dem GNSS-Modul. Als weitere Schnittstelle musste eine RJ-45 für Ethernet vorhanden sein. Diese sollte auch über PoE verfügen, hier musste auf eine Alternative zurückgegriffen werden, da kein angemessenes Gerät gefunden wurde, welches zusätzlich diese Spezifikation erfüllt. Der gewählte Embedded Computer verfügt über die geforderten Schnittstellen und ist aufgrund der handelsüblichen x86 Architektur auch für die RTK-Lib geeignet. Der Energiebedarf war mit den Spezifikationen schon im SOLL und konnte noch darüber hinaus reduziert werden.
+
+		\subsection{Rover}
+			Die Anforderungen an Rover stammen aus der übergeordneten Forderung. Laut dieser soll der Rover so erweitert werden, dass dieser eine zuvor aufgezeichnete Route eigenständig abfahren kann. Dafür wurden die folgenden Komponenten als Anforderungen definiert:
+
+			\begin{itemize}
+				\item Der Rover muss über einen \textbf{Ntrip-Client} verfügen. Die Implementation wurde in Abschnitt \ref{ssec:ntripclient} beschrieben. Dafür wurde ein Dokument von der RTCM herangezogen welches Anmerkungen und Hilfestellung für die erfolgreiche Implementation eines Clients gibt. Durch die Umsetzung als Zustandsautomat kann der aktuelle Zustand des Clients einfach an andere Komponenten weitergegeben werden. Die Anforderungen verloren gegangene Verbindung automatisch wieder aufzubauen wurde für die Verbindung zu dem Caster umgesetzt. Die Umsetzung der W-Lan-Verbindung und deren Funktion zum automatischen Wiederverbinden wurde bereits in der vorhanden Software des Rovers umgesetzt.
+				\item Für die Navigation müssen die Daten für eine \textbf{Route} gespeichert werden. Das Management der Routen wurde den Anforderungen entsprechend vollständig implementiert und wird in Abschnitt \ref{ssec:route_management} beschrieben. Dabei wurde die Speicherung von einzelnen Punkten mit Metadaten, welche durch eine verkette Liste in eine feste Reihenfolge gebracht werden umgesetzt. Außerdem wurde die Schnittstelle zu einer HTTP-API implementiert damit die Routen unabhängig von dem ESP32 persistiert werden können. Eine neue Route kann mit dem dafür angelegten Betriebsmodus des Rovers aufgenommen werden.
+				\item Die neue Kernfunktion wurde in zwei Funktionen aufgeteilt, davon ist die erste die \textbf{Navigation}. Mit dieser wird die Route lesend verarbeitet und die Informationen über Distanz und Kurs zum nächsten Punkt werden über einen erstellten Datentypen der Nutzenden Komponente zur Verfügung gestellt. Eine nähere Beschreibung der Vorgehensweise ist in Abschnitt \ref{ssec:navigation_implementation} zu finden. Die Eigenständig der Navigation wurde durch die Implementierung als Komponente erreicht.
+				\item Die zweite Funktion zur Realisierung der Kernfunktion ist der \textbf{Autopilot}. Dessen Anforderung werden durch die Implementierungen ab Abschnitt \ref{ssec:route_drive} erfüllt. Dafür wurde der Autopilot und der dazu passende Betriebsmodus entwickelt. Die Kernfunktionen werden zusätzlich mit den Test in Abschnitt \ref{sec:tests} überprüft.
+			\end{itemize}
+
+	\section{Referenzstation}
+		Die Abschnitt beschreibt und bewertet die Errichtung der Referenzstation. Dafür sind zunächst die Empfangenen Satelliten und die Fehler der Signale interessant. Des weiteren erfordert der Server zwar wenig wartungsarbeit, aber dieser ist schwer auszuführen, da alle Einstelungen manuell und textbasiert getätigt wurden.
+		\par
+		Der Ntrip-Client welcher auf dem Rover implementiert wurde kann mit beiden Revisionen von Ntrip betrieben werden, daher ist es interessant ob Unterschiede erkennbar sind.
+
+		\subsection{Signalqualität}
+
+		\subsection{Verwaltungsoberfläche}
+
+		\subsection{Ntrip Revision 1}
+
+			Genaauigkeit antenne ohne Korrekturdaten (drift)
+			Mögliche verbesserung durch web ui
+			Ntrip rev 1 oder 2 Ergebnis (Sapos auch testen)
 
 	\section{Tests}
-		\subsection{Route aufnehmen}
+		\label{sec:tests}
+		\subsection{Route aufzeichnen}
 			\subsubsection{Koordinaten Plausibilität}
 		\subsection{Routen management}
 			\subsubsection{Route exportieren}
@@ -9,7 +49,3 @@
 			\subsubsection{Route löschen}
 		\subsection{Route abfahren}
 			\subsubsection{Genuigkeitsprüfung stören}
-
-	\section{Anforderungsauswertung}
-
-		Ntrip Client mies?

Notes.txt

@@ -20,8 +20,6 @@ Fehlende Abschnitte:
         -ser2net bei den Protokollen? Mal lesen ob das da rein muss.
     - Anforderungen
         - Genauigkeit der Positionsbestimmung | Vielleicht rausschmeißen
-    - Implementierung
-        - Ntrip Client
     - Bewertung komplett
     - Resümee komplett