kleiax/Bachelor-Arbeit-Latex
Archived
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

- firs correction ruin finished

Browse Source 
- added more pictures
This commit is contained in:
kleiax
2024-08-12 01:30:48 +02:00
parent b616953920
commit 70b19fb66c
19 changed files with 323 additions and 157 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.vscode/ltex.dictionary.de-DE.txt
Vendored
+15
View File
@@ -161,3 +161,18 @@ Coordinates
Postionsspeicherung
bool
RouteInfo
CourseCorrection
CaptureRoute
DiveModi
SelfDriving
SelfDrivingRotate
SkyView
RTKBase
Sapos
complete
import
Complete
Clear
API-URL
ArduinoCore
FreeRTOS
.vscode/ltex.hiddenFalsePositives.de-DE.txt
Vendored
+1
View File
@@ -23,3 +23,4 @@
{"rule":"UPPERCASE_SENTENCE_START","sentence":"^\\Qdie Antenne soll am Ende des C-Profils, welches zur Verlängerung des Pfostens dient, befestigt werden.\\E$"}
{"rule":"ALTERNATIVEN_FUER_ANGLIZISMEN","sentence":"^\\QDamit die Aufzeichnung nicht als Kind-Prozess der Remote-Sitzung läuft wird das Hilfsprogramm []bash|screen| installiert, da ansonsten ein Abbruch der Verbindung auch die Aufzeichnung frühzeitig beenden würde.\\E$"}
{"rule":"ALTERNATIVEN_FUER_ANGLIZISMEN","sentence":"^\\QDamit die Aufzeichnung nicht als Kind-Prozess der Remote-Sitzung läuft, wird das Hilfsprogramm []bash|screen| installiert, da ansonsten ein Abbruch der Verbindung auch die Aufzeichnung frühzeitig beenden würde.\\E$"}
{"rule":"ALTERNATIVEN_FUER_ANGLIZISMEN","sentence":"^\\QDie Datenhaltung der Route wird über statische Funktionen und Member in der Klasse Route realisiert, die zwischengespeicherte Route ist dementsprechend nicht persistent.\\E$"}
000_main.tex
+3 -1
View File
@@ -34,6 +34,7 @@
\usepackage{url} % Zum einfügen von URLs ohne das alles escaped werden muss
\usepackage{menukeys} % Zum Anzeigen von Tastenkombinationen
\usepackage{pdfpages} % Einbinden von PDFs
\usepackage{wrapfig} % Bilder im Fließtext
% Tabelle über mehrere Seiten
\usepackage{longtable}
@@ -126,7 +127,8 @@
\include{060_4_implementierung_rover}
\include{060_5_implementierung_rover}
\include{065_bewertung}
\include{065_1_bewertung}
\include{065_2_bewertung}
\include{070_resuemee}
030_einleitung.tex
+8 -4
View File
@@ -20,12 +20,16 @@
\par
Dem Rover liegt eine Fernbedienung zur Steuerung des Systems bei, diese wurde ebenfalls in der genannten Arbeit entworfen und verfügt über 7 Taster, einem Joystick und einem Display. Dadurch konnte die vollständige Benutzerschnittstelle auf der Fernbedienung abgebildet werden.
\begin{figure}
\begin{figure}[ht]
\centering
\includegraphics[width=\linewidth]{img/rover.jpg}
\includegraphics[width=0.5\linewidth]{img/rover.jpg}
\caption{Abbildung des Rovers}
\label{fig:rover}
\end{figure}
!!!Bild von der Fernbedienung!!!?
\begin{figure}[ht]
\centering
\includegraphics[width=0.5\linewidth]{img/fernbedienung.png}
\caption{Abbildung der Fernbedienung für den Rover}
\label{fig:fernbedienung}
\end{figure}
060_2_implementierung_basisstation.tex
+8 -12
View File
@@ -12,8 +12,8 @@
\subsubsection{Netzwerk}
Nach der Installation bezieht der Server seine Netzwerkkonfiguration über einen DHCP-Server. Für eine feste Installation eines Servers ist die manuelle Konfiguration der Netzwerkschnittstelle dringend empfohlen, damit die IP-Adresse zu jeder Zeit persistent und bekannt ist. Dafür müssen zwei Dateien editiert werden und der Name des Netzwerkinterfaces muss bekannt sein.
Die erste Datei mit dem Pfad \url{/etc/network/interfaces} enthält die Konfigurationen aller auf dem System verfügbaren Interfaces. Da der Server lediglich über ein Interface verfügt, kann in der Datei auch der Name des Interfaces abgelesen werden. !!!Im folgenden Dings ist die Conf:!!!
Die erste Datei mit dem Pfad \url{/etc/network/interfaces} enthält die Konfigurationen aller auf dem System verfügbaren Interfaces. Da der Server lediglich über ein Interface verfügt, kann in der Datei auch der Name des Interfaces abgelesen werden.
\par
Die zweite Datei ist unter dem Pfad \url{/etc/resolv.conf} zu finden und definiert die zu benutzenden DNS-Server. Dabei wird in jeder Zeile nach dem folgenden Muster ein Nameserver angegeben: \flqq nameserver xxx.xxx.xxx.xxx\frqq. In dem Netz der FH-Dortmund lauten die IP-Adressen der Nameserver \mintinline{text}|172.22.1.10| und \mintinline{text}|172.22.1.20|.
\par
Die Netzwerkkonfiguration wurde durch einen Mitarbeiter im Hardwarelabor der FH-Dortmund festgelegt und im System eingepflegt. Wenn die Bearbeitung der Datei abgeschlossen ist, muss das Netzwerkinterface neu gestartet werden. Dies kann mit dem Befehl \mintinline{bash}|ifdown <interface>| gefolgt von \mintinline{bash}|ifup <interface>| oder einem Neustart des Computers erfolgen.
@@ -53,16 +53,12 @@
Um ein serielles Interface über ser2net im Netzwerk freizugeben, muss dieses in der Konfigurationsdatei (\url{/etc/ser2net.yaml}) deklariert werden. Dafür muss der Gerätepfad des GNSS-Moduls bekannt sein. Dieser kann herausgefunden werden, indem das Modul an einen USB-Port angesteckt und in dem Verzeichnis \url{/dev} nach einer neuen Datei geschaut wird, welche mit \mintinline{text}|tty| beginnt. In der Konfigurationsdatei wird der folgende Yaml-Block ergänzt:
% \begin{minted}[linenos, gobble=4, tabsize=4, showtabs=no]{yaml}
% connection: con0096
% accepter: tcp,2000
% enable: on !!!mach mal richtig hier!!!
% options:
% banner: *banner
% kickolduser: true
% telnet-brk-on-sync: true
% connector: serialdev,/dev/ttyS0,9600n81,local
% \end{minted}
\begin{minted}[linenos, gobble=4, tabsize=4]{yaml}
connection: &ZEDF9P
accepter: tcp,1234
enable: on
connector: serialdev,/dev/ttyUSB0,38400n81,local
\end{minted}
Sollte der Service zum Zeitpunkt der Konfiguration aktiv gewesen sein, muss es mit dem genannten Befehl gestoppt und kann anschließend je nach Bedarf aktiviert werden. Sobald der Service aus Abschnitt \ref{ssec:pushService} aktiv ist, muss dieser gestoppt werden, bevor eine Verbindung zu ser2net aufgebaut wird. Wenn dies nicht geschieht, ist es nicht vorhersehbar, an welchen Service die ankommenden Daten des GNSS-Moduls geleitet werden.
060_4_implementierung_rover.tex
+20 -5
View File
@@ -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.
060_5_implementierung_rover.tex
+22 -22
View File
@@ -1,36 +1,36 @@
\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.
Diese Klasse vereinigt die Verwaltung der Route mit den Sensorwerten wie die Positionsdaten und Ausrichtung, damit die eigentliche Navigation bereitgestellt werden kann. 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.
Es wurde ein \mintinline{c++}|enum Status| implementiert, welcher von einigen Funktionen der Klasse genutzt wird, um Informationen über das Ergebnis der aufgerufenen Funktion zu informieren. Es kann mitgeteilt werden, ob die Genauigkeit unzureichend ist, keine Änderungen erfolgt sind, etwas geändert und ob die etwas abgeschlossen wurde. Des Weiteren wird in derselben Header-Datei das \mintinline{c++}|struct CourseCorrection| definiert, um die Distanz und die anzuwendende Kurskorrektur zum Zielpunkt in einem Datentypen zu vereinen.
\subsection{Modus - Route aufzeichnen}
Um eine Route aufzeichnen zu können wurde zum einen die \mintinline{c++}|class CaptureRoute| implementiert, welche von der bereits vorhanden Klasse zum manuellen Verfahren des Rovers erbt und damit auch in der Hierarchie des \texttt{DiveModi} Interfaces zu finden ist. Dadurch kann der Modus dem bestehenden System ohne weitere Änderungen hinzugefügt werden.
Um eine Route aufzeichnen zu können, wurde zum einen die \mintinline{c++}|class CaptureRoute| implementiert, welche von der bereits vorhanden Klasse zum manuellen Verfahren des Rovers erbt und damit auch in der Hierarchie des \texttt{DiveModi} Interfaces zu finden ist. Dadurch kann der Modus dem bestehenden System ohne weitere Änderungen hinzugefügt werden.
\par
Die Instanz der \mintinline{c++}|class Navigation| wird von dem aktuellen Modus erzeugt dafür wird Komponente \texttt{SensorData} benötigt und eine Route. Die \texttt{SensorData} Komponente wird jedem \texttt{DriveModi} über den Konstruktor zur Verfügung gestellt. Wenn keine Route übergeben wird, erzeugt die \texttt{Navigation} eine eigene. Da eine neue Route aufgezeichnet werden soll ist dieses Verhalten gewollt.
Die Instanz der \mintinline{c++}|class Navigation| wird von dem aktuellen Modus erzeugt, dafür wird Komponente \texttt{SensorData} benötigt und eine Route. Die \texttt{SensorData} Komponente wird jedem \texttt{DriveModi} über den Konstruktor zur Verfügung gestellt. Wenn keine Route übergeben wird, erzeugt die \texttt{Navigation} eine eigene. Da eine neue Route aufgezeichnet werden soll, ist dieses Verhalten gewollt.
\par
Um die aktuellen Koordinaten der Route hinzuzufügen, muss der Aktions-Button auf der Fernbedienung gedrückt werden. Dadurch versucht \texttt{Navigation} die Route zu erweitern. Dies kann fehlschlagen, wenn die Genauigkeit der aktuellen Position nicht den eingestellten Anforderungen entspricht oder die aktuelle Position zu nah an der, sofern vorhanden, vorherigen ist. Der minimale Abstand zwischen zwei Punkten kann ebenfalls eingestellt werden. Auch der maximale Abstand zwischen zwei Punkten ist definiert und kann eingestellt werden. Wenn die gesamte Route aufgezeichnet wurde, kann der Modus verlassen werden. Dabei wird die Instanz von Navigationsklasse zerstört und damit auch die dort gehaltene Route. Deshalb wird diese zwischengespeichert und überschreibt gegebenen falls die zuletzt gespeicherte Route. Ein Überschreiben erfolgt nur wenn die Route mindesten über zwei Einträge verfügt. Die Datenhaltung der Route wird über statische Funktionen und Member in der Klasse \texttt{Route} realisiert, die zwischengespeicherte Route ist dementsprechend nicht persistent.
Um die aktuellen Koordinaten der Route hinzuzufügen, muss der Aktions-Button auf der Fernbedienung gedrückt werden. Dadurch versucht \texttt{Navigation} die Route zu erweitern. Dies kann fehlschlagen, wenn die Genauigkeit der aktuellen Position nicht den eingestellten Anforderungen entspricht oder die aktuelle Position zu nah an der, sofern vorhanden, vorherigen ist. Der minimale Abstand zwischen zwei Punkten kann ebenfalls eingestellt werden. Auch der maximale Abstand zwischen zwei Punkten ist definiert und kann eingestellt werden. Wenn die gesamte Route aufgezeichnet wurde, kann der Modus verlassen werden. Dabei wird die Instanz von Navigationsklasse zerstört und damit auch die dort gehaltene Route. Deshalb wird diese zwischengespeichert und überschreibt gegebenenfalls die zuletzt gespeicherte Route. Ein Überschreiben erfolgt nur, wenn die Route mindestens über zwei Einträge verfügt. Die Datenhaltung der Route wird über statische Funktionen und Member in der Klasse \texttt{Route} realisiert, die zwischengespeicherte Route ist dementsprechend nicht persistent.
\par
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.
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.
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. Sofern der Autopilot verfügbar ist, kann dieser durch das Betätigen der Aktions-Taste aktiviert und auch wieder deaktiviert werden.
\par
Auch der \texttt{Autopilot} verfügt über ein Menü über den dieser aufgerufen wird. Das Menü stellt Status-, Sensor-, Routen-, und Navigationsinformationen zur Verfügung und ermöglicht das Einstellen der wie präzise ein Punkt angefahren werden muss, ob nach Abschluss der Route diese von vorne gestartet werden soll und ob der aktuelle Zielpunkt eingefroren werden soll was dazu führt, dass die Route an diesem Punkt pausiert wird.
Auch der \texttt{Autopilot} verfügt über ein Menü, über welches dieser aufgerufen wird. Das Menü stellt Status-, Sensor-, Routen- und Navigationsinformationen zur Verfügung und ermöglicht das Einstellen der wie präzise ein Punkt angefahren werden muss, ob nach Abschluss der Route diese von vorn gestartet werden soll und ob der aktuelle Zielpunkt eingefroren werden soll, was dazu führt, dass die Route an diesem Punkt pausiert wird.
\subsubsection{Kursberechnung}
Das Ziel der Kursberechnung ist es ein vorzeichenbehaftete Kurskorrektur in Grad zu erzeugen. Dafür muss die aktuelle Ausrichtung bekannt sein. Für diese Information stehen drei Quellen zur Verfügung.
Das Ziel der Kursberechnung ist es, ein vorzeichenbehaftete Kurskorrektur in Grad zu erzeugen. Dafür muss die aktuelle Ausrichtung bekannt sein. Für diese Information stehen drei Quellen zur Verfügung.
\begin{itemize}
\item Das Magnetometer liefert absolute Werte, welche die Ausrichtung laut Datenblatt !!!cite!!! im optimalen Fall auf \(2^\circ\) genau beschreiben.
\item Die nächste Quelle ergibt sich aus den gefahrenen Strecken des Rovers. Dafür wird der erste Punkt nach einer Rotation und der letzte Punkt vor einer Rotation festgehalten und daraus die Ausrichtung mit der \mintinline{c++}|int16_t Point::courseTo(Point&);| Methode berechnet. Diese Variante ist bei kurzen Strecken ungenau und wird mit steigendem Abstand zwischen den Punkten genauer, wenn die Positionsbestimmung im niedrigen Zentimeter Bereich erfolgt. Sollte der Rover durch den Untergrund oder anderen Fehlern keineGerade fahren sondern ein leichte Kurve, wird dieses Verfahren ungenauer.
\item Es bleibt noch das hinzugefügte Gyroskop, dieses kann keine absoluten Werte bestimmen. Dafür kann es präzise relative Drehwerte angeben. Es eignet sich also um bei einem vorgegebenen Winkel die Drehung zu überwachen. !!!Sensorfusion ausgeführt?!!!
\item Das Magnetometer liefert absolute Werte, welche die Ausrichtung laut Datenblatt \cite[]{QST} im optimalen Fall auf \(2^\circ\) genau beschreiben.
\item Die nächste Quelle ergibt sich aus den gefahrenen Strecken des Rovers. Dafür wird der erste Punkt nach einer Rotation und der letzte Punkt vor einer Rotation festgehalten und daraus die Ausrichtung mit der \mintinline{c++}|int16_t Point::courseTo(Point&); | Methode berechnet. Diese Variante ist bei kurzen Strecken ungenau und wird mit steigendem Abstand zwischen den Punkten genauer, wenn die Positionsbestimmung im niedrigen Zentimeterbereich erfolgt. Sollte der Rover durch den Untergrund oder anderen Fehlern keine Gerade fahren, sondern eine leichte Kurve, wird dieses Verfahren ungenauer.
\item Es bleibt noch das hinzugefügte Gyroskop, dieses kann keine absoluten Werte bestimmen. Dafür kann es präzise relative Drehwerte angeben. Es eignet sich also, um bei einem vorgegebenen Winkel die Drehung zu überwachen. Die Genauigkeit hätte zusätzlich erhöht werden können, wenn die Implementierung der 9-Achsen Sensorfusion funktional gewesen wäre.
\end{itemize}
Nachdem die Datenquelle ausgewählt wurde muss der Kurs von der aktuellen Position zum Zielpunkt berechnet werden. Von diesem Ergebnis wird die aktuelle Ausrichtung subtrahiert. Anschließend muss das Resultat auf den gewünschten Wertbereich normiert werden.
Nachdem die Datenquelle ausgewählt wurde, muss der Kurs von der aktuellen Position zum Zielpunkt berechnet werden. Von diesem Ergebnis wird die aktuelle Ausrichtung subtrahiert. Anschließend muss das Resultat auf den gewünschten Wertbereich normiert werden.
\subsubsection{Navigationsanweisungen}
Aus der berechneten Kurskorrektur und dem verbleibenden Abstand zum Zielpunkt wird Navigationsanweisung erstellt. Die Informationen in das folgende \mintinline{c++}|struct| verpackt:
@@ -43,17 +43,17 @@
};
\end{minted}
Wenn die Navigationsanweisungen bei der Navigationsklasse abgefragt werden muss das genannte \mintinline{c++}|struct| der Funktion als Referenz übergeben werden. Der Rückgabewert wird für das bereits beschriebene \mintinline{c++}|enum Navigation::Status| verwendet. Darüber wird mitgeteilt ob die Navigationsanweisungen aktualisiert wurden oder weshalb dies nicht geschah. Zum Beispiel wenn der Rover seine Position nicht wesentlich verändert hat, die aktuelle Positionsbestimmung zu ungenau ist oder das Ziel erreicht wurde.
Wenn die Navigationsanweisungen bei der Navigationsklasse abgefragt werden, muss das genannte \mintinline{c++}|struct| der Funktion als Referenz übergeben werden. Der Rückgabewert wird für das bereits beschriebene \mintinline{c++}|enum Navigation::Status| verwendet. Darüber wird mitgeteilt, ob die Navigationsanweisungen aktualisiert wurden oder, weshalb dies nicht geschah. Zum Beispiel, wenn der Rover seine Position nicht wesentlich verändert hat, die aktuelle Positionsbestimmung zu ungenau ist oder das Ziel erreicht wurde.
\subsubsection{Autopilot aufbau}
Der Autopilot ist einen Zustandsautomaten nachempfunden. In den verschiedenen Zuständen können unterschiedliche und gleiche Funktionen aufgerufen werden. Die beiden häufigsten Funktionsaufrufe in den verschiedenen Status sollen erläutert werden:
\subsubsection{Autopilot Aufbau}
Der Autopilot ist einem Zustandsautomaten nachempfunden. In den verschiedenen Zuständen können unterschiedliche und gleiche Funktionen aufgerufen werden. Die beiden häufigsten Funktionsaufrufe in den verschiedenen Status sollen erläutert werden:
\begin{itemize}
\item \mintinline{c++}|void Autopilot::askNavigationForOrder();| holt sich die aktuellen Navigationsanweisungen von \texttt{Navigation} und wertet dabei den zurückgegebenen Status aus. Durch diese Auswertung können Zustandsübergänge auftreten. Beispielsweise bei vollständiger abgefahrener Route oder mangelnder Genauigkeit bei der Positionsbestimmung. Sollte der zweite Fall eintreten wird der vorherige Zustand gespeichert, in welchen zurückgekehrt wird, wenn die Genauigkeit wieder den Anforderungen entspricht und
\item \mintinline{c++}|void Autopilot::checkButtonInput();| überprüft ob der Aktions-Button gedrückt ist. Wenn die Eingabe vorliegt werden Zustandswechsel durchgeführt, wie selbstständiges Fahren aktivieren und deaktivieren.
\item \mintinline{c++}|void Autopilot::askNavigationForOrder(); | holt sich die aktuellen Navigationsanweisungen von \texttt{Navigation} und wertet dabei den zurückgegebenen Status aus. Durch diese Auswertung können Zustandsübergänge auftreten. Beispielsweise bei vollständiger abgefahrener Route oder mangelnder Genauigkeit bei der Positionsbestimmung. Sollte der zweite Fall eintreten, wird der vorherige Zustand gespeichert, in welchen zurückgekehrt wird, wenn die Genauigkeit wieder den Anforderungen entspricht und
\item \mintinline{c++}|void Autopilot::checkButtonInput(); | überprüft, ob der Aktions-Button gedrückt ist. Wenn die Eingabe vorliegt, werden Zustandswechsel durchgeführt, wie selbstständiges Fahren aktivieren und deaktivieren.
\end{itemize}
Die folgende Tabelle \ref{tab:autopilot} listet die Zustände auf und beschreibt die Funktionalitäten der einzelnen Zustände. Dabei wird in der Spalte \texttt{Update} angegeben ob die Navigationsanweisungen mit der beschriebenen Funktion in diesem Zustand aktualisiert werden und mit der Spalte \texttt{Check} wird das gleich für die Überprüfung der Benutzereingaben dargestellt.
Die folgende Tabelle \ref{tab:autopilot} listet die Zustände auf und beschreibt die Funktionalitäten der einzelnen Zustände. Dabei wird in der Spalte \texttt{Update} angegeben, ob die Navigationsanweisungen mit der beschriebenen Funktion in diesem Zustand aktualisiert werden und mit der Spalte \texttt{Check} wird das gleich für die Überprüfung der Benutzereingaben dargestellt.
\begin{table}[]
\centering
@@ -75,17 +75,17 @@
\end{table}
\subsubsection{Ausrichten}
Wenn der Rover zu weit von dem Kurs abweicht und damit nicht mehr ausreichend genau auf den Zielpunkt ausgerichtet ist, wird von dem Zustand \texttt{SelfDriving} in den Zustand \texttt{SelfDrivingRotate} gewechselt. Dieser wechsel kann nur aus \texttt{SelfDriving} erfolgen und beginnt damit die Rotation einzuleiten. Dabei wird Drehrichtung der Rotation durch das Vorzeichen der gegebenen Kurskorrektur bestimmt. Ab diesem Zeitpunkt wird ständig überprüft, wann sich der Rover weit genug gedreht hat um die Rotation rechtzeitig zu beenden. Anschließend wird wieder in den vorherigen Zustand gewechselt.
Wenn der Rover zu weit von dem Kurs abweicht und damit nicht mehr ausreichend genau auf den Zielpunkt ausgerichtet ist, wird von dem Zustand \texttt{SelfDriving} in den Zustand \texttt{SelfDrivingRotate} gewechselt. Dieser Wechsel kann nur aus \texttt{SelfDriving} erfolgen und beginnt damit, die Rotation einzuleiten. Dabei wird Drehrichtung der Rotation durch das Vorzeichen der gegebenen Kurskorrektur bestimmt. Ab diesem Zeitpunkt wird durchgehend überprüft, wann sich der Rover weit genug gedreht hat, um die Rotation rechtzeitig zu beenden. Anschließend wird wieder in den vorherigen Zustand gewechselt.
\subsubsection{Geschwindigkeit}
Die Geschwindigkeit wird je nach Abstand zu dem Zielpunkt eingestellt. Dabei gibt es drei verschiedene Abstandszonen. Die Werte für Geschwindigkeit und Abstand werden in Tabelle \ref{tab:roverSpeed} beschrieben. Die Geschwindigkeit wird im Nahbereich deutlich reduziert um einfacher auf Abweichungen reagieren zu können.
Die Geschwindigkeit wird je nach Abstand zu dem Zielpunkt eingestellt. Dabei gibt es drei verschiedene Abstandszonen. Die Werte für Geschwindigkeit und Abstand werden in Tabelle \ref{tab:roverSpeed} beschrieben. Die Geschwindigkeit wird im Nahbereich deutlich reduziert, um einfacher auf Abweichungen reagieren zu können.
\begin{table}[]
\centering
\begin{tabular}{|l|c|c|}
\hline
Bereich & \multicolumn{1}{l|}{Abstand {[}m{]}} & \multicolumn{1}{l|}{Geschwindigkeit {[}m/s{]}} \\ \hline
ferm & 2!!! & 2 \\ \hline
fern & 2!!! & 2 \\ \hline
mittel & 1!!! & 1 \\ \hline
nah & 0,75!!! & 0,5 \\ \hline
\end{tabular}
065_1_bewertung.tex
+113
View File
@@ -0,0 +1,113 @@
\chapter{Bewertung}
\label{cha: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 minimalem Wartungsaufwand.
\par
Die Anforderungen an die Gebäudesicherheit wurden durch Absprache und Begleitung der Installation sichergestellt. 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 RTKLib 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 Hilfestellungen 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 vorhandenen 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 dem Test in Abschnitt \ref{sec:tests} überprüft.
\end{itemize}
\section{Referenzstation}
Dieser 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 Einstellungen 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}
Das in Anhang \ref{cha:winAndUcenter} beschriebene u-center bietet verschiedene Möglichkeiten, die Signalqualität des Systems zu bestimmen. Einer dieser Möglichkeiten ist, die im Programm sogenannte SkyView zu betrachten. Die Abbildungen \ref{fig:skyview} zeigt einen Screenshot dieser Ansicht. Dort sind alle aktuell empfangen Satelliten und deren Positionsverlauf aus Sicht der Antenne eingezeichnet. Die einzelnen Satelliten sind mit einem Buchstaben für das jeweilige GNSS und einer Nummer gekennzeichnet (G - GPS, E - Galileo, R - GLONASS, B - BeiDou, S - SBAS). Durch die Farbgebung der Satelliten wird angezeigt, wie der betroffene Satellit in die Auswertung der Position einbezogen werden kann, dabei sind grüne Satelliten, die die ohne Einschränkungen genutzt werden können, weil alle Informationen übertragen wurden. Von den blauen hingegen sind nicht alle Informationen empfangen worden oder das Signal wird nicht immer fehlerfrei empfangen. Daher tragen diese einen geringeren Teil zur Positionsbestimmung bei. Zu den roten Satelliten besteht keine Verbindung mehr. Dies lässt sich gut durch die Position am äußerten Horizont dieser Satelliten erklären. Auch die blauen Satelliten zeichnen sich dadurch aus, dass die meisten sich am Rand des empfangbaren Bereichs befinden.
In der nächsten Abbildung \ref{fig:SatelliteSignal} werden die Satellitensignale als Balkendiagramm dargestellt. Die Tabelle \ref{tab:satellitenAnzahl} fasst die Daten der Abbildung zusammen. Dabei wird deutlich, dass von allen GNSS mehr als die benötigten vier Satelliten für eine Positionsbestimmung mit diesem System empfangen werden.
\begin{wrapfigure}{r}{0.4\textwidth}
\centering
\includegraphics[width=0.38\textwidth]{img/SkyView.png}
\caption{Screenshot aus dem u-center - SkyView}
\label{fig:skyview}
\end{wrapfigure}
\begin{figure}[ht]
\centering
\includegraphics[width=\linewidth]{img/SatelliteSignal.png}
\caption{Screenshot aus dem u-center - Satelliten mit Signalstärke}
\label{fig:SatelliteSignal}
\end{figure}
\begin{table}[]
\centering
\begin{tabular}{|l|c|c|}
\hline
\textbf{GNSS} & \multicolumn{1}{l|}{\textbf{Sichtbare Satelliten}} & \multicolumn{1}{l|}{\textbf{Nutzbare Satelliten}} \\ \hline
GPS & 14 & 8 \\ \hline
GLONASS & 10 & 8 \\ \hline
Galileo & 9 & 6 \\ \hline
BeiDou & 8 & 7 \\ \hline
\end{tabular}
\caption{Gleichzeitig für die Referenzstation sichtbare Satelliten }
\label{tab:satellitenAnzahl}
\end{table}
Um die Positionslösung der Station beobachten zu können, kann die \texttt{Deviation Map} aus Abbildung \ref{fig:deviationMap} betrachten werden. Diese zeigt alle bestimmten Positionen als Punkte an. Dabei ist die aktuellste Position zentriert dargestellt und alle anderen in Abhängigkeit zu ihr. In der Abbildung werden die Punkte von einer dreistündigen Beobachtungsphase dargestellt. Mit den eingezeichneten Radien kann der Drift der Positionslösung abgelesen werden. In diesem Fall ist der Drift selten größer als ein halber Meter. Diese Genauigkeit kann durch die Anwendung von SBAS und der optimalen Antennenposition erklärt werden. Ohne diese Vorteile könnte der Drift über \(10m\) betragen. Der geringe Drift spricht für eine gelungene Errichtung des Systems.
\begin{figure}[ht]
\vspace{1cm}
\centering
\includegraphics[width=\linewidth]{img/DevinationMapDachAntenne1h.png}
\caption{Screenshot aus dem u-center - Deviation Map}
\label{fig:deviationMap}
\end{figure}
\subsection{Verwaltungsoberfläche}
Die Einstellungen des Servers sind zum Abschluss dieser Arbeit lediglich über den Zugriff auf die Kommandozeile möglich. Damit sich spätere Benutzter leichter zurechtfinden, wurden kurze Beschreibungen der Einstellungen in dem \texttt{Home-Verzeichnis} des rtk-Benutzers abgelegt. Bei einem Neustart des Systems wird der benötigte Dienst automatisch gestartet. Der Server startet auch nach einem Stromausfall automatisch. Sollte der benötigte Dienst jedoch aus irgendeinem Grund abstürzen, erfordert dies einen manuellen Eingriff in das System, um den Dienst erneut zu starten und das Problem möglicherweise zu lösen. Außerdem wurde keine Monitoring- oder Benachrichtigungslösung eingebaut. Dadurch wird ein möglicher Fehler erst an anderer Stelle festgestellt und es kann dementsprechend nicht direkt auf die Ursache geschlossen werden.
\par
Eine erneute Konfiguration des GNSS-Moduls ist nur durch mehrere Schritte möglich, siehe dafür Anhang \ref{cha:winAndUcenter}. Der Gründe für eine erneute Konfiguration sind zwar kaum vorhanden, jedoch könnte jederzeit ein Defekt auftreten, welcher ein neues GNSS-Modul erfordert. Dieses wäre natürlich bislang nicht konfiguriert.
\par
Zusammen mit der Erfüllung der gestellten Anforderungen an die Referenzstation lässt sich diese als voll funktionsfähig beschreiben. Da der Wartungsaufwand voraussichtlich sehr gering ausfallen wird, reduziert dies die Relevanz der eben genannten Einschränkungen. Einiger dieser Einschränkungen lassen sich mit einem Projekt auf GitHub namens \texttt{RTKBase} \cite[]{rtkbase} beheben und die Referenzstation damit mit Flexibilität ausstatten. Diese mögliche Änderung wird kurz im Abschnitt \ref{sec:ausblick} Ausblick beschrieben.
\subsection{Ntrip Revision 1}
Es wurden beide Revision des Ntrip-Protokolls jeweils mit dem Caster \url{rtk2go.com} und \url{sapos-ni-ntrip.de} getestet. Dabei wurde aufgrund der Abwärtskompatibilität erwartet, dass beide Caster die aktuelle Revision von Ntrip akzeptieren. Bei der Erstellung des Mountpoints auf \url{rtk2g0.com} wurde aufgrund der Empfehlungen des Formulars die Revision 1 von Ntrip gewählt. Welche Version von Ntrip der Caster von Sapos nutzt, ist auf der Website nicht ersichtlich, da jedoch von beiden Castern Anfragen beider Ntrip Revisionen akzeptiert wurden, wird davon ausgegangen, dass auch beide die Revision 1 nutzen.
\par
Durch die vorhandene und funktionierende Abwärtskompatibilität kann daher problemlos auf die veraltete Revision verzichtet werden. Sollte doch mal ein Caster aus unerwarteten Gründen nur die Revision 1 akzeptieren, kann dies durch den implementierten Client berücksichtigt werden.
\subsection{Vergleich der Korrekturdatenqualität durch Nutzung von Spaos}
Im Folgenden sollen die Positionsbestimmungen des GNSS-Moduls mit unterschiedlichen Quellen für die Korrekturdaten verglichen werden. Es werden wie im Abschnitt zuvor die eigene Referenzstation und der Sapos Dienst in Anspruch genommen.
\par
Es wurden mehrere Messungen mit wachsendem Abstand zur errichteten Referenzstation vorgenommen. Dabei wurden alle Komponenten vor jeder Messung zurückgesetzt. Dem GNSS-Modul wurde vor jede Messung fünf Minuten Zeit gegeben, damit die Position ohne Korrekturdaten ermittelt werden konnte. Sobald der Ntrip-Client zugeschaltet wurde, startete zeitgleich eine Zeitmessung. Es wurden die Zeiten gemessen, wie lange das Modul für die Berechnung einer fixen Position benötigt hat. Die Messergebnisse werden in Tabelle \ref{tab:vergleichDatenQuali} dargestellt.
\begin{table}[]
\centering
\begin{tabular}{|c|c|c|l|c|c|l|}
\hline
\multicolumn{1}{|l|}{\textbf{\begin{tabular}[c]{@{}l@{}}Distanz\\ {[}km{]}\end{tabular}}} & \multicolumn{1}{l|}{\textbf{\begin{tabular}[c]{@{}l@{}}Sapos\\ ambigious\\ {[}s{]}\end{tabular}}} & \multicolumn{1}{l|}{\textbf{\begin{tabular}[c]{@{}l@{}}Sapos\\ fix\\ {[}s{]}\end{tabular}}} & \textbf{\begin{tabular}[c]{@{}l@{}}Sapos\\ fix\\ Position\end{tabular}} & \multicolumn{1}{l|}{\textbf{\begin{tabular}[c]{@{}l@{}}FH\\ ambigious\\ {[}s{]}\end{tabular}}} & \multicolumn{1}{l|}{\textbf{\begin{tabular}[c]{@{}l@{}}FH\\ \\ fix\\ {[}s{]}\end{tabular}}} & \textbf{\begin{tabular}[c]{@{}l@{}}FH\\ fix\\ Position\end{tabular}} \\ \hline
1 & 10 & 20 & & 12 & 12 & \\ \hline
2 & 12 & 12 & & 12 & 12 & \\ \hline
5 & 12 & 12 & & 12 & 12 & \\ \hline
10 & 12 & 12 & & 12 & 12 & \\ \hline
15 & 12 & 12 & & 12 & 12 & \\ \hline
20 & 12 & 12 & & 12 & 21 & \\ \hline
40 & 12 & 12 & & 12 & 12 & \\ \hline
\end{tabular}
\caption{Messergebnisse vergleich Korrekturdatenqualität}
\label{tab:vergleichDatenQuali}
\end{table}
Aus den Messergebnissen können folgende Schlussfolgerungen gezogen werden.
\begin{itemize}
\item Vorteil Referenznetz automatisch richtige Korrekturdaten, auch wenn die eigentliche Station zu weit weg ist.
\end{itemize}
065_2_bewertung.tex
+40
View File
@@ -0,0 +1,40 @@
\section{Tests}
\label{sec:tests}
\subsection{Route aufzeichnen}
\subsubsection{Koordinaten Plausibilität}
\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}
\subsubsection{Genuigkeitsprüfung stören}
\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 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?}
065_bewertung.tex
-98
View File
@@ -1,98 +0,0 @@
\chapter{Bewertung}
\label{cha: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 Hilfestellungen 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}
Dieser 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 Einstellungen 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}
Das in Anhang \ref{cha:winAndUcenter} beschriebene U-Center bietet verschieden Möglichkeiten die Signalqualität des Systems zu bestimmen. Einer dieser Möglichkeiten ist die im Programm sogenannte SkyView zu betrachten. Die Abbildungen !!!ref!!! zeigt einen Screenshot dieser Ansicht. Dort sind alle aktuell empfangen Satelliten und deren Positionsverlauf aus Sicht der Antenne eingezeichnet. Die einzelnen Satelliten sind mit einem Buchstaben für das jeweilige GNSS und einer Nummer gekennzeichnet (G - GPS, E - Galileo, R - GLONASS, B - Beidou, S - SBAS). Durch die Farbgebung der Satelliten wird angezeigt wie der betroffene Satellit in die Auswertung der Position mit einbezogen werden kann, !!!Folgende Farben checken lassen!!! dabei sind grüne Satelliten, die die ohne Einschränkungen genutzt werden können, weil alle Informationen übertragen wurden. Von den blauen hingegen sind nicht alle Informationen empfangen worden oder das Signal wird nicht immer fehlerfrei empfangen. Daher tragen diese einen geringeren Teil zur Positionsbestimmung bei. Zu den roten Satelliten besteht keine Verbindung mehr. Dies lässt sich gut durch die Position am äußerten Horizont dieser Satelliten erklären. Auch die blauen Satelliten zeichnen sich dadurch aus, das die meisten sich am Rand des empfangbaren Bereichs befinden.
In der nächsten Abbildung !!!ref!!! werden die Satelliten Signale als Balkendiagramm dargestellt die Tabelle !!!ref!!! fasst die Daten der Abbildung zusammen. Dabei wird deutlich, dass von allen GNSS mehr als die benötigten vier Satelliten für eine Positionsbestimmung mit diesem System empfangen werden.
!!!Bild
!!!Tabelle
Um die Positionslösung der Station beobachten zu können, kann die \texttt{Deviation Map} !!!Namen kontrollieren!!! aus Abbildung !!!ref!!! betrachten werden. Diese zeigt alle bestimmten Positionen als Punkte an. Dabei ist die aktuellste Position zentriert dargestellt und alle anderen in Abhängigkeit zu ihr. In der Abbildung werden die Punkte von einer dreistündigen Beobachtungsphase dargestellt. Mit den eingezeichneten Radien kann der Drift der Positionslösung abgelesen werden. In diesem Fall ist der Drift selten größer als ein halber Meter. Diese Genauigkeit kann durch die Anwendung von SBAS und der optimalen Antennenposition erklärt werden. Ohne diese Vorteile könnte der Drift über \(10m\) betragen. Der geringe Drift spricht für eine gelungene des Systems.
\subsection{Verwaltungsoberfläche}
Die Einstellungen des Servers sind zum Abschluss dieser Arbeit lediglich über den Zugriff auf die Kommandozeile möglich. Damit sich spätere Benutzter leichter zurechtfinden wurden kurze Beschreibungen der Einstellungen in dem \texttt{Home-Verzeichnis} des rtk-Benutzers abgelegt. Bei einem Neustart des Systems wird der benötigte Dienst automatisch gestartet. Der Server startet auch nach einem Stromausfall automatisch. Sollte der benötigte Dienst jedoch aus irgendeinem Grund abstürzen, erfordert dies einen manuellen Eingriff in das System um den Dienst erneut zu starten und das Problem möglicherweise zu lösen. Außerdem wurde keine Monitoring- oder Benachrichtigungslösung eingebaut. Dadurch wird ein möglicher Fehler erst an anderer Stelle festgestellt und es kann dementsprechend nicht direkt auf die Ursache geschlossen werden.
\par
Eine erneute Konfiguration des GNSS-Moduls ist nur durch mehrere Schritte möglich, siehe dafür Anhang \ref{cha:winAndUcenter}. Der Gründe für eine erneute Konfiguration sind zwar kaum vorhanden, jedoch könnte jederzeit ein Defekt auftreten, welcher ein neues GNSS-Modul erfordert. Dieses wäre natürlich noch nicht konfiguriert.
\par
Zusammen mit der Erfüllung der gestellten Anforderungen an die Referenzstation lässt sich diese als voll Funktionsfähig beschreiben. Da der Wartungsaufwand voraussichtlich sehr gering ausfallen wird, reduziert dies die Relevanz der eben genannten Einschränkungen. Einiger dieser Einschränkungen lassen sich mit einem Projekt auf GitHub Namens \texttt{rtkbase!!!Name checken} !!!ref beheben und die Referenzstation damit mit Flexibilität ausstatten. Diese mögliche Änderung wird kurz im Abschnitt \ref{sec:ausblick} Ausblick !!!gibt ref auch mit auto name?!!! beschrieben.
\subsection{Ntrip Revision 1}
Es wurden beide Revision des Ntrip-Protokolls jeweils mit dem Caster \url{rtk2go.com} und \url{sapos-ni-ntrip.de} getestet. Dabei wurde aufgrund der Abwärtskompatibilität erwartet, dass beide Caster die aktuelle Revision von Ntrip akzeptieren. Bei der Erstellung des Mountpoints auf \url{rtk2g0.com} wurde aufgrund der Empfehlungen des Formulars die Revision 1 von Ntrip gewählt. Welche Version von Ntrip der Caster von Sapos nutzt ist auf der Website nicht ersichtlich, da jedoch von beiden Castern Anfragen beider Ntrip Revisionen akzeptiert wurden, wird davon ausgegangen, dass auch beide die Revision 1 nutzen.
\par
Durch die vorhandene und funktionierende Abwärtskompatibilität kann daher problemlos auf die veraltete Revision verzichtet werden. Sollte doch mal ein Caster aus unerwarteten Gründen die nur die Revision 1 akzeptieren, kann dies durch den implementierten Client berücksichtigt werden.
\subsection{Vergleich der Korrekturdatenqualität durch Nutzung von Spaos}
!!!Tabelle!!!
- Vorteil Referenznetz automatisch richitge Korrekturdaten, auch wenn die eigentlich Station zu weit weg ist.
\section{Tests}
\label{sec:tests}
\subsection{Route aufzeichnen}
\subsubsection{Koordinaten Plausibilität}
\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 werden 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 der selben \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 neugestartet. 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 wurde 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 werden oder es kann versucht werden die gelöscht Route zu importieren. Beides schlägt wie erwartet mit dem Code \(418\) fehl.
\subsection{Route abfahren}
\subsubsection{Genuigkeitsprüfung stören}
\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 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?}
070_resuemee.tex
+13 -15
View File
@@ -3,15 +3,15 @@
\section{Zusammenfassung}
Im Verlauf dieser Arbeit wurde die Referenzstation errichtet und der Rover sowohl mit weiterer Hardware als auch Software ausgestattet.
\par
Für die Referenzstation mussten zunächst die Gegebenheiten und die Möglichkeiten einer Installation besprochen werden. Nachdem der Installationsort festgelegt worden war, konnte mit der Auswahl der passenden Hardware und dem Installationsmaterial begonnen werden. Dabei wurde das Augenmerk besonders auf die Umweltbedingungen gelegt um der Anlage eine möglichst lange und störungsfreie Lebenszeit zu ermöglichen. Die Anbindung an das Netzwerk sowie die Herstellung der Stromversorgung stellten eine Herausforderung dar, weil ein sich bereits in Benutzung befindliches Netzwerkkabel mit \texttt{Power over Ethernet} verwendet werden musste, um die Referenzstation anzubinden. Deshalb musste dieses zunächst mit einem PoE-Extender aufgeteilt werden um anschließend mit einem PoE-Splitter die Daten und die Stromzuführung für den Server zu trennen. Die eingebrachte Technik wurden in einem wasserfesten Installationskasten untergebracht, für diesen wurde Halterungen passend für den Installationsort entwickelt. Die Position der GNSS-Antenne wurde mit einem C-Profil deutlich erhöht, sodass diese keinen Abschattungen unterliegt.
Für die Referenzstation mussten zunächst die Gegebenheiten und die Möglichkeiten einer Installation besprochen werden. Nachdem der Installationsort festgelegt worden war, konnte mit der Auswahl der passenden Hardware und dem Installationsmaterial begonnen werden. Dabei wurde das Augenmerk besonders auf die Umweltbedingungen gelegt, um der Anlage eine möglichst lange und störungsfreie Lebenszeit zu ermöglichen. Die Anbindung an das Netzwerk sowie die Herstellung der Stromversorgung stellten eine Herausforderung dar, weil ein bereits in Benutzung befindliches Netzwerkkabel mit \texttt{Power over Ethernet} verwendet werden musste, um die Referenzstation anzubinden. Deshalb musste dieses zunächst mit einem PoE-Extender aufgeteilt werden, um anschließend mit einem PoE-Splitter die Daten und die Stromzuführung für den Server zu trennen. Die eingebrachte Technik wurden in einem wasserfesten Installationskasten untergebracht, für diesen wurde Halterungen passend für den Installationsort entwickelt. Die Position der GNSS-Antenne wurde mit einem C-Profil deutlich erhöht, sodass diese keinen Abschattungen unterliegt.
\par
Der Server der Referenzstation wurde so vorbereitet, dass ein Fernzugriff möglich ist. Mit diesem wurde die benötigte Software installiert und das angeschlossen GNSS-Modul konfiguriert. Damit die Konfiguration abgeschlossen werden konnte, musste die Antenne mit einer 24-stündigen Sitzung eingemessen werden. Dafür wurden die Daten von einem Post-Processing-Service verarbeitet. Seit diesem Zeitpunkt ist die Referenzstation operativ und kann Endgeräte mit Korrekturdaten versorgen.
Der Server der Referenzstation wurde so vorbereitet, dass ein Fernzugriff möglich ist. Mit diesem wurde die benötigte Software installiert und das angeschlossene GNSS-Modul konfiguriert. Damit die Konfiguration abgeschlossen werden konnte, musste die Antenne mit einer 24-stündigen Sitzung eingemessen werden. Dafür wurden die Daten von einem Post-Processing-Service verarbeitet. Seit diesem Zeitpunkt ist die Referenzstation operativ und kann Endgeräte mit Korrekturdaten versorgen.
\par
Nach dem die Korrekturdaten verfügbar waren musste der passende Client für den Rover entwickelt werden, damit die Korrekturdaten von diesem empfangen werden können. Dafür wurde sich an die Best Practices orientiert und gehalten, welche von der Norm vorgebenden Institution veröffentlicht wurden. Anschließend konnte der Rover seine Position im Zentimeterbereich bestimmen.
Nachdem die Korrekturdaten verfügbar waren, musste der passende Client für den Rover entwickelt werden, damit die Korrekturdaten von diesem empfangen werden können. Dafür wurde sich an die Best Practices orientiert und gehalten, welche von der Norm vorgebenden Institution veröffentlicht wurden. Anschließend konnte der Rover seine Position im Zentimeterbereich bestimmen.
\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 vorne 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.
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 Test ausgeführt, mit diesen sollte zunächst die Funktion der Implementierungen geprüft werden. Darüber hinaus 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 Untersuchen werden im nächsten Abschnitt, dem Fazit, erläutert.
\section{Fazit}
Ergebnisse eigene vs andere Station
@@ -25,30 +25,28 @@
Diese Arbeit wird mit einem Ausblick auf die mögliche Zukunft des Projekts abgeschlossen. Die einzelnen Punkte des Ausblicks ergeben sich aus dem eben geschlossenen Fazit und den im vorherigen Kapitel \ref{cha:bewertung} gemachten Bewertungen. Dabei steht die Bedienung und Umstrukturierung des Rovers im Mittelpunkt und wird von Erweiterungen des Rovers für eine gesteigerte Autonomie begleitet. Zusätzlich wird die Option der Softwareänderung auf dem Server der Referenzstation erläutert.
\subsection{Erweiterung des Bedienkonzepts mittels Web-App}
Die Fernbedienung eignet sich besonders gut für die Einrichtung des Rovers. Darüber hinaus ist die Bedienung jedoch sehr eingeschränkt. In dem angestrebten Anwendungsfall des Patrouille fahrenden Rovers ist eine Steuerung unabhängig des Standorts des Rovers, angebracht. Diese könnte über eine Webapplikation, welche dem Rover als Server dient, umgesetzt werden. Die bereits minimal als Webapplikation bestehende Routenverwaltung könnte mit dieser Erweiterungen zusammengefügt werden. Für die Anwendung sind die folgen Punkte als Features denkbar.
Die Fernbedienung eignet sich besonders gut für die Einrichtung des Rovers. Weiterhin ist die Bedienung jedoch sehr eingeschränkt. In dem angestrebten Anwendungsfall des Patrouille fahrenden Rovers ist eine Steuerung unabhängig des Standorts des Rovers, angebracht. Diese könnte über eine Webapplikation, welche dem Rover als Server dient, umgesetzt werden. Die bereits minimal als Webapplikation bestehende Routenverwaltung könnte mit dieser Erweiterungen zusammengefügt werden. Für die Anwendung sind die folgenden Punkte als Features denkbar.
\begin{itemize}
\item Eine Hauptfunktion könnte die Verwaltung der gespeicherten Routen darstellen. Die verschiedenen Routen könnten in Karten dargestellt werden. Wenn der Rover zurzeit eine Route abfährt, kann die aktuelle Position, der Fortschritt, die restliche Route und der aktuelle Zielpunkt sowie die Geschwindigkeit und geschätzte Ankunftszeiten angezeigt werden.
\item Als weitere Funktion ist die Planung der Aufgaben des Rovers vorstellbar, beispielsweise wann eine Route abgefahren werden soll oder in welchen Abständen und wie oft diese wiederholt werden soll.
\item Über diese Anwendung könnten auch Push-Benachrichtigungen Versand werden, die über den aktuellen Zustand oder etwaige Probleme informieren.
\item Über diese Anwendung könnten auch Push-Benachrichtigungen versandt werden, die über den aktuellen Zustand oder etwaige Probleme informieren.
\item Dem Rover könnten auch allgemeine Befehle und Konfiguration übermittelt werden. Dazu könnte die Rückkehr zum Ausgangspunkt (Ladestation) oder die angestrebte Geschwindigkeit gehören.
\item Der Vorteil einer Webapplikation besteht darin, dass diese mit geringem Entwicklungsaufwand für unterschiedliche Endgeräte verfügbar gemacht werden könnte. Die Kommunikation mit dem Rover würde über die bereits erforderliche Internetverbindung abgewickelt werden.
\item Zusätzlich bestünde durch die Client-Server-Architektur die Möglichkeit Programmcode von dem Rover auf den Server zu verlegen.
\item Zusätzlich bestünde durch die Client-Server-Architektur die Möglichkeit, Programmcode von dem Rover auf den Server zu verlegen.
\end{itemize}
\subsection{Umstrukturierung und Erweiterung des Rovers}
Durch die zu Anfang des Projektes gesetzte Anforderung den Hardwareaufwand des Rovers möglichst gering zu halten und die Nähe zu dem ArduinoCore zu halten wurde das System des Rovers in Komponenten unterteilt welche durch das Interface \mintinline{c++}|class Component| definiert werden. Dieses wird den Ansprüchen an eine Taskverwaltung nicht gerecht. Daher sollte in zukünftigen Versionen das System auf die Nutzung von \texttt{FreeRTOS} umstrukturiert werden. Dies erfordert keine komplette Abkehr von dem ArduinoCore, da dieser im auf FreeRTOS aufbaut.
Durch die zu Anfang des Projekts gesetzte Anforderung, den Hardwareaufwand des Rovers möglichst gering zu halten und die Nähe zu dem ArduinoCore zu halten wurde das System des Rovers in Komponenten unterteilt, welche durch das Interface \mintinline{c++}|class Component| definiert werden. Dieses wird den Ansprüchen an eine Taskverwaltung nicht gerecht. Daher sollte in zukünftigen Versionen das System auf die Nutzung von \texttt{FreeRTOS} umstrukturiert werden. Dies erfordert keine komplette Abkehr von dem ArduinoCore, da dieser im auf FreeRTOS aufbaut.
\par
Sollte das Projekt weiter wachsen und auf stärkere Hardware setzen, kann auch der Einsatz von dem speziellen Betriebssystem \texttt{ROS} !!!cite!!! für Roboter in betracht gezogen werden. Dies würde allerdings sehr bedeutende Veränderungen für Soft- und Hardware herbeiführen. Daher wäre auch der Einsatz von \texttt{micro-ROS} !!!cite!!! vorstellbar, da so die Änderungen an der Hardware eingespart werden könnten.
Sollte das Projekt weiter wachsen und auf stärkere Hardware setzen, kann auch der Einsatz von dem speziellen Betriebssystem \texttt{ROS} für Roboter in Betracht gezogen werden. Dies würde allerdings sehr bedeutende Veränderungen für Soft- und Hardware herbeiführen. Daher wäre auch der Einsatz von \texttt{micro-ROS} vorstellbar, da so die Änderungen an der Hardware eingespart werden könnten.
\par
Um die Bedingungen für den Einsatz und den Konfigurationsaufwand des Rovers zu minimieren, könnte ein Mobilfunkmodul hinzugefügt werden. Mit diesem wäre es möglich die Internetverbindung an den meisten Orten herzustellen und dadurch den Rover zuverlässig mit Korrekturdaten zu versorgen sowie die Verbindung zu dem möglichen Server der Webapplikation herzustellen.
Um die Bedingungen für den Einsatz und den Konfigurationsaufwand des Rovers zu minimieren, könnte ein Mobilfunkmodul hinzugefügt werden. Mit diesem wäre es möglich, die Internetverbindung an den meisten Orten herzustellen und dadurch den Rover zuverlässig mit Korrekturdaten zu versorgen sowie die Verbindung zu dem möglichen Server der Webapplikation herzustellen.
\par
Die Hardware des Rovers könnte mit weiteren Sensoren ausgestattet werden. Bumper an der Vorderseite würden die Erkennung von Hindernissen ermöglichen. Mit dieser Information könnte der Rover gestoppt werden oder es könnte versucht werden das Hindernis zu umfahren. Für weitere Informationen über die Umwelt würden sich weitere Sensoren wie Infrarot- und Ultraschallabstandsensoren eignen. Sollte die Hardware aufgestockt werden, sind natürlich weitere Optionen wie Kamera und Bildverarbeitung oder komplexere Sensoren wie ein Radar vorstellbar.
Die Hardware des Rovers könnte mit weiteren Sensoren ausgestattet werden. Bumper an der Vorderseite würden die Erkennung von Hindernissen ermöglichen. Mit dieser Information könnte der Rover gestoppt oder es könnte versucht werden, das Hindernis zu umfahren. Für weitere Informationen über die Umwelt würden sich weitere Sensoren wie Infrarot- und Ultraschallabstandsensoren eignen. Sollte die Hardware aufgestockt werden, sind natürlich weitere Optionen wie Kamera und Bildverarbeitung oder komplexere Sensoren wie ein Radar vorstellbar.
\subsection{Server umstellen auf \href{https://github.com/Stefal/rtkbase}{RTKBase}}
Das Projekt \texttt{RTKBase} ist auf GitHub !!!cite!!! 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 beispielsweise direkt in U-Blox über das Netzwerk eingebunden werden kann.
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.
Literatur.bib
+24
View File
@@ -259,4 +259,28 @@
urldate = {2024-08-11},
}
@Online{9achsfail,
author = {Jeff Rowberg},
date = {2012-11-06},
title = {MPU-6050 6-axis accelerometer/gyroscope},
url = {https://www.i2cdevlib.com/devices/mpu6050#help},
urldate = {2024-08-11},
}
@Online{QST,
author = {QST},
title = {3-Axis Magnetic SensorQMC5883L},
url = {https://datasheet.lcsc.com/szlcsc/QST-QMC5883L-TR_C192585.pdf},
urldate = {2023-05-19},
}
@Software{rtkbase,
author = {Stefal},
date = {2024-07-05},
title = {RTKBase},
url = {https://github.com/Stefal/rtkbase},
urldate = {2024-08-12},
version = {2.6.0},
}
@Comment{jabref-meta: databaseType:biblatex;}
doc/dograms/ntripClientStates.uxf
+56
View File
@@ -0,0 +1,56 @@
<diagram program="umletino" version="15.1"><zoom_level>14</zoom_level><help_text>Space for diagram notes</help_text><element><id>UMLState</id><coordinates><x>812</x><y>462</y><w>252</w><h>154</h></coordinates><panel_attributes>openingConnection
--
+ do / Verbindung zum Caster
herstellen
valign=top
</panel_attributes><additional_attributes></additional_attributes></element><element><id>UMLState</id><coordinates><x>1204</x><y>462</y><w>252</w><h>154</h></coordinates><panel_attributes>pushingData
--
+ do / Daten von Caster
empfangen
+ do / Daten an GNSS-Modul
weiterleiten
valign=top
</panel_attributes><additional_attributes></additional_attributes></element><element><id>UMLState</id><coordinates><x>812</x><y>742</y><w>252</w><h>154</h></coordinates><panel_attributes>waiting
--
+ do / warten zwischen
Verbindungsversuchen
+ do / warten auf
Aktivierung des Clients
valign=top
</panel_attributes><additional_attributes></additional_attributes></element><element><id>UMLState</id><coordinates><x>1064</x><y>126</y><w>252</w><h>154</h></coordinates><panel_attributes>notAvailable
--
+ do / Warten auf
Internetverbindung
valign=top
</panel_attributes><additional_attributes></additional_attributes></element><element><id>UMLState</id><coordinates><x>392</x><y>462</y><w>252</w><h>154</h></coordinates><panel_attributes>closingConnection
--
+ do / Verbindung
zurücksetzen
valign=top
</panel_attributes><additional_attributes></additional_attributes></element><element><id>Relation</id><coordinates><x>1050</x><y>518</y><w>182</w><h>84</h></coordinates><panel_attributes>Verbindung
zum Caster
lt=-&gt;
hergestellt</panel_attributes><additional_attributes>10;20;110;20</additional_attributes></element><element><id>Relation</id><coordinates><x>630</x><y>518</y><w>210</w><h>70</h></coordinates><panel_attributes>Client
lt=-&gt;
deaktiviert</panel_attributes><additional_attributes>130;20;10;20</additional_attributes></element><element><id>Relation</id><coordinates><x>672</x><y>574</y><w>168</w><h>238</h></coordinates><panel_attributes>lt=-&gt;
Verbindung
zum Caster
fehlgeschlagen</panel_attributes><additional_attributes>100;10;10;10;10;150;100;150</additional_attributes></element><element><id>Relation</id><coordinates><x>588</x><y>378</y><w>700</w><h>112</h></coordinates><panel_attributes>lt=-&gt;
Verbindung abgebrochen</panel_attributes><additional_attributes>480;60;480;20;10;20;10;60</additional_attributes></element><element><id>Relation</id><coordinates><x>546</x><y>336</y><w>784</w><h>154</h></coordinates><panel_attributes>lt=-&gt;
Client deaktiviert</panel_attributes><additional_attributes>540;90;540;20;10;20;10;90</additional_attributes></element><element><id>Relation</id><coordinates><x>588</x><y>602</y><w>252</w><h>238</h></coordinates><panel_attributes>lt=-&gt;</panel_attributes><additional_attributes>10;10;10;150;160;150</additional_attributes></element><element><id>Relation</id><coordinates><x>1022</x><y>602</y><w>98</w><h>168</h></coordinates><panel_attributes>lt=-&gt;
Client
aktiviert</panel_attributes><additional_attributes>10;100;10;10</additional_attributes></element><element><id>Relation</id><coordinates><x>826</x><y>602</y><w>168</w><h>168</h></coordinates><panel_attributes>lt=-&gt;
automatisches
wiederverbinden</panel_attributes><additional_attributes>10;100;10;10</additional_attributes></element><element><id>UMLSpecialState</id><coordinates><x>560</x><y>182</y><w>28</w><h>28</h></coordinates><panel_attributes>type=initial</panel_attributes><additional_attributes></additional_attributes></element><element><id>Relation</id><coordinates><x>574</x><y>168</y><w>518</w><h>56</h></coordinates><panel_attributes>lt=-&gt;
Keine Internetverbindung</panel_attributes><additional_attributes>10;20;350;20</additional_attributes></element><element><id>Relation</id><coordinates><x>574</x><y>182</y><w>280</w><h>308</h></coordinates><panel_attributes>lt=-&gt;</panel_attributes><additional_attributes>10;10;180;200</additional_attributes></element><element><id>Relation</id><coordinates><x>980</x><y>266</y><w>210</w><h>224</h></coordinates><panel_attributes>lt=-&gt;</panel_attributes><additional_attributes>130;10;10;140</additional_attributes></element><element><id>Relation</id><coordinates><x>1036</x><y>266</y><w>308</w><h>224</h></coordinates><panel_attributes>lt=-&gt;
Keine
Internetverbindung
</panel_attributes><additional_attributes>10;140;120;10</additional_attributes></element></diagram>
img/DevinationMapDachAntenne1h.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 8.8 KiB

img/SatelliteSignal.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 27 KiB

img/SkyView.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 42 KiB

img/fernbedienung.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.4 MiB

img/gyroPlatine.jpg
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 419 KiB

img/ntripClientStates.png
BIN
View File
Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 445 KiB