Archived
- messaufbau bild hinzegfügt und spalten beschrieben - Ausfall Station eingebracht
60 lines
12 KiB
TeX
60 lines
12 KiB
TeX
\chapter{Resümee}
|
|
|
|
\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 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 wurden 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 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
|
|
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 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 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 Untersuchungen werden im nächsten Abschnitt, dem Fazit, erläutert.
|
|
|
|
\section{Fazit}
|
|
Dieses Fazit misst sich an der Zielsetzung aus Abschnitt \ref{sec:zielsetzung}. Der Themenbereich rund um die Referenzstation wurde als erstes Ziel festgesetzt und daher auch zu Anfang dieser Arbeit umgesetzt. Dadurch weist dieser Teil die längste Erprobungszeit auf. Die Station entspricht den Erwartungen und erfüllt ihre Aufgabe. Ein Ausfall nach zweimonatiger Laufzeit zeigte mögliche Schwächen der Anlage bei hohen Temperaturen auf. Überdies wurden Informationen gewonnen, welche für Verbesserungen an der Referenzstation herangezogen werden können. Diese werden mit anderen Vorschlägen im nächsten Abschnitt \ref{sec:ausblick} dargelegt. Aus den vergleichenden Messungen in einem 40 km Radius zwischen dieser Station und dem Sapos Dienst ging ein kleiner Vorteil für die Lösung dieser Arbeit hervor. Dieser gemessene Vorteil kann allerdings nicht für jedes Einsatzszenario angenommen werden. Im Betrieb des Rovers ergeben sich keine funktionalen Unterschiede anhand der Korrekturdatenquelle. Deshalb ist die Referenzstation hauptsächlich durch nicht funktionale Aspekte von Vorteil. Aufgrund der Hardwarekontrolle ist keine Abhängigkeit zu anderen Dienstleistern gegeben. Es können eigene Projekte umgesetzt und alternative Übertragungsmöglichkeiten erprobt werden.
|
|
\par
|
|
Bei den Testungen des für den Rover implementierten Ntrip-Clients konnten beide Datenquellen mit der Revision 1 und 2 des Protokolls erfolgreich getestet werden.
|
|
\par
|
|
Die Erweiterungen des Rovers konnten alle ausgeführt werden, sodass der Rover nun autonom aufgezeichnete Routen abfahren kann. Die Navigation des Rovers greift dabei auf die Sensoren und die Implementierung der Routen zurück. Durch die Möglichkeit der Speicherung über die API konnte eine flexible Verwaltung der Routen erschaffen werden. Während der aktiven Navigation verfehlt der Rover gelegentlich die Zielpunkte, kann dies jedoch korrigieren. Die Funktionalität des Rovers ist von einer Internetverbindung und dem sauberen Empfang der GNSS-Signale abhängig und lässt sich daher als sehr vulnerabel betrachten.
|
|
\par
|
|
Der zusätzliche Sensor in Form des Gyroskops trägt dazu bei, den Rover mit weniger Aufwand während einer Navigation auszurichten und ist darüber hinaus weniger anfällig für Störungen als das Magnetometer. Dieses erleichtert jedoch die erste Ausrichtung des Rovers. Daher lassen sich beide Sensoren als sinnvoll eingesetzt betrachten.
|
|
\par
|
|
Zusammengenommen lässt sich aus der Bewertung schließen, dass das Projekt erfolgreich durchgeführt wurde und dabei Erkenntnisse für Verbesserungen und zukünftige Projekte gewonnen wurden.
|
|
|
|
\section{Ausblick}
|
|
\label{sec:ausblick}
|
|
Diese Arbeit wird mit einem Ausblick auf die mögliche Zukunft des Projekts abgeschlossen. Die einzelnen Punkte des Ausblicks ergeben sich aus dem eben geschlossenem 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. 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 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.
|
|
\end{itemize}
|
|
|
|
|
|
\subsection{Umstrukturierung und Erweiterung des Rovers}
|
|
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 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} 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.
|
|
\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 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[]{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.
|
|
|
|
\subsection{Temperaturbeständigkeit der Referenzstation}
|
|
Der in der Bewertung beschriebene Ausfall der Referenzstation ist der Wahrscheinlichkeit nach auf sehr hohe Außentemperaturen zurückzuführen. Daher empfiehlt es sich, für die Langlebigkeit der Komponenten im Installationskasten sowie der Ausfallsicherheit eine Isolierung in den Kasten einzubringen.
|