Archived
114 lines
18 KiB
TeX
114 lines
18 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 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}
|