Archived
55 lines
9.3 KiB
TeX
55 lines
9.3 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 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.
|
|
\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.
|
|
\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.
|
|
\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.
|
|
\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.
|
|
|
|
\section{Fazit}
|
|
Ergebnisse eigene vs andere Station
|
|
Eigene Station sinnvoll?
|
|
Kompass erweiterung sinnvoll?
|
|
Navigationsleistung des Rovers
|
|
|
|
|
|
\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 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.
|
|
|
|
\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 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 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.
|
|
\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.
|
|
\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 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.
|
|
|
|
\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.
|
|
\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.
|
|
|
|
|