Archived
224 lines
36 KiB
TeX
224 lines
36 KiB
TeX
\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 Unterteilung wird 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 7. Juni 2024 bis zum 12. August 2024 lief die Anlage ohne Störungen. Während der Temperaturen über \(30^\circ C\) hat sich der PoE-Splitter ausgeschaltet. Dieser konnte getestet und anschließend wieder eingebaut werden. Zudem ist das Gewinde der Antennenaufnahme abgebrochen. Das Formteil wurde von Mitarbeitern des Hardwarelabors an der FH Dortmund durch eine innen liegende Schraube verstärkt und wieder montiert. Durch diese Instandsetzungen kann die zunächst betriebene Version nicht als wartungsarm bezeichnet werden und erfüllt diese Anforderung somit nicht.
|
|
\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 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 gewährleistet werden.
|
|
|
|
\subsubsection{Server}
|
|
Der Server musste einige Spezifikationen aufweisen. Der USB-Port war 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 darüber hinaus noch reduziert werden.
|
|
|
|
\subsection{Rover}
|
|
Die Anforderungen an den 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ändigkeit 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 diese 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 wurde 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]
|
|
\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}. Die 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 die beiden 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 in den Bereitgestellten FAQs \cite[]{saposfaq} 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 Sapos}
|
|
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
|
|
Für diese Tests wurde das GNSS-Modul von dem Rover entfernt und wird über den Computer mit dem \texttt{u-center} Programm gesteuert. Dies ermöglicht eine bessere Auswertung und ein komfortableres Wechseln des Casters, da das u-center ebenfalls einen Ntrip-Client implementiert hat. Zusätzlich kann in der Oberfläche mit einem Klick ein Kaltstart oder Reset des Moduls ausgelöst werden. Dies wird zwischen jedem Messdurchgang ausgeführt.
|
|
\par
|
|
Es werden Messungen in verschiedenen Entfernungen von der Referenzstation vorgenommen, dabei wird die Entfernung mit jedem Standortwechsel erhöht. An jedem Standort wird jeder Caster dreimal hintereinander gemessen. Vor jeder Messung wird dem Modul zwei Minuten Zeit gelassen. Dadurch kann das Modul vor dem Testbeginn bereits Daten von den Satelliten sammeln.
|
|
\par
|
|
Sobald das GNSS-Modul mit Korrekturdaten versorgt wird, beginnt die Zeitmessung. Dabei wird die Zeit gemessen, bis das Modul den Status \texttt{Float} und anschließend \texttt{Fix} anzeigt. Wenn eine Fix-Lösung gefunden wurde und mindestens 25 Satelliten sichtbar sind, wird der Drift der Position fünf Minuten lang in der \texttt{Deviation Map} beobachtet. In dem u-center kann eine Tabelle mit Statistiken abgerufen werden, welche als Datenquelle dient. Die gesammelten Daten werden vor Beginn der fünf Minuten gelöscht. Dadurch fließen nur die durch Korrekturdaten beeinflussten Positionslösungen in die Statistik ein.
|
|
\par
|
|
Bei den Ergebnissen des Sapos Dienst werden über den gesamten Test hinweg gleichbleibende Ergebnisse erwartet, da die Korrekturdaten automatisch an die aktuelle Position des Empfängers angepasst werden. Die Ergebnisse der eigenen Referenzstation sollten sich mit steigender Entfernung zu der Referenzstation verschlechtern, weil die erzeugten Daten nicht mehr zu dem Standort des Empfängers passen. Eine deutlich sichtbare Verschlechterung wird ab einer Entfernung von 10 km erwartet.
|
|
\par
|
|
Die Zeitmessungen werden händisch ausgeführt, daher werden die Messwerte der menschlichen Reaktionszeit unterliegen. Da diese jedoch relative gleichbleibend ist, tritt der Fehler gleichmäßig über die Messwerte verteilt auf. Der Fehler ist dementsprechend absolut vorhanden, ist jedoch für die relative Auswertung vernachlässigbar. Die Umweltbedingungen während der Messungen können nicht kontrolliert werden und können zu Messfehlern beitragen. Bei der Standortwahl für die Messungen wird möglichst versucht, freie Flächen zu benutzen, um eine Abschattung der Antenne zu verhindern.
|
|
\par
|
|
Alle gesammelten Messdaten werden im Anhang \ref{cha:messergenisse} dargestellt. In der folgenden Tabelle \ref{tab:vergleichZusammenfassung} werden nur die für die Auswertung relevanten Daten in zusammengefasster Form angegeben.
|
|
|
|
\begin{table}[]
|
|
\centering
|
|
\begin{tabular}{|c|c|c|c|c|l|}
|
|
\hline
|
|
\multicolumn{1}{|l|}{\textbf{Caster}} &
|
|
\multicolumn{1}{l|}{\textbf{\begin{tabular}[c]{@{}l@{}}avg\\ \\ SVs\end{tabular}}} &
|
|
\multicolumn{1}{l|}{\textbf{\begin{tabular}[c]{@{}l@{}}Gesamtzeit\\ bis FIX\\ Lösung {[}s{]}\end{tabular}}} &
|
|
\multicolumn{1}{l|}{\textbf{\begin{tabular}[c]{@{}l@{}}max Delta\\ Distanz\\ Station {[}cm{]}\end{tabular}}} &
|
|
\multicolumn{1}{l|}{\textbf{\begin{tabular}[c]{@{}l@{}}Drift\\ {[}cm{]}\end{tabular}}} &
|
|
\textbf{\begin{tabular}[c]{@{}l@{}}Drift\\ avg\\ {[}cm{]}\end{tabular}} \\ \hline
|
|
\multirow{3}{*}{\begin{tabular}[c]{@{}c@{}}rtk2go\\ 40 km\end{tabular}} & 31 & 8,63 & \multirow{3}{*}{0,54} & 5,03 & \multirow{3}{*}{3,61} \\ \cline{2-3} \cline{5-5}
|
|
& 30 & 8 & & 3,67 & \\ \cline{2-3} \cline{5-5}
|
|
& 30 & 12,6 & & 2,13 & \\ \hline
|
|
\multirow{3}{*}{Sapos} & 29 & 16,1 & \multirow{3}{*}{1,57} & 2,13 & \multirow{3}{*}{3,6} \\ \cline{2-3} \cline{5-5}
|
|
& 29 & 51,2 & & 4,35 & \\ \cline{2-3} \cline{5-5}
|
|
& 31 & 31,8 & & 4,32 & \\ \hline
|
|
\multirow{3}{*}{\begin{tabular}[c]{@{}c@{}}rtk2go\\ 20 km\end{tabular}} & 30 & 7,1 & \multirow{3}{*}{1,61} & 2,96 & \multirow{3}{*}{3,45} \\ \cline{2-3} \cline{5-5}
|
|
& 30 & 8,1 & & 4,42 & \\ \cline{2-3} \cline{5-5}
|
|
& 28 & 7,6 & & 2,96 & \\ \hline
|
|
\multirow{3}{*}{Sapos} & 27 & 17,2 & \multirow{3}{*}{2,74} & 4,36 & \multirow{3}{*}{3,94} \\ \cline{2-3} \cline{5-5}
|
|
& 28 & 19,7 & & 3,94 & \\ \cline{2-3} \cline{5-5}
|
|
& 27 & 18 & & 3,94 & \\ \hline
|
|
\multirow{3}{*}{\begin{tabular}[c]{@{}c@{}}rtk2go\\ 10 km\end{tabular}} & 27 & 178,6 & \multirow{3}{*}{2,29} & 3,89 & \multirow{3}{*}{5,21} \\ \cline{2-3} \cline{5-5}
|
|
& 25 & 103,9 & & 8,77 & \\ \cline{2-3} \cline{5-5}
|
|
& 27 & 15,2 & & 2,96 & \\ \hline
|
|
\multirow{3}{*}{Sapos} & 27 & 84,9 & \multirow{3}{*}{0,76} & 13,35 & \multirow{3}{*}{8,38} \\ \cline{2-3} \cline{5-5}
|
|
& 26 & 31,3 & & 8,87 & \\ \cline{2-3} \cline{5-5}
|
|
& 25 & 30 & & 7,88 & \\ \hline
|
|
\multirow{3}{*}{\begin{tabular}[c]{@{}c@{}}rtk2go\\ 5 km\end{tabular}} & 27 & 5 & \multirow{3}{*}{2,48} & 2,96 & \multirow{3}{*}{2,47} \\ \cline{2-3} \cline{5-5}
|
|
& 30 & 8,9 & & 2,23 & \\ \cline{2-3} \cline{5-5}
|
|
& 31 & 5,9 & & 2,23 & \\ \hline
|
|
\multirow{3}{*}{Sapos} & 29 & 14 & \multirow{3}{*}{0,48} & 2,23 & \multirow{3}{*}{4,1} \\ \cline{2-3} \cline{5-5}
|
|
& 30 & 12,2 & & 5,04 & \\ \cline{2-3} \cline{5-5}
|
|
& 29 & 11,9 & & 5,04 & \\ \hline
|
|
\multirow{3}{*}{\begin{tabular}[c]{@{}c@{}}rtk2go\\ 2 km\end{tabular}} & 30 & 13,6 & \multirow{3}{*}{1,85} & 4,32 & \multirow{3}{*}{3,72} \\ \cline{2-3} \cline{5-5}
|
|
& 30 & 5,4 & & 3,89 & \\ \cline{2-3} \cline{5-5}
|
|
& 30 & 5,8 & & 2,95 & \\ \hline
|
|
\multirow{3}{*}{Sapos} & 30 & 17,3 & \multirow{3}{*}{3,06} & 3,94 & \multirow{3}{*}{3,95} \\ \cline{2-3} \cline{5-5}
|
|
& 30 & 14,8 & & 4,94 & \\ \cline{2-3} \cline{5-5}
|
|
& 28 & 12,6 & & 2,97 & \\ \hline
|
|
\multirow{3}{*}{\begin{tabular}[c]{@{}c@{}}rtk2go\\ 200 m\end{tabular}} & 30 & 5,3 & \multirow{3}{*}{0,75} & 2,97 & \multirow{3}{*}{3,2} \\ \cline{2-3} \cline{5-5}
|
|
& 31 & 5,1 & & 2,19 & \\ \cline{2-3} \cline{5-5}
|
|
& 31 & 4,4 & & 4,45 & \\ \hline
|
|
\multirow{3}{*}{Sapos} & 30 & 12,8 & \multirow{3}{*}{0,52} & 4,42 & \multirow{3}{*}{3,49} \\ \cline{2-3} \cline{5-5}
|
|
& 29 & 14,9 & & 2,19 & \\ \cline{2-3} \cline{5-5}
|
|
& 28 & 14,9 & & 3,85 & \\ \hline
|
|
\end{tabular}
|
|
\caption{Zusammenfassung der Vergleichsmessung}
|
|
\label{tab:vergleichZusammenfassung}
|
|
\end{table}
|
|
|
|
Aus den Messergebnissen können folgende Schlussfolgerungen gezogen werden:
|
|
|
|
\begin{itemize}
|
|
\item Der erwartete Vorteil bei der Verwendung des Sapos Dienst bei höherer Entfernung ist nicht zu erkennen. Bei der maximalen Entfernung von 40 km ist der Drift bei beiden Castern nahezu identisch.
|
|
\item Wenn die Drifts von jeweils einem Caster über alle Entfernung gemittelt werden, schneidet rtk2go um fast einen Zentimeter besser ab.
|
|
\item Errechnet man die gleichen Mittelwerte für die Zeit bis zur Fix-Lösung, erreicht rtk2go ebenfalls einen fast eine Sekunde schnelleren Wert.
|
|
\item Die Messergebnisse scheinen eher von der Umgebung des Teststandorts, als der Entfernung zu der Referenzstation, abhängig zu sein.
|
|
\end{itemize}
|
|
|
|
\section{Tests}
|
|
\label{sec:tests}
|
|
Die folgenden Tests beschäftigen sich alle mit dem Rover und sollen die einzelnen implementierten Komponenten sowie deren zusammenwirken überprüfen. Die Tests sind in der Reihenfolge so sortiert, dass für den jeweils nächsten Test der vorherige erfolgreich abgeschlossen sein muss.
|
|
|
|
\subsection{Route aufzeichnen}
|
|
Für die Aufzeichnung muss der Rover zunächst in den \texttt{Capture Route} Modus versetzt werden. Dadurch wird automatisch der Ntrip-Client gestartet und es muss gewartet werden, bis das GNSS-Modul die eingestellte Genauigkeit erreicht hat. Dies kann im Menü überprüft werden. Währenddessen kann der Rover bereits verfahren und somit an den Startpunkt der Route gefahren werden. Anschließend wird der Befehl zur Speicherung des aktuellen Punktes über den Joystick gegeben. Nach jedem Speicherbefehl wird das Ergebnis im Menü überprüft. Sollte der aktuelle Punkt nicht gespeichert worden sein, liegt dies meistens an einer mangelhaften Positionsgenauigkeit. In diesem Fall wird gewartet bis diese wieder den Anforderungen entspricht.
|
|
\par
|
|
Es wurde für diesen Test eine Route, bestehend aus sechs Koordinatenpaaren, erfolgreich aufgezeichnet.
|
|
|
|
\subsubsection{Koordinaten Plausibilität}
|
|
Die Koordinaten wurden in der Webversion von Google Earth markiert und miteinander verbunden, siehe Abbildung \ref{fig:roverRouteGoogleEarth}. Während der Aufzeichnung der Route wurde darauf geachtet, markante Punkte, welche auch auf Satellitenbildern zu erkennen sind, zu benutzen. Deshalb wurden hauptsächlich Regenwassereinläufe als Positionen genutzt. Diese sind auf der Abbildung als kleine Rechtecke unter den Markierungen zu erkennen. Unter der Bedingung, dass die Positionierung der Bilder in Google Earth der Realität entspricht, treffen die aufgezeichneten Koordinaten die gewählten Punkte und können daher als plausibel betrachtet werden.
|
|
|
|
\begin{figure}[ht]
|
|
\centering
|
|
\includegraphics[width=\linewidth]{img/roverRouteGoogleEarth.png}
|
|
\caption{Abbildung einer aufgezeichneten Route in Google Earth\protect\footnote[3]{Quelle Google Earth. (2024) Bild eines Parkplatzes der an der Emil-Figge-Straße in Dortmund, Deutschland {[51.496567 N 7.418032 E]} Zugriff am 19.08.24, von \url{https://earth.google.com/web/}}}
|
|
\label{fig:roverRouteGoogleEarth}
|
|
\end{figure}
|
|
|
|
\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}
|
|
Die Zielfunktion des Rovers wurde mit einer Route vor einem Gebäude der FH Dortmund getestet. Die Punkte der Route ergeben miteinander verbunden ein Fünfeck. Der Rover konnte die aufgezeichnete Route abfahren. Dabei fiel auf, dass der Rover besonders einen Punkt verfehlte und um diesen zu erreichen, wendete und ihn dann traf. Dieses Verhalten trat bei jeder Runde auf. Ansonsten verlief der Test den Anforderungen entsprechend und zeigte, dass Fehler während der Navigation korrigiert werden können. Im Anhang \ref{cha:cd} wird der Pfad zu einer Videoaufzeichnung des Tests angegeben.
|
|
\par
|
|
Der Test wurde einige Stunden später erneut ausgeführt. Dabei wurde beobachtet, dass sich die ganze Route um ungefähr 20 cm von dem Gebäude entfernt hat. Aufgrund der Tatsache, dass alle Punkte gleichermaßen von diesem Phänomen betroffen waren, wird davon ausgegangen, dass das GNSS-Modul durch die Abschattung des Gebäudes einem Offset unterlag.
|
|
|
|
\subsubsection{Genuigkeitsprüfung}
|
|
Der Rover soll die autonome Navigation unterbrechen, sobald die verfügbare Genauigkeit des GNSS-Moduls einen Schwellwert unterschreitet. Dieses Verhalten wurde getestet, indem das W-LAN, welches die Internetverbindung für den Rover bereitstellt, abgeschaltet wurde. Der Rover fuhr anschließend etwa 16 Sekunden weiter und blieb dann stehen. Die Verzögerung ist dadurch zu erklären, dass das GNSS-Modul auch ohne neue Korrekturdaten zeitweise die geforderte Genauigkeit bereitstellen kann. Deshalb passt das Ergebnis zu dem erwarteten Verhalten.
|
|
\par
|
|
Zusätzlich konnte durch Wiederherstellen des W-LANs getestet werden, ob die Navigation wieder fortgesetzt wird, sobald die Genauigkeit den Anforderungen entspricht. Dieser Test konnte ebenfalls mit einem positiven Ergebnis abgeschlossen werden. Der Rover benötigte ungefähr 27 Sekunden, um die Navigation fortzusetzen. Diese Zeit ergibt sich zum einen aus den Warteschleifen, welche die Verbindungsversuche begrenzen und zum anderen durch das GNSS-Modul, welches die Korrekturdaten zunächst verarbeiten muss.
|
|
|
|
|
|
\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 die 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{Korrekturen während der Navigation}
|
|
Während einer Kurskorrektur in der Navigation wirkt der Rover sehr stockend. Dieser Eindruck entsteht, weil der Rover vor jeder Kurskorrektur bis zum Stillstand abbremst. Zusätzlich muss für die Rotation um die eigene Achse genügend Kraft aufgebracht werden, um den Grip der Reifen zu überwinden. Bei diesen Leistungen am Motor ist es in dieser Arbeit nicht gelungen, Drehungen um wenige Grad auf der Stelle auszuführen, weil der plötzliche Verlust des Grips der Reifen zu einer stoßartigen Drehung führt.
|
|
\par
|
|
Aufgrund dieser Problemstellungen wird eine Kurskorrektur erst ausgeführt, wenn die Abweichung groß genug ist. Durch diese Vorgehensweise neigt der Rover eher dazu, an einem Ziel vorbeizufahren. Der Algorithmus für die Kurskorrektur wurde angesichts der steigenden Komplexität nicht angepasst.
|