added ntrip client implementation

.vscode/settings.json

@@ -100,6 +100,7 @@
         "mintinline",
         "Nachstellzeit",
         "NAVSTAR",
+        "Ntrip",
         "NTRIP",
         "PICO",
         "Pinleiste",

060_implementierung.tex

@@ -213,9 +213,34 @@
 			Die Einbindung des Sensors in den vorhandenen Programmcode erfolgte mit der bereits vorhanden \mintinline{c++}|class SensorData|. Für die Kommunikation mit dem Sensor wird die Bibliothek \texttt{I2Cdevlib-MPU6050} verwendet. Der Klasse wurden neben einer Funktionen zum Datenerhalt, die Funktion \mintinline{c++}|void enableGyroscope();| hinzugefügt. Diese erzeugt ein Objekt für den MPU6050 und initialisiert sowohl den MPU6050 als auch den verbauten Digital Motion Processor. Außerdem werden ermittelte Offsets eingestellt. Die periodische aufgerufene \mintinline{c++}|void run();| Funktion wurde ebenfalls erweitertet und überprüft jetzt im jeden Durchgang ob neue Daten des Sensors verfügbar sind und verarbeitet diese dann.
 
 
-		\subsection{NTRIP Client}
+		\subsection{Ntrip Client}
 			\label{ssec:ntripclient}
-			Die Implementierungen des Clients orientiert sich an dem von der RTCM herausgegebenen Paper \glqq Best Practices for NTRIP Client developers\grqq \cite{NTRIPWorkingGroup2023}
+			Die Implementierungen des Clients orientiert sich an dem von der RTCM herausgegebenen Paper \glqq Best Practices for NTRIP Client developers\grqq \cite{NTRIPWorkingGroup2023}. Außerdem können beide Revisionen des Protokolls mit dem Client benutzt werden. Die Revision 1 ist offiziell von der RTCM als \texttt{outdated} markiert. Der in dieser Arbeit verwendete Caster \url{rtk2go.com} gibt jedoch in seinen Statistiken an, dass \(95\%\) der eingehenden Verbindungen die Revision 1 verwenden. Zusätzlich kann durch die Implementierung beider Revisionen die angegeben Abwärtskompatibilität getestet werden. Des weiteren wird die Authentisierung mit Benutzernamen und Kennwort sowie die Übermittlung des eigenen Standorts an den Caster implementiert. Der Eigene Standort ist für Caster wichtig, welche mit einem Netz aus Referenzstationen betrieben werden. Die Implementierung erfolgt also damit der Rover auch abseits der errichteten Referenzstation von anderen Anbietern mit Korrekturdaten versorgt werden kann.
+
+			\subsubsection{Einstellungen}
+				Eine Instanz des Clients fordert die Adresse des Casters, den Mountpoint, die Zugangsdaten und das GNSS-Modul als Parameter für den Konstruktor, diese sind nur durch eine neue Instanz änderbar. Der Benutzername und das Passwort können ignoriert werden, wenn eine Anmeldung bei dem Caster ohne Zugangsdaten möglich ist.
+				\par
+				Eine erstellte Instanz verfügt über vier Einstellungsmöglichkeiten. Diese können entweder aktiviert oder deaktiviert werden.
+
+				\setlist{noitemsep}
+				\begin{itemize}[]
+					\item Automatisches Wiederverbinden bei Verbindungsabbrüchen \texttt{(default : true)}
+					\item Die eigene Position übertragen \texttt{(default : false)}
+					\item Ntrip Revision 1 verwenden \texttt{(default : false)}
+					\item Den Client selbst aktivieren \texttt{(default : true)}
+				\end{itemize}
+				\setlist{}
+
+			\subsubsection{Zustandsautomaten}
+				Der Ntrip Client wurde nach dem Schema eines Zustandsautomaten entworfen, welcher in Abbildung !!!ref!!! skizziert wird. Im folgenden wird auf die Funktionalitäten der einzelnen Zustände eingegangen. Die Zustände werden durch das \mintinline{c++}|enum NTRIPClientStates| definiert.
+
+				\begin{itemize}
+					\item \textbf{openingConnection} In diesem Zustand wird versucht die Verbindung zu dem Caster aufzubauen. Dafür wird zwischen den Revisionen von Ntrip unterschieden, ob die Position gesendet werden soll und ob Zugangsdaten angegeben worden sind. Sollte der Verbindungsaufbau scheitern wird in den \texttt{waiting} Zustand gewechselt ansonsten in den \texttt{pushingData} Zustand.
+					\item \textbf{pushingData} Wenn eine Verbindung zu dem Caster besteht, befindet sich der Client in diesem Zustand und leitet die empfangenen Daten an das GNSS-Modul weiter. Es kann nur in den \texttt{closingConnection} Zustand gewechselt werden.
+					\item \textbf{closingConnection} Sollt der Ntrip Client deaktiviert werden oder ein Timeout festgestellt werden, wird in diesen Zustand gewechselt, damit die Verbindung aus Sicht des Clients ordnungsgemäß beendet wird. Sobald die Verbindung getrennt ist wird der \texttt{waiting} Zustand aktiv.
+					\item \textbf{waiting} Wenn dieser Zustand betreten wird, wurde die Verbindung getrennt und es wird darauf gewartet in den \texttt{openingConnection} Zustand zu wechseln. Dafür muss entweder der Client wieder aktiviert werden oder die automatische Wiederverbindung muss aktiviert sein.
+					\item \textbf{notAvailable} Dieser Zustand wird betreten wenn keine Verbindung zum Internet bereitsteht.
+				\end{itemize}
 
 		\subsection{Routen 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|.