- firs correction ruin finished

- added more pictures

060_4_implementierung_rover.tex

@@ -4,16 +4,24 @@
 	\subsection{Gyroskop installieren}
 		Die elektrische Verbindung des Moduls wird über vier Pins hergestellt, dabei handelt es sich um die zwei I2C Leitungen sowie Masse und die Spannungsversorgung. Das Modul kann mit \(+5V\) betrieben werden. Auf der Hauptplatine sind Pin-Leisten vorhanden, um weitere I2C-Module, welche mit \(+5V\) betrieben werden können, dem System hinzufügen zu können.
 		\par
-		Das Modul wird mit einer nicht bestückten Pin-Leise geliefert, daher bestand die Möglichkeit eine gewinkelte Pin-Leiste einzulöten. Es wurde eben diese Pin-Leiste gewählt, um das Modul waagerecht mit einer weiteren Platine verbinden zu können. Bei der zusätzlichen Platine handelt es sich lediglich um einen Verteiler, welcher in Abbildung !!!ref!!! gezeigt wird. Dort ist zu sehen, wie der Verteiler, durch seine L-Form, an einem Querbalken mit einer Maul-Büroklammer befestigt wird. Das MPU-6050 Module wird seitlich an eine ebenfalls gewinkelte Sockel-Leiste eingesteckt. Auf der Oberseite der Platine befinden sich drei weitere Konnektoren, an denen das Display und das Magnetometer angeschlossen werden. Zwei der Konnektoren sind für das Magnetometer, um es entweder an den I2C-Bus des ESP32 oder an den Auxiliary-I2C-Bus des MPU-6050 anzuschließen. Auf der Unterseite der Platine ist ein Kabel angelötet, welches auf die Hauptplatine gesteckt wird.
+		Das Modul wird mit einer nicht bestückten Pin-Leise geliefert, daher bestand die Möglichkeit eine gewinkelte Pin-Leiste einzulöten. Es wurde eben diese Pin-Leiste gewählt, um das Modul waagerecht mit einer weiteren Platine verbinden zu können. Bei der zusätzlichen Platine handelt es sich lediglich um einen Verteiler, welcher in Abbildung \ref{fig:gyroPlatine} gezeigt wird. Dort ist zu sehen, wie der Verteiler, durch seine L-Form, an einem Querbalken mit einer Maul-Büroklammer befestigt wird. Das MPU-6050 Module wird seitlich an eine ebenfalls gewinkelte Sockel-Leiste eingesteckt. Auf der Oberseite der Platine befinden sich drei weitere Konnektoren, an denen das Display und das Magnetometer angeschlossen werden. Zwei der Konnektoren sind für das Magnetometer, um es entweder an den I2C-Bus des ESP32 oder an den Auxiliary-I2C-Bus des MPU-6050 anzuschließen. Auf der Unterseite der Platine ist ein Kabel angelötet, welches auf die Hauptplatine gesteckt wird.
 		\par
-		Durch diese weitere Platine wurde zum einen der benötigte feste Platz für das neue Modul geschaffen und zum anderen die Möglichkeit offen gehalten, den bereits verbauten Kompass nun über den MPU-6050 zu nutzen, um eine 9-Achsen Sensorfusion zu ermöglichen. Der Versuch diese 9-Achsen Sensorfusion zu implementieren ist gescheitert. Der Hersteller wirbt zwar mit dieser Funktion, jedoch ist die Rechenleitung des Chips nicht ausreichend hoch genug, damit die Funktion umzusetzen werden kann. Daher müssten Berechnung dafür auf den ESP32 ausgelagert werden !!!cite \url{https://www.i2cdevlib.com/devices/mpu6050#help}!!!. Dieser Weg wurde aufgrund der Komplexität nicht weiter verfolgt.
+
+		\begin{wrapfigure}{r}{0.4\textwidth}
+			\centering
+			\includegraphics[width=0.38\textwidth]{img/gyroPlatine.jpg}
+			\caption{I2C Verteilung mit abgeschlossen Gyroskop}
+			\label{fig:gyroPlatine}
+		\end{wrapfigure}
+
+		Durch diese weitere Platine wurde zum einen der benötigte feste Platz für das neue Modul geschaffen und zum anderen die Möglichkeit offen gehalten, den bereits verbauten Kompass nun über den MPU-6050 zu nutzen, um eine 9-Achsen Sensorfusion zu ermöglichen. Der Versuch diese 9-Achsen Sensorfusion zu implementieren ist gescheitert. Der Hersteller wirbt zwar mit dieser Funktion, jedoch ist die Rechenleitung des Chips nicht ausreichend hoch genug, damit die Funktion umzusetzen werden kann. Daher müssten Berechnung dafür auf den ESP32 ausgelagert werden\cite[]{9achsfail}. Dieser Weg wurde aufgrund der Komplexität nicht weiter verfolgt.
 		\par
 		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 Funktion zum Datenerhalt, die Funktion \mintinline{c++}|void enableGyroscope(); | hinzugefügt. Diese erzeugt ein Objekt für den MPU-6050 und initialisiert sowohl den MPU-6050 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 in jedem Durchgang, ob neue Daten des Sensors verfügbar sind und verarbeitet diese dann.
 
 
 	\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}. Zudem 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.
+		Die Implementierungen des Clients orientiert sich an dem von der RTCM herausgegebenen Paper \glqq Best Practices for Ntrip Client developers\grqq \cite{NTRIPWorkingGroup2023}. Zudem 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.
@@ -29,8 +37,15 @@
 			\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.
+		\subsubsection{Zustandsautomat}
+			Der Ntrip Client wurde nach dem Schema eines Zustandsautomaten entworfen, welcher in Abbildung \ref{fig:NTRIPClientStates} 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{figure}[ht]
+				\centering
+				\includegraphics[width=\linewidth]{img/ntripClientStates.png}
+				\caption{Skizzierung des Zustandsautomaten des Ntrip Clients}
+				\label{fig:NTRIPClientStates}
+			\end{figure}
 
 			\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.