Archived
- splitting files for languagetool
- use languagetool - adding pictures - remove some !!!fixMe!!!!
This commit is contained in:
Vendored
+101
@@ -3,3 +3,104 @@ Caster
|
|||||||
Routenverwaltung
|
Routenverwaltung
|
||||||
Taskverwaltung
|
Taskverwaltung
|
||||||
over
|
over
|
||||||
|
Skid-Antrieb
|
||||||
|
u-blox
|
||||||
|
Sparkfun
|
||||||
|
BeiDou
|
||||||
|
RTK-Modus
|
||||||
|
ZED-F
|
||||||
|
NavIC
|
||||||
|
PoE
|
||||||
|
Extender
|
||||||
|
Twisted-Pair-Kabel
|
||||||
|
Twisted-Pair-Kabeln
|
||||||
|
Terminalblock
|
||||||
|
PoE-Hardware
|
||||||
|
RTK-Basisstation
|
||||||
|
Systemd
|
||||||
|
ser2net
|
||||||
|
U-Blox
|
||||||
|
com0com
|
||||||
|
com2tcp
|
||||||
|
PostProcessing
|
||||||
|
RINEX-Format
|
||||||
|
Uhrendaten
|
||||||
|
RTKLib
|
||||||
|
Ntrip-Caster
|
||||||
|
RINEX
|
||||||
|
U-center
|
||||||
|
Ntrip-Client
|
||||||
|
RTK
|
||||||
|
go
|
||||||
|
Pulsecounter
|
||||||
|
ESPNow
|
||||||
|
GPIO
|
||||||
|
Component
|
||||||
|
DriveModi
|
||||||
|
Xtensa
|
||||||
|
NAVSTAR
|
||||||
|
Klobuchar-Modell
|
||||||
|
Hopfield
|
||||||
|
Saastamoinen
|
||||||
|
the
|
||||||
|
Ionosphärische
|
||||||
|
ionosphärischen
|
||||||
|
DGNSS-Methode
|
||||||
|
SBAS
|
||||||
|
EGNOS
|
||||||
|
DGNSS-Nachrichten
|
||||||
|
DGNSS
|
||||||
|
INdependent
|
||||||
|
Gurtner
|
||||||
|
RTCM-SC
|
||||||
|
EXchange
|
||||||
|
.obs
|
||||||
|
.nav
|
||||||
|
PostProcessingService
|
||||||
|
Post-Processing-Service
|
||||||
|
.sbs
|
||||||
|
RTCM
|
||||||
|
RTCM-Nachrichten
|
||||||
|
Msg-Nr
|
||||||
|
MSM
|
||||||
|
Phaserange
|
||||||
|
Protocol
|
||||||
|
Ntrip-Server
|
||||||
|
Ntrip-Clients
|
||||||
|
Multimode-Glasfaserkabel
|
||||||
|
Singlemode-Glasfaserkabel
|
||||||
|
Twisted-Pair
|
||||||
|
Cat
|
||||||
|
BASE-TX
|
||||||
|
GBASE-T
|
||||||
|
GBASE-SR
|
||||||
|
GBASE-LR
|
||||||
|
Cat6a
|
||||||
|
bt
|
||||||
|
af
|
||||||
|
at
|
||||||
|
LoRaWan-Gateway
|
||||||
|
PicoSYS
|
||||||
|
Hanzsung
|
||||||
|
PoE-Anschluss
|
||||||
|
PoE-Splitter
|
||||||
|
AZ-Delivery
|
||||||
|
Processor
|
||||||
|
Jinchang
|
||||||
|
Electron
|
||||||
|
Surveying
|
||||||
|
TNC-Buchse
|
||||||
|
TNC-Stecker
|
||||||
|
UNC
|
||||||
|
Serial
|
||||||
|
PoE-Kabel
|
||||||
|
SparkFun
|
||||||
|
Exsys
|
||||||
|
hxbxt
|
||||||
|
TRENDnet
|
||||||
|
PoE-Kabels
|
||||||
|
TI-BE
|
||||||
|
PoE-fähige
|
||||||
|
PoE-Extender
|
||||||
|
GPS-RTK-SMA
|
||||||
|
Breakout
|
||||||
|
|||||||
+18
@@ -1 +1,19 @@
|
|||||||
{"rule":"GERMAN_SPELLER_RULE","sentence":"^\\QDafür existiert der Menüeintrag Clear oder der Rover wird neugestartet.\\E$"}
|
{"rule":"GERMAN_SPELLER_RULE","sentence":"^\\QDafür existiert der Menüeintrag Clear oder der Rover wird neugestartet.\\E$"}
|
||||||
|
{"rule":"DE_CASE","sentence":"^\\QCommunication Server - Für die Verwendung können mehrere Ein- und Ausgänge konfiguriert werden.\\E$"}
|
||||||
|
{"rule":"DE_CASE","sentence":"^\\QRINEX Converter - Mit diesem Konverter können die Beobachtungsdaten, welche im proprietären Format von U-Blox vorliegen in das RINEX-Format konvertiert werden.\\E$"}
|
||||||
|
{"rule":"DE_CASE","sentence":"^\\QRINEX Konverter - Mit diesem Konverter können die Beobachtungsdaten, welche im proprietären Format von U-Blox vorliegen in das RINEX-Format konvertiert werden.\\E$"}
|
||||||
|
{"rule":"DE_CASE","sentence":"^\\QRINEX Konverter - Mit diesem Konverter können die Beobachtungsdaten, welche im proprietären Format von U-Blox vorliegen, in das RINEX-Format konvertiert werden.\\E$"}
|
||||||
|
{"rule":"GERMAN_SPELLER_RULE","sentence":"^\\QFür die Einmessung der zu errichtenden Basisstation wird in dieser Arbeit der kostenlose Service Canadian Spatial Reference System Precise Point Positioning (CSRS-PPP) \\E(?:Dummy|Ina|Jimmy-)[0-9]+\\Q genutzt.\\E$"}
|
||||||
|
{"rule":"GERMAN_SPELLER_RULE","sentence":"^\\QFür die Einmessung der zu errichtenden Basisstation wird in dieser Arbeit der kostenlose Service Canadian Spatial Reference System Precise Point Positioning (CSRS-PPP) \\E(?:Dummy|Ina|Jimmy-)[0-9]+\\Q genutzt.\\E$"}
|
||||||
|
{"rule":"GERMAN_SPELLER_RULE","sentence":"^\\QThis file comes from Science Museum Collections, a website operated by Science Museum Group, a non-departmental public body in the UK.\\E$"}
|
||||||
|
{"rule":"EINZELBUCHSTABE_PREMIUM","sentence":"^\\QThis file comes from Science Museum Collections, a website operated by Science Museum Group, a non-departmental public body in the UK.\\E$"}
|
||||||
|
{"rule":"GERMAN_SPELLER_RULE","sentence":"^\\QA normal copyright tag is still required.\\E$"}
|
||||||
|
{"rule":"GERMAN_SPELLER_RULE","sentence":"^\\QSee Commons:Licensing.\\E$"}
|
||||||
|
{"rule":"GERMAN_SPELLER_RULE","sentence":"^\\QIn der Strato- und Troposphäre wird das Signal hauptsächlich durch die Zusammensetzung der Gase, dem Luftdruck und der Temperatur in diesen Schichten beeinflusst.\\E$"}
|
||||||
|
{"rule":"GERMAN_SPELLER_RULE","sentence":"^\\QGNSS ist das Akronym für Global Navigation Satellite System.\\E$"}
|
||||||
|
{"rule":"GERMAN_SPELLER_RULE","sentence":"^\\QGNSS ist das Akronym für Global Navigation Satellite System.\\E$"}
|
||||||
|
{"rule":"GERMAN_SPELLER_RULE","sentence":"^\\QDie sogenannten Satellite-Based Augmentation System stellen Erweiterungen zu den GNSS Diensten dar um beispielsweise die Genauigkeit zu erhöhen.\\E$"}
|
||||||
|
{"rule":"GERMAN_SPELLER_RULE","sentence":"^\\QDie sogenannten Satellite-Based Augmentation System stellen Erweiterungen zu den GNSS Diensten dar um insbesondere die Genauigkeit zu erhöhen.\\E$"}
|
||||||
|
{"rule":"DE_CASE","sentence":"^\\QDie in Tabelle \\E(?:Dummy|Ina|Jimmy-)[0-9]+\\Q bezeichnete MSM4 enthält die Pseudorange, Phaserange und CNR (Carrier to Noise Ratio).\\E$"}
|
||||||
|
{"rule":"DE_CASE","sentence":"^\\Q\\E(?:Dummy|Ina|Jimmy-)[0-9]+\\Q Damit das Protokoll möglichst gut unterstützt wird, orientiert es sich stark an dem HTTP (Hypertext Transfer Protokoll)in der Version 1.1.\\E$"}
|
||||||
|
{"rule":"EINHEIT_LEERZEICHEN","sentence":"^\\QStandard Verabschiedung Frequenzband [GHz] max. brutto Datenrate 802.11a 1999 2,4 & 5 \\E(?:Dummy|Ina|Jimmy-)[0-9]+\\Q 802.11b 1999 2,4 \\E(?:Dummy|Ina|Jimmy-)[0-9]+\\Q 802.11g 2003 2,4 \\E(?:Dummy|Ina|Jimmy-)[0-9]+\\Q 802.11n 2009 2,4 & 5 \\E(?:Dummy|Ina|Jimmy-)[0-9]+\\Q 802.11ac 2013 5 \\E(?:Dummy|Ina|Jimmy-)[0-9]+\\Q 802.11ax 2019 2,4 & 5 \\E(?:Dummy|Ina|Jimmy-)[0-9]+\\Q 802.11be ausstehend 2,4, 5 & 6 \\E(?:Dummy|Ina|Jimmy-)[0-9]+\\Q Ausschnitt verschiedener IEEE 802.11 Standards\\E$"}
|
||||||
|
|||||||
Vendored
+12
@@ -4,6 +4,7 @@
|
|||||||
"editor.suggest.snippetsPreventQuickSuggestions": false,
|
"editor.suggest.snippetsPreventQuickSuggestions": false,
|
||||||
"editor.fontSize": 16,
|
"editor.fontSize": 16,
|
||||||
"editor.trimAutoWhitespace": true,
|
"editor.trimAutoWhitespace": true,
|
||||||
|
"editor.minimap.enabled": false,
|
||||||
"files.trimFinalNewlines": true,
|
"files.trimFinalNewlines": true,
|
||||||
"files.insertFinalNewline": true,
|
"files.insertFinalNewline": true,
|
||||||
"ltex.language": "de-DE",
|
"ltex.language": "de-DE",
|
||||||
@@ -71,6 +72,8 @@
|
|||||||
"cSpell.words": [
|
"cSpell.words": [
|
||||||
"Akozon",
|
"Akozon",
|
||||||
"Arduinoframework",
|
"Arduinoframework",
|
||||||
|
"ased",
|
||||||
|
"atellite",
|
||||||
"Austauschencoder",
|
"Austauschencoder",
|
||||||
"Bachelorthesis",
|
"Bachelorthesis",
|
||||||
"Basissation",
|
"Basissation",
|
||||||
@@ -81,11 +84,13 @@
|
|||||||
"bürstenbehafteten",
|
"bürstenbehafteten",
|
||||||
"Christof",
|
"Christof",
|
||||||
"CPHA",
|
"CPHA",
|
||||||
|
"CSRS",
|
||||||
"Desktopumgebung",
|
"Desktopumgebung",
|
||||||
"DGNSS",
|
"DGNSS",
|
||||||
"documentclass",
|
"documentclass",
|
||||||
"Doxygen",
|
"Doxygen",
|
||||||
"Dutycycle",
|
"Dutycycle",
|
||||||
|
"eceiver",
|
||||||
"EGNOS",
|
"EGNOS",
|
||||||
"Encodern",
|
"Encodern",
|
||||||
"Encoderscheibe",
|
"Encoderscheibe",
|
||||||
@@ -94,13 +99,16 @@
|
|||||||
"gesockelt",
|
"gesockelt",
|
||||||
"GLONASS",
|
"GLONASS",
|
||||||
"GPIO",
|
"GPIO",
|
||||||
|
"Gurtner",
|
||||||
"Hopfield",
|
"Hopfield",
|
||||||
"hypersetup",
|
"hypersetup",
|
||||||
|
"inematic",
|
||||||
"Ionosphärische",
|
"Ionosphärische",
|
||||||
"ionosphärischen",
|
"ionosphärischen",
|
||||||
"Kalibrierungsdaten",
|
"Kalibrierungsdaten",
|
||||||
"Klobuchar",
|
"Klobuchar",
|
||||||
"Konnektoren",
|
"Konnektoren",
|
||||||
|
"lobal",
|
||||||
"magnetoresistiv",
|
"magnetoresistiv",
|
||||||
"Mehrdeutigkeitslösung",
|
"Mehrdeutigkeitslösung",
|
||||||
"Meterbereich",
|
"Meterbereich",
|
||||||
@@ -133,11 +141,15 @@
|
|||||||
"subsubsection",
|
"subsubsection",
|
||||||
"Taskverwaltung",
|
"Taskverwaltung",
|
||||||
"Terminalblock",
|
"Terminalblock",
|
||||||
|
"Ubuntuusers",
|
||||||
|
"ugmentation",
|
||||||
|
"Uhrendaten",
|
||||||
"Vorwärtstransformation",
|
"Vorwärtstransformation",
|
||||||
"WROOM",
|
"WROOM",
|
||||||
"XOUT",
|
"XOUT",
|
||||||
"Xtensa",
|
"Xtensa",
|
||||||
"YOUT",
|
"YOUT",
|
||||||
|
"ystem",
|
||||||
"ZEDF",
|
"ZEDF",
|
||||||
"Zielinski",
|
"Zielinski",
|
||||||
"ZOUT",
|
"ZOUT",
|
||||||
|
|||||||
+14
-3
@@ -107,13 +107,24 @@
|
|||||||
|
|
||||||
\include{030_einleitung}
|
\include{030_einleitung}
|
||||||
|
|
||||||
\include{040_grundlagen}
|
\include{040_1_grundlagen_main}
|
||||||
|
\include{040_2_grundlagen_rover}
|
||||||
|
\include{040_3_1_grundlagen_protokolle}
|
||||||
|
\include{040_3_2_grundlagen_protokolle_gnss}
|
||||||
|
\include{040_3_3_grundlagen_protokolle_gnsscorrections}
|
||||||
|
\include{040_3_4_grundlagen_protokolle_internet}
|
||||||
|
\include{040_4_grundlagen_hardware}
|
||||||
|
\include{040_5_grundlagen_software}
|
||||||
|
|
||||||
\include{045_anforderungen}
|
\include{045_anforderungen}
|
||||||
|
|
||||||
\include{050_hardwareauswahl}
|
\include{050_hardwareauswahl}
|
||||||
|
|
||||||
\include{060_implementierung}
|
\include{060_1_implementierung}
|
||||||
|
\include{060_2_implementierung_basisstation}
|
||||||
|
\include{060_3_implementierung_basisstation}
|
||||||
|
\include{060_4_implementierung_rover}
|
||||||
|
\include{060_5_implementierung_rover}
|
||||||
|
|
||||||
\include{065_bewertung}
|
\include{065_bewertung}
|
||||||
|
|
||||||
@@ -137,4 +148,4 @@
|
|||||||
|
|
||||||
\include{999_eidesstattlicheErklärung}
|
\include{999_eidesstattlicheErklärung}
|
||||||
|
|
||||||
\end{document}
|
\end{document}
|
||||||
|
|||||||
+4
-4
@@ -4,19 +4,19 @@
|
|||||||
\par
|
\par
|
||||||
Durch hochgenaue Positionsbestimmungen konnten weitere Anwendungsbereiche erschlossen werden. Dabei sind einige von diesen Positionslösungen auf geschlossene Systeme wie beispielsweise in Lagerhallen für automatische Lagerhaltung mit selbstfahrenden Robotern begrenzt. Da jedoch auch der Bedarf nach globalen hochgenauen Systemen zur Positionsbestimmung bestand, wurden die GNSS weiterentwickelt und es wurde die Möglichkeit geschaffen durch kontinuierliche Referenzmessungen die Genauigkeit in den niedrigen Zentimeterbereich anzuheben \cite[]{Bauer2018}.
|
Durch hochgenaue Positionsbestimmungen konnten weitere Anwendungsbereiche erschlossen werden. Dabei sind einige von diesen Positionslösungen auf geschlossene Systeme wie beispielsweise in Lagerhallen für automatische Lagerhaltung mit selbstfahrenden Robotern begrenzt. Da jedoch auch der Bedarf nach globalen hochgenauen Systemen zur Positionsbestimmung bestand, wurden die GNSS weiterentwickelt und es wurde die Möglichkeit geschaffen durch kontinuierliche Referenzmessungen die Genauigkeit in den niedrigen Zentimeterbereich anzuheben \cite[]{Bauer2018}.
|
||||||
\par
|
\par
|
||||||
Mit dieser Genauigkeit ist es zum Beispiel möglich kartografische Aufgaben mit GNSS und RTK zu bewältigen. Neben anderen Industriezweigen profitiert die Landwirtschaft ebenfalls von dieser Technologie, indem Traktoren damit in der Spur gehalten werden können und so die Felder effizienter bewirtschaften können. Neben der professionellen Landwirtschaft kommt RTK inzwischen auch in kleineren Gärten zum Einsatz in Form von autonomen Rasenmähern. Diese können dadurch ohne physische Begrenzungen im Garten navigieren und gewünschte Schnittmuster des Rasens erzeugen \cite[]{rasenRtk}.
|
Mit dieser Genauigkeit ist es etwa möglich, kartografische Aufgaben mit GNSS und RTK zu bewältigen. Neben anderen Industriezweigen profitiert die Landwirtschaft ebenfalls von dieser Technologie, indem Traktoren damit in der Spur gehalten werden und so die Felder effizienter bewirtschaften können. Neben der professionellen Landwirtschaft kommt RTK inzwischen auch in kleineren Gärten zum Einsatz in Form von autonomen Rasenmähern. Diese können dadurch ohne physische Begrenzungen im Garten navigieren und gewünschte Schnittmuster des Rasens erzeugen \cite[]{rasenRtk}.
|
||||||
|
|
||||||
\section{Zielsetzung}
|
\section{Zielsetzung}
|
||||||
Die Ziele lassen sich in drei Arbeitsbereiche unterteilen, welche zusammengenommen ein bereits bestehendes Projekt über ein Fahrzeug so erweitern sollen, dass dieses eine Patrouillenfahrt um ein Gebäude oder anderen Bereich ausführen kann.
|
Die Ziele lassen sich in drei Arbeitsbereiche unterteilen, welche zusammengenommen ein bereits bestehendes Projekt über ein Fahrzeug so erweitern sollen, dass dieses eine Patrouillenfahrt um ein Gebäude oder anderen Bereich ausführen kann.
|
||||||
\par
|
\par
|
||||||
Der erste Bereich widmet sich der Breitstellung einer Referenzstation zur Erzeugung von Korrekturdaten mit deren Hilfe es GNSS-Modulen möglich ist Positionsbestimmungen im Zentimeterbereich durchzuführen. Der Installationsort einer solchen Station unterliegt mehreren Anforderungen, welche berücksichtigt werden müssen. Durch die Bindung an einen bestimmten Installationsort muss adäquate Hardware ausgewählt werden. Darüber hinaus sollen die erzeugten Daten öffentlich zur Verfügung gestellt werden, damit das System auch über diese Arbeit hinaus einen Mehrwert bietet.
|
Der erste Bereich widmet sich der Breitstellung einer Referenzstation zur Erzeugung von Korrekturdaten, mit deren Hilfe es GNSS-Modulen möglich ist, Positionsbestimmungen im Zentimeterbereich durchzuführen. Der Installationsort einer solchen Station unterliegt mehreren Anforderungen, welche berücksichtigt werden müssen. Durch die Bindung an einen bestimmten Installationsort muss adäquate Hardware ausgewählt werden. Weiterhin sollen die erzeugten Daten öffentlich zur Verfügung gestellt werden, damit das System auch über diese Arbeit hinaus einen Mehrwert bietet.
|
||||||
\par
|
\par
|
||||||
Wenn der erste Bereich abgeschlossen ist, kann mit dem zweiten begonnen werden. In diesem soll das bestehende Projekt erweitert werden, sodass dieses die Daten von der Referenzstation nutzt. Mit der dadurch zu erlangenden Positionsbestimmung soll eine autonome Navigation entlang von abgefahrenen Routen ermöglicht werden. Damit die Steuerung des Fahrzeugs erleichtert wird, soll dem Projekt ein Gyroskop hinzugefügt werden.
|
Wenn der erste Bereich abgeschlossen ist, kann mit dem zweiten begonnen werden. In diesem soll das bestehende Projekt erweitert werden, sodass dieses die Daten von der Referenzstation nutzt. Mit der dadurch zu erlangenden Positionsbestimmung soll eine autonome Navigation entlang von abgefahrenen Routen ermöglicht werden. Damit die Steuerung des Fahrzeugs erleichtert wird, soll dem Projekt ein Gyroskop hinzugefügt werden.
|
||||||
\par
|
\par
|
||||||
In dem letzten Bereich sollen Erkenntnisse aus den ersten beiden Bereichen gesammelt und analysiert werden. Dazu sollen verschiedene Test durchgeführt werden, welche die erarbeiteten Funktionen testen. Zusätzlich soll ein Vergleich zwischen der aus dem ersten Bereich errichteten Referenzstation und dem vom Bund betrieben Netz aus Referenzstationen im Hinblick auf die Positionsgenauigkeit gezogen werden.
|
In dem letzten Bereich sollen Erkenntnisse aus den ersten beiden Bereichen gesammelt und analysiert werden. Dazu sollen verschiedene Tests durchgeführt werden, welche die erarbeiteten Funktionen testen. Zusätzlich soll ein Vergleich zwischen der aus dem ersten Bereich errichteten Referenzstation und dem vom Bund betrieben Netz aus Referenzstationen im Hinblick auf die Positionsgenauigkeit gezogen werden.
|
||||||
|
|
||||||
\section{Ausgangssituation}
|
\section{Ausgangssituation}
|
||||||
Diese Arbeit baut auf einer Projektarbeit auf, bei welcher ein Rover mit Skid-Antrieb zum autonomen Navigieren mittels GNSS vorbereitet wurde. Dabei wurde ein erweiterbares System erschaffen, welches es erlaubt die für diese Arbeit notwendigen Implementierungen durchzuführen, einen abstrahierten Zugriff auf die Hardware bietet und eine Möglichkeit den Rover Fernzusteuern bereitstellt. Hardwareseitig wurden bereits Sensoren verbaut, die zur Ortung und Ausrichtung des Rovers beitragen. Eine detailliertere Beschreibung ist in der genannten Arbeit \cite{Klein2023} zu finden. Zusätzlich beschreibt der Abschnitt \ref{sec:rover} den Rover in zusammengefasster und für diese Arbeit angepasster Form.
|
Diese Arbeit baut auf einer Projektarbeit auf, bei welcher ein Rover mit Skid-Antrieb zum autonomen Navigieren mittels GNSS vorbereitet wurde. Dabei wurde ein erweiterbares System erschaffen, welches es erlaubt, die für diese Arbeit notwendigen Implementierungen durchzuführen, einen abstrahierten Zugriff auf die Hardware bietet und eine Möglichkeit den Rover fernzusteuern bereitstellt. Hardwareseitig wurden bereits Sensoren verbaut, die zur Ortung und Ausrichtung des Rovers beitragen. Eine detailliertere Beschreibung ist in der genannten Arbeit \cite{Klein2023} zu finden. Zusätzlich beschreibt der Abschnitt \ref{sec:rover} den Rover in zusammengefasster und für diese Arbeit angepasster Form.
|
||||||
\par
|
\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.
|
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.
|
||||||
|
|
||||||
|
|||||||
@@ -0,0 +1,2 @@
|
|||||||
|
\chapter{Grundlagen}
|
||||||
|
Dieses Kapitel startet mit der Beschreibung des vorhandenen Fahrzeugs, dem Rover, anhand der darüber verfassten Projektarbeit. Dabei ist die Systemarchitektur und die vorhandenen Schnittstellen von besonderer Relevanz, da diese genutzt werden müssen, um die nötigen Implementierungen für diese Arbeit ausführen zu können. Im weiteren Verlauf des Kapitels werden die notwendigen Protokolle erläutert. In diesem Abschnitt wird besonderes auf die Erläuterung der Funktionsweise von GNSS und den Möglichkeiten für Korrekturen der Positionsdaten eingegangen. Darauf folgt eine Beschreibung der Funktionen von Hardwarekomponenten. Geschlossen wird das Kapitel mit der Erläuterung von benötigter und verwendeter Software.
|
||||||
@@ -0,0 +1,15 @@
|
|||||||
|
\section{Rover}
|
||||||
|
\label{sec:rover}
|
||||||
|
Dieser Abschnitt beschreibt das in der zugrundeliegenden Projektarbeit \cite{Klein2023} erstellte Gesamtsystems des Rovers für diese Arbeit.
|
||||||
|
\par
|
||||||
|
Der Rover wird durch einen 3-Zellen Lithium-Ionen-Akkumulator mit Strom versorgt, dabei wird der Motortreiber und infolgedessen die beiden Motoren für den Skid-Antrieb mit der anliegenden Spannung des Akkus von nominal \(11,1V\) versorgt. Der Akkumulator und der Motortreiber befinden sich nebeneinander auf der Unterseite des Hauptträgers der Komponenten, auf dem Bild \ref{fig:rover} das blaue Plastik. Je einer der beiden Motoren treibt eine der Fahrzeugseiten an, diese bestehen aus jeweils drei Rädern, welche alle über einen Riemen mit der Ausgangswelle des Getriebes zur Untersetzung verbunden sind. An der dieser Ausgangswelle befindet sich ein Encoder-Rad, welches durch eine einfache Gabellichtschranke ausgelesen wird, dafür wird der in Hardware implementierte Pulsecounter des verbauten Prozessors verwendet.
|
||||||
|
\par
|
||||||
|
Die restlichen Komponenten werden mit \(5V\) versorgt, die \(5V\) werden über einen Spannungsregler mit einem maximalen dauerhaften Ausgangsstrom von \(1A\) bereitgestellt. Der Spannungsregler befindet sich auf der Hauptplatine, welche wiederum auf der Oberseite des Hauptträgers zentral verbaut ist. Diese Platine verbindet alle Komponenten mit dem auf einem aufgesteckten Entwicklungsboard verbauten ESP32 Prozessor. Der ESP32 stellt verschiedene Schnittstellen über die GPIO (General Purpose Input Output) Pins zur Verfügung, davon werden für den Rover die Bussysteme I2C und SPI, ein ADC Kanal (Analog Digital Konverter) und PWM (Pulsweitenmodulation) genutzt. Weitere Kommunikation findet auf dem drahtlosen Weg statt, dafür wird das Wi-Fi-Modul genutzt, mit diesem kann eine Verbindung zu einem \(2,4GHz\) WLAN aufgebaut werden und es wird mit dem Protokoll ESPNow über dasselbe Frequenzband eine Verbindung zu der Fernbedienung hergestellt. Zur Verwaltung des Funkmoduls und der Bewältigung anderen Aufgaben, welche an den Prozessor gestellt werden, verfügt dieser über zwei Xtensa 32Bit LX6 Kerne, welche mit bis zu \(240MHz\) takten. Als SRAM stehen 540 KB bereit und der Flash-Speicher für die Software ist 4 Megabyte groß.
|
||||||
|
\par
|
||||||
|
Mit auf der Hauptplatine befindet sich das ebenfalls aufgesteckte Entwicklungsboard von Sparkfun. Das Board nutzt den SPI-Bus, um die Kommunikation zwischen dem ESP32 und dem ZED-F9K herzustellen. Bei dem ZED-F9K handelt es sich um einen hochpräziser Multi-Band-GNSS-Receiver, welcher die Signale von allen öffentlichen Satelliten gestützten Navigationssystemen verarbeiten kann. Zusätzlich können Korrekturdaten verarbeitet werden, mit welchen die Genauigkeit der Positionsbestimmung auf den Bereich einstelliger Zentimeter erhöht wird. Auf der Platine befindet sich eine SMA-Buchse, mit welcher die GNSS-Antenne verbunden ist. Die Antenne befindet sich am Heck des Rovers auf dem grünen T-Träger.
|
||||||
|
\par
|
||||||
|
Der I2C-Bus wird benutzt, um den letzten Sensor und ein Display anzubinden. Der Sensor ist ein Kompass, welcher möglichst weit von anderen Komponenten entfernt sein sollte und deshalb auf dem Mast, der neben dem Display nach oben ragt, montiert ist und die aktuelle Himmelsrichtung bei richtiger Kalibrierung auf \(2^{\circ}\) genau angeben kann. Bei dem Display auf dem Querbalken handelt es sich um ein 16 x 2 Zeichen LCD, dieses wird von einem I2C-Seriell Adapterinterface betrieben.
|
||||||
|
\par
|
||||||
|
Zu dem Rover gehört eine Fernbedienung, welche über sieben Tasten und einem Joystick als Eingabemöglichkeit verfügt. Vier Tasten bilden ein Steuerkreuz, um das Navigieren im Menü zu ermöglichen. Zwei weitere Tasten werden zum Bestätigen und Ablehnen genutzt. Die letzte Taste wird als Action-Button bezeichnet und wird betätigt, wenn der Joystick gedrückt wird. Die Taste ist für spezielle Aktionen der verschiedenen Betriebsmodi des Rovers vorgesehen. An der Fernbedienung wurde ebenfalls das zuvor genannte LCD verbaut, dieses spiegelt das Display am Rover. Die Fernbedienung wird ebenfalls von einem ESP32 gesteuert, dieser stellt die Kommunikation über das genannte ESPNow Protokoll zu dem Rover her. Um die Fernbedienung mit Energie zu versorgen, wird eine Powerbank benötigt, an der das heraushängende USB-Kabel vom Typ A angeschlossen werden kann.
|
||||||
|
\par
|
||||||
|
Die vorhandene Software für den Rover ist objektorientiert und modular aufgebaut. Zusätzlich ist der Programmcode für die Benutzeroberfläche von dem restlichen Code getrennt. Die Struktur des Codes wird wesentlich durch zwei Interfaces bestimmt. Das erste wird als \texttt{Component} bezeichnet und muss implementiert werden, um eigenständige wiederkehrende Aufgaben zu implementieren. Das zweite Interface mit dem Namen \texttt{DriveModi} definiert, welche Mindestanforderungen an einen Betriebsmodus des Rovers gestellt werden und stellt die Komponenten für die Benutzereingaben, die Sensorverwaltung und die Bewegungsreglung zur Nutzung im Betriebsmodus bereit. Andere Komponenten überwachen den Akku, steuern das Display, verwalten die Benutzeroberfläche, überwachen Benutzereingaben oder verarbeiten Sensordaten.
|
||||||
@@ -0,0 +1,2 @@
|
|||||||
|
\section{Protokolle}
|
||||||
|
Dieser Abschnitt beschreibt die verschiedenen Protokolle, welche von unterschiedlichen Teilsystemen genutzt werden, um die Funktionalität des Gesamtsystems zu ermöglichen.
|
||||||
@@ -0,0 +1,94 @@
|
|||||||
|
\subsection{GNSS}
|
||||||
|
GNSS ist das Akronym für \textbf{G}lobal \textbf{N}avigation \textbf{S}atellite \textbf{S}ystem. Inzwischen gibt es mehrere dieser Systeme, deren Hauptzweck die Positionsbestimmung auf dem gesamten Globus und auch darüber ist. In der Tabelle \ref{tab:sats} sind diese aufgelistet. Die Positionsbestimmung wird unter anderem für die Navigation in allen Bereichen, zur Vermessung und Zeitmessung verwendet. Ein anderer Anwendungsfall liegt in der Landwirtschaft, mithilfe von Korrekturdaten wird die Positionsbestimmung ausreichend genau, um Traktoren im Feld eine exakt gerade Linie fahren zu lassen, damit der laufende landwirtschaftliche Prozess optimal ausgeführt werden kann.
|
||||||
|
|
||||||
|
\begin{table}[ht]
|
||||||
|
\centering
|
||||||
|
\begin{tabular}{|l|l|c|c|}
|
||||||
|
\hline
|
||||||
|
\textbf{Name} & \textbf{Betreiber} & \textbf{Verfügbar seit} & \textbf{Anzahl Satelliten} \\
|
||||||
|
\hline
|
||||||
|
NAVSTAR GPS & USA & 1995 & 24 \\
|
||||||
|
\hline
|
||||||
|
GLONASS & Russische Föderation & 1993 & 24 \\
|
||||||
|
\hline
|
||||||
|
Galileo & Europäische Union & 2020 & 28 \\
|
||||||
|
\hline
|
||||||
|
BeiDou & China & 2011 & 35 \\
|
||||||
|
\hline
|
||||||
|
\end{tabular}
|
||||||
|
\caption{Satelliten zur Positionsbestimmung \cite{Klein2023}}
|
||||||
|
\label{tab:sats}
|
||||||
|
\end{table}
|
||||||
|
|
||||||
|
\subsubsection{Allgemeine Funktionsweise}
|
||||||
|
Bauer \cite[S. 67ff]{Bauer2018} beschreibt, dass mindestens die Sicht auf vier Satelliten gegeben sein muss, um die eigene Position bestimmen zu können. Die Verbindung zwischen den Satelliten und dem Empfänger ist einseitig, deshalb stehen dem GNSS-Empfänger nur die Informationen zur Verfügung, die mit Signal übertragen werden können. Eine dieser Informationen ist die zwingend benötigte Position des Satelliten, welche aus den übermittelten Bahndaten errechnet wird.
|
||||||
|
\par
|
||||||
|
Die Position des GNSS-Nutzers wird durch die Berechnung der Signallaufzeiten von dem Satelliten zu dem Empfänger errechnet. Alle Satelliten senden in einem festgelegten und synchronisierten Intervall ihr Signal. Der Empfänger besitzt aufgrund der Systemarchitektur Informationen darüber, wie das Signal erzeugt wird und erzeugt intern ebenfalls ein Signal. Die Zeitdifferenz \(\Delta t_i\) wird für jedes ankommendes Signal zu dem erzeugten Signal gemessen. Durch die sehr präzisen Atomuhren in den Satelliten können diese bis auf einen Fehler im niedrigen Nanosekundenbereich dem Intervall einhalten, allerdings ist dies nicht für den Empfänger möglich, da weder eine ähnlich genaue Uhr zur Verfügung steht noch die vorhandene Uhr mit dem GNSS synchronisiert ist. Deshalb muss von dem gemessenen \(\Delta t_i\) die Uhrzeitdifferenz \(\Delta t\) zwischen dem Empfänger und dem GNSS subtrahiert werden. Für die Berechnung der Strecke wird außerdem die Ausbreitungsgeschwindigkeit \(v\) des Signals benötigt. Im Vakuum beträgt die Ausbreitungsgeschwindigkeit für die genutzten Mikrowellen annähernd Lichtgeschwindigkeit. Da es sich bei der Erdatmosphäre um kein Vakuum handelt und auch nicht um ein anderes konstantes Medium, muss die Ausbreitungsgeschwindigkeit ebenfalls ermittelt werden.
|
||||||
|
\par
|
||||||
|
Die Berechnung einer Position im Raum enthält die drei unbekannten für die X-, Y- und Z-Koordinate in einem kartesischen Koordinatensystem. Hinzu kommt die unbekannte Uhrzeitdifferenz \(\Delta t\). Daher ergibt sich die Mindestanforderung von vier sichtbaren Satelliten, um für jede der unbekannten Variablen eine Gleichung aufstellen zu können. Bauer gibt folgende \cite[Gleichung 1.24]{Bauer2018} zur Ortsbestimmung an:
|
||||||
|
|
||||||
|
\begin{eqnarray}
|
||||||
|
(\Delta T_i \cdot v + \Delta t \cdot v)^2 = (X_i - X_E)^2 + (Y_i - Y_E)^2 + (Z_i - Z_E)^2;i = 1,2,3,4
|
||||||
|
\end{eqnarray}
|
||||||
|
|
||||||
|
Dabei steht \({Koordinate_E}\) für die unbekannte Empfängerposition und \({Koordinate_i}\) für die bekannte Position des Satelliten. Auf die Ausbreitungsgeschwindigkeit \(v\) wird gleich noch eingegangen. Hergeleitet wurde die Formel aus dem räumlichen Pythagoras.
|
||||||
|
|
||||||
|
\subsubsection{Signallaufzeit}
|
||||||
|
Grundsätzlich breiten sich elektromagnetische Wellen jeder Frequenz im Vakuum mit der Lichtgeschwindigkeit \(c\) aus. Jedes Medium vermindert diese Geschwindigkeit. Die Geschwindigkeitsabnahme hängt von dem Medium ab. Im Kontext von GNSS handelt es sich bei den Medien um die Schichten der Erdatmosphäre. Von Bauer \cite[S. 116ff]{Bauer2018} wird erläutert, dass die Lichtgeschwindigkeit \(c\) mit dem Brechungsindex \(n\) des jeweiligen Mediums multipliziert werden muss, um die passende Geschwindigkeit bei den Berechnungen zu nutzen. Er definiert den Brechungsindex wie folgt:
|
||||||
|
|
||||||
|
\begin{eqnarray}
|
||||||
|
n = \frac{c}{v} = \frac{[Geschwindigkeit \: des \: Signals \: im \: Vakuum]}{[Geschwindigkeit \: des \: Signals \: im \: Medium]}
|
||||||
|
\end{eqnarray}
|
||||||
|
|
||||||
|
Für die Signallaufzeit wird zunächst der ionisierte Teil der Erdatmosphäre betrachtet. Die Änderung der Signallaufzeit wird auch Refraktion genannt. Die Ionosphäre beginnt ungefähr bei \(50km\) und endet bei \(1000km\) über der Erdoberfläche. Das Signal wird durch die freien Elektronen beeinflusst. Die Anzahl der freien Elektronen wird mit der Elektronendichte \(N_e\) angegeben, diese variiert nach Tages- und Jahreszeit, sowie nach verschieden Schichten in der Ionosphäre. In dem Kapitel \glqq{}Ionosphärische Refraktion\grqq{} \cite[S. 123f]{Bauer2018} zeigt Bauer die Herleitung für folgende Formel:
|
||||||
|
|
||||||
|
\begin{eqnarray}
|
||||||
|
n_{PH} = 1 - \frac{40,3 \cdot N_e}{f^2}
|
||||||
|
\label{eq:brechungsindexIonosphäre}
|
||||||
|
\end{eqnarray}
|
||||||
|
|
||||||
|
Diese Gleichung zeigt, dass der Brechungsindex für die Phasengeschwindigkeit von der Elektronendichte \(N_e\) und der Frequenz \(f\) des Senders bestimmt wird. Aufgrund der unstetigen Elektronendichte in der Ionosphäre gibt es etwa das \textbf{Klobuchar-Modell} \cite[128]{Bauer2018}, welches stetig an den Tag und die Sonnenaktivität angepasst und von den Satelliten an die Empfänger publiziert wird. Mit diesem Modell können \(50\%\) der ionosphärischen Laufzeitfehler korrigiert werden.
|
||||||
|
\par
|
||||||
|
Eine aufwendigere und genauere Alternative bietet die Zweifrequenzkorrektur, aufgrund der Abhängigkeit des Brechungsindexes von der Frequenz kann durch die Messung von zwei unterschiedlichen Frequenzen, im Fall von GNSS meist im L1 und L5 Band, auf die Refraktion in der Ionosphäre geschlossen werden.
|
||||||
|
\par
|
||||||
|
Sobald die Signale die Ionosphäre durchquert haben, treffen diese erst auf Stratosphäre und anschließend auf die Troposphäre, in welcher sich typischerweise der Empfänger befindet. In der Strato- und Troposphäre wird das Signal hauptsächlich durch die Zusammensetzung der Gase, dem Luftdruck und der Temperatur in diesen Schichten beeinflusst. Diese Zusammensetzung ist allerdings über den Planeten verteilt relativ homogen, weshalb dieser Fehler gut kalkuliert werden kann. In Troposphäre stellt die Luftfeuchtigkeit ein zusätzliches Hindernis für den Signallaufweg dar. Dieser Fehler ist Orts- und Zeitabhängig und deshalb schwerer zu modellieren. Es gibt mehrere Modelle zur Berechnung des aktuell wirkenden Einflusses, hier zu nennen wären das Modell von Hopfield und das Modell von Saastamoinen, wie von Bauer \cite[131]{Bauer2018} beschrieben.
|
||||||
|
|
||||||
|
\subsubsection{Andere Fehlerquellen}
|
||||||
|
In der folgenden List werden mögliche Fehlerquellen dargestellt, welche eine Positionsbestimmung behindern können:
|
||||||
|
|
||||||
|
\begin{itemize}
|
||||||
|
\item \textbf{Mehrwegeausbreitung} beschreibt den Umstand, dass die Antenne das Signal des Satelliten auf mindestens zwei Wegen empfängt. Der erste Weg ist der direkte vom Satelliten zu dem Empfänger, der so auch gewünscht ist. Die anderen Wege stammen von Reflexionen des Signals. Die unerwünschten Reflexionen können meist dadurch erkannte werden, dass die Dämpfung des Signals deutlich höher als die des direkt empfangenen Signals ist.
|
||||||
|
\item \textbf{Signalbeugung} beschreibt den Empfang eines Signals von einem Satelliten, welcher durch ein Hindernis abgeschattet ist. Das ist möglich, weil ein Signal, welches zum Beispiel auf eine Gebäudekante trifft, abgelenkt (gebeugt) wird. Wenn ein Satellit von dem Empfänger schon beobachtet wird, kann dieser Fehler erkannt werden, weil die Signaldämpfung unvorhergesehen zunimmt.
|
||||||
|
\item \textbf{Aktive Störung} können bei GNSS mit wenig Aufwand herbeigeführt werden. Bauer beschreibt \cite[169]{Bauer2018}, dass die Signalstärke von GNSS bei lediglich \(-160dBW\) liegt, was umgerechnet \(1 \cdot 10^{-16}W\) entspricht. Deshalb ist es möglich, mit geringen Sendeleistungen von wenigen \(W\) bereits Bereich mit mehreren \(10km\) zu stören.
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
\subsubsection{Aufbau}
|
||||||
|
Bauer beschreibt in dem Kapitel "Die Systemkomponenten" \cite[S. 201ff]{Bauer2018} von GNSS. Diese werden in drei Kategorien aufgeteilt:
|
||||||
|
|
||||||
|
\setlist{noitemsep}
|
||||||
|
\begin{itemize}
|
||||||
|
\item Weltraumsegment,
|
||||||
|
\item Bodensegment,
|
||||||
|
\item Nutzersegment.
|
||||||
|
\end{itemize}
|
||||||
|
\setlist{}
|
||||||
|
|
||||||
|
Das Weltraumsegment besteht aus den GNSS-Satelliten. Ein Empfänger an einem beliebigen Ort auf Erde muss immer 4 Satelliten sehen können, um eine Ortung durchführen zu können. Dementsprechend wurden die Satellitenumlaufbahnen von den verschiedenen Systembetreibern gewählt. Im Falle von GPS sind es 24 Satelliten, welche auf 6 Bahnebenen aufgeteilt sind. Ein Satellit wird über Sonnenpaddel mit Strom versorgt. In dem Satelliten befindet sich unter anderem die hochgenaue Atomuhr. An Hülle befindet sich eine Sendevorrichtung für das GNSS-Signal und eine Kommunikationsvorrichtung, um mit Bodensegment kommunizieren zu können. Viele Systeme sind in den Satelliten redundant ausgelegt, um die Lebenserwartung zu erhöhen, diese liegt bei moderne Satelliten bei 15 Jahren. Die Satelliten der unterschiedlichen Generationen und Systeme sehen unterschiedlich aus, als Beispiel siehe Abbildung \ref{fig:satellite}
|
||||||
|
|
||||||
|
|
||||||
|
\begin{figure}[ht]
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=\linewidth]{img/satellite.jpg}
|
||||||
|
\caption{Modell eines Satelliten von dem GNSS Galileo \protect\footnote[1]{This file comes from Science Museum Collections, a website operated by Science Museum Group, a non-departmental public body in the UK. This tag does not indicate the copyright status of the attached work. A normal copyright tag is still required. See Commons:Licensing. (\url{https://commons.wikimedia.org/wiki/File:Galileo_satellite_model.jpg}), \url{https://creativecommons.org/licenses/by/4.0/legalcode}}}
|
||||||
|
\label{fig:satellite}
|
||||||
|
\end{figure}
|
||||||
|
|
||||||
|
Das Bodensegment hat die Aufgabe, die Satelliten mit dem aktuellen Informationsstand zu versorgen, welche wiederrum über die Satelliten an die Nutzer weitergegeben werden. Für diese Aufgabe werden mehrere Stationen genutzt:
|
||||||
|
|
||||||
|
\begin{itemize}
|
||||||
|
\item \textbf{Überwachungsstationen} messen die Daten der GNSS-Satelliten und übermitteln diese an die Zentralstation.
|
||||||
|
\item In der \textbf{Zentralstation} werden die Daten verarbeitet. Aus diesen Daten werden die aktuellen Bahndaten mit einer Genauigkeit von 1 bis 2 m der einzelnen Satelliten bestimmt. Die Ergebnisse werden der Sendestation übergeben.
|
||||||
|
\item Die \textbf{Sendestationen} übermitteln die Ergebnisse an die Satelliten.
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
Das Nutzersegment wird durch die GNSS-Empfänger gebildet.
|
||||||
@@ -0,0 +1,67 @@
|
|||||||
|
\subsection{DGNSS}
|
||||||
|
Da die Genauigkeit von GNSS lediglich einige Meter beträgt, wurden Verfahren entwickelt, um die Positionsbestimmung zu optimieren. Ein Prinzip ist dabei das \textbf{Differenzielle}-GNSS, dabei gibt es immer eine ortsfeste Referenzstation oder ein Netz dieser und den GNSS-Empfänger im Feldeinsatz (Rover). Zusätzlich muss eine Verbindung zwischen diesen beiden Empfängern bestehen. Über diese Verbindung werden Code"=Beobachtungskorrekturen von der Referenzstation an den Rover übermittelt. Diese Korrekturen ermöglichen es den Fehler der Positionsbestimmung in Echtzeit auf bis zu \(1m\) zu reduzieren. \cite[vgl.][S. 248]{Bauer2018}
|
||||||
|
|
||||||
|
\subsubsection{RTK}
|
||||||
|
\label{sssec:rtkDescription}
|
||||||
|
\textbf{R}eal \textbf{T}ime \textbf{K}inematic bezeichnet ebenfalls eine DGNSS-Methode, im Gegensatz zu der zuvor beschriebenen sind mit RTK Echtzeitpositionierungen im einstelligen \(cm\)-Bereich möglich. Die zusätzlich gewonnene Genauigkeit kommt laut Bauer \cite[249]{Bauer2018} bei diesem Verfahren durch die Erhebung von Phasendaten zustande. Die Verwendung der Phasendaten ist aufwendiger als die Code-Daten, dafür aber auch genauer. Außerdem werden typischerweise Zweifrequenzen-Phasendaten erzeugt, damit schneller eine Mehrdeutigkeitslösung gefunden werden kann. Der Rover muss dementsprechend die gleichen Frequenzen empfangen können, um die Korrekturdaten anwenden zu können. Die Daten werden im Sekundentakt an den Rover übermittelt.
|
||||||
|
|
||||||
|
\subsubsection{SBAS durch EGNOS}
|
||||||
|
Die sogenannten \textbf{S}atellite \textbf{B}ased \textbf{A}ugmentation \textbf{S}ystem stellen Erweiterungen zu den GNSS Diensten dar, um insbesondere die Genauigkeit zu erhöhen. Ein großer Nutzeranteil wird durch die Luftfahrt gestellt, um Landungen zu vereinfachen.
|
||||||
|
\par
|
||||||
|
Bei SBAS handelt es sich um geostationäre Satelliten. Diese Art von Satelliten stehen für einen Beobachter auf der Erde fest am Horizont, daher kann mit dieser Art von Satelliten nur ein gewähltes Gebiet mit Informationen versorgt werden. Dadurch gibt es mehrere dieser Systeme, im Folgenden wird kurz das in Europa betriebene EGNOS (European Geostationary Navigation Overlay System) beschrieben.
|
||||||
|
\par
|
||||||
|
Mit Messstationen werden im Sekundentakt Rohdaten unterschiedlicher GNSS und die Entfernung zu den EGNOS Satelliten gesammelt. Die gesammelten Daten werden von mehreren Mission Control Center (MMC) verarbeitet, um daraus DGNSS-Nachrichten zu formulieren. Die Nachricht enthält unter anderem Korrekturen für die Satellitenuhren, Korrekturen der Umlaufbahnen und Werte zur Berechnung der ionosphärischen Einflüsse. Diese Nachricht wird dann die Satelliten weiter gegeben, welche diese dann wiederum über das L1-Band senden und damit GNSS-Empfängern in Reichweite zur Verfügung stellen. Mit Anwendung der verschickten Korrekturdaten kann eine Positionsbestimmung mit \(1m\) Genauigkeit erzielt werden. \cite[vgl.][S. 393ff]{Bauer2018}
|
||||||
|
|
||||||
|
\subsection{RINEX}
|
||||||
|
Das RINEX-Format ist aus der Notwendigkeit einer unabhängigen Möglichkeit des Datenaustausches zwischen GNSS-Modulen unterschiedlicher Hersteller entstanden. Das Format wurde nach seinen Anforderungen benannt und heißt daher ausgeschrieben \textbf{R}eceiver \textbf{IN}dependent \textbf{EX}change. Die erste Version des Formats wurde 1989 von Werner Gurtner veröffentlicht. Nach einigen weiteren Versionen, welche das Format unter anderem für weitere GNSS erweiterte, wird die Versionspflege inzwischen von der IGS und dem RTCM-SC104 übernommen.
|
||||||
|
\par
|
||||||
|
Das RINEX-Format bietet die Dateitypen für Beobachtungs- (*.obs), Navigations- (*.nav) und meteorologischen Daten (*.sbs) an. Für diese Arbeit werden für die Einmessung der Antenne lediglich die Beobachtungsdaten benötigt, welche mit einem Header für allgemeingültige Daten beginnt und danach unter anderem Daten zu den Messzeiten, Pseudostrecken, Trägerphasen, Signalrauschen und Dopplereffekt enthält. Die gesammelten Daten während der Einmessung können dann durch eine Post-Processing-Service (PPP) verarbeitet werden, dabei werden weitere Daten von Beobachtungsstationen verwendet, um eine möglichst genaue Position der Antenne errechnen zu können. \cite[vgl.][S. 107ff]{Ogaja}
|
||||||
|
|
||||||
|
\subsection{RTCM}
|
||||||
|
RTCM ist ein Standard zur Echtzeitübertragung von Daten zwischen GNSS-Empfängern. Dieses Format wurde zunächst 1985 von der namensgebenden Organisation \textbf{R}adio \textbf{T}echnical \textbf{C}ommission for \textbf{M}aritime Services veröffentlicht. Aktuell ist die Version 2.3 aus dem Jahr 2001 noch stark verbreitet, welche sich stark an der Nachrichtenstruktur von GPS orientiert. Mit jeder neuen Version wurden Möglichkeiten geschaffen, um weitere Daten übertragen zu können. Um das in Abschnitt \ref{sssec:rtkDescription} beschrieben RTK anwenden zu können, empfiehlt sich die Version 3 des Formats. Insbesondere die Version 3.2 und 3.3 eignen sich besonders gut, da ab diesen Versionen auch die neueren GNSS einbezogen werden können und diese Versionen Raum für Erweiterungen lassen. \cite[vgl.][S. 249ff]{Bauer2018}
|
||||||
|
\par
|
||||||
|
RTCM bietet noch weitere Funktionen wie eine Netzwerkkomponente, für diese Arbeit sind jedoch lediglich die Übertragungen der Code- und Phasenkorrekturen von Bedeutung, da die Übertragung der RTCM-Nachrichten mit dem Ntrip umgesetzt wird, siehe Abschnitt \ref{ssec:ntripDescription}. Nachfolgenden wird die Tabelle \ref{tab:rtcmMsg} dargestellt, welche die in dieser Arbeit Anwendung findenden Nachrichten Typen beschreibt. \cite[vgl.][S. 113f]{Ogaja}
|
||||||
|
|
||||||
|
\begin{table}[ht]
|
||||||
|
\centering
|
||||||
|
\begin{tabular}{|l|l|}
|
||||||
|
\hline
|
||||||
|
\textbf{RTCM 3 Msg-Nr.} & \textbf{Inhalt} \\ \hline
|
||||||
|
1005 & Koordinaten der Referenzstation \\ \hline
|
||||||
|
1074 & GPS MSM4 \\ \hline
|
||||||
|
1084 & GLONASS MSM4 \\ \hline
|
||||||
|
1094 & Galileo MSM4 \\ \hline
|
||||||
|
1124 & BeiDou MSM4 \\ \hline
|
||||||
|
1230 & GLONASS L1 und L2 Code-Phase Biases \\ \hline
|
||||||
|
\end{tabular}
|
||||||
|
\caption{Auszug von Ethernet Übertragungsstandards nach IEEE 802.3}
|
||||||
|
\label{tab:rtcmMsg}
|
||||||
|
\end{table}
|
||||||
|
|
||||||
|
MSM ist Akronym für Multiple Signal Messages und ist aufgeteilt in sieben Nachrichtentypen, wobei mit aufsteigender Nummer mehr Informationen übertragen werden. Die in Tabelle \ref{tab:rtcmMsg} bezeichnete MSM4 enthält die Pseudorange, Phaserange und CNR (Carrier to noise ratio). \cite[vgl.][114]{Ogaja}
|
||||||
|
|
||||||
|
\subsection{Ntrip}
|
||||||
|
\label{ssec:ntripDescription}
|
||||||
|
Ntrip wird ausgeschrieben zu \textbf{N}etworked \textbf{T}ransport of \textbf{R}TCM via \textbf{I}nternet \textbf{P}rotocol. Dieses Transferprotokoll wurde zunächst von dem Bundesamt für Kartografie und Geodäsie mithilfe der Technischen Universität Dortmund entwickelt. Es wird von der Ntrip Working Group of RTCM Special Committee 104 (SC104) standardisiert und weiterentwickelt. Seit 2009 ist die verbesserte und abwärtskompatible Version 2 standardisiert. \cite[vgl.][]{FACG}
|
||||||
|
\par
|
||||||
|
Damit das Protokoll möglichst gut unterstützt wird, orientiert es sich stark an dem HTTP (Hypertext Transfer Protokoll)in der Version 1.1. Im Nachfolgenden wird das übernommene Beispiel eines Verbindungsaufbaus gezeigt. \cite[siehe][2]{NTRIPWorkingGroup2023}
|
||||||
|
|
||||||
|
\begin{minted}{http}
|
||||||
|
GET /MountPtName HTTP/1.1<CR><LF>
|
||||||
|
Host: Acaster.com:2101<CR><LF>
|
||||||
|
Ntrip-Version: Ntrip/2.0<CR><LF>
|
||||||
|
User-Agent: NTRIP ProductName/Version<CR><LF>
|
||||||
|
<CR><LF>
|
||||||
|
\end{minted}
|
||||||
|
|
||||||
|
An diesem Beispiel ist die Ähnlichkeit zum HTTP sehr deutlich zu sehen, es werden bekannte HTTP-Methoden eingesetzt sowie gleiche Zeilen Abschlüsse genutzt.
|
||||||
|
\par
|
||||||
|
Das System basiert auf diesen drei Komponenten \cite[vgl.][S. 2-1]{FACG2004}:
|
||||||
|
|
||||||
|
\begin{itemize}
|
||||||
|
\item Ein \textbf{Ntrip-Caster} ist eine Serveranwendung, die einem Webserver ähnelt. Die Kommunikation wird immer von einem Client, ähnlich dem Beispiel, initialisiert. Für diese Arbeit wird der Service RTK2go als Caster genutzt, welcher in Abschnitt \ref{ssec:rtk2go} kurz beschrieben wird.
|
||||||
|
\item Der \textbf{Ntrip-Server} stellt die Daten als Client für den Ntrip-Caster zur Verfügung. Dieser wird auf der Basisstation mithilfe der RTKLib ausgeführt, siehe dafür Abschnitt \ref{sec:Basisstation} und \ref{sssec:rtklib}.
|
||||||
|
\item Der \textbf{Ntrip-Client} ist ein ebenfalls ein Client des Ntrip-Caster und bezieht die Korrekturdaten. Da die Korrekturdaten auf dem Rover benötigt werden, wird in Abschnitt \ref{ssec:ntripclient} die Implementierung eines Ntrip-Clients für den ESP32 beschrieben.
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
Wie auch das HTTP, verwendet das Ntrip Protokoll, TCP (Transmission Control Protocol) für die Verbindung zwischen den Komponenten.
|
||||||
@@ -0,0 +1,62 @@
|
|||||||
|
\subsection{WLAN}
|
||||||
|
\label{ssec:wlan-description}
|
||||||
|
Das Akronym WLAN wird ausgeschrieben zu \textbf{W}ireless \textbf{L}ocal \textbf{A}rea \textbf{N}etwork. Dabei handelt es sich um drahtlose lokal begrenzte Netzwerke, welche dafür vorgesehen sind, mobile Endgeräte direkt oder über eine Vermittlungsstelle, wie einem Router, miteinander oder anderen Netzwerken zu verbinden. Diese Art von Netzwerken werden am häufigsten durch den IEEE 802.11 Standard \cite{WLAN} realisiert.
|
||||||
|
\par
|
||||||
|
Der genannte Standard wurde erstmals 1997 veröffentlicht und wird seitdem immer wieder den aktuellen Anforderungen angepasst. Zunächst wurde die physikalische Ebene in dem \( 2,4 GHz\) Frequenzband definiert. In der ersten Erweiterung (IEEE 802.11a) von 1999 wurde das \(5GHz\) Band dem Standard hinzugefügt. In dem ersten Frequenzband können die Frequenzen \( 2,3995GHz - 2,4845GHz\) genutzt werden, dafür wird dieser Bereich in 13 sogenannten Kanäle aufgeteilt. Es werden Kanalbreiten von \(20MHz\) und \(40MHz\) genutzt. Das \(5GHz\) ist in zwei Frequenzbereiche aufgeteilt, zum einen von \(5,15GHz - 5,35GHZ\) und zum anderen von \(5,5GHz - 5,7GHz\), dabei werden die Kanäle von 36 bis 64 und von 100 bis 140 angeben. Die Kanalbreite kann zwischen \(20MHz\), \(40MHz\), \(80MHz\) und \(1600MHz\) variiert werden. Dabei ist zu beachten, dass die verschiedenen Kanalbreiten erst mit späteren Standards implementiert wurden.
|
||||||
|
\par
|
||||||
|
Die verschiedenen Korrekturen und Erweiterungen des Standards dienen im Allgemeinen dazu eines oder mehrere der folgenden Kriterien zu verbessern: Geschwindigkeit, Reichweite, Zuverlässigkeit und Effizienz. Die Fortsetzungen wurden beginnend mit dem Buchstaben 'a' begonnen, nachdem das Alphabet vollständig genutzt wurde, werden nun zwei Buchstaben genutzt. Es handelt sich dabei um ein Zahlensystem zur Basis 26. In der Tabelle \ref{tab:wlan} sind einige wichtigere oder bekanntere Erweiterungen des Standards aufgeführt.
|
||||||
|
|
||||||
|
\begin{table}[ht]
|
||||||
|
\centering
|
||||||
|
\begin{tabular}{|l|c|c|c|}
|
||||||
|
\hline
|
||||||
|
\textbf{Standard} & \multicolumn{1}{l|}{\textbf{Verabschiedung}} & \multicolumn{1}{l|}{\textbf{\begin{tabular}[c]{@{}l@{}}Frequenzband\\ {[}GHz{]}\end{tabular}}} & \multicolumn{1}{l|}{\textbf{\begin{tabular}[c]{@{}l@{}}max. brutto\\ Datenrate\end{tabular}}} \\ \hline
|
||||||
|
802.11a & 1999 & 2,4 \& 5 & \(54\frac{MBit}{s}\) \\ \hline
|
||||||
|
802.11b & 1999 & 2,4 & \(11\frac{MBit}{s}\) \\ \hline
|
||||||
|
802.11g & 2003 & 2,4 & \(54\frac{MBit}{s}\) \\ \hline
|
||||||
|
802.11n & 2009 & 2,4 \& 5 & \(600\frac{MBit}{s}\) \\ \hline
|
||||||
|
802.11ac & 2013 & 5 & \(3,4\frac{GBit}{s}\) \\ \hline
|
||||||
|
802.11ax & 2019 & 2,4 \& 5 & \(12\frac{GBit}{s}\) \\ \hline
|
||||||
|
802.11be & ausstehend & 2,4, 5 \& 6 & \(46\frac{GBit}{s}\) \\ \hline
|
||||||
|
\end{tabular}
|
||||||
|
\caption{Ausschnitt verschiedener IEEE 802.11 Standards}
|
||||||
|
\label{tab:wlan}
|
||||||
|
\end{table}
|
||||||
|
|
||||||
|
Die Folge von höheren Frequenzen und Bitraten ist eine nachlassende Reichweite. Daher bieten sich für Anwendungen, bei denen große Bereiche abgedeckt werden sollen, die Standards mit \(2,4 GHz\) oder welche die beiden Bänder koppeln, um dadurch die Reichweite und Geschwindigkeit zu erhöhen. Die Reichweite der Signale ist immer auch von den Interferenzen und den Hindernissen abhängig, daher können nur schwer Zahlen zu Reichweite angegeben werden.
|
||||||
|
|
||||||
|
Die Verbreitung von WLAN in das alltägliche private Leben begann mit dem 802.11b Standard, weil mehrere Hersteller begannen Geräte für einen moderaten Preis zu verkaufen und diese durch den Standard kompatibel zueinander sein müssen. Dadurch wurde es viel leichter, Laptops und andere mobile Gräte kabellos mit dem Netzwerk zu verbinden. Heute sind in fast jedem Gebäude WLAN-Netzwerke zu finden.
|
||||||
|
\par
|
||||||
|
Auch in der Industrie ist WLAN eine essenzielle Technik, zum Beispiel für automatisierte Lagersysteme mit mobilen Robotern.
|
||||||
|
|
||||||
|
\subsection{Ethernet}
|
||||||
|
Ethernet beschreibt nach dem Standard IEEE 802.3 \cite{Ethernet} verschiedene kabelgebundene Möglichkeiten \textbf{L}ocal \textbf{A}rea \textbf{N}etworks (LANs) aufzubauen. Diese Netzwerke werden typischerweise in Gebäuden eingesetzt, mit einer Sterntopologie. Bei der Installation wird hauptsächlich mehradriges Kupferkabel oder Glasfaserkabel genutzt. Das Kupferkabel wird auch Twisted-Pair-Kabel genannt und wird in verschiedene Kategorien eingeteilt, durch diese ist es möglich, die maximale Geschwindigkeit des Kabels abzulesen. Einige dieser Kategorien können in der Tabelle \ref{tab:ethernet} abgelesen werden.
|
||||||
|
\par
|
||||||
|
Glasfaserkabel werden nur in zwei Kategorien eingeteilt. Multimode-Glasfaserkabel werden oft in LANs benutzt, da sie sich eher für kürzere Distanzen eignen. Die Distanz wird durch die Brechung des Lichts und der Verwendung mehrerer Lichtmoden in dem Lichtleiter eingeschränkt. Die Reichweite ist der von Twisted-Pair-Kabeln trotzdem deutlich überlegen.
|
||||||
|
Aufgrund der höheren Fertigungskosten der Singlemode-Glasfaserkabel sind diese eher selten in LANs zu finden. Der Kerndurchmesser des Lichtleiters ist bei diesen Kabeln um ein Vielfaches geringer. Die Reduzierung von \(50\mu m\) bzw. \(62,5\mu m\) auf typischerweise \(8\mu m\) bis \(10\mu m\) und der ausschließlichen Übertragung einer Lichtmode ermöglicht nochmals längere Signalwege. Außerdem bietet die Glasfasertechnologie den Vorteil, unabhängig von elektromagnetischen Störungen zu sein.
|
||||||
|
\par
|
||||||
|
Die Tabelle \ref{tab:ethernet} zeigt einige Übertragungsstandards von Ethernet, dabei wurde unter anderem die Übertragungsmöglichkeiten über Koaxialkabel aus den Anfängen von Ethernet ausgelassen.
|
||||||
|
|
||||||
|
\begin{table}[ht]
|
||||||
|
\centering
|
||||||
|
\begin{tabular}{|l|c|c|r|}
|
||||||
|
\hline
|
||||||
|
\textbf{Standard} & \multicolumn{1}{l|}{\textbf{max. Geschwindigkeit}} & \multicolumn{1}{l|}{\textbf{Medium}} & \multicolumn{1}{l|}{\textbf{max. Segmentlänge}} \\ \hline
|
||||||
|
10BASE-T & \(10\frac{MBit}{s}\) & \begin{tabular}[c]{@{}c@{}}Twisted-Pair\\ min. Cat3\end{tabular} & 100 m \\ \hline
|
||||||
|
100BASE-TX & \(100\frac{MBit}{s}\) & \begin{tabular}[c]{@{}c@{}}Twisted-Pair\\ min. Cat5\end{tabular} & 100 m \\ \hline
|
||||||
|
1000BASE-T & \(1\frac{GBit}{s}\) & \begin{tabular}[c]{@{}c@{}}Twisted-Pair\\ min. Cat5e\end{tabular} & 100 m \\ \hline
|
||||||
|
1000BASE-SX & \(1\frac{GBit}{s}\) & \begin{tabular}[c]{@{}c@{}}Glasfaser\\ Multimode\end{tabular} & 550 m \\ \hline
|
||||||
|
1000BASE-LX & \(1\frac{GBit}{s}\) & \begin{tabular}[c]{@{}c@{}}Glasfaser\\ Singlemode\end{tabular} & 5 km \\ \hline
|
||||||
|
10GBASE-T & \(10\frac{GBit}{s}\) & \begin{tabular}[c]{@{}c@{}}Twisted-Pair\\ min. Cat6\end{tabular} & \begin{tabular}[c]{@{}r@{}}55 m\\ 100 m mit Cat6a\end{tabular} \\ \hline
|
||||||
|
10GBASE-SR & \(10\frac{GBit}{s}\) & \begin{tabular}[c]{@{}c@{}}Glasfaser\\ Multimode\end{tabular} & 400 m \\ \hline
|
||||||
|
10GBASE-LR & \(10\frac{GBit}{s}\) & \begin{tabular}[c]{@{}c@{}}Glasfaser\\ Singlemode\end{tabular} & 10 km \\ \hline
|
||||||
|
\end{tabular}
|
||||||
|
\caption{Auszug von Ethernet Übertragungsstandards nach IEEE 802.3}
|
||||||
|
\label{tab:ethernet}
|
||||||
|
\end{table}
|
||||||
|
|
||||||
|
\subsubsection{PoE}
|
||||||
|
\label{sssec:PoE}
|
||||||
|
PoE ist die Abkürzung für \textbf{P}ower \textbf{o}ver \textbf{E}thernet und meint damit, die Funktion, neben den Daten zusätzlich die Stromversorgung für kleinere Netzwerkgeräte über ein Twisted-Pair-Kabel zu ermöglichen. PoE wird ebenfalls im IEEE 802.3 \cite{Ethernet} Standard definiert. Eingeführt wurde PoE 2003 in IEEE 802.3af mit einer Leistung von 15 Watt. Seitdem wurde PoE erweitert, um mehr Leistung bieten zu können. Dies geschah mit den Standards 802.3at und 802.3bt. Die erste Erweiterung wird auch als PoE+ bezeichnet und kann 30 Watt je Port zur Verfügung stellen. Der aktuelle Stand wird auch PoE++ genannt. Bei der Verwendung von PoE++ wird zwischen dem Typ 3 und 4 unterschieden, da Typ 3 60 Watt leisten kann und Typ 4 100 Watt. Die Spannungen auf dem Ethernetkabel liegen bei PoE zwischen 44 und 57 Volt.
|
||||||
|
\par
|
||||||
|
PoE wird unter anderem oft für Telefone, Kameras und Accesspoints eingesetzt.
|
||||||
@@ -0,0 +1,20 @@
|
|||||||
|
\section{Hardware}
|
||||||
|
In diesem Abschnitt wird zunächst die allgemeine Funktionalität von GNSS-Hardware allgemein und speziell der aktuell auf dem Rover verbauten erklärt. Darauf folgt die Funktionsbeschreibung von PoE-Hardware, die zur späteren Anbindung der RTK-Basisstation benötigt wird. In dem Abschnitt \ref{sec:PoE-Hardware} wird auf die konkret verwendete PoE-Hardware eingegangen, während Abschnitt \ref{sec:GNSS-Hardware} die Auswahl der GNSS-Hardware für die Basisstation beschreibt.
|
||||||
|
\subsection{GNSS-Modul}
|
||||||
|
Auf dem Markt sind eine Vielzahl von GNSS-Modulen erhältlich. Dessen allgemeine Aufgabe es immer ist, die Position auf der Erde durch die über eine Antenne empfangen Signale zu bestimmen. Die erhältlichen Module unterscheiden sich hauptsächlich in der Genauigkeit und der verfügbaren Features. Die günstigsten Module bieten keine Möglichkeit, die Rohdaten auszugeben oder Korrekturdaten einzuspeisen, weshalb sich weder extern und noch intern Fehlerkorrekturen anwenden lassen und somit die Genauigkeit auf 10 Meter begrenzt ist. Bei professionelleren Modulen ist beides möglich, wodurch sich Positionsbestimmungen im niedrigen Zentimeterbereich realisieren lassen.
|
||||||
|
\par
|
||||||
|
In dem Rover ist ein GNSS-Chip von u-blox auf einem Entwicklungsmodul von Sparkfun verbaut. Der Chip wird unter dem Namen ZED-F9K-00B vermarktet. Dem Datenblatt des Herstellers \cite{zed-f9k} sind folgende Informationen zu entnehmen. Das Modul unterstützt die Bänder L1/L2/E5b, damit können die Daten von den Systemen BeiDou, Galileo, GLONASS und GPS verarbeitet werden. Unter normalen Bedingungen ist die Position bei einem Kaltstart nach spätestens 30 Sekunden ermittelt und bei einem Warmstart nach 2 Sekunden. In dieses Modul können Korrekturdaten eingespeist werden, allerdings ist es nicht in der Lage diese zu erzeugen. Im RTK-Modus ist die Genauigkeit mit 0,2 Meter angegeben.
|
||||||
|
|
||||||
|
\subsection{GNSS-Antenne}
|
||||||
|
Die Antennen von GNSS-Modulen können extern ausgeführt werden oder direkt am Modul verbaut sein und dienen dazu, die Signale der Satelliten zu empfangen. Dabei bieten externe Antennen den Vorteil, unabhängig und für den Empfang optimiert aufgestellt/verbaut werden zu können. Für externe Antenne steht häufig mehr Platz zur Verfügung, deshalb wird Empfangsqualität nicht durch mangelnden Bauraum beeinflusst.
|
||||||
|
\par
|
||||||
|
Die auf dem Rover extern installierte Antenne wurde wie das GNSS-Modul ebenfalls von u-blox entwickelt und auf die F9-Reihe abgestimmt. Dabei handelt es sich laut Datenblatt \cite{antenneKlein} um eine aktive Antenne, welche die Bänder des GNSS-Moduls unterstützt und darüber hinaus noch die Bänder B2a und NavIC. Das Gehäuse der Antenne misst 60 mm x 82 mm, wobei die Position der eigentlichen im Gehäuse zentriert ist. Angeschlossen wird die Antenne über einen SMA-Stecker.
|
||||||
|
|
||||||
|
\subsection{PoE Hardware}
|
||||||
|
\subsubsection{PoE Extender}
|
||||||
|
Ein PoE Extender wird dafür genutzt, die Reichweite eines mit PoE versehenen Twisted-Pair-Kabel zu verlängern. Die Reichweite wird durch die begrenzte Segmentlänge des verwendeten Mediums beschränkt. Im Fall von Twisted-Pair-Kabeln beträgt diese \(100m\). Der Extender nutzt die über PoE verfügbare Energie zur Signalaufbereitung und gibt das Signal inklusive PoE wieder aus, dabei ist zu beachten, dass aufgrund der verbrauchten Energie das ausgangsseitige PoE um einen Typen verringert wird und somit weniger Leistung zur Verfügung stellt.
|
||||||
|
\par
|
||||||
|
Speziellere Extender können zusätzlich als Switch fungieren. Diese Extender verfügen typischerweise über zwei Ethernet Ausgänge. Die verfügbare PoE Leistung wird dann auf diese beiden Ports aufgeteilt. \cite{poeextender}
|
||||||
|
|
||||||
|
\subsubsection{PoE Splitter}
|
||||||
|
Der PoE Splitter trennt die Daten und den Strom vom Ethernetkabel. Diese Geräte haben typischerweise drei Anschlüsse, dabei ist der erste der PoE Eingang. Bei den anderen beiden handelt es sich um die Ausgänge für die Daten und den Strom. Bei dem Anschluss für die Daten ohne Strom handelt es sich normalerweise wieder um eine RJ-45 Buchse für den Anschluss des Ethernetkabels. Der Strom wird über Anschlussklemmen oder einem Terminalblock ausgegeben. Die ausgegebene Spannung hängt von dem gewählten Splitter ab, wird aber meistens von der höheren PoE Spannung (siehe Unterabschnitt \ref{sssec:PoE}) auf typische Spannungen von Netzteilen wie \(12V\) reduziert. \cite[]{poesplitter}
|
||||||
@@ -0,0 +1,59 @@
|
|||||||
|
\section{Software}
|
||||||
|
Im Folgenden wird die benötigte Software für diese Arbeit beschrieben. Dabei wird zunächst das Betriebssystem der Basisstation beschrieben, gefolgt von der verwendeten Software mit spezifischem Bezug auf die GNSS-Thematik.
|
||||||
|
\subsection{Debian}
|
||||||
|
\label{ssec:debian}
|
||||||
|
Als Betriebssystem wird das freie Debian ohne grafische Oberfläche verwendet. Debian ist eine GNU/Linux-Distribution, welche bereits seit 1993 entwickelt und weiterentwickelt und als Basis für viele weitere sehr erfolgreichen und bekannten Betriebssystemen wie Ubuntu verwendet wird. Daher kann Debian als ein stabiles und hartes Betriebssystem angesehen werden, welches auch in der Industrie für viele Server eingesetzt und bei Cloud-Services als Betriebssystem für virtuelle Maschinen angeboten wird.
|
||||||
|
|
||||||
|
\subsubsection{Systemd}
|
||||||
|
Systemd wird von dem Wiki Ubuntuusers \cite{systemd} als ein Teil des Betriebssystems, welcher für die Verwaltung und das Starten der Dienste des Systems zuständig ist, da alle Prozesse während des Bootvorgangs von Systemd gestartet werden, erhält Systemd immer die Prozess-ID 1.
|
||||||
|
\par
|
||||||
|
Die Konfiguration erfolgt über eine Datei für jeden Service, in welcher unter anderem folgende Einstellungen getätigt werden können:
|
||||||
|
|
||||||
|
\begin{itemize}
|
||||||
|
\item eine Kurzbeschreibung des Service,
|
||||||
|
\item eine Bedingung für den Start,
|
||||||
|
\item die Art des Service,
|
||||||
|
\item das als Service auszuführende Programm
|
||||||
|
\item und den Betriebsmodus des Betriebssystems.
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
Durch dieses System wird es ermöglicht, dem Betriebssystem mit geringem Entwicklungsaufwand weitere Services hinzuzufügen, was in dieser Arbeit für Installation der Basisstation von Vorteil ist.
|
||||||
|
|
||||||
|
\subsection{ser2net}
|
||||||
|
Die auf GitHub und über die Paketquellen von Debian veröffentliche Software ser2net \cite{ser2net} wird dem Betriebssystem bei Installation als Service hinzugefügt. Mit diesem Service können unter anderem verfügbare Geräte, mit einem seriellen Interface, dem Netzwerk über eine TCP-Verbindung zugänglich gemacht werden. Dafür müssen die Interfaces inklusive der verwendeten Einstellungen wie, die Baudrate in der Konfigurationsdatei unter dem Pfad \url{/etc/ser2net/ser2net.yaml} definiert werden.
|
||||||
|
\par
|
||||||
|
Dadurch ist es möglich, das GNSS-Modul der Basisstation, der U-Blox Software (siehe Abschnitt \ref{sssec:u-blox}) auf einem im Netzwerk erreichbaren Computer mit Windows als Betriebssystem zur Verfügung zu stellen.
|
||||||
|
|
||||||
|
\subsection{com0com und com2tcp}
|
||||||
|
Diese beiden Programme bilden das Gegenstück zu ser2net auf einem Computer mit Windows als Betriebssystem. Dabei stellt das Programm den Treiber für virtuelle COM-Ports zur Verfügung und ermöglicht es mehrere dieser virtuellen Ports miteinander zu verbinden. Dies ist nötig, weil nur ein Programm zurzeit auf einen COM-Port zugreifen kann. Durch die Brücke von zwei virtuellen COM-Ports kann ein Port von der U-Blox Software genutzt werden.
|
||||||
|
\par
|
||||||
|
Der andere Port wird von dem zweiten Programm (com2tcp) genutzt, um die Verbindung zu ser2net herzustellen. Dafür muss die IP-Adresse des Servers und der Port, auf dem das Interface veröffentlicht wurde, bekannt sein.
|
||||||
|
|
||||||
|
\subsection{GNSS}
|
||||||
|
Dieser Abschnitt beschreibt Programme, die direkt mit GNSS-Modul interagieren oder dessen Daten verarbeiten.
|
||||||
|
|
||||||
|
\subsubsection{GNSS PostProcessing}
|
||||||
|
Für die Errichtung einer Basisstation muss die Position der Antenne möglichst exakt bestimmt werden. Die exakteste Möglichkeit bieten dafür sogenannte PostProcessing Dienste. Um diese nutzen zu können, muss der Receiver zunächst die Beobachtungsdaten erstellen und diese im Anschluss im RINEX-Format an der PostProcessing Dienst senden.
|
||||||
|
\par
|
||||||
|
Für die Einmessung der zu errichtenden Basisstation wird in dieser Arbeit der kostenlose Service \texttt{Canadian Spatial Reference System Precise Point Positioning} (CSRS-PPP) \cite{canada} genutzt. Zur Berechnung nutzt dieser globale Bahn- und Uhrendaten der Satelliten. Nachdem die Beobachtungsdaten übersendet wurde, wird nach ein paar Stunden, das Ergebnis per E-Mail übersandt. Neben den berechneten Koordinaten mit Angaben zur Genauigkeit werden, Graphen der beobachteten Satelliten dargestellt. Durch diese Graphen kann kontrolliert werden, ob die Antenne freie Sicht auf den Himmel hatte.
|
||||||
|
|
||||||
|
\subsubsection{RTKLib}
|
||||||
|
\label{sssec:rtklib}
|
||||||
|
Die RTKLib \cite{rtklib} ist eine Sammlung von Open-Source-Programmen für GNSS Positionierung. Für Windows gibt es die Programme fertig compiliert und mit einer grafischen Oberfläche, zur Nutzung unter Linux muss der Quellcode eigenständig compiliert werden. Die Hälfte der Programme verfügt über eine CLI und ist somit ohne grafische Benutzeroberfläche nutzbar. Aus dieser Sammlung sind für diese Arbeit zwei der Programme von Bedeutung, welche auch beide über eine CLI verfügen.
|
||||||
|
|
||||||
|
\begin{itemize}
|
||||||
|
\item \textbf{Communication Server} - Für die Verwendung können mehrere Ein- und Ausgänge konfiguriert werden. Die Eingänge werden zusammengeführt und an alles Ausgänge weitergeleitet. Der Eingang ist in dem Kontext dieser Arbeit immer das GNSS-Modul und der Ausgang ist entweder ein Ntrip-Caster oder eine Datei. Die Ausgabe in der Daten in eine Datei ermöglicht es, die Beobachtungsdaten zu persistieren.
|
||||||
|
\item \textbf{RINEX Konverter} - Mit diesem Konverter können die Beobachtungsdaten, welche im proprietären Format von U-Blox vorliegen, in das RINEX-Format konvertiert werden.
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
\subsubsection{U-center}
|
||||||
|
\label{sssec:u-blox}
|
||||||
|
Das U-center \cite{u-center} ist laut dem Hersteller u-blox eine GNSS Evaluierungssoftware für Windows.
|
||||||
|
\par
|
||||||
|
Mit dieser lassen sich die Module von u-blox konfigurieren und die eingehenden Daten der Satelliten und des Moduls analysieren und loggen. Besonders die grafische Möglichkeit der Konfiguration erleichtert den Umgang mit diesen Modulen. Für die Evaluation lassen sich Graphen über verschiedene Informationen wie der Drift der Position, die Laufbahn der Satelliten, die Anzahl der Satelliten mit Signalpegel und weitere Werte anzeigen.
|
||||||
|
\par
|
||||||
|
Das Programm bietet zusätzlich Tools an, um als Ntrip-Client zu fungieren oder Daten mittels MQTT zu versenden.
|
||||||
|
|
||||||
|
\subsubsection{RTK2go}
|
||||||
|
\label{ssec:rtk2go}
|
||||||
|
RTK2go \cite{rtk2go} ist kostenlos nutzbarer Ntrip-Caster. Damit eine Basisstation sich mit RTK2go verbinden kann, muss diese zunächst registriert werden, damit eine Mount Point erstellt werden kann. Anschließend können Korrekturdaten über den Caster veröffentlicht werden, dabei kann jeder auf die veröffentlichten Daten zugreifen. Als Client zur Datennutzung muss lediglich als Benutzername eine valide E-Mail-Adresse hinterlegt werden, die ausschließlich als Kanal für Fehlermeldungen mit der Verbindung genutzt wird. Eine Registrierung als Rover ist daher nicht notwendig.
|
||||||
@@ -1,328 +0,0 @@
|
|||||||
\chapter{Grundlagen}
|
|
||||||
Dieses Kapitel startet mit der Beschreibung des vorhandenen Fahrzeugs, dem Rover, anhand der darüber verfassten Projektarbeit. Dabei ist die Systemarchitektur und die vorhandene Schnittstellen von besonderer Relevanz, da diese genutzt werden müssen, um die nötigen Implementierungen für diese Arbeit ausführen zu können. Im weiteren Verlauf des Kapitels werden die notwendigen Protokolle erläutert. In diesem Abschnitt wird besonderes auf die Erläuterung der Funktionsweise von GNSS und den Möglichkeiten für Korrekturen der Positionsdaten eingegangen. Darauf folgt eine Beschreibung der Funktionen von Hardwarekomponenten. Geschlossen wird das Kapitel mit der Erläuterung von benötigter und verwendeter Software.
|
|
||||||
|
|
||||||
\section{Rover}
|
|
||||||
\label{sec:rover}
|
|
||||||
Dieser Abschnitt beschreibt das in der zugrundeliegenden Projektarbeit \cite{Klein2023} erstellte Gesamtsystems des Rovers für diese Arbeit.
|
|
||||||
\par
|
|
||||||
Der Rover wird durch einen 3-Zellen Lithium-Ionen-Akkumulator mit Strom versorgt, dabei wird der Motortreiber und somit auch die beiden Motoren für den Skid-Antrieb mit der anliegenden Spannung des Akkus von nominal \(11,1V\) versorgt. Der Akkumulator und der Motortreiber befinden sich nebeneinander auf der Unterseite des Hauptträgers der Komponenten, auf dem Bild \ref{fig:rover} das blaue Plastik. Je einer der beiden Motoren treibt eine der Fahrzeugseiten an, diese bestehen aus jeweils drei Rädern welche alle über einen Riemen mit der Ausgangswelle des Getriebes zur Untersetzung verbunden sind. An der dieser Ausgangswelle befindet sich ein Encoder-Rad welches durch eine einfache Gabellichtschranke ausgelesen wird, dafür wird der in Hardware implementierte Pulsecounter des verbauten Prozessors verwendet.
|
|
||||||
\par
|
|
||||||
Die restlichen Komponenten werden mit \(5V\) versorgt, die \(5V\) werden über einen Spannungsregler mit einem maximalen dauerhaften Ausgangsstrom von \(1A\) bereitgestellt. Der Spannungsregler befindet sich auf der Hauptplatine, welche wiederrum auf der oberseite des Hauptträgers zentral verbaut ist. Diese Platine verbindet alle Komponenten mit dem auf einem aufgesteckten Entwicklungsboard verbauten ESP32 Prozessor. Der ESP32 stellt verschiedene Schnittstellen über die GPIO (General Purpose Input Output) Pins zur Verfügung, davon werden für den Rover die Bussysteme I2C und SPI, ein ADC Kanal (Analog Digital Converter) und PWM (Pulsweitenmodulation) genutzt. Weitere Kommunikation findet auf dem drahtlosen Weg statt, dafür wird das WiFi-Modul genutzt, mit diesem kann eine Verbindung zum einem \(2,4GHz\) WLAN aufgebaut werden und es wird mit dem Protokoll ESPNow über das selbe Frequenzband eine Verbindung zu der Fernbedienung hergestellt. Zur Verwaltung des Funkmoduls und der Bewältigung anderen Aufgaben, welche an den Prozessor gestellt werden, verfügt dieser über zwei Xtensa 32bit LX6 Kerne, welche mit bis zu \(240MHz\) takten. Als SRAM stehen 540 KB bereit und der Flash-Speicher für die Software ist 4 Megabyte groß.
|
|
||||||
\par
|
|
||||||
Mit auf der Hauptplatine befindet sich das ebenfalls aufgesteckte Entwicklungsboard von Sparkfun. Das Board nutzt den SPI-Bus um die Kommunikation zwischen dem ESP32 und dem ZED-F9K herzustellen. Bei dem ZED-F9K handelt es sich um einen hochpräziser multi-band GNSS Receiver, welcher die Signale von allen öffentlichen Satelliten gestützten Navigationssystemen verarbeiten kann. Zusätzlich können Korrekturdaten verarbeitet werden mit welchen die Genauigkeit der Positionsbestimmung auf den Bereich einstelliger Centimeter erhöht wird. Auf der Platine befindet sich eine SMA-Buchse mit welcher die GNSS-Antenne verbunden ist. Die Antenne befindet sich am Heck des Rovers auf dem grünen T-Träger.
|
|
||||||
\par
|
|
||||||
Der I2C-Bus wird benutzt um den letzten Sensor und ein Display anzubinden. Bei dem Sensor handelt es sich um einen Kompass, welcher möglichst weit entfernt von anderen Komponenten sein sollte und deshalb auf dem Mast der neben dem Display nach oben ragt montiert ist und die aktuelle Himmelsrichtung bei richtiger Kalibrierung auf \(2^{\circ}\) genau angeben kann. Bei dem Display auf dem Querbalken handelt es sich um ein 16 x 2 Zeichen LCD, dieses wird von einem I2C-Seriell Adapterinterface betrieben.
|
|
||||||
\par
|
|
||||||
Zu dem Rover gehört eine Fernbedienung, welche über sieben Tasten und einem Joystick als Eingabemöglichkeit verfügt. Vier Tasten bilden ein Steuerkreuz, um das navigieren im Menü zu ermöglichen. Zwei Weitere Tasten werden zum bestätigen und ablehnen genutzt. Die letzte Taste wird als Action-Button bezeichnet und wird betätigt, wenn der Joystick gedrückt wird. Die Taste ist für spezielle Aktionen der verschiedenen Betriebsmodi des Rovers vorgesehen. An der Fernbedienung wurde ebenfalls das zuvor genannte LCD verbaut, dieses spiegelt das Display am Rover. Die Fernbedienung wird ebenfalls von einem ESP32 gesteuert, dieser stellt die Kommunikation über das genannte ESPNow Protokoll zu dem Rover her. Um die Fernbedienung mit Energie zu versorgen wird eine Powerbank benötigt an der das heraushängende USB-Kabel vom Typ A angeschlossen werden kann.
|
|
||||||
\par
|
|
||||||
Die vorhandene Software für den Rover ist Objektorientiert und Modular aufgebaut. Zusätzlich ist der Programmcode für die Benutzeroberfläche von dem restlichen Code getrennt. Die Struktur des Codes wird wesentlich durch zwei Interfaces bestimmt. Das erste wird als 'Component' bezeichnet und muss implementiert werden um eigenständige wiederkehrende Aufgaben zu implementieren. Das zweite Interface mit dem Namen 'DriveModi' definiert welche Mindestanforderungen an einen Betriebsmodus des Rovers gestellt werden und stellt die Komponenten für die Benutzereingaben, die Sensorverwaltung und die Bewegungsreglung zur Nutzung im Betriebsmodus bereit. Andere Komponenten überwachen den Akku, steuern das Display, verwalten die Benutzeroberfläche, überwachen Benutzereingaben oder verarbeiten Sensordaten.
|
|
||||||
|
|
||||||
\section{Protokolle}
|
|
||||||
Dieser Abschnitt beschreibt die verschiedenen Protokolle, welche von unterschiedlichen Teilsystemen genutzt werden um die Funktionalität des Gesamtsystems zu ermöglichen.
|
|
||||||
|
|
||||||
\subsection{GNSS}
|
|
||||||
GNSS ist das Akronym für \textbf{G}lobal \textbf{N}avigation \textbf{S}atellite \textbf{S}ystem. Inzwischen gibt es mehrere dieser Systeme deren Hauptzweck die Positionsbestimmung auf dem gesamten Globus und auch darüber ist. In der Tabelle \ref{tab:sats} sind diese aufgelistet. Die Positionsbestimmung wird unter anderem für die Navigation in allen Bereichen, zur Vermessung und Zeitmessung verwendet. Ein anderer Anwendungsfall liegt in der Landwirtschaft, mit Hilfe von Korrekturdaten wird die Positionsbestimmung ausreichend genau, um Traktoren im Feld eine exakt gerade Linie fahren zu lassen, damit der laufende landwirtschaftliche Prozess optimal ausgeführt werden kann.
|
|
||||||
|
|
||||||
\begin{table}[ht]
|
|
||||||
\centering
|
|
||||||
\begin{tabular}{|l|l|c|c|}
|
|
||||||
\hline
|
|
||||||
\textbf{Name} & \textbf{Betreiber} & \textbf{Verfügbar seit} & \textbf{Anzahl Satelliten} \\
|
|
||||||
\hline
|
|
||||||
NAVSTAR GPS & USA & 1995 & 24 \\
|
|
||||||
\hline
|
|
||||||
GLONASS & Russische Föderation & 1993 & 24 \\
|
|
||||||
\hline
|
|
||||||
Galileo & Europäische Union & 2020 & 28 \\
|
|
||||||
\hline
|
|
||||||
Beidou & China & 2011 & 35 \\
|
|
||||||
\hline
|
|
||||||
\end{tabular}
|
|
||||||
\caption{Satelliten zur Positionsbestimmung \cite{Klein2023}}
|
|
||||||
\label{tab:sats}
|
|
||||||
\end{table}
|
|
||||||
|
|
||||||
\subsubsection{Allgemeine Funktionsweise}
|
|
||||||
Bauer \cite[S. 67ff]{Bauer2018} beschreibt, dass mindestens die Sicht auf vier Satelliten gegeben sein muss um die eigene Position bestimmen zu können Die Verbindung zwischen den Satelliten und dem Empfänger ist einseitig, deshalb stehen dem GNSS-Empfänger nur die Informationen zur Verfügung die mit Signal übertragen werden können. Eine dieser Informationen ist die zwingend benötigte Position des Satelliten, welche aus den übermittelten Bahndaten errechnet wird.
|
|
||||||
\par
|
|
||||||
Die Position des GNSS-Nutzers wird durch die Berechnung der Signallaufzeiten von dem Satelliten zu dem Empfänger errechnet. Alle Satelliten senden in einem festgelegten und synchronisierten Interval ihr Signal. Der Empfänger besitzt aufgrund der Systemarchitektur Informationen darüber wie das Signal erzeugt wird und erzeugt intern ebenfalls ein Signal. Die Zeitdifferenz \(\Delta t_i\) wird für jedes ankommendes Signal zu dem erzeugten Signal gemessen. Durch die sehr präzisen Atomuhren in den Satelliten können diese bis auf einen Fehler im niedrigen Nanosekundenbereich den Interval einhalten, allerdings ist dies nicht für den Empfänger möglich, da weder eine ähnlich genaue Uhr zur Verfügung steht noch die vorhandene Uhr mit dem GNSS synchronisiert ist. Deshalb muss von dem gemessenen \(\Delta t_i\) die Uhrzeitdifferenz \(\Delta t\) zwischen dem Empfängers und dem GNSS subtrahiert werden. Für die Berechnung der Strecke wird außerdem die Ausbreitungsgeschwindigkeit \(v\) des Signals benötigt. Im Vakuum beträgt die Ausbreitungsgeschwindigkeit für die genutzten Mikrowellen annähernd Lichtgeschwindigkeit. !!!Nochmal lesen ob das so ist mit v = c!!! Da es sich bei der Erdatmosphäre um keine Vakuum handelt und auch nicht um ein anderes konstantes Medium, muss die Ausbreitungsgeschwindigkeit ebenfalls ermittelt werden.
|
|
||||||
\par
|
|
||||||
Die Berechnung einer Position im Raum enthält die drei unbekannten für die X-, Y- und Z-Koordinate in einem kartesischen Koordinatensystem. Hinzu kommt die unbekannte Uhrzeitdifferenz \(\Delta t\). Daher ergibt sich die Mindestanforderung von vier Sichtbaren Satelliten, um für jede der unbekannten Variablen eine Gleichung aufstellen zu können. Bauer gibt folgende \cite[Gleichung 1.24]{Bauer2018} zur Ortsbestimmung an: !!!Formel verstehen!!!
|
|
||||||
|
|
||||||
\begin{eqnarray}
|
|
||||||
(\Delta T_i \cdot v + \Delta t \cdot v)^2 = (X_i - X_E)^2 + (Y_i - Y_E)^2 + (Z_i - Z_E)^2;i = 1,2,3,4
|
|
||||||
\end{eqnarray}
|
|
||||||
|
|
||||||
Dabei steht \({Koordinate_E}\) für die unbekannte Empfänger Position und \({Koordinate_i}\) für die bekannte Position des Satelliten. Auf die Ausbreitungsgeschwindigkeit \(v\) wird gleich noch eingegangen. Hergeleitet wurde die Formel aus dem räumlichen Pythagoras.
|
|
||||||
|
|
||||||
\subsubsection{Signallaufzeit}
|
|
||||||
Grundsätzlich breiten sich elektromagnetische Wellen jeder Frequenz im Vakuum mit der Lichtgeschwindigkeit \(c\) aus. Jedes Medium vermindert diese Geschwindigkeit. Die Geschwindigkeitsabnahme hängt von dem Medium ab. Im Kontext von GNSS handelt es sich bei den Medien um die Schichten der Erdatmosphäre. Von Bauer \cite[S. 116ff]{Bauer2018} wird erläutert, dass die Lichtgeschwindigkeit \(c\) mit dem Brechungsindex \(n\) des jeweiligen Mediums multipliziert werden muss um die passende Geschwindigkeit bei den Berechnungen zu nutzen. Er definiert den Brechungsindex wie folgt:
|
|
||||||
|
|
||||||
\begin{eqnarray}
|
|
||||||
n = \frac{c}{v} = \frac{[Geschwindigkeit \: des \: Signals \: im \: Vakuum]}{[Geschwindigkeit \: des \: Signals \: im \: Medium]}
|
|
||||||
\end{eqnarray}
|
|
||||||
|
|
||||||
Für die Signallaufzeit wird zunächst der ionisierte Teil der Erdatmosphäre betrachtet. Die Änderung der Signallaufzeit wird auch Refraktion genannt. Die Ionosphäre beginnt ungefähr bei \(50km\) und endet bei \(1000km\) über der Erdoberfläche. Das Signal wird durch die freie Elektronen beeinflusst. Die Anzahl der freien Elektronen wird mit der Elektronendichte \(N_e\) angegeben, diese variiert nach Tages- und Jahreszeit, sowie nach verschieden Schichten in der Ionosphäre. In dem Kapitel \glqq{}Ionosphärische Refraktion\grqq{} \cite[S. 123f]{Bauer2018} zeigt Bauer die Herleitung für folgende Formel:
|
|
||||||
|
|
||||||
\begin{eqnarray}
|
|
||||||
n_{PH} = 1 - \frac{40,3 \cdot N_e}{f^2}
|
|
||||||
\label{eq:brechungsindexIonosphäre}
|
|
||||||
\end{eqnarray}
|
|
||||||
|
|
||||||
Diese Gleichung zeigt, dass der Brechungsindex für die Phasengeschwindigkeit von der Elektronendichte \(N_e\) und der Frequenz \(f\) des Senders bestimmt wird. Aufgrund der unstetigen Elektronendichte in der Ionosphäre gibt es beispielsweise das \textbf{Klobuchar-Modell} \cite[128]{Bauer2018}, welches stetig an den Tag und die Sonnenaktivität angepasst wird und von den Satelliten an die Empfänger publiziert wird. Mit diesem Modell können \(50\%\) der ionosphärischen Laufzeitfehler korrigiert werden.
|
|
||||||
\par
|
|
||||||
Eine aufwendigere und genauere Alternative bietet die Zweifrequenzkorrektur, aufgrund der Abhängigkeit des Brechungsindexes von der Frequenz kann durch die Messung von zwei unterschiedlichen Frequenzen, im Fall von GNSS meist im L1 und L5 Band, auf die Refraktion in der Ionosphäre geschlossen werden.
|
|
||||||
\par
|
|
||||||
Sobald die Signale die Ionosphäre durchquert haben, treffen diese erst auf Stratosphäre und anschließend auf die Troposphäre, in welcher sich typischerweise der Empfänger befindet. In der Strato- und Troposphäre wird das Signal hauptsächlich durch die Zusammensetzung der Gase, dem Luftdruck und der Temperatur in diesen Schichten beeinflusst. Diese Zusammensetzung ist allerdings über den Planeten verteilt relativ homogen, weshalb dieser Fehler gut kalkuliert werden kann. In Troposphäre stellt die Luftfeuchtigkeit ein zusätzliches Hindernis für den Signallaufweg dar. Dieser Fehler ist Orts- und Zeitabhängig und deshalb schwerer zu modellieren. Es gibt mehrere Modelle zur Berechnung des aktuell wirkenden einflusses, hier zu nennen wären das Modell von Hopfield und das Modell von Saastamoinen, wie von Bauer \cite[131]{Bauer2018} beschrieben.
|
|
||||||
|
|
||||||
\subsubsection{Andere Fehlerquellen}
|
|
||||||
In der folgenden List werden mögliche Fehlerquellen dargestellt, welche eine Positionsbestimmung behindern können:
|
|
||||||
|
|
||||||
\begin{itemize}
|
|
||||||
\item \textbf{Mehrwegeausbreitung} beschreibt den Umstand, dass die Antenne das Signal des Satelliten auf mindesten zwei Wegen empfängt. Der erste Weg ist der direkte vom Satelliten zu dem Empfänger, der so auch gewünscht ist. Die anderen Wege stammen von Reflexionen des Signals. Die unerwünschten Reflexionen können meist dadurch erkannte werden, dass die Dämpfung des Signals deutlich höher als die des direkt empfangenen Signals ist.
|
|
||||||
\item \textbf{Signalbeugung} beschreibt den Empfang eines Signals von einem Satelliten, welcher durch ein Hindernis abgeschattet ist. Das ist möglich weil ein Signal, welches zum Beispiel auf eine Gebäudekante trifft abgelenkt (gebeugt) wird. Wenn ein Satelliten von dem Empfänger schon beobachtet wird, kann dieser Fehler erkannt werden, weil die Signaldämpfung unvorhergesehen zunimmt.
|
|
||||||
\item \textbf{Aktive Störung} können bei GNSS mit wenig Aufwand herbeigeführt werden. Bauer beschreibt \cite[169]{Bauer2018}, dass die Signalstärke von GNSS bei lediglich \(-160dBW\) liegt, was umgerechnet \(1 \cdot 10^{-16}W\) entspricht. Deshalb ist es möglich mit geringen Sendeleistungen von wenigen \(W\) bereits Bereich mit mehreren \(10km\) zu stören.
|
|
||||||
\end{itemize}
|
|
||||||
|
|
||||||
\subsubsection{Aufbau}
|
|
||||||
Bauer beschreibt in dem Kapitel "Die Systemkomponenten" \cite[S. 201ff]{Bauer2018} von GNSS. Diese werden in drei Kategorien aufgeteilt:
|
|
||||||
|
|
||||||
\setlist{noitemsep}
|
|
||||||
\begin{itemize}
|
|
||||||
\item Weltraumsegment,
|
|
||||||
\item Bodensegment,
|
|
||||||
\item Nutzersegment.
|
|
||||||
\end{itemize}
|
|
||||||
\setlist{}
|
|
||||||
|
|
||||||
Das Weltraumsegment besteht aus den GNSS-Satelliten. Ein Empfänger an einem beliebigen Ort auf Erde muss immer 4 Satelliten sehen können um eine Ortung durchführen zu können. Dementsprechend wurden die Satellitenumlaufbahnen von den verschiedenen Systembetreibern gewählt. Im Falle von GPS sind es 24 Satelliten, welche auf 6 Bahnebenen aufgeteilt sind. Ein Satellit wird über Sonnenpaddel mit Strom versorgt. In dem Satelliten befindet sich unter anderem die hochgenaue Atomuhr. An Hülle befindet sich eine Sendevorrichtung für das GNSS-Signal und eine Kommunikationsvorrichtung um mit Bodensegment kommunizieren zu können. Viele Systeme sind in den Satelliten redundant ausgelegt um die Lebenserwartung zu erhöhen, diese liegt bei moderne Satelliten bei 15 Jahren. Die Satelliten der unterschiedlichen Generationen und Systeme sehen unterschiedlich aus, als Beispiel siehe Abbildung \ref{fig:satellite}
|
|
||||||
|
|
||||||
|
|
||||||
\begin{figure}[h]
|
|
||||||
\centering
|
|
||||||
\includegraphics[width=\linewidth]{img/satellite.jpg}
|
|
||||||
\caption{Modell eines Satelliten von dem GNSS Galileo \protect\footnote[1]{This file comes from Science Museum Collections, a website operated by Science Museum Group, a non-departmental public body in the UK. This tag does not indicate the copyright status of the attached work. A normal copyright tag is still required. See Commons:Licensing. (\url{https://commons.wikimedia.org/wiki/File:Galileo_satellite_model.jpg}), \url{https://creativecommons.org/licenses/by/4.0/legalcode}}}
|
|
||||||
\label{fig:satellite}
|
|
||||||
\end{figure}
|
|
||||||
|
|
||||||
Das Bodensegment hat die Aufgabe die Satelliten mit den aktuellen Information zu versorgen, welche über die Satelliten an die Nutzer weitergegeben werden. Für diese Aufgabe werden mehrere Stationen genutzt:
|
|
||||||
|
|
||||||
\begin{itemize}
|
|
||||||
\item \textbf{Überwachungsstationen} messen die Daten der GNSS-Satelliten und übermitteln diese an die Zentralstation.
|
|
||||||
\item In der \textbf{Zentralstation} werden die Daten verarbeitet. Aus diesen Daten werden die aktuellen Bahndaten mit einer Genauigkeit von 1 bis 2m der einzelnen Satelliten bestimmt. Die Ergebnisse werden der Sendestation übergeben.
|
|
||||||
\item Die \textbf{Sendestationen} übermitteln die Ergebnisse an die Satelliten.
|
|
||||||
\end{itemize}
|
|
||||||
|
|
||||||
Das Nutzersegment wird durch die GNSS-Empfänger gebildet.
|
|
||||||
|
|
||||||
\subsection{DGNSS}
|
|
||||||
Da die Genauigkeit von GNSS lediglich einige Meter beträgt, wurden verfahren Entwickelt, um die Positionsbestimmung zu optimieren. Ein Prinzip ist dabei das \textbf{Differenzielle}-GNSS, dabei gibt es immer eine ortsfeste Referenzstation oder ein Netz dieser und den GNSS-Empfänger im Feldeinsatz (Rover). Zusätzlich muss eine Verbindung zwischen diesen beiden Empfängern bestehen. Über diese Verbindung werden Code"=Beobachtungskorrekturen von der Referenzstation an den Rover übermittelt. Diese Korrekturen ermöglichen es den Fehler der Positionsbestimmung in Echtzeit auf bis zu \(1m\) zu reduzieren. \cite[vgl.][S. 248]{Bauer2018}
|
|
||||||
|
|
||||||
\subsubsection{RTK}
|
|
||||||
\label{sssec:rtkDescription}
|
|
||||||
\textbf{R}eal \textbf{T}ime \textbf{K}inematic bezeichnet ebenfalls eine DGNSS-Methode, im gegensatz zu der zuvor beschriebenen sind mit RTK Echtzeitpositionierungen im einstelligen \(cm\)-Bereich möglich. Die zusätzlich gewonnene Genauigkeit kommt laut Bauer\cite[249]{Bauer2018} bei diesem Verfahren durch die Erhebung von Phasendaten zustande. Die Verwendung der Phasendaten ist aufwendiger als die Code-Daten dafür aber auch genauer. Außerdem werden typischerweise Zweifrequenzen-Phasendaten erzeugt, damit schneller eine Mehrdeutigkeitslösung gefunden werden kann. Der Rover muss dementsprechend die gleichen Frequenzen empfangen können um die Korrekturdaten anwenden zu können. Die Daten werden im Sekundentakt an den Rover übermittelt.
|
|
||||||
|
|
||||||
\subsubsection{SBAS durch EGNOS}
|
|
||||||
Die sogenannten \textbf{S}atellite-\textbf{B}ased \textbf{A}ugmentation \textbf{S}ystem stellen Erweiterungen zu den GNSS Diensten dar um beispielsweise die Genauigkeit zu erhöhen. Ein großer Nutzeranteil wird durch die Luftfahrt gestellt um Landungen zu vereinfachen.
|
|
||||||
\par
|
|
||||||
Bei SBAS handelt es sich um geostationäre Satelliten. Diese Art von Satelliten stehen für einen Beobachter auf der Erde fest am Horizont, daher kann mit dieser Art von Satelliten nur ein gewähltes Gebiet mit Informationen versorgt werden. Dadurch gibt es mehrere dieser Systeme, im folgenden wird kurz das in Europa betriebene EGNOS (European Geostationary Navigation Overlay System) beschrieben.
|
|
||||||
\par
|
|
||||||
Mit Messstationen werden im Sekunden Takt Rohdaten unterschiedlicher GNSS und die Entfernung zu den EGNOS-Satelliten gesammelt. Die gesammelten Daten werden von mehreren Mission Control Center (MMC) verarbeitet um daraus DGNSS-Nachrichten zu formulieren. Die Nachricht enthält unter anderem Korrekturen für die Satellitenuhren, Korrekturen der Umlaufbahnen und Werte zur Berechnung der ionosphärischen Einflüsse. Diese Nachricht wird dann die Satelliten weiter gegeben, welche diese dann wiederrum über das L1-Band senden und damit GNSS-Empfängern in Reichweite zur Verfügung stellen. Mit Anwendung der verschickten Korrekturdaten kann eine Positionsbestimmung mit \(1m\) Genauigkeit erzielt werden.\cite[vgl.][S. 393ff]{Bauer2018}
|
|
||||||
|
|
||||||
\subsection{RINEX}
|
|
||||||
Das RINEX-Format ist aus der Notwendigkeit einer unabhängigen Möglichkeit des Datenaustausches zwischen GNSS-Modulen unterschiedlicher Hersteller entstanden. Das Format wurden nach seinen Anforderungen benannt und heißt daher ausgeschrieben \textbf{R}eceiver \textbf{IN}dependent \textbf{EX}change. Die erste Version des Formats wurde 1989 von Werner Gurtner veröffentlicht. Nach einigen weiteren Versionen, welche das Format unter anderem für weitere GNSS erweiterte, wird die Versionspflege inzwischen von der IGS und dem RTCM-SC104 übernommen.
|
|
||||||
\par
|
|
||||||
Das RINEX-Format bietet die Dateitypen für Beobachtungs- (*.obs), Navigations- (*.nav) und Meteorologischendaten (*.sbs) an. Für diese Arbeit werden für die Einmessung der Antenne lediglich die Beobachtungsdaten benötigt, welche mit einem Header für allgemeingültige Daten beginnt und danach unter anderem Daten zu den Messzeiten, Pseudostrecken, Trägerphasen, Signalrauschen und Dopplereffekt enthält. Die gesammelten Daten während der einmessung können dann durch eine PostProcessingService verarbeitet werden, dabei werden weitere Daten von Beobachtungsstationen verwendet um eine möglichst genaue Position der Antenne errechnen zu können.\cite[vgl.][S. 107ff]{Ogaja}
|
|
||||||
|
|
||||||
\subsection{RTCM}
|
|
||||||
RTCM ist ein Standard zur Echtzeitübertragung von Daten zwischen GNSS-Empfängern. Dieses Format wurde zunächst in 1985 von der namensgebenden Organisation \textbf{R}adio \textbf{T}echnical \textbf{C}ommission for \textbf{M}aritime Services veröffentlicht. Aktuell ist die Version 2.3 aus dem Jahr 2001 noch stark verbreitet, welche sich stark an den Nachrichtenstruktur von GPS orientiert. Mit jeder neuen Version wurden Möglichkeiten geschaffen um weitere Daten übertragen zu können. Um das in Abschnitt \ref{sssec:rtkDescription} beschrieben RTK anwenden zu können empfiehlt sich die Version 3 des Formats. Insbesondere die Version 3.2 und 3.3 eigenen sich besonders gut, da ab diesen Versionen auch die neueren GNSS mit einbezogen werden können und diese Versionen Raum für Erweiterungen lassen.\cite[vgl.][S. 249ff]{Bauer2018}
|
|
||||||
\par
|
|
||||||
RTCM bietet noch weitere Funktionen wie eine Netzwerkkomponente, für diese Arbeit sind jedoch lediglich die Übertragungen der Code- und Phasenkorrekturen von Bedeutung, da die Übertragung der RTCM-Nachrichten mit dem NTRIP umgesetzt wird, siehe Abschnitt \ref{ssec:ntripDescription}. Nachfolgenden wird die Tabelle \ref{tab:rtcmMsg} dargestellt, welche die in dieser Arbeit Anwendung findenden Nachrichten Typen beschreibt.\cite[vgl.][S. 113f]{Ogaja}
|
|
||||||
|
|
||||||
\begin{table}[h]
|
|
||||||
\centering
|
|
||||||
\begin{tabular}{|l|l|}
|
|
||||||
\hline
|
|
||||||
\textbf{RTCM 3 Msg-Nr.} & \textbf{Inhalt} \\ \hline
|
|
||||||
1005 & Koordinaten der Referenzstation \\ \hline
|
|
||||||
1074 & GPS MSM4 \\ \hline
|
|
||||||
1084 & GLONASS MSM4 \\ \hline
|
|
||||||
1094 & Galileo MSM4 \\ \hline
|
|
||||||
1124 & BeiDou MSM4 \\ \hline
|
|
||||||
1230 & GLONASS L1 und L2 Code-Phase Biases \\ \hline
|
|
||||||
\end{tabular}
|
|
||||||
\caption{Auszug von Ethernet Übertragungsstandards nach IEEE 802.3}
|
|
||||||
\label{tab:rtcmMsg}
|
|
||||||
\end{table}
|
|
||||||
|
|
||||||
MSM ist Akronym für Multiple Signal Messages und ist aufgeteilt in sieben Nachrichtentypen, wobei mit aufsteigender Nummer mehr Informationen übertragen werden. Die in Tabelle \ref{tab:rtcmMsg} bezeichnete MSM4 enthält die Pseudorange, Phaserange und CNR (Carrier to Noise Ratio). \cite[vgl.][114]{Ogaja}
|
|
||||||
|
|
||||||
\subsection{NTRIP}
|
|
||||||
\label{ssec:ntripDescription}
|
|
||||||
NTRIP wird ausgeschrieben zu \textbf{N}etworked \textbf{T}ransport of \textbf{R}TCM via \textbf{I}nternet \textbf{P}rotocol. Dieses Transferprotokoll wurde zunächst von dem Bundesamt für Kartographie und Geodäsie mit Hilfe der Technischen Universität Dortmund entwickelt. Es wird von der NTRIP Working group of RTCM Special Committee 104 (SC104) standardisiert und weiterentwickelt. Seit 2009 ist die verbesserte und abwärtskompatible Version 2 standardisiert. \cite[vgl.][]{FACG}
|
|
||||||
\par
|
|
||||||
Damit das Protokoll möglichst gut unterstützt wird, orientiert es sich stark an dem HTTP (Hypertext Transfer Protokoll)in der Version 1.1. Im nachfolgenden wird das übernommene Beispiel einer minimal Verbindung gezeigt. \cite[siehe][2]{NTRIPWorkingGroup2023}
|
|
||||||
|
|
||||||
\begin{minted}{http}
|
|
||||||
GET /MountPtName HTTP/1.1<CR><LF>
|
|
||||||
Host: Acaster.com:2101<CR><LF>
|
|
||||||
Ntrip-Version: Ntrip/2.0<CR><LF>
|
|
||||||
User-Agent: NTRIP ProductName/Version<CR><LF>
|
|
||||||
<CR><LF>
|
|
||||||
\end{minted}
|
|
||||||
|
|
||||||
An diesem Beispiel ist die Ähnlichkeit zum HTTP sehr deutlich zu sehen, es werden bekannte HTTP-Methoden eingesetzt sowie gleiche Zeilen Abschlüsse genutzt.
|
|
||||||
\par
|
|
||||||
Das System basiert auf diesen drei Komponenten \cite[vgl.][S. 2-1]{FACG2004}:
|
|
||||||
|
|
||||||
\begin{itemize}
|
|
||||||
\item Ein \textbf{Ntrip-Caster} ist eine Serveranwendung die einem Webserver ähnelt. Die Kommunikation wird immer von einem Client, ähnlich dem Beispiel, initialisiert. Für diese Arbeit wird der Service rtk2go als Caster genutzt, welcher in Abschnitt \ref{ssec:rtk2go} kurz beschrieben wird.
|
|
||||||
\item Der \textbf{Ntrip-Server} stellt die Daten als Client für den Ntrip-Caster zur Verfügung. Dieser wird auf der Basisstation mithilfe der RTKLib ausgeführt siehe dafür Abschnitt \ref{sec:Basisstation} und \ref{sssec:rtklib}
|
|
||||||
\item Der \textbf{Ntrip-Client} ist ein ebenfalls ein Client des Ntrip-Caster und bezieht die Korrekturdaten. Da die Korrekturdaten auf dem Rover benötigt werden, wird in Abschnitt \ref{ssec:ntripclient} die Implementierung eines Ntrip-Clients für den ESP32 beschrieben.
|
|
||||||
\end{itemize}
|
|
||||||
|
|
||||||
Wie auch das HTTP, verwendet das Ntrip Protokoll, TCP (Transmission Control Protocol) für die Verbindung zwischen den Komponenten.
|
|
||||||
|
|
||||||
\subsection{WLAN}
|
|
||||||
\label{ssec:wlan-description}
|
|
||||||
Das Akronym WLAN wird ausgeschrieben zu \textbf{W}ireless \textbf{L}ocal \textbf{A}rea \textbf{N}etwork. Dabei handelt es sich um drahtlose lokal begrenzte Netzwerke, welche dafür vorgesehen sind mobile Endgeräte direkt oder über eine Vermittlungsstelle, wie einem Router, miteinander oder anderen Netzwerken zu verbinden. Diese Art von Netzwerken werden am häufigsten durch den IEEE 802.11 Standard \cite{WLAN} realisiert.
|
|
||||||
\par
|
|
||||||
Der genannte Standard wurde erstmals 1997 veröffentlicht und wird seit dem immer wieder dem aktuellen Anforderungen angepasst. Zunächst wurde die Physikalische Ebene in dem \( 2,4 GHz\) Frequenzband definiert. In der ersten Erweiterung (IEEE 802.11a) von 1999 wurde das \(5GHz\) Band dem Standard hinzugefügt. In dem ersten Frequenzband können die Frequenzen \( 2,3995GHz - 2,4845GHz\) genutzt werden, dafür wird dieser Bereich in 13 sogenannten Kanäle aufgeteilt. Es werden Kanalbreiten von \(20MHz\) und \(40MHz\) genutzt. Das \(5GHz\) ist in zwei Frequenzbereiche aufgeteilt, zum einen von \(5,15GHz - 5,35GHZ\) und zum anderen von \(5,5GHz - 5,7GHz\), dabei werden die Kanäle von 36 bis 64 und von 100 bis 140 angeben. Die Kanalbreite kann zwischen \(20MHz\), \(40MHz\), \(80MHz\) und \(1600MHz\) variiert werden. Dabei ist zu beachten, dass die verschiedenen Kanalbreiten erst mit späteren Standards implementiert wurden.
|
|
||||||
\par
|
|
||||||
Die verschieden Korrekturen und Erweiterungen des Standard dienen im allgemeinen dazu eines oder mehrere der folgenden Kriterien zu verbessern: Geschwindigkeit, Reichweite, Zuverlässigkeit und Effizienz. Die Fortsetzungen wurden beginnend mit dem Buchstaben 'a' begonnen, nachdem das Alphabet vollständig genutzt wurde, werden nun zwei Buchstaben genutzt. Es handelt sich dabei um ein Zahlensystem zur Basis 26. In der Tabelle \ref{tab:wlan} sind einige wichtigere oder bekanntere Erweiterungen des Standards aufgeführt.
|
|
||||||
|
|
||||||
\begin{table}[h]
|
|
||||||
\centering
|
|
||||||
\begin{tabular}{|l|c|c|c|}
|
|
||||||
\hline
|
|
||||||
\textbf{Standard} & \multicolumn{1}{l|}{\textbf{Verabschiedung}} & \multicolumn{1}{l|}{\textbf{\begin{tabular}[c]{@{}l@{}}Frequenzband\\ {[}GHz{]}\end{tabular}}} & \multicolumn{1}{l|}{\textbf{\begin{tabular}[c]{@{}l@{}}max. Brutto\\ Datenrate\end{tabular}}} \\ \hline
|
|
||||||
802.11a & 1999 & 2,4 \& 5 & \(54\frac{MBit}{s}\) \\ \hline
|
|
||||||
802.11b & 1999 & 2,4 & \(11\frac{MBit}{s}\) \\ \hline
|
|
||||||
802.11g & 2003 & 2,4 & \(54\frac{MBit}{s}\) \\ \hline
|
|
||||||
802.11n & 2009 & 2,4 \& 5 & \(600\frac{MBit}{s}\) \\ \hline
|
|
||||||
802.11ac & 2013 & 5 & \(3,4\frac{GBit}{s}\) \\ \hline
|
|
||||||
802.11ax & 2019 & 2,4 \& 5 & \(12\frac{GBit}{s}\) \\ \hline
|
|
||||||
802.11be & ausstehend & 2,4, 5 \& 6 & \(46\frac{GBit}{s}\) \\ \hline
|
|
||||||
\end{tabular}
|
|
||||||
\caption{Ausschnitt verschiedener IEEE 802.11 Standards}
|
|
||||||
\label{tab:wlan}
|
|
||||||
\end{table}
|
|
||||||
|
|
||||||
Die Verbreitung von WLAN in das alltägliche private Leben begann mit dem 802.11b Standard, weil mehrere Hersteller begannen Geräte für einen moderaten Preis zu verkaufen und diese durch den Standard Kompatibel zu einander sein müssen. Dadurch wurde es viel leichter Laptops und andere mobile Gräte kabellos mit dem Netzwerk zu verbinden. Heute sind in fast jedem Gebäude WLAN-Netzwerke zu finden.
|
|
||||||
\par
|
|
||||||
Auch in der Industrie ist WLAN eine essentielle Technik, zum Beispiel für automatisierte Lagersysteme mit mobilen Robotern.
|
|
||||||
!!!Reichweiten hinzufügen - wird in bewertung für rover referenziert!!!
|
|
||||||
|
|
||||||
\subsection{Ethernet}
|
|
||||||
Ethernet beschreibt nach dem Standard IEEE 802.3 \cite{Ethernet} verschiedene kabelgebundene Möglichkeiten \textbf{L}ocal \textbf{A}rea \textbf{N}etworks (LANs) aufzubauen. Diese Netzwerke werden typischerweise in Gebäuden eingesetzt mit einer Sterntopologie. Bei der installation wird hauptsächlich mehradriges Kupferkabel oder Glasfaserkabel genutzt. Das Kupferkabel wird auch Twisted-Pair-Kabel genannt und wird in verschiedene Kategorien eingeteilt, durch diese ist es möglich die maximale Geschwindigkeit des Kabels abzulesen. Einige dieser Kategorien können in der Tabelle \ref{tab:ethernet} abgelesen werden.
|
|
||||||
\par
|
|
||||||
Glasfaserkabel werden nur in zwei Kategorien eingeteilt. Multimode-Glasfaserkabel werden oft in LANs benutzt, da sie sich eher für kürzere Distanzen eignen. Die Distanz wird durch die Brechung des Lichts und der Verwendung mehrerer Lichtmoden in dem Lichtleiter eingeschränkt. Die Reichweite ist der von Twisted-Pair-Kabeln trotzdem deutlich überlegen.
|
|
||||||
Aufgrund der höheren Fertigungskosten der Singlemode-Glasfaserkabel sind diese eher selten in LANs zu finden. Der Kerndurchmesser des Lichtleiters ist bei diesen Kabeln um ein vielfaches geringer. Die Reduzierung von \(50\mu m\) bzw. \(62,5\mu m\) auf typischerweise \(8\mu m\) bis \(10\mu m\) und der ausschließlichen Übertragung einer Lichtmode ermöglicht nochmals längere Signalwege. Außerdem bietet die Glasfasertechnologie den Vorteil unabhängig von elektromagnetischen Störungen zu sein.
|
|
||||||
\par
|
|
||||||
Die Tabelle \ref{tab:ethernet} zeigt einige Übertragungsstandards von Ethernet, dabei wurde unter anderem die Übertragungsmöglichkeiten über Coaxialkabel aus den Anfängen von Ethernet ausgelassen.
|
|
||||||
|
|
||||||
\begin{table}[h]
|
|
||||||
\centering
|
|
||||||
\begin{tabular}{|l|c|c|r|}
|
|
||||||
\hline
|
|
||||||
\textbf{Standard} & \multicolumn{1}{l|}{\textbf{max. Geschwindigkeit}} & \multicolumn{1}{l|}{\textbf{Medium}} & \multicolumn{1}{l|}{\textbf{max. Segmentlänge}} \\ \hline
|
|
||||||
10BASE-T & \(10\frac{MBit}{s}\) & \begin{tabular}[c]{@{}c@{}}Twisted-Pair\\ min. Cat3\end{tabular} & 100m \\ \hline
|
|
||||||
100BASE-TX & \(100\frac{MBit}{s}\) & \begin{tabular}[c]{@{}c@{}}Twisted-Pair\\ min. Cat5\end{tabular} & 100m \\ \hline
|
|
||||||
1000BASE-T & \(1\frac{GBit}{s}\) & \begin{tabular}[c]{@{}c@{}}Twisted-Pair\\ min. Cat5e\end{tabular} & 100m \\ \hline
|
|
||||||
1000BASE-SX & \(1\frac{GBit}{s}\) & \begin{tabular}[c]{@{}c@{}}Glasfaser\\ Multimode\end{tabular} & 550m \\ \hline
|
|
||||||
1000BASE-LX & \(1\frac{GBit}{s}\) & \begin{tabular}[c]{@{}c@{}}Glasfase\\ Singlemode\end{tabular} & 5km \\ \hline
|
|
||||||
10GBASE-T & \(10\frac{GBit}{s}\) & \begin{tabular}[c]{@{}c@{}}Twisted-Pair\\ min. Cat6\end{tabular} & \begin{tabular}[c]{@{}r@{}}55m\\ 100m mit Cat6a\end{tabular} \\ \hline
|
|
||||||
10GBASE-SR & \(10\frac{GBit}{s}\) & \begin{tabular}[c]{@{}c@{}}Glasfaser\\ Multimode\end{tabular} & 400m \\ \hline
|
|
||||||
10GBASE-LR & \(10\frac{GBit}{s}\) & \begin{tabular}[c]{@{}c@{}}Glasfase\\ Singlemode\end{tabular} & 10km \\ \hline
|
|
||||||
\end{tabular}
|
|
||||||
\caption{Auszug von Ethernet Übertragungsstandards nach IEEE 802.3}
|
|
||||||
\label{tab:ethernet}
|
|
||||||
\end{table}
|
|
||||||
|
|
||||||
\subsubsection{PoE}
|
|
||||||
\label{sssec:PoE}
|
|
||||||
PoE ist die Abkürzung für \textbf{P}ower \textbf{o}ver \textbf{E}thernet und meint damit die Funktion neben den Daten zusätzlich die Stromversorgung für kleinere Netzwerkgeräte über ein Twisted-Pair-Kabel zu ermöglichen. PoE wird ebenfalls im IEEE 802.3 \cite{Ethernet} Standard definiert. Eingeführt wurde PoE 2003 in IEEE 802.3af mit einer Leistung von 15 Watt. Seit dem wurde PoE erweitert um mehr Leistung bieten zu können. Dies geschah mit den Standards 802.3at und 802.3bt. Die erste Erweiterung wird auch als PoE+ bezeichnet und kann 30 Watt je Port zur Verfügung stellen. Der aktuelle Stand wird auch PoE++ genannt. Bei der Verwendung von PoE++ wird zwischen dem Typ 3 und 4 unterschieden, da Typ 3 60 Watt leisten kann und Typ 4 100 Watt. Die Spannungen auf dem Ethernetkabel liegen bei PoE zwischen 44 und 57 Volt.
|
|
||||||
\par
|
|
||||||
PoE wird unter anderem oft für Telefone, Kameras und AccessPoints eingesetzt.
|
|
||||||
|
|
||||||
\section{Hardware}
|
|
||||||
In diesem Abschnitt wird zunächst die allgemeine Funktionalität von GNSS-Hardware allgemein und speziell der aktuell auf dem Rover verbauten erklärt. Darauf folgt die Funktionsbeschreibung von PoE-Hardware die zur späteren Anbindung der RTK-Basisstation benötigt wird. In dem Abschnitt \ref{sec:PoE-Hardware} wird auf die konkret verwendete PoE-Hardware eingegangen, während Abschnitt \ref{sec:GNSS-Hardware} die Auswahl der GNSS-Hardware für die Basisstation beschreibt.
|
|
||||||
\subsection{GNSS-Modul}
|
|
||||||
Auf dem Markt sind eine vielzahl von GNSS-Modulen erhältlich. Dessen allgemeine Aufgabe es immer ist die Position auf der Erde durch die über eine Antenne Empfangen Signale zu bestimmen. Die erhältlichen Module unterscheiden sich hauptsächlich in der Genauigkeit und der verfügbaren Features. Die günstigsten Module bieten keine Möglichkeit die Rohdaten auszugeben oder Korrekturdaten einzuspeisen, weshalb sich weder extern und intern Fehlerkorrekturen anwenden lassen und somit die Genauigkeit im 10 Meter Bereich liegt. Bei professionelleren Modulen kann beides möglich sein, wodurch sich Positionsbestimmungen im niedrigen Centimeter Bereich realisieren lassen.
|
|
||||||
\par
|
|
||||||
In dem Rover ist ein GNSS-Chip von u-blox auf einem Entwicklungsmodul von Sparkfun verbaut. Der Chip wird unter dem Namen ZED-F9K-00B vermarktet. Dem Datenblatt des Herstellers \cite{zed-f9k} sind folgende Informationen zu entnehmen. Das Modul unterstützt die Bänder L1/L2/E5b, damit können die Daten von den GNSSystemen BeiDou, Galileo, GLONASS und GPS verarbeitet werden. Unter normalen Bedingungen ist die Position bei einem Kaltstart nach spätestens 30 Sekunden ermittelt und bei einem Warmstart nach 2 Sekunden. In dieses Modul können Korrekturdaten eingespeist werden, allerdings ist es nicht in der Lage diese zu erzeugen. Im RTK-Modus ist die Genauigkeit mit 0,2 Meter angegeben.
|
|
||||||
|
|
||||||
\subsection{GNSS-Antenne}
|
|
||||||
Die Antennen von GNSS-Modulen können extern ausgeführt werden oder direkt am Modul verbaut sein und dienen dazu die Signale der Satelliten zu empfangen. Dabei bieten externe Antennen den Vorteil unabhängig und für den Empfang optimiert aufgestellt/verbaut werden zu können. Für externe Antenne steht häufig mehr Platz zur Verfügung, deshalb wird Empfangsqualität nicht durch mangelnden Bauraum beeinflusst.
|
|
||||||
\par
|
|
||||||
Die auf dem Rover extern installierte Antenne wurde wie das GNSS-Modul ebenfalls von u-blox entwickelt und auf die F9-Reihe abgestimmt. Dabei handelt es sich laut Datenblatt \cite{antenneKlein} um eine aktive Antenne welche die Bänder des GNSS-Moduls unterstützt und darüber hinaus noch die Bänder B2a und NavIC. Das Gehäuse der Antenne misst 60mm x 82mm, wobei die Position der eigentlichen im Gehäuse zentriert ist. Angeschlossen wir die Antenne über einen SMA-Stecker.
|
|
||||||
|
|
||||||
\subsection{PoE Hardware}
|
|
||||||
\subsubsection{PoE Extender}
|
|
||||||
Ein PoE Extender wird dafür genutzt die Reichweite eines mit PoE versehenen Twisted-Pair-Kabel zu verlängern. Die Reichweite wird durch die begrenzte Segmentlänge des verwendeten Mediums beschränkt. Im Fall von Twisted-Pair-Kabeln beträgt diese \(100m\). Der Extender nutzt die über PoE verfügbare Energie zur Signalaufbereitung und gibt das Signal inklusive PoE wieder aus, dabei ist zu beachten, dass aufgrund der verbrauchten Energie das ausgangsseitige PoE um einen Typen verringert wird und somit weniger Leistung zur Verfügung stellt.
|
|
||||||
\par
|
|
||||||
Speziellere Extender können zusätzlich als Switch fungieren. Diese Extender verfügen typischerweise über zwei Ethernet Ausgänge. Die verfügbare PoE Leistung wird dann auf diese beiden Ports aufgeteilt. !!!Datenblatt!!!
|
|
||||||
|
|
||||||
\subsubsection{PoE Splitter}
|
|
||||||
Der PoE Splitter trennt die Daten und den Strom vom Ethernetkabel. Diese Geräte haben typischerweise drei Anschlüsse, dabei ist der erste der PoE Eingang. Bei den anderen beiden handelt es sich um die Ausgänge für die Daten und den Strom. Bei dem Anschluss für die Daten ohne Strom handelt es sich normalerweise wieder um ein Ethernet anschluss mit einer RJ-45 Buchse. Der Strom wird über Anschlussklemmen oder einen Terminalblock ausgegeben. Die Ausgegebene Spannung hängt von dem gewählten Splitter ab, wird aber meistens von der höheren PoE Spannung (siehe Unterabschnitt \ref{sssec:PoE}) auf typische Spannungen von Netzteilen wie \(12V\) reduziert. !!!Datenblatt!!!
|
|
||||||
|
|
||||||
|
|
||||||
\section{Software}
|
|
||||||
Im folgenden wird die benötigte Software für diese Arbeit beschrieben. Dabei wird zunächst das Betriebssystem der Basisstation beschrieben, gefolgt von der verwendeten Software mit spezifischen Bezug auf die GNSS-Thematik.
|
|
||||||
\subsection{Debian}
|
|
||||||
\label{ssec:debian}
|
|
||||||
Als Betriebssystem wird das freie Debian ohne grafische Oberfläche verwendet. Debian ist eine GNU/Linux-Distribution, welche bereits seit 1993 entwickelt und weiterentwickelt wird und als Basis für viele weitere sehr erfolgreichen und bekannten Betriebssystemen wie Ubuntu verwendet wird. Daher kann Debian als ein stabiles und hartes Betriebssystem angesehen werden, welches auch in der Industrie für viele Server eingesetzt wird und bei Cloud-Services als Betriebssystem für virtuelle Maschinen angeboten wird.
|
|
||||||
|
|
||||||
\subsubsection{Systemd}
|
|
||||||
Systemd wird von dem Wiki Ubuntuusers\cite{systemd} als ein Teil des Betriebssystems, welcher für die Verwaltung und das Starten der Dienste des Systems zuständig ist, da alle Prozesse während des Bootvorgangs von Systemd gestartet werden erhält Systemd immer die Prozess-ID 1.
|
|
||||||
\par
|
|
||||||
Die Konfiguration erfolgt über eine Datei für jeden Service, in welcher unter anderem folgende Einstellungen getätigt werden können:
|
|
||||||
|
|
||||||
\begin{itemize}
|
|
||||||
\item eine Kurzbeschreibung des Service,
|
|
||||||
\item eine Bedingung für den Start,
|
|
||||||
\item die Art des Service,
|
|
||||||
\item das als Service auszuführende Programm
|
|
||||||
\item und den Betriebsmodus des Betriebssystems.
|
|
||||||
\end{itemize}
|
|
||||||
|
|
||||||
Durch dieses System wird es ermöglicht, dem Betriebssystem mit geringen Entwicklungsaufwand weitere Services hinzuzufügen, was in dieser Arbeit für Installation der Basisstation von Vorteil ist.
|
|
||||||
|
|
||||||
\subsection{ser2net}
|
|
||||||
Die auf GitHub und über die Paketquellen von Debian veröffentliche Software ser2net\cite{ser2net} wird dem Betriebssystem bei Installation als Service hinzugefügt. Mit diesem Service können unter anderem verfügbare Geräte mit einem seriellen Interface dem Netzwerk über eine TCP-Verbindung zugänglich gemacht werden. Dafür müssen die zu veröffentlichen Interfaces inklusive der verwendeten Einstellungen wie die Baudrate in der Konfigurationsdatei unter dem Pfad \url{/etc/ser2net/ser2net.yaml} definiert werden.
|
|
||||||
\par
|
|
||||||
Dadurch ist es möglich das GNSS-Modul der Basisstation, der U-Blox Software (siehe Abschnitt \ref{sssec:u-blox}) auf einem im Netzwerk erreichbaren Computer mit Windows als Betriebssystem zur Verfügung zu stellen.
|
|
||||||
|
|
||||||
\subsection{com0com und com2tcp}
|
|
||||||
Diese beiden Programme bilden das Gegenstück zu ser2net auf einem Computer mit Windows als Betriebssystem. Dabei stellt das Programm den Treiber für virtuelle COM-Ports zur Verfügung und ermöglicht es mehrere dieser virtuellen Ports miteinander zu verbinden. Dies ist nötig, weil nur ein Programm zur Zeit auf einen COM-Port zugreifen kann. Durch die Brücke von zwei virtuellen COM-Ports kann ein Port von der U-Blox Software genutzt werden.
|
|
||||||
\par
|
|
||||||
Der andere Port wird von dem zweiten Programm (com2tcp) genutzt um die Verbindung zu ser2net herzustellen. Dafür muss die IP-Adresse des Servers und der Port auf dem das Interface veröffentlicht wird bekannt sein.
|
|
||||||
|
|
||||||
\subsection{GNSS}
|
|
||||||
Dieser Abschnitt beschreibt Programme die direkt mit GNSS-Modul interagieren oder dessen Daten verarbeiten.
|
|
||||||
|
|
||||||
\subsubsection{GNSS PostProcessing}
|
|
||||||
Für die Errichtung einer Basisstation muss die Position der Antenne möglichst exakt bestimmt werden. Die exakteste Möglichkeit bieten dafür sogenannte Post Processing Dienste. Um diese Nutzen zu können muss der Receiver zunächst die Beobachtungsdaten erstellen und diese im Anschluss im RINEX-Format an der Post Processing Dienst senden.
|
|
||||||
\par
|
|
||||||
Für die Einmessung der zu errichtenden Basisstation wird in dieser Arbeit der kostenlose Service Canadian Spatial Reference System Precise Point Positioning (CSRS-PPP) \cite{canada} genutzt. Zur Berechnung nutzt dieser globale Bahn- und Uhrendaten der Satelliten. Nachdem die Beobachtungsdaten übersendet wurde, wird nach ein paar Stunden, das Ergebnis per E-Mail übersandt. Neben den berechneten Koordinaten mit angaben zur Genauigkeit, werden Graphen der beobachteten Satelliten dargestellt. Durch diese Graphen kann kontrolliert werden ob die Antenne freie Sicht auf den Himmel hatte.
|
|
||||||
|
|
||||||
\subsubsection{RTKLib}
|
|
||||||
\label{sssec:rtklib}
|
|
||||||
Die RTKLib\cite{rtklib} ist eine Sammlung von Open Source Programmen für GNSS Positionierung. Für Windows gibt es die Programme fertig compiliert und mit einer grafischen Oberfläche, zur Nutzung unter Linux muss der Quellcode eigenständig compiliert werden. Die Hälfte der Programme verfügt über eine CLI und ist somit ohne grafische Benutzeroberfläche nutzbar. Aus dieser Sammlung sind für diese Arbeit zwei der Programme von Bedeutung, welche auch beide über eine CLI verfügen.
|
|
||||||
|
|
||||||
\begin{itemize}
|
|
||||||
\item \textbf{Communication Server} - Für die Verwendung können mehrere Ein- und Ausgänge konfiguriert werden. Die Eingänge werden zusammengeführt und an alles Ausgänge weitergeleitet. Der Eingang ist in dem Kontext dieser Arbeit immer das GNSS-Modul und der Ausgang ist entweder ein NTRIP-Caster oder eine Datei. Die Ausgabe in der Daten in eine Datei ermöglicht es die Beobachtungsdaten zu persistieren.
|
|
||||||
\item \textbf{RINEX Converter} - Mit diesem Konverter können die Beobachtungsdaten, welche im proprietären Format von U-Blox vorliegen in das RINEX-Format konvertiert werden.
|
|
||||||
\end{itemize}
|
|
||||||
|
|
||||||
\subsubsection{u-center}
|
|
||||||
\label{sssec:u-blox}
|
|
||||||
Das u-center\cite{u-center} ist laut dem Hersteller u-blox eine GNSS Evaluierungssoftware für Windows.
|
|
||||||
\par
|
|
||||||
Mit dieser lassen sich die Module von u-blox konfigurieren und die eingehenden Daten der Satelliten und des Moduls analysieren und loggen. Besonders die grafische Möglichkeit der Konfiguration erleichtert den Umgang mit diesen Modulen. Für die Evaluation lassen sich Graphen mit die den Drift der Position, die Laufbahn der Satelliten, die Anzahl der Satelliten mit Signalpegel und weitere Werte anzeigen.
|
|
||||||
\par
|
|
||||||
Das Programm bietet zusätzlich Tools an um als NTRIP-Client zu fungieren oder Daten mittels MQTT zu versenden.
|
|
||||||
|
|
||||||
\subsubsection{RTK2go}
|
|
||||||
\label{ssec:rtk2go}
|
|
||||||
RTK2go\cite{rtk2go} ist kostenlos nutzbarer NTRIP-Caster. Damit eine Basisstation sich mit RTK2go verbinden kann, muss diese zunächst registriert werden, damit eine Mount Point erstellt werden kann. Anschließend können Korrekturdaten über den Caster veröffentlicht werden dabei kann jeder auf die veröffentlichten Daten zugreifen. Als Client zur Datennutzung muss lediglich als Benutzername eine valide E-Mail Adresse hinterlegt werden, die ausschließlich als Kanal für Fehlermeldungen mit der Verbindung genutzt wird. Eine Registrierung als Rover ist daher nicht notwendig.
|
|
||||||
+23
-23
@@ -1,65 +1,65 @@
|
|||||||
\chapter{Anforderungen}
|
\chapter{Anforderungen}
|
||||||
\label{cha:anforderunge}
|
\label{cha:anforderunge}
|
||||||
In diesem Teil der Arbeit werden die Anforderungen an die verschieden Komponenten des Gesamtsystems beschrieben. Dabei wird zunächst auf die Anforderungen der Referenzstation eingegangen, neben den funktionalen Anforderungen sind die durch den Installationsort gegebenen nicht funktionalen Anforderungen besonders bei der Hardwareauswahl zu beachten.
|
In diesem Teil der Arbeit werden die Anforderungen an die verschiedenen Komponenten des Gesamtsystems beschrieben. Dabei wird zunächst auf die Anforderungen der Referenzstation eingegangen, neben den funktionalen Anforderungen sind die durch den Installationsort gegebenen nicht funktionalen Anforderungen besonders bei der Hardwareauswahl zu beachten.
|
||||||
\par
|
\par
|
||||||
Darüber hinaus werden Anforderungen zur Erweiterung des Rovers definiert.
|
Ferner werden Anforderungen zur Erweiterung des Rovers definiert.
|
||||||
|
|
||||||
\section{Referenzstation}
|
\section{Referenzstation}
|
||||||
\label{sec:referenzstation_req}
|
\label{sec:referenzstation_req}
|
||||||
Das Gesamtsystem der Station muss im Millimeterbereich eingemessen werden können. Das Eingemessene System muss im Dauerbetrieb die Korrekturdaten im RTCM3-Format erstellen und veröffentlichen, dafür soll als Caster der kostenlose RTK2go Service genutzt werden. Die Korrekturdaten sollen für alle aktuell verfügbaren GNSS bereitgestellt werden. Der Wartungsaufwand soll möglichst gering sein. Die komplette Installation muss an dem vorgegebenen Ort sicher angebracht werden und sich diesem anpassen.
|
Das Gesamtsystem der Station muss im Millimeterbereich eingemessen werden können. Das eingemessene System muss im Dauerbetrieb die Korrekturdaten im RTCM3-Format erstellen und veröffentlichen, dafür soll als Caster der kostenlose RTK2go Service genutzt werden. Die Korrekturdaten sollen für alle aktuell verfügbaren GNSS bereitgestellt werden. Der Wartungsaufwand soll möglichst gering sein. Die komplette Installation muss an dem vorgegebenen Ort sicher angebracht werden und sich diesem anpassen.
|
||||||
|
|
||||||
\subsection{Antennenposition}
|
\subsection{Antennenposition}
|
||||||
Der Installationsort der Antenne muss so gewählt werden, dass die Antenne eine freie Sicht auf den kompletten Himmel hat, dafür eignen sich besonders höher gelegene Orte. Deshalb und aufgrund der vorhandenen Infrastruktur wurde im Vorhinein entschieden, dass die Referenzstation auf dem Flachdach des Fachhochschulgebäudes an der Emil-Figge-Straße 44 in Dortmund errichtet werden soll.
|
Der Installationsort der Antenne muss so gewählt werden, dass die Antenne eine freie Sicht auf den kompletten Himmel hat, dafür eignen sich besonders höher gelegene Orte. Deshalb und aufgrund der vorhandenen Infrastruktur wurde im Vorhinein entschieden, dass die Referenzstation auf dem Flachdach des Fachhochschulgebäudes an der Emil-Figge-Straße 44 in Dortmund errichtet werden soll.
|
||||||
|
|
||||||
\subsection{Umweltbedingungen}
|
\subsection{Umweltbedingungen}
|
||||||
Da der Installationsort der Station auf dem Dach der Witterung und der Sonneneinstrahlung ausgesetzt ist müssen die Komponenten entweder Wasserfest und UV-beständig sein oder so installiert werden, dass diese vor den genannten Einflüssen geschützt werden.
|
Da der Installationsort der Station auf dem Dach der Witterung und der Sonneneinstrahlung ausgesetzt ist, müssen die Komponenten entweder wasserfest und UV-beständig sein oder so installiert werden, dass diese vor den genannten Einflüssen geschützt werden.
|
||||||
\par
|
\par
|
||||||
Des weiteren müssen alle auf dem Dach installierten Komponenten einen Betriebstemperaturbereich vorweisen welchen den realen Temperaturen im Außenbereich aller Jahreszeiten entspricht. Dabei muss auch beachtet werden, dass sich Objekte je nach Farbe durch die Sonneneinstrahlung über die Umgebungstemperatur hinaus erhitzen können.
|
Des Weiteren müssen alle auf dem Dach installierten Komponenten einen Betriebstemperaturbereich vorweisen, welchen den realen Temperaturen im Außenbereich aller Jahreszeiten entspricht. Dabei muss auch beachtet werden, dass sich Objekte je nach Farbe durch die Sonneneinstrahlung über die Umgebungstemperatur hinaus erhitzen können.
|
||||||
\par
|
\par
|
||||||
Der gewählt Installationsort verfügt über Blitzschutzeinrichtungen, diese dürfen nicht kompromittiert werden.
|
Der gewählte Installationsort verfügt über Blitzschutzeinrichtungen, diese dürfen nicht kompromittiert werden.
|
||||||
|
|
||||||
\subsection{Energieversorgung}
|
\subsection{Energieversorgung}
|
||||||
Die Energieversorgung ist durch ein vorhandenes Ethernetkabel mit PoE++ gegeben. Das Kabel versorgt das vorhandene Lora-Gateway mit Energie und stellt die Netzwerkverbindung her. Dieses Kabel muss so genutzt werden, dass damit die Energieversorgung und die Netzwerkverbindung für die Referenzstation und das Lora-Gateway hergestellt werden kann.
|
Die Energieversorgung ist durch ein vorhandenes Ethernetkabel mit PoE++ gegeben. Das Kabel versorgt das vorhandene LoRaWan-Gateway mit Energie und stellt die Netzwerkverbindung her. Dieses Kabel muss so genutzt werden, dass damit die Energieversorgung und die Netzwerkverbindung für die Referenzstation und das LoRaWan-Gateway hergestellt werden kann.
|
||||||
|
|
||||||
\subsection{Server}
|
\subsection{Server}
|
||||||
Die Daten des GNSS-Moduls müssen verarbeitet werden, dafür und um eine Remote-Konfiguration des Moduls vornehmen zu können wird ein Computer benötigt für welcher die folgenden Spezifikationen gelten müssen:
|
Die Daten des GNSS-Moduls müssen verarbeitet werden, dafür und um eine Remote-Konfiguration des Moduls vornehmen zu können, wird ein Computer benötigt. Für den Computer müssen die folgenden Spezifikationen gelten:
|
||||||
|
|
||||||
\setlist{noitemsep}
|
\setlist{noitemsep}
|
||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
\item mindesten einen USB-Port,
|
\item Mindestens einen USB-Port,
|
||||||
\item Netzwerkschnittstelle mit RJ-45 Buchse,
|
\item Netzwerkschnittstelle mit RJ-45 Buchse,
|
||||||
\item Stromversorgung über PoE oder einer gleichwertigen alternative,
|
\item Stromversorgung über PoE oder einer gleichwertigen Alternative,
|
||||||
\item Prozessor auf dem die RTKLib kompiliert werden kann
|
\item Prozessor, auf dem die RTKLib kompiliert werden kann
|
||||||
\item und eine möglichst geringe Energieaufnahme welche mit der PoE-Lösung kompatibel ist.
|
\item und eine möglichst geringe Energieaufnahme, welche mit der PoE Lösung kompatibel ist.
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
\setlist{}
|
\setlist{}
|
||||||
|
|
||||||
Darüber hinaus müssen die bereits zuvor allgemein definierten Anforderungen erfüllt werden. Der Server selbst soll ebenfalls über das Netzwerk administriert werden können.
|
Ebenso müssen die bereits zuvor allgemein definierten Anforderungen erfüllt werden. Der Server selbst soll ebenfalls über das Netzwerk administriert werden können.
|
||||||
|
|
||||||
\section{Rover}
|
\section{Rover}
|
||||||
\label{sec:rover_req}
|
\label{sec:rover_req}
|
||||||
Die vorhandene Software des Rovers soll um einige Komponenten erweitert werden. Diese Komponenten sollen den Rover im allgemeinen um die Funktion erweitern mittels GNSS eine Route abzufahren, die zuvor manuell abgefahren wurde. Die Erweiterungen sollen sofern möglich an das vorhandene Softwaredesign angepasst sein. Im folgenden werden die dazu nötigen Anforderungen zu definieren.
|
Die vorhandene Software des Rovers soll um einige Komponenten erweitert werden. Diese Komponenten sollen den Rover im allgemeinen, um die Funktion erweitern mittels GNSS eine Route abzufahren, die zuvor manuell abgefahren wurde. Die Erweiterungen sollen, sofern möglich, an das vorhandene Softwaredesign angepasst sein. Im Folgenden werden die dazu nötigen Anforderungen zu definieren.
|
||||||
|
|
||||||
\subsection{NTRIP-Client}
|
\subsection{Ntrip-Client}
|
||||||
Der Rover muss das GNSS-Modul mit Korrekturdaten versorgen um die benötigte Genauigkeit zu erreichen. Dafür soll der ESP32 über einen NTRIP-Client verfügen, welcher sich mit dem Caster verbindet und die Korrekturdaten empfängt. Es wird davon ausgegangen, dass eine Internetverbindung über WLAN vorhanden ist. Die Empfangenen Daten müssen an das GNSS-Modul weitergeleitet werden, dies muss durch die vorhandene Anbindung über SPI geschehen. Der Verbindungsstatus des Clients soll für andere Komponenten verfügbar gemacht werden können, um beispielsweise mit einer Navigationspause während eines Verbindungsabbruches reagieren zu können. Sollte die Verbindung zum WLAN und oder zu dem Caster verloren gehen, sollen diese sofern möglich automatisch wieder aufgebaut werden.
|
Der Rover muss das GNSS-Modul mit Korrekturdaten versorgen, um die benötigte Genauigkeit zu erreichen. Dafür soll der ESP32 über einen Ntrip-Client verfügen, welcher sich mit dem Caster verbindet und die Korrekturdaten empfängt. Es wird davon ausgegangen, dass eine Internetverbindung über WLAN vorhanden ist. Die empfangenen Daten müssen an das GNSS-Modul weitergeleitet werden, dies muss durch die vorhandene Anbindung über SPI geschehen. Der Verbindungsstatus des Clients soll für andere Komponenten verfügbar gemacht werden können, um beispielsweise mit einer Navigationspause während eines Verbindungsabbruches reagieren zu können. Sollte die Verbindung zum WLAN und/oder zu dem Caster verloren gehen, sollen diese, sofern möglich, automatisch wieder aufgebaut werden.
|
||||||
|
|
||||||
\subsection{Route}
|
\subsection{Route}
|
||||||
Eine Route soll aus einer Anzahl von Punkten bestehen. Die Punkte sollen die Koordinaten für Längen- und Breitengrad enthalten, zusätzlich können Metadaten wie die geschätzte Genauigkeit der Koordinaten mit gespeichert werden. Die Punkte müssen in einer festen Reihenfolge gespeichert werden. Die Strecken zwischen den Punkten müssen Geraden sein.
|
Eine Route soll aus einer Anzahl von Punkten bestehen. Die Punkte sollen die Koordinaten für Längen- und Breitengrad enthalten, zusätzlich können Metadaten wie die geschätzte Genauigkeit der Koordinaten mit gespeichert werden. Aufgezeichnete Punkte müssen in einer festen Reihenfolge gespeichert werden. Die Strecken zwischen den Punkten müssen Geraden sein.
|
||||||
|
|
||||||
\subsubsection{Aufzeichnen}
|
\subsubsection{Aufzeichnen}
|
||||||
Die Aufzeichnung einer Route soll ausschließlich von dem Benutzer gesteuert werden. Dazu soll der manuelle Fahrmodus des Rover genutzt werden, der eine Steuerung mit dem Joystick der Fernbedingung ermöglicht. Sofern das aufzeichnen der Route begonnen hat soll mit Drücken des Joystick-Buttons ein neuer Punkt der Route hinzugefügt werden. Der hinzuzufügende Punkt soll zuvor auf eine ausreichende Genauigkeit und einen Mindestabstand zu dem, falls vorhanden, vorherigen Punkt geprüft werden. Ob die aktuelle Position der Route hinzugefügt wurde soll dem Nutzer als Feedback zur Verfügung stehen.
|
Die Aufzeichnung einer Route soll ausschließlich von dem Benutzer gesteuert werden. Dazu soll der manuelle Fahrmodus des Rover genutzt werden, der eine Steuerung mit dem Joystick der Fernbedingung ermöglicht. Sobald die Aufzeichnung der Route begonnen hat, soll mit Drücken des Joystick-Buttons ein neuer Punkt der Route hinzugefügt werden. Der hinzuzufügende Punkt soll zuvor auf eine ausreichende Genauigkeit und einen Mindestabstand zu dem, falls vorhanden, vorherigen Punkt geprüft werden. Ob die aktuelle Position der Route hinzugefügt wurde, soll dem Nutzer als Feedback zur Verfügung stehen.
|
||||||
|
|
||||||
\subsubsection{Persistieren}
|
\subsubsection{Persistieren}
|
||||||
Eine aufgezeichnete Route soll persistiert werden können, sodass diese später wieder geladen und danach abgefahren werden kann ohne diese erneut aufzeichnen zu müssen. Es wäre von Vorteil die Speicherung der Routen extern zu ermöglichen um die Datenhaltung unabhängig von dem ESP32 zu gestalten und damit auch vor erneuten überspielen des Flash-Speichers bei Updates zu schützen.
|
Eine aufgezeichnete Route soll persistiert werden können, sodass diese später wieder geladen und danach abgefahren werden kann, ohne diese erneut aufzeichnen zu müssen. Es wäre von Vorteil die Speicherung der Routen extern zu ermöglichen, um die Datenhaltung unabhängig von dem ESP32 zu gestalten und damit auch vor erneuten überspielen des Flash-Speichers bei Updates zu schützen.
|
||||||
|
|
||||||
\subsection{Navigation}
|
\subsection{Navigation}
|
||||||
Die Navigation muss lesenden Zugriff die Daten der Route innehalten. Es muss die Entfernung und der Kurs vom aktuellen Standort zum nächsten Zielpunkt berechnet werden und daraufhin dem Autopiloten und/oder dem Nutzer zur Verfügung gestellt werden. Sofern ein Punkt ausreichend nah erreicht wurde soll automatisch der nächste Punkt in der Route angepeilt werden bis die Route vollständig abgefahren wurde. Die Navigation soll eigenständig arbeiten können.
|
Die Navigation muss lesenden Zugriff die Daten der Route innehalten. Es muss die Entfernung und der Kurs vom aktuellen Standort zum nächsten Zielpunkt berechnet und daraufhin dem Autopiloten und/oder dem Nutzer zur Verfügung gestellt werden. Sofern ein Punkt ausreichend nah erreicht wurde, soll automatisch der nächste Punkt in der Route angepeilt werden, bis die Route vollständig abgefahren wurde. Die Navigation soll eigenständig arbeiten können.
|
||||||
|
|
||||||
\subsection{Autopilot}
|
\subsection{Autopilot}
|
||||||
Der Autopilot muss die Navigation Nutzen um den Rover zu steuern. Dabei muss er Zugriff auf die Sensoren und die Steuerung des Rovers haben. Der Benutzer muss den Autopiloten zu jedem Zeitpunkt deaktivieren können. Der Autopilot muss von dem Benutzer überwacht werden, da keine Hinderniserkennung implementiert werden soll. Die Geschwindigkeit soll in Etappen reduziert werden, wenn der Rover sich dem Ziel nähert. Der Autopilot darf den Rover nur Bewegen wenn die aktuelle Positions-Lösung dem Anwendungsfall gerecht wird.
|
Der Autopilot muss die Navigation nutzen, um den Rover zu steuern. Dabei muss er Zugriff auf die Sensoren und die Steuerung des Rovers haben. Der Benutzer muss den Autopiloten zu jedem Zeitpunkt deaktivieren können. Der Autopilot muss von dem Benutzer überwacht werden, da keine Hinderniserkennung implementiert werden soll. Die Geschwindigkeit soll in Etappen reduziert werden, wenn der Rover sich dem Ziel nähert. Der Autopilot darf den Rover nur bewegen, wenn die aktuelle Positions-Lösung dem Anwendungsfall gerecht wird.
|
||||||
|
|
||||||
\subsubsection{Ausrichtung}
|
\subsubsection{Ausrichtung}
|
||||||
Um den Rover am Anfang auf den vorgegebenen Kurs ausrichten zu können muss zunächst der verbaute Kompass benutzt werden. Sobald der Rover in Bewegung ist soll der anliegende Kurs aus den Positionsdaten, dem Kompass und dem noch zu verbauenden Gyroskop hergeleitet werden. Das Gyroskop soll über I2C-Bus an den Rover angeschlossen werden.
|
Um den Rover am Anfang auf den vorgegebenen Kurs ausrichten zu können, muss zunächst der verbaute Kompass benutzt werden. Sobald der Rover in Bewegung ist, soll der anliegende Kurs aus den Positionsdaten, dem Kompass und dem noch zu verbauenden Gyroskop hergeleitet werden. Das Gyroskop soll über I2C-Bus an den Rover angeschlossen werden.
|
||||||
|
|
||||||
\section{Genauigkeit der Positionsbestimmung}
|
\section{Genauigkeit der Positionsbestimmung}
|
||||||
Ich weiß noch nicht ob der Abschnitt bleib. :D
|
Ich weiß bislang nicht, ob der Abschnitt bleibt. :D
|
||||||
|
|||||||
+33
-20
@@ -1,49 +1,62 @@
|
|||||||
\chapter{Hardwareauswahl}
|
\chapter{Hardwareauswahl}
|
||||||
\label{cha:Hardwareauswahl}
|
\label{cha:Hardwareauswahl}
|
||||||
Dieses Kapitel widmet sich der Auswahl passender Komponenten für die Basisstation und der Erweiterung des Rovers. Die zu installierende Basisstation soll fortan dauerhaft betrieben werden, deshalb muss diese wie in den Anforderungen beschrieben (siehe !!!ref!!!) unabhängig von anderen Teilen dieser Arbeit funktionsfähig sein und den Witterungsbedingungen an dem Installationsort standhalten.
|
Dieses Kapitel widmet sich der Auswahl passender Komponenten für die Basisstation und der Erweiterung des Rovers. Die zu installierende Basisstation soll fortan dauerhaft betrieben werden, deshalb muss diese wie in den Anforderungen beschrieben (siehe Abschnitt \ref{sec:referenzstation_req}) unabhängig von anderen Teilen dieser Arbeit funktionsfähig sein und den Witterungsbedingungen an dem Installationsort standhalten.
|
||||||
\par
|
\par
|
||||||
Bei einer Begutachtung des Installationsortes mit dem Personal des Gebäudemanagements wurde die Installation entsprechend der Abbildung !!!ref!!! vorgefunden. Da der verbleibende Raum in dem vorhandenen Installationskasten voraussichtlich nicht für die Installation des gesamten Systems der Referenzstation ausreichend ist, wurde die mündliche Genehmigung erteilt einen weiteren Installationskasten unter dem bereits vorhanden zu installieren. Um die passende Halterung für einen weiteren Kasten bestimmen zu können wurde der Durchmesser des Pfosten mit \(90mm\) festgehalten. Weiterhin wurde über die Position der Antenne gesprochen, das Problem lag darin, dass durch die Luftschächte der Klimatisierung die Antenne zu Teilen vom Himmel abgeschattet wäre, wenn diese direkt an dem vorhandenen Pfosten angebracht würde. Deshalb wurde sich auf darauf geeinigt, dass der Pfosten bis auf die Höhe der Luftschächte mittels eines C-Profils verlängert werden darf. Es wurde vorgeschlagen das Profil an der bereits vorhanden Halterung des Treibers für die Richtfunkantenne zu befestigen.
|
Bei einer Begutachtung des Installationsortes mit dem Personal des Gebäudemanagements wurde die Installation entsprechend der Abbildung \ref{fig:dach_vorher} vorgefunden. Da der verbleibende Raum in dem vorhandenen Installationskasten voraussichtlich nicht für die Installation des gesamten Systems der Referenzstation ausreichend ist, wurde die mündliche Genehmigung erteilt, einen weiteren Installationskasten unter dem bereits vorhanden zu installieren. Um die passende Halterung für einen weiteren Kasten bestimmen zu können, wurde der Durchmesser des Pfostens mit \(90 mm\) festgehalten. Weiterhin wurde über die Position der Antenne gesprochen, das Problem lag darin, dass durch die Luftschächte der Klimatisierung die Antenne zu Teilen vom Himmel abgeschattet wäre, wenn diese direkt an dem vorhandenen Pfosten angebracht würde. Deshalb wurde sich auf darauf geeinigt, dass der Pfosten bis auf die Höhe der Luftschächte mittels eines C-Profils verlängert werden darf. Es wurde vorgeschlagen, das Profil an der bereits vorhanden Halterung des Treibers für die Richtfunkantenne zu befestigen.
|
||||||
|
|
||||||
|
\begin{figure}[ht]
|
||||||
|
\vspace{1cm}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=0.7\linewidth]{img/dach_vorher.jpg}
|
||||||
|
\caption{LoRaWan-Gateway Installation - Bestand}
|
||||||
|
\label{fig:dach_vorher}
|
||||||
|
\end{figure}
|
||||||
|
|
||||||
\section{Computer}
|
\section{Computer}
|
||||||
\label{sec:computer}
|
\label{sec:computer}
|
||||||
Als Server wurde ein PicoSYS 2880 Embedded-PC der Firma Hanzsung mit den folgenden Gehäuseabmessungen !!!xxmm!!! (hbt) ausgewählt. Dieser wird mit einem Intel Celeron J4105 als Prozessor und 4GB Arbeitsspeicher ausgeliefert. Als Schnittstellen stehen USB 2.0 und USB 3.2 Gen 1 sowie RS232, RJ-45 Ethernet, PS2, VGA und HDMI zur Verfügung. Der Computer wird mit einem externen Netzteil mit 12V versorgt, welches über ein Hohlbuchse mit dem Computer verbunden wird. Da der Computer nur über die Buchse mit Strom versorgt werden kann und nicht über den gewünschten PoE-Anschluss verfügt, muss dieser über eine PoE-Splitter mit Strom versorgt werden. Durch die Gegebenheiten muss die Stromaufnahme ins Gesamtsystem passen und daher bekannt sein. Der Verkaufsseite !!!cite!!! kann nur entnommen werden, dass das mitgelieferte Netzteil eine Ausgangsleistung von \(60W\) hat. Da der verbaute Prozessor mit einer Verlustleistung von \(10W\) angegeben wird, scheint das Netzteil überdimensioniert zu sein und gibt keinen Aufschluss über den tatsächlichen Energiebedarf. Daher wurde der Computer an einem Labornetzteil angeschlossen um die Leistungsaufnahme zu messen. Zuvor wurde jedoch der Turbo-Modus des Prozessors, bei welchem die Taktfrequenz von \(1,5GHz\) auf bis zu \(2,5GHz\) angehoben werden kann, deaktiviert. Die Mehrleistung des Prozessors durch diese Technologie wird für den Anwendungsfall nicht benötigt. Während der Messung wurde über das Terminal ein Programm zum stressen der Hardware ausgeführt. Die CPU Auslastung wurde durch ein weiteres Programm beobachtet und lag durchgehend beim Maximum. Zusätzlich wurde das GNSS-Modul angeschlossen und die aktive Antenne an das GNSS-Modul um auch diesen Verbraucher in die Messung einbeziehen zu können. Unter Volllast wurde bei \(12V\) ein Strom von \(0,6A\) gemessen, dies entspricht einer Leistung von \(7,2W\). Auch unter Beachtung von Messtoleranzen kann somit von einer Leistungsaufnahme unter \(10W\) ausgegangen werden, die durch den PoE-Splitter erbracht werden muss. Auf der Rückseite des Computers befinden sich verschiedene Befestigungslöcher mit welchen sich auch die Montage an einer Wand ausführen lässt. Der Betriebstemperaturbereich wird mit \(-10^\circ C\) bis \(60^\circ C\) angegeben. Die Installation des Computers muss in einem vor der Witterung geschützten Bereich erfolgen.
|
Als Server wurde ein PicoSYS 2880 Embedded-PC der Firma Hanzsung mit den folgenden Gehäuseabmessungen 61 mm x 142 mm x 126 mm (hxbxt) ausgewählt. Dieser wird mit einem Intel Celeron J4105 als Prozessor und 4 GB Arbeitsspeicher ausgeliefert. Als Schnittstellen stehen USB 2.0 und USB 3.2 Gen 1 sowie RS232, RJ-45 Ethernet, PS2, VGA und HDMI zur Verfügung. Der Computer wird mit einem externen Netzteil mit 12V versorgt, welches über ein Hohlbuchse mit dem Computer verbunden wird. Da der Computer nur über die Buchse mit Strom versorgt werden kann und nicht über den gewünschten PoE-Anschluss verfügt, muss dieser über einen PoE-Splitter mit Strom versorgt werden. Durch die Gegebenheiten muss die Stromaufnahme ins Gesamtsystem passen und daher bekannt sein. Der Verkaufsseite \cite[]{server} kann nur entnommen werden, dass das mitgelieferte Netzteil eine Ausgangsleistung von \(60W\) hat. Da der verbaute Prozessor mit einer Verlustleistung von \(10W\) angegeben wird, scheint das Netzteil überdimensioniert zu sein und gibt keinen Aufschluss über den tatsächlichen Energiebedarf. Daher wurde der Computer an einem Labornetzteil angeschlossen, um die Leistungsaufnahme zu messen. Zuvor wurde jedoch der Turbo-Modus des Prozessors, bei welchem die Taktfrequenz von \(1,5GHz\) auf bis zu \(2,5GHz\) angehoben werden kann, deaktiviert. Die Mehrleistung des Prozessors durch diese Technologie wird für den Anwendungsfall nicht benötigt. Während der Messung wurde über das Terminal ein Programm zum Stressen der Hardware ausgeführt. Die CPU Auslastung wurde durch ein weiteres Programm beobachtet und lag durchgehend beim Maximum. Zusätzlich wurde das GNSS-Modul angeschlossen und die aktive Antenne an das GNSS-Modul, um auch diesen Verbraucher in die Messung einbeziehen zu können. Unter Volllast wurde bei \(12V\) ein Strom von \(0,6A\) gemessen, dies entspricht einer Leistung von \(7,2W\). Auch unter Beachtung von Messtoleranzen kann somit von einer Leistungsaufnahme unter \(10W\) ausgegangen werden, die durch den PoE-Splitter erbracht werden muss. Auf der Rückseite des Computers befinden sich verschiedene Befestigungslöcher, mit welchen sich auch die Montage an einer Wand ausführen lässt. Der Betriebstemperaturbereich wird mit \(-10^\circ C\) bis \(60^\circ C\) angegeben. Die Installation des Computers muss in einem vor der Witterung geschützten Bereich erfolgen. Der Computer ist in Abbildung \ref{fig:vorbereitetKasten} zu sehen.
|
||||||
!!!Position auf irgendeinem Bild!!!
|
|
||||||
|
|
||||||
\section{PoE-Hardware}
|
\section{PoE-Hardware}
|
||||||
\label{sec:PoE-Hardware}
|
\label{sec:PoE-Hardware}
|
||||||
Das vorhandene Netzwerkkabel mit angelegtem PoE++ wird bereits von dem erwähnten Lora-Gateway genutzt, weshalb die folgenden beiden Komponenten benötigt werden um beiden Installationen Strom zuzuführen und eine Netzwerkverbindung bereitzustellen.
|
Das vorhandene Netzwerkkabel mit angelegtem PoE++ wird bereits von dem erwähnten LoRaWan-Gateway genutzt, weshalb die folgenden beiden Komponenten benötigt werden, um beiden Installationen Strom zuzuführen und eine Netzwerkverbindung bereitzustellen.
|
||||||
|
|
||||||
\subsection{PoE Extender}
|
\subsection{PoE-Extender}
|
||||||
Der gewählte Extender kann als Ethernet-Switch betrachtet werden, der sich selbst über die Stromversorgung des PoE-Kabels am Eingang versorgt und gleichzeitig zwei Ausgangsports bietet, an denen auch PoE anliegt. Die Leistung wird dabei zwischen den beiden Ports aufgeteilt, sodass es sich nach der Aufteilung nur noch um PoE+ Ports handelt. Die verfügbare Leistung je Port würde somit \(30W\) betragen, dies stellt die Versorgung der vorhanden Installation sicher, da im Datenblatt des LoRaWAN Gateway !!!cite Datenblatt!!! eine Stromaufnahme von unter \(10W\) aufgeführt wird.
|
Der gewählte Extender kann als Ethernet-Switch betrachtet werden, der sich selbst über die Stromversorgung des PoE-Kabels am Eingang versorgt und gleichzeitig zwei Ausgangsports bietet, an denen auch PoE anliegt. Die Leistung wird dabei zwischen den beiden Ports aufgeteilt, sodass es sich nach der Aufteilung nur noch um PoE+ Ports handelt. Die verfügbare Leistung je Port würde somit \(30W\) betragen, dies stellt die Versorgung der vorhanden Installation sicher, da im Datenblatt des LoRaWAN Gateways \cite[]{lorawangateway} eine Stromaufnahme von unter \(10W\) aufgeführt wird.
|
||||||
\par
|
\par
|
||||||
Bei dem ausgewählten Geräte handelt es sich um das Modell TI-BE200 von der Firma TRENDnet, welches im Datenblatt als \glqq Industrieller 2-Port Gigabit PoE++ Extender für den
|
Bei dem ausgewählten Geräte handelt es sich um das Modell TI-BE200 von der Firma TRENDnet, welches im Datenblatt als \glqq Industrieller 2-Port Gigabit PoE++ Extender für den
|
||||||
Außenbereich\grqq !!!cite Datenblatt!!! bezeichnet wird. Des weiteren wird die Schutzklasse IP67 und ein Betriebstemperaturbereich von \(-40^\circ C\) bis \(75^\circ C\) angegeben. Das Gehäuse verfügt über Löcher für eine Wandmontage. Für die Montage müssen diese Abmessungen beachtet werden !!!xxmm!!! (hbt).
|
Außenbereich\grqq \cite[]{poeextender} bezeichnet wird. Des Weiteren wird die Schutzklasse IP67 und ein Betriebstemperaturbereich von \(-40^\circ C\) bis \(75^\circ C\) angegeben. Das Gehäuse verfügt über Löcher für eine Wandmontage. Für die Montage müssen diese Abmessungen beachtet werden 44 mm x 74 mm x 167 mm (hxbxt). Die Abbildung \ref{fig:poeextenderkasten} zeigt den installierten PoE-Extender.
|
||||||
!!!Verweis auf Position im Installationsbild!!!
|
|
||||||
|
|
||||||
\subsection{PoE Splitter}
|
\subsection{PoE-Splitter}
|
||||||
Ein PoE-Splitter stellt ein Netzteil für nicht PoE-fähige Geräte dar. Dazu wird die Energieversorgung des PoE-Kabels genutzt um eine gängige Spannung über ein Terminalblock oder ähnlichem auszugeben. Zusätzlich stellt ein Splitter die eine Netzwerkverbindung ohne PoE zur Verfügung.
|
Ein PoE-Splitter stellt ein Netzteil für nicht PoE-fähige Geräte dar. Dazu wird die Energieversorgung des PoE-Kabels genutzt, um eine gängige Spannung über ein Terminalblock oder ähnlichem auszugeben. Zusätzlich stellt ein Splitter, die eine Netzwerkverbindung ohne PoE zur Verfügung.
|
||||||
\par
|
\par
|
||||||
Ausgesucht wurde das Gerät EX-60326 von der Firma Exsys !!!cite Datenblatt!!!. Der Splitter kann einen Betriebstemperaturbereich von \(-40^\circ C\) bis \(80^\circ C\) aufweisen. Die Abmessungen betragen !!!xxmm!!! (hbt). Da allerdings keine Schutzklasse nach IP gegeben ist, muss der Splitter zwingend in einem zusätzlichen Gehäuse verbaut werden. Für die Montage eine vormontierte Hutschienenhalterung angeboten und als alternative eine Platte zur Wandmontage. Die Gleichspannung am Ausgang mit Klemmverschraubungen beträgt \(12V\) und ist auf \(3A\) beziehungsweise \(36W\) beschränkt. Bei der Verwendung in der angestrebten Installation wird die Leistung weiter dadurch begrenzt, dass über das eingehende PoE-Kabel lediglich \(30W\) zur Verfügung stehen. Es besteht jedoch eine ausreichend hohe Differenz zwischen der benötigen und der verfügbaren Leistung, da wie in Abschnitt \ref{sec:computer} beschrieben die maximale Leistungsaufnahme des Computers \(10W\) nicht überschreitet. Der PoE-Splitter ist auf der Abbildung !!!ref!!! ganz links zu sehen.
|
Ausgesucht wurde das Gerät EX-60326 von der Firma Exsys \cite[]{poesplitter}. Der Splitter kann einen Betriebstemperaturbereich von \(-40^\circ C\) bis \(80^\circ C\) aufweisen. Da allerdings keine Schutzklasse nach IP gegeben ist, muss der Splitter zwingend in einem zusätzlichen Gehäuse verbaut werden. Für die Montage eine vormontierte Hutschienenhalterung angeboten und als Alternative eine Platte zur Wandmontage. Die Gleichspannung am Ausgang mit Klemmverschraubungen beträgt \(12V\) und ist auf \(3A\) beziehungsweise \(36W\) beschränkt. Bei der Verwendung in der angestrebten Installation wird die Leistung weiter dadurch begrenzt, dass über das eingehende PoE-Kabel lediglich \(30W\) zur Verfügung stehen. Es besteht jedoch eine ausreichend hohe Differenz zwischen der benötigen und der verfügbaren Leistung, da wie in Abschnitt \ref{sec:computer} beschrieben die maximale Leistungsaufnahme des Computers \(10W\) nicht überschreitet. Der PoE-Splitter ist auf der Abbildung \ref{fig:vorbereitetKasten} ganz links zu sehen.
|
||||||
|
|
||||||
\section{GNSS-Hardware}
|
\section{GNSS-Hardware}
|
||||||
\label{sec:GNSS-Hardware}
|
\label{sec:GNSS-Hardware}
|
||||||
Da der Rover bereits mit einem GNSS-Modul und einer passenden Antenne ausgestattet ist, muss lediglich für die Basisstation weitere Hardware angeschafft werden. Dabei ist zu beachten, dass nicht die gleiche Hardware wie die des Rovers verwendet werden kann, weil GNSS-Modul ZED-F9K lediglich Korrekturdaten für die eigene Positionsbestimmung verarbeiten kann und keine Korrekturdaten für andere GNSS-Module erzeugen kann.
|
Da der Rover bereits mit einem GNSS-Modul und einer passenden Antenne ausgestattet ist, muss lediglich für die Basisstation weitere Hardware angeschafft werden. Dabei ist zu beachten, dass nicht die gleiche Hardware wie die des Rovers verwendet werden kann, weil GNSS-Modul ZED-F9K lediglich Korrekturdaten für die eigene Positionsbestimmung verarbeiten und keine Korrekturdaten für andere GNSS-Module erzeugen kann.
|
||||||
|
|
||||||
\subsubsection{GNSS-Modul}
|
\subsubsection{GNSS-Modul}
|
||||||
Für die Basisstation wurde ein Modul aus der gleichen Produktfamilie gewählt. Die Bezeichnungen unterscheiden sich nur durch das letzten Zeichen. Der U-Blox Chip ZED-F9P !!!Data sheet!!! kann die benötigten Korrekturdaten erzeugen. Für die Integration in das Gesamtsystem wurde das von SparkFun !!!Data sheet!!! kreierte Entwicklungsboard mit dem ZED-F9P ausgewählt. Dieses verfügt, ähnlich wie das GNSS-Board des Rovers, über einen USB-C anschluss, Stiftleisten unter anderem mit I2C, SPI und zwei Serial Ports sowie einer SMA-Buchse für den Anschluss der GNSS-Antenne. Außerdem zeigen auf dem Board angebrachte LEDs an ob Positionsbestimmung zur Zeit möglich ist und ob RTK verwendet wird. Der Betriebstemperaturbereich des ZED-F9P reicht von \(-20^\circ C\) bis \(70^\circ C\) !!!Temperaturen kontrollieren!!!.
|
Für die Basisstation wurde ein Modul aus der gleichen Produktfamilie gewählt. Die Bezeichnungen unterscheiden sich nur durch das letzte Zeichen. Der U-Blox Chip ZED-F9P \cite[]{zed-f9p} kann die benötigten Korrekturdaten erzeugen. Für die Integration in das Gesamtsystem wurde das von SparkFun !!!Data sheet!!! kreierte Entwicklungsboard mit dem ZED-F9P ausgewählt. Dieses verfügt, ähnlich wie das GNSS-Board des Rovers, über einen USB-C-Anschluss, Stiftleisten unter anderem mit I2C, SPI und zwei Serial Ports sowie einer SMA-Buchse für den Anschluss der GNSS-Antenne. Außerdem zeigen auf dem Board angebrachte LEDs an, ob Positionsbestimmung zurzeit möglich ist und ob RTK verwendet wird. Der Betriebstemperaturbereich des ZED-F9P reicht von \(-40^\circ C\) bis \(85^\circ C\).
|
||||||
\par
|
\par
|
||||||
Ausschlaggebenden für die Auswahl dieses Moduls war die einfache Verbindung des Moduls über USB-C mit dem Computer, den passenden Betriebstemperaturbereich und die bereits bekannte Software der Produktfamilie zur Konfiguration des Moduls.
|
Ausschlaggebenden für die Auswahl dieses, in Abbildung \ref{fig:zedf9p} gezeigten, Moduls war die einfache Verbindung des Moduls über USB-C mit dem Computer, den passenden Betriebstemperaturbereich und die bereits bekannte Software der Produktfamilie zur Konfiguration des Moduls.
|
||||||
|
|
||||||
|
\begin{figure}[ht]
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=\linewidth]{img/zed-f9p.jpg}
|
||||||
|
\caption{Das verbaute GNSS Modul von SparkFun mit dem ZED-F9P \protect\footnote[2]{GPS-RTK-SMA Breakout von Sparkfun, lizenziert unter [CC BY 2.0] \url{https://creativecommons.org/licenses/by/2.0/legalcode.en}, abgerufen von \url{https://www.sparkfun.com/products/16481}}}
|
||||||
|
\label{fig:zedf9p}
|
||||||
|
\end{figure}
|
||||||
|
|
||||||
\subsubsection{GNSS-Antenne}
|
\subsubsection{GNSS-Antenne}
|
||||||
Bei der gewählten Antenne handelt es sich um das Modell JCA228F von der Firma Jinchang Electron. !!!Data cheet!!! Diese wird als GNSS Multi-Band Surveying Antenne vermarktet und eignet sich besonders für den stationären Einsatz als Referenzstation. Die Antenne erfüllt die Anforderungen der IP 67 Schutzklasse und ist zusätzlich mit dem Betriebstemperaturbereich von \(-40^\circ C\) bis \(85^\circ C\) für ganzjährigen ungeschützten Einsatz im freien geeignet. Da es sich um eine aktive Antenne handelt, wird diese über das GNSS-Modul mit Strom versorgt, dabei sind Gleichspannungen von \(3V - 12V\) zulässig. Die Stromaufnahme wird mit kleinergleich \(50mA\) angegeben. Es werden alle Frequenzbänder der aktuellen GNSS unterstützt. Die Montage erfolgt in dem die Antenne auf eine 5/8 Zoll Schraube mit 11 Gewindegängen pro Zoll nach dem amerikanischen UNC (5/8''-11UNC) Standard aufgeschraubt wird. An der Antenne befindet sich eine TNC-Buchse zur Verbindung mit dem GNSS-Modul, da sich die Anschlüsse unterscheiden braucht es ein Adapterkabel, welches mit einem TNC-Stecker und einem SMA-Stecker endet. Das erworbene Antennenkabel weißt eint Länge von \(2,5m\) auf. !!!Bild der Antenne?!!!
|
Bei der gewählten Antenne handelt es sich um das Modell JCA228F von der Firma Jinchang Electron. !!!Data cheet!!! Diese wird als GNSS Multi-Band Surveying Antenne vermarktet und eignet sich besonders für den stationären Einsatz als Referenzstation. Die Antenne erfüllt die Anforderungen der IP 67 Schutzklasse und ist zusätzlich mit dem Betriebstemperaturbereich von \(-40^\circ C\) bis \(85^\circ C\) für ganzjährigen ungeschützten Einsatz im Freien geeignet. Da es sich um eine aktive Antenne handelt, wird diese über das GNSS-Modul mit Strom versorgt, dabei sind Gleichspannungen von \(3V - 12V\) zulässig. Die Stromaufnahme wird mit kleiner gleich \(50mA\) angegeben. Es werden alle Frequenzbänder der aktuellen GNSS unterstützt. Die Montage erfolgt, in dem die Antenne auf eine \(\frac{5}{8}\) Zoll Schraube mit 11 Gewindegängen pro Zoll nach dem amerikanischen UNC (5/8''-11UNC) Standard aufgeschraubt wird. An der Antenne befindet sich eine TNC-Buchse zur Verbindung mit dem GNSS-Modul, da sich die Anschlüsse unterscheiden braucht es ein Adapterkabel, welches mit einem TNC-Stecker und einem SMA-Stecker endet. Das erworbene Antennenkabel weist eine Länge von \(2,5m\) auf. !!!Bild der Antenne?!!!
|
||||||
|
|
||||||
\section{Installationskasten}
|
\section{Installationskasten}
|
||||||
Für Installation der nicht wasserfesten Komponenten wird ein Installationskasten benötigt, um diese zu schützen. Für ein Einheitlicheres Bild wurde ein Kasten von der selben Firma, wie der vorhandene Gewählt. Allerdings wurde für günstigere Temperaturen in dem Kasten die helle Ausführung gewählt. Bei dem Installationskasten handelt es sich um den KF 5000 H von der Firma Hensel. Laut des Datenblatts \cite{kasten} verfügt dieser über die Schutzklassen IP66, TP67 und IP69. Unter dem Punkt Umgebungsbedingungen wird als Einsatzgebiet die ungeschützte Installation genannt, dabei ist die Umgebungstemperatur von \(-25^\circ C\) bis \(70^\circ C\) angegeben. Als Ausnahme wird die maximale Umgebungstemperatur über 24 Stunden mit \(55^\circ C\) angegeben. Durch diese Eigenschaften ist der Kasten für die Dachinstallation geeignet.
|
Für Installation der nicht wasserfesten Komponenten wird ein Installationskasten benötigt, um diese zu schützen. Für ein einheitlicheres Bild wurde ein Kasten von derselben Firma, wie der vorhandene Gewählt. Allerdings wurde für günstigere Temperaturen in dem Kasten die helle Ausführung gewählt. Bei dem Installationskasten handelt es sich um den KF 5000 H von der Firma Hensel. Laut des Datenblatts \cite{kasten} verfügt dieser über die Schutzklassen IP66, TP67 und IP69. Unter dem Punkt Umgebungsbedingungen wird als Einsatzgebiet die ungeschützte Installation genannt, dabei ist die Umgebungstemperatur von \(-25^\circ C\) bis \(70^\circ C\) angegeben. Als Ausnahme wird die maximale Umgebungstemperatur über 24 Stunden mit \(55^\circ C\) angegeben. Durch diese Eigenschaften ist der Kasten für die Dachinstallation geeignet.
|
||||||
\par
|
\par
|
||||||
Die Innenmaße bieten bei einer hochkantigen Ausrichtung einen Installationsraum von 320x215x106mm (hbt). Somit lassen sich der Computer, der PoE-Splitter und das GNSS-Modul nebeneinander Platzieren. Die Montage soll auf einer Hutschiene stattfinden, die dem Kasten noch hinzugefügt wird. Außerdem müssen für den Computer und das GNSS-Modul entsprechende Halterungen geschaffen werden.
|
Die Innenmaße bieten bei einer hochkantigen Ausrichtung einen Installationsraum von 320x215x106mm (hxbxt). Somit lassen sich der Computer, der PoE-Splitter und das GNSS-Modul nebeneinander platzieren. Die Montage soll auf einer Hutschiene stattfinden, die dem Kasten noch hinzugefügt wird. Außerdem müssen für den Computer und das GNSS-Modul entsprechende Halterungen geschaffen werden.
|
||||||
|
|
||||||
\section{Gyroskop}
|
\section{Gyroskop}
|
||||||
\label{sec:gyroskop}
|
\label{sec:gyroskop}
|
||||||
Die Anforderung ein Gyroskop zu integrieren soll durch das GY-521 Modul !!!data sheet!!! von AZ-Delivery erfüllt werden. Auf dem Modul ist ein Chip mit der Bezeichnung MPU-6050 aufgelötet. Dieser vereinigt einen 3-Achsen Gyroskop und eine 3-Achsen Beschleunigungssensor. Das Gyroskop kann auf den Bereich der erwarteten Winkelgeschwindigkeiten eingestellt werden, diese reichen von \(\pm 250^\circ/sec\) bis \(\pm 2000^\circ/sec\). Der Beschleunigungssensor ist ebenfalls anpassbar, von \(\pm 2g\) bis \(\pm 16g\). Die Analogen Werte der Sensoren werden mit 16-bit ADC digitalisiert. Des weiteren verfügt der MPU-6050 über einen Digital Motion Processor (DPM), dieser kann zu den vom Sensor erzeugten 6-Achsen zusätzlich die 3-Achsen von einem extern über I2C angeschlossenen Magnetometer verrechnen. Die Daten, welche durch diese Sensorfusion entstehen erhöhen die Genauigkeit, ergeben ein Zugewinn an Information bezüglich der Ausrichtung des Chips und erlauben es dem Nutzer diese zentral abzurufen.
|
Die Anforderung ein Gyroskop zu integrieren soll durch das GY-521 Modul !!!data sheet!!! von AZ-Delivery erfüllt werden. Auf dem Modul ist ein Chip mit der Bezeichnung MPU-6050 aufgelötet. Dieser vereinigt einen 3-Achsen Gyroskop und eine 3-Achsen Beschleunigungssensor. Das Gyroskop kann auf den Bereich der erwarteten Winkelgeschwindigkeiten eingestellt werden, diese reichen von \(\pm 250^\circ/sec\) bis \(\pm 2000^\circ/sec\). Der Beschleunigungssensor ist ebenfalls anpassbar, von \(\pm 2g\) bis \(\pm 16g\). Die analogen Werte der Sensoren werden mit 16-Bit ADC digitalisiert. Des Weiteren verfügt der MPU-6050 über einen Digital Motion Processor (DMP), dieser kann zu den vom Sensor erzeugten 6-Achsen zusätzlich die 3-Achsen von einem extern über I2C angeschlossenen Magnetometer verrechnen. Die Daten, welche durch diese Sensorfusion entstehen, erhöhen die Genauigkeit, ergeben ein Zugewinn an Information bezüglich der Ausrichtung des Chips und erlauben es dem Nutzer diese zentral abzurufen.
|
||||||
\par
|
\par
|
||||||
Die Kommunikation findet über I2C statt, dies ermöglicht die Einbindung des Sensors in das bestehende System. Durch das Board von AZ-Delivery, ist eine Versorgung mit der gegebenen Spannung von \(5V\) möglich. Der bereits verbaute Kompass könnte vom ESP32 getrennt werden und an das GY-521 Modul angeschlossen werden.
|
Die Kommunikation findet über I2C statt, dies ermöglicht die Einbindung des Sensors in das bestehende System. Durch das Board von AZ-Delivery ist eine Versorgung mit der gegebenen Spannung von \(5V\) möglich. Der bereits verbaute Kompass könnte vom ESP32 getrennt und an das GY-521 Modul angeschlossen werden.
|
||||||
|
|||||||
@@ -0,0 +1,2 @@
|
|||||||
|
\chapter{Implementierung}
|
||||||
|
Im folgenden Teil dieser Arbeit wird auf den Aufbau der Basisstation eingegangen, dabei wird der mechanische Aufbau sowie die Implementierung und Einrichtung der Station erläutert. Außerdem werden die Erweiterungen des Rovers ausführlich beschrieben, dazu gehören die Implementierung weiterer Softwarekomponenten sowie der Einbau des GY-521 Moduls (siehe Abschnitt \ref{sec:gyroskop}).
|
||||||
@@ -0,0 +1,98 @@
|
|||||||
|
|
||||||
|
\section{Basisstation}
|
||||||
|
\label{sec:Basisstation}
|
||||||
|
Für die Errichtung der Referenzstation stellte sich zunächst die Frage, wie das System aufgebaut werden soll. Dabei sind die bereits beschriebenen Anforderungen im Abschnitt \ref{sec:referenzstation_req} entstanden. Um das System den Anforderungen entsprechend erstellen zu können wurde die Hardwareauswahl in dem vorangegangenen Kapitel \ref{cha:Hardwareauswahl} bereits beschrieben. Deshalb wird in diesem Abschnitt die noch fehlende Installation und Konfiguration der Komponenten thematisiert. Darüber hinaus werden für die vollständige Montage Formteile benötigt, welche mit einem 3D-Drucker produziert werden sollen.
|
||||||
|
|
||||||
|
\subsection{Installation Betriebssystem}
|
||||||
|
Im ersten Schritt muss der Server betriebsbereit gemacht werden, dafür muss ein Betriebssystem installiert werden. Dazu soll das in Unterabschnitt \ref{ssec:debian} beschriebene Debian genutzt werden.
|
||||||
|
\par
|
||||||
|
Da der Server über übliche Anschlüsse für einen Monitor verfügt, kann die Installation über den Installationsassistenten mittels Tastatur und Bildschirm durchgeführt werden. Dafür wurde die iso-Datei von Debian so auf einen USB-Stick geschrieben, dass dieser Bootfähig ist. Während der Installation wurden die meisten Einstellungen bei ihrem Standard belassen.
|
||||||
|
\par
|
||||||
|
Nach der erfolgreichen Installation des Betriebssystems wurde sich zunächst als root Benutzer angemeldet, um die ersten grundlegenden Einstellungen zu tätigen.
|
||||||
|
|
||||||
|
\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 zweite Datei ist unter dem Pfad \url{/etc/resolv.conf} zu finden. In diese Datei müssen die zu benutzen DNS-Server eingetragen werden. In jeder Zeile kann ein Eintrag getätigt werden. In diesem Fall nach dem Muster \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 !!!command!!! oder einem Neustart des Computers erfolgen.
|
||||||
|
|
||||||
|
\subsubsection{sudo}
|
||||||
|
Sudo ist ein Programm aus den Paketquellen von Debian, dass es anderen Nutzern erlauben kann Befehle mit root-Rechten auszuführen. Diese Vorgehensweise empfiehlt sich, damit nicht alle Befehle automatisch mit root-Rechten ausgeführt werden und das vollständige System über ein normales Benutzerkonto gesteuert werden kann. Das Paket kann mit dem Paketverwaltungstool \mintinline{bash}|apt-get| installiert werden. Davor sollten die Paketquellen jedoch aktualisiert und möglich Paketupdates installiert werden. Um die Aktualisierung und die Installation auszuführen müssen diese Befehle ausgeführt werden:
|
||||||
|
|
||||||
|
\begin{minted}[linenos, gobble=5]{bash}
|
||||||
|
apt-get update
|
||||||
|
apt-get upgrade
|
||||||
|
apt-get install sudo
|
||||||
|
\end{minted}
|
||||||
|
|
||||||
|
Im Anschluss müssen die Benutzer welche neben dem root-Benutzer ebenfalls Befehle mit erweiterten Rechten ausführen können sollen in die Benutzergruppe \mintinline{text}|sudo???| hinzugefügt werden. Für den bei der Installation automatisch erstellen Benutzer \mintinline{text}|rtk| sieht der Befehl wie folgt aus: \mintinline{text}|usermod -aG sudo rtk???|.
|
||||||
|
Danach wird der root-Account abgemeldet und nur noch der rtk-Benutzer verwendet. Befehle können nun mit einem vorangestellten \mintinline{bash}|sudo| als Administrator ausgeführt werden.
|
||||||
|
|
||||||
|
\subsubsection{ssh-server}
|
||||||
|
Der SSH-Server wird ebenfalls über die Paketquellen installiert, der Paketname entspricht der Überschrift dieses Abschnitts. Mit einem SSH-Server wird die Verwaltung des System über das Netzwerk ermöglicht und damit der Zugriff auf das Terminal erheblich zu vereinfacht. Der Server kann in mit den Standardeinstellungen betrieben werden, für eine erhöhte Sicherheit wird jedoch der Login mit dem root-Account verboten. Dafür wird in der Konfigurationsdatei (\url{/etc/ssh/sshd_config}) die Zeile \mintinline{text}|PermitRootLogin no| ergänzt und der SSH-Server anschließend mit \mintinline{bash}|sudo service sshd restart| neugestartet.
|
||||||
|
\par
|
||||||
|
Ab diesem Zeitpunkt der Installation kann der Server headless betrieben werden. Es ist nur noch eine die Netzwerkverbindung und die Stromversorgung notwendig. Zum einloggen wird ein SSH-Client, die Zugangsdaten und die Adresse des Servers benötigt.
|
||||||
|
|
||||||
|
\subsection{ser2net vorbereiten}
|
||||||
|
Die Konfiguration der GNSS-Module von U-Blox lässt sich am einfachsten mit dem u-center (siehe Abschnitt \ref{sssec:u-blox}) erledigen. Da das u-center ausschließlich unter Windows verfügbar und ein Programm mit grafischer Oberfläche ist, kann es nicht auf dem Server ausgeführt werden. Allerdings ist es nicht praktikabel das GNSS-Modul aus dem System der Referenzstation zu entfernen, um es an einem anderen Computer zu konfigurieren. Deshalb bietet sich die Installation von ser2net an, damit die Verbindung zwischen dem u-center und dem GNSS-Modul über eine Netzwerkverbindung aufgebaut werden kann.
|
||||||
|
\par
|
||||||
|
Die Installation erfolgt über die Paketquellen mit \mintinline{bash}|sudo apt-get install ser2net|. Das Programm wird dem Betriebssystem als Service hinzugefügt und läuft damit ständig. Da die Verbindung nur zur Verfügung stehen soll wenn diese auch benötigt wird, kann der automatische Start des Service beim Bootvorgang mit dem Befehl
|
||||||
|
|
||||||
|
\begin{minted}[linenos, gobble=4]{bash}
|
||||||
|
sudo systemctl disable ser2net
|
||||||
|
\end{minted}
|
||||||
|
|
||||||
|
deaktiviert werden. Die nächsten beiden Befehle sind zum stoppen und starten des Services. Nach der Deaktivierung läuft der Service weiter bis der Computer neugestartet wird oder der Service mit dem ersten Befehl gestoppt wird.
|
||||||
|
|
||||||
|
\begin{minted}[linenos, gobble=4]{bash}
|
||||||
|
sudo systemctl stop ser2net
|
||||||
|
sudo systemctl start ser2net
|
||||||
|
\end{minted}
|
||||||
|
|
||||||
|
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 wird 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}
|
||||||
|
|
||||||
|
Sollte der Service zum Zeitpunkt der Konfiguration aktiv gewesen sein, muss es mit dem genannten Befehl gestoppt werden 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.
|
||||||
|
|
||||||
|
\subsection{RTKLib installieren}
|
||||||
|
Die in den Grundlagen unter \ref{sssec:rtklib} beschriebene RTKLib ist nicht über die Paketquellen verfügbar und muss deshalb auf dem Server kompiliert werden. Um das Projekt von GitHub clonen zu können muss Git installiert werden. Außerdem wird als Abhängigkeit die Bibliothek \mintinline[]{text}|libpng-dev| benötigt. Der Compiler inklusive weiterer benötigter Tools wie \mintinline[]{text}|make| ist in dem Paket \mintinline[]{text}|build-essential| enthalten. Für die vollständige Installation wird die folgende Befehlsfolge in dem Home-Verzeichnis des rtk-Benutzers benötigt:
|
||||||
|
|
||||||
|
\begin{minted}[linenos, gobble=4]{bash}
|
||||||
|
sudo apt-get update
|
||||||
|
sudo apt-get install git
|
||||||
|
sudo apt-get install libpng-dev
|
||||||
|
sudo apt-get install build-essential
|
||||||
|
|
||||||
|
git clone https://github.com/rtklibexplorer/RTKLIB.git
|
||||||
|
cd RTKLIB/app/consapp/
|
||||||
|
make
|
||||||
|
make install
|
||||||
|
\end{minted}
|
||||||
|
|
||||||
|
\subsection{Dachinstallation}
|
||||||
|
Die Installation auf dem Dach wurde in ihren groben Zügen bei der in der Einleitung des Kapitels \ref{cha:Hardwareauswahl} beschriebenen Begehung des Installationsortes geplant. Von diesem Plan wurde die in dem Kapitel folgende Hardwareauswahl abgeleitet. Im ersten Schritt sollen nun alle Vorbereitungen getroffen werden, welche von dem Installationsort unabhängig sind. Im Anschluss wird die eigentliche Montage auf dem Dach vorgenommen.
|
||||||
|
|
||||||
|
\subsubsection{Befestigungen}
|
||||||
|
Die anzubringenden Komponenten benötigen Halterungen und Befestigungspunkte. Diese werden im folgenden Beschrieben:
|
||||||
|
|
||||||
|
\begin{itemize}
|
||||||
|
\item die \textbf{Antenne} soll am Ende des C-Profils welches zur Verlängerung des Pfostens dient befestigt werden. Dafür wurde ein Formteil konstruiert (siehe Abbildung !!!). Im wesentlichen besteht diesel Teil aus einem Quader, welcher in das C-Profil eingeführt werden kann. Der Quader verfügt über eine Bohrung, damit dieser mittels einer Schrauben-Mutter-Kombination am C-Profil fixiert werden kann. Am oberen Ende befindet sich ein Gewinde auf welches die Antenne aufgeschraubt werden kann,
|
||||||
|
|
||||||
|
\item der \textbf{Installationskasten} soll unterhalb des vorhandenen Kastens am Pfosten angebracht werden. Als Maße stehen der gemessene Durchmesser des Pfostens (\(90mm\)) und der aus dem Datenblatt !!!cite!!! verfügbare Lochabstand der Befestigungslöcher des Kastens. Mit diesen Werten konnte eine Halterung konstruiert werden, welche aus zwei Halbschalen besteht. Ein Halbschale verfügt über abstehende Arme mit vorhandenen Löchern für M!!!-Schrauben, an denen der Kasten befestigt werden kann. Die M!!!-Schrauben können von hinten mit der passenden Mutter gesichert werden. In die gleich Halbschale können passgenau M8-Muttern eingelegt werden. Die andere Halbschale verfügt über die Löcher und Vertiefungen um diese mit zwei M8-Schrauben an der anderen Halbschale befestigen zu können. Die Halterungen wurde für den oberen und den unteren Teil des Kastens jeweils einmal ausgedruckt. Eine Halterung ist in Abbildung !!!ref!!! zu sehen,
|
||||||
|
|
||||||
|
\item für den \textbf{Server} wird eine Halterung benötigt, damit dieser an der Hutschiene im Installationskasten befestigt werden kann. Es bot sich an die mitgelieferten Winkel und Schrauben von dem Computer in die Konstruktion mit einzubeziehen. Die Winkel sind für die Wandmontage gedacht und werden nach Herstellervorgaben auf der Rückseite des Computers befestigt, so dass nach der Montage der Winkel Befestigungspunkte neben Computer benutzbar sind. Die Winkel haben einen Versatz, der den Computer theoretisch etwas von der Wand hervorstehen lassen würde. Um die Befestigung an der Hutschiene zu ermöglichen, wurden die Winkel um \(180^\circ\) verdreht. Dadurch entsteht auf der Rückseite der Computer ein breites Trapez mit geringer Höhe. Diese Form wurde als Grundplatte für den Adapter genutzt. Auf dieser Grundplatte befinden sich neben der Aufnahme für die Hutschiene herausstehende Kegel, welche genutzt werden um den Adapter mittels der am Winkel vorgesehenen Löcher zur Wandmontage zu fixieren, !!!Bild?!!!
|
||||||
|
|
||||||
|
\item die letzte Konstruktion soll das \textbf{GNSS-Modul} ebenfalls an der Hutschiene fixieren. Das Formteil ist ein etwas in die Länge gezogene Quader. An einem Ende befindet sich der Mechanismus für die Hutschiene. Für das Modul ist eine Vertiefung mit Aussparungen für die Anschlüsse eingefügt worden. Das Modul wird durch das Einschieben einer Deckplatte gesichert. Das Formteil wird in Abbildung !!!ref!!! gezeigt.
|
||||||
|
\end{itemize}
|
||||||
@@ -0,0 +1,116 @@
|
|||||||
|
\subsubsection{Installationskasten bestücken}
|
||||||
|
Der Installationskasten kann weitgehend vorbereitet werden. Dafür wurden zunächst ein Loch an der unteren Seite gebohrt, welches groß genug ist um ein RJ45-Stecker durchzuführen. Weiterhin wurde die Hutschiene außer mittig positioniert, damit im unteren Raum mehr Platz für Kabel bleibt. Danach wurden die beiden Halbschalen an der Rückseite des Kastens befestigt, weil die Löcher für die Befestigungen durch die Komponenten teilweise verdeckt werden. Anschließend konnten die Komponenten an der Hutschiene befestigt werden. Die Komponenten wurden rechtsbündig verbaut. Dabei wurde der PoE-Splitter links neben dem Server und das GNSS-Modul rechts neben dem Server eingehackt. Diese beiden Komponenten auf je eine Seite des Computers zu befestigen, vereinfacht die Kabelführung. Der PoE-Splitter befindet sich auf der linken Seite, weil dieser die beste Klemmwirkung an der Hutschiene aufweist und so das verrücken der anderen Komponenten verhindert.
|
||||||
|
\par
|
||||||
|
Um den Computer über den PoE-Splitter mit Strom zu versorgen wurde ein Kabel mit einem Hohlbuchsenstecker konfektioniert. Das andere Ende des Kabels wurde verzinnt und an dem Blockterminal des Splitters angebracht. Das Netzwerkkabel von dem PoE-Splitter zu dem Server konnte ebenfalls schon eingesetzt werden. Mit einem USB-C auf USB-A Kabel wurde die Verbindung zwischen dem GNSS-Modul und dem Server hergestellt. Das Antennenkabel wurde durch das gebohrte Loch geführt und an dem GNSS-Modul angeschraubt. Der vorbereitete Installationskasten wird in Abbildung \ref{fig:vorbereitetKasten} dargestellt.
|
||||||
|
\par
|
||||||
|
Als weitere Vorbereitung wurden weitere benötigte Netzwerkkabel bereitgelegt und Adapter für die Antennenmontage wurde an dem C-Profil befestigt.
|
||||||
|
|
||||||
|
\begin{figure}[ht]
|
||||||
|
\vspace{1cm}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=0.5\linewidth]{img/installationskasten.png}
|
||||||
|
\caption{Der für die Montage vorbereitete Installationskasten}
|
||||||
|
\label{fig:vorbereitetKasten}
|
||||||
|
\end{figure}
|
||||||
|
|
||||||
|
\subsubsection{Montage}
|
||||||
|
Die Montage began mit der Befestigung des Installationskastens, dafür wurde in je eine Halbschale ein griffiges Klebeband eingebracht, um den Halt zu verbessern. Der Kasten wurde an den Pfosten gehalten und durch die dazugehörigen Halbschalen fixiert. Daraufhin wurde die Antenne an dem C-Profil befestigt und das Antennenkabel angeschlossenen. Das C-Profil wurde an den bei der Begehung besprochen Befestigungspunkten angebracht. Das Antennenkabel wurde mit Kabelbindern an dem C-Profil befestigt.
|
||||||
|
\par
|
||||||
|
Als nächstes musste der PoE-Extender in den vorhanden Anschlusskasten eingebracht werden. Dieser wurde ebenfalls an der Hutschiene befestigt. Das von dem !!!DragiLoRaWAN-Gateway?!!! kommende Ethernetkabel wurde aus der Hutschienen-RJ45-Buchse entnommen und in mit dem ersten Ausgang des Extenders verbunden. Der Eingang wurde mit dem nun freien Port an der Hutschiene verbunden. Danach wurde kontrolliert, ob der vorhandene System wieder einsatzbereit ist. Für die letzte herzustellende Verbindung zwischen dem Poe-Extender und dem Poe-Splitter, musste das Loch in dem vorhanden Installationskasten etwas aufgebohrt werden. Danach konnte das Kabel verlegt werden, wobei die überschüssige Länge des Kabel im neuen Installationskasten aufgewickelt wurde. Die Abbildung \ref{fig:poeextenderkasten} zeigt den verbauten Extender im Installationskasten. Durch die Betriebs-LED des Servers und den LEDs des Netzwerkinterfaces konnte schon während der Installation festgestellt werden, dass der Server mit Strom versorgt wird und einen Link aufbauen konnten.
|
||||||
|
|
||||||
|
\begin{figure}[ht]
|
||||||
|
\vspace{1cm}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=0.5\linewidth]{img/extenderkasten.png}
|
||||||
|
\caption{Vorhandener Installationskasten mit eingebrachtem PoE-Extender}
|
||||||
|
\label{fig:poeextenderkasten}
|
||||||
|
\end{figure}
|
||||||
|
|
||||||
|
\subsection{Antennenposition bestimmen}
|
||||||
|
Die nun folgenden Schritte wurde alle von einem Remote-Arbeitsplatz durchgeführt.
|
||||||
|
\par
|
||||||
|
Damit die Antennenposition bestimmt werden kann sind im grundlegenden drei Schritte notwendig:
|
||||||
|
|
||||||
|
\setlist{noitemsep}
|
||||||
|
\begin{enumerate}
|
||||||
|
\item Rohdaten des GNSS-Moduls aufzeichnen,
|
||||||
|
\item die Rohdaten in das RINEX-Format konvertieren
|
||||||
|
\item und die Daten von einem Post Processing Dienst auswerten lassen.
|
||||||
|
\end{enumerate}
|
||||||
|
\setlist{}
|
||||||
|
|
||||||
|
Damit die Rohdaten aufgezeichnet werden können, muss das Modul so konfiguriert werden, dass es diese ausgibt. Dafür wird das u-center und die Verbindung über ser2net genutzt. Die dafür benötigte Installation unter Windows, sowie die grundlegende Nutzung vom u-center wird im Anhang \ref{cha:winAndUcenter} beschrieben. Im u-center muss der Nachrichtentyp RAWX und RAW!!!?!!! für die USB-Schnittstelle aktiviert werden. Ob die benötigten Daten gesendet werden kann in !!!Packet-View?!!! kontrolliert werden.
|
||||||
|
\par
|
||||||
|
Die Aufzeichnung der Daten übernimmt der Kommunikations-Server der RTKLib. Das Programm heißt in der Kommandozeilenversion \mintinline[]{text}|STR2STR| und kann einen Dateneingang auf mehrere Datenausgänge übertragen. In diesem Fall werden die Daten des GNSS-Moduls in eine Datei geschrieben. Die meisten Post Processing Dienst verarbeiten bis zu 24 Stunden Aufzeichnungslänge, deshalb wird für die höchste Genauigkeit genau diese Dauer für die Einmessung verwendet. Die Länge der Aufzeichnung wird über den \mintinline[]{bash}|timeout| Befehl gesteuert. Damit die Aufzeichnung nicht als Kind-Prozess der Remote-Sitzung läuft wird das Hilfsprogramm \mintinline[]{bash}|screen| installiert, da ansonsten ein Abbruch der Verbindung auch die Aufzeichnung frühzeitig beenden würde. Aus dieser Beschreibung ergibt sich diese Befehlsfolge:
|
||||||
|
|
||||||
|
\begin{minted}[linenos, gobble=4, breaklines]{bash}
|
||||||
|
sudo apt-get update
|
||||||
|
sudo apt-get install screen
|
||||||
|
|
||||||
|
screen
|
||||||
|
|
||||||
|
cd ~
|
||||||
|
timeout 24h ./RTKLIB/app/consapp/str2str/gcc/str2str -in serial://ttyACM0:9600:8:n:1:off -out observation.ubx
|
||||||
|
\end{minted}
|
||||||
|
|
||||||
|
Die screen-Sitzung kann mit der Tastenkombinationen \keys{\ctrl + A} gefolgt von \keys{D} verlassen werden.
|
||||||
|
\par
|
||||||
|
Sobald die Aufzeichnung beendet ist, müssen die Daten in das allgemeingültige RINEX-Format umgewandelt werden. Dafür bietet die RTKLib einen RINEX Konverter an. Zur Benutzung im Terminal muss das Programm \mintinline[]{bash}|convbin| aufgerufen werden. Die Konvertierung erfolgt mit:
|
||||||
|
|
||||||
|
\begin{minted}[linenos, gobble=4, breaklines]{bash}
|
||||||
|
cd ~
|
||||||
|
./RTKLIB/app/consapp/convbin/gcc/convbin -od -os -oi -ot -ti 30 observation.ubx
|
||||||
|
\end{minted}
|
||||||
|
|
||||||
|
Für die Erklärung der verwendeten Optionen folgt ein Ausschnitt aus dem Manual der RTKLib !!!cite!!!:
|
||||||
|
|
||||||
|
\setlist{noitemsep}
|
||||||
|
\begin{itemize}[label=-]
|
||||||
|
\item od include doppler frequency in rinex obs
|
||||||
|
\item os include snr in rinex obs
|
||||||
|
\item oi include iono correction in rinex nav header
|
||||||
|
\item ot include time correction in rinex nav header
|
||||||
|
\item ti tint observation data interval (s)
|
||||||
|
\end{itemize}
|
||||||
|
\setlist{}
|
||||||
|
|
||||||
|
Die umgewandelte Datei muss als nächstes zu einem Post Processing Dienst übermittelt werden, der gewählte Dienst erhält die Daten über ein Formular im Browser, deshalb ist die einfachste Variante die Datei \url{ubservation.obs} auf einen Rechner mit einer Desktopumgebung zu kopieren. Dafür wurde die Datei mit dem Programm \mintinline[]{bash}|scp| über ssh kopiert.
|
||||||
|
\par
|
||||||
|
Nach einigen Stunden wird die Auswertung per E-Mail versandt. In dem erhaltenen Archiv befinden sich eine PDF (siehe Anhang \ref{cha:auswerungObservation}) in der die Auswertung grafisch veranschaulicht wird und neben anderen Dateien die Datei \url{observation.sum}. In dieser wird ab Zeile 69 die Position der Antenne im Erdkoordinatensystem angegeben. Zusätzlich werden geschätzt Genauigkeiten angegeben, diese liegen je nach Achse zwischen \(1,8mm\) und \(5,2mm\).
|
||||||
|
\par
|
||||||
|
Die Koordinaten für X, Y und Z müssen nun über das u-center in das GNSS-Modul programmiert werden. Dafür muss in der Konfigurationsansicht der TMODE ausgewählt werden. In den Einstellungen des TMODE muss der Modus auf \texttt{fixed} eingestellt werden, danach können die Koordinaten im gleichen Fenster eingetragen werden. Damit das Modul auch die Korrekturdaten ausgibt kann ich das Fenster zur Konfiguration der Nachrichten gewechselt werden. Dort sollten die Nachrichten für die Rohdaten wieder entfernt werden, um das Datenaufkommen zu reduzieren. Danach können die RTCM3 Nachrichten mit den Nummern 1005, 1074, 1084, 1094, 1124 und 1230 aktiviert werden. Ob die Konfiguration erfolgreich war kann wieder im Packet View Fenster kontrolliert werden. Diese Finale Konfiguration des Moduls sollte in den Flash des Moduls geschrieben werden um auch über einen neustart hinweg verfügbar zu sein. Dafür kann in der Menüleiste der Punkt !!!?!!! ausgewählt werden.
|
||||||
|
|
||||||
|
\subsection{Service einrichten}
|
||||||
|
\label{ssec:pushService}
|
||||||
|
Die von dem GNSS-Modul generierten Korrekturdaten müssen kontinuierlich an den Ntrip-Caster weitergeleitet werden. Dafür wird der bereits zuvor genutzte Kommunikationsserver der RTKLib verwendet. Als Ausgang wird anstelle der Datei nun der Ntrip-Caster angegeben.
|
||||||
|
\par
|
||||||
|
Damit die Ausgabe automatisch protokolliert wird und der Kommunikationsserver auch nach einem Neustart des Servers automatisch startet wird dem Betriebssystem ein Service hinzugefügt. Dafür muss eine Datei mit root-Rechten und der Endung \texttt{.service}, welche den Service definiert unter dem Pfad \url{/etc/systemd/system} erstellt werden. Der Inhalt der erstellten Datei \texttt{rtk.service} sieht wie folgt aus:
|
||||||
|
|
||||||
|
\begin{minted}[linenos, gobble=4, breaklines]{bash}
|
||||||
|
[Unit]
|
||||||
|
Description=Push RTCM correction data from serial to caster
|
||||||
|
After=network-online.target
|
||||||
|
|
||||||
|
[Service]
|
||||||
|
Type=simple
|
||||||
|
ExecStart=/home/rtk/pushRtcm2Caster.sh
|
||||||
|
|
||||||
|
[Install]
|
||||||
|
WantedBy=multi-user.target
|
||||||
|
\end{minted}
|
||||||
|
|
||||||
|
Das auszuführende Skript enthält zum aktuellen Zeitpunkt lediglich den Aufruf des Kommunikationsservers mit den benötigten Parametern.
|
||||||
|
|
||||||
|
\begin{minted}[linenos, gobble=4, breaklines]{bash}
|
||||||
|
#!/bin/bash
|
||||||
|
/home/rtk/RTKLIB/app/consapp/str2str/gcc/str2str -in serial://ttyACM0:9600:8:n:1:off -out ntrips://:password@rtk2go.com:2101/GER-Dortmund
|
||||||
|
\end{minted}
|
||||||
|
|
||||||
|
Anschließend muss der Service aktiviert und gestartet werden.
|
||||||
|
|
||||||
|
\begin{minted}[linenos, gobble=4, breaklines]{bash}
|
||||||
|
sudo systemctl activate rtk
|
||||||
|
sudo systemctl start rtk
|
||||||
|
\end{minted}
|
||||||
|
|
||||||
|
In den Logs kann die übermittelte Datenmenge oder auftretende Fehler betrachtet werden. Wenn der Caster die Daten akzeptiert, erscheint der zuvor bei rtk2go registrierte Mount Point \texttt{GER-Dortmund} in der Mount Point Tabelle unter \url{rtk2go.com:2101}
|
||||||
@@ -0,0 +1,90 @@
|
|||||||
|
\section{Rover}
|
||||||
|
Die Implementierungen für den Rover beginnen mit der Integration des Gyroskops, dies umschließt den Einbau der Hardware und das einbinden der Sensorwerte in die dafür vorgesehene Komponente. Im nächsten Schritt wird der Ntrip-Client dem System hinzugefügt, damit in den folgenden Prozessen die hochgenaue Positionsbestimmung verfügbar ist. Sobald das GNSS-Modul die Korrekturdaten verarbeitet, kann die Implementierung der Verwaltung für die Routen beginnen. Danach sind alle voraussetzungen gegeben um den Modus zum Routen aufzeichnen programmieren zu können. Daraufhin können die Algorithmen für das automatische befahren der Route entwickelt werden.
|
||||||
|
|
||||||
|
\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.
|
||||||
|
\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 um die Funktion umzusetzen. 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.
|
||||||
|
\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 Funktionen zum Datenerhalt, die Funktion \mintinline{c++}|void enableGyroscope();| hinzugefügt. Diese erzeugt ein Objekt für den MPU6050 und initialisiert sowohl den MPU6050 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 im jeden 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}. Außerdem 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.
|
||||||
|
\par
|
||||||
|
Eine erstellte Instanz verfügt über vier Einstellungsmöglichkeiten. Diese können entweder aktiviert oder deaktiviert werden.
|
||||||
|
|
||||||
|
\setlist{noitemsep}
|
||||||
|
\begin{itemize}[]
|
||||||
|
\item Automatisches Wiederverbinden bei Verbindungsabbrüchen \texttt{(default : true)}
|
||||||
|
\item Die eigene Position übertragen \texttt{(default : false)}
|
||||||
|
\item Ntrip Revision 1 verwenden \texttt{(default : false)}
|
||||||
|
\item Den Client selbst aktivieren \texttt{(default : true)}
|
||||||
|
\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.
|
||||||
|
|
||||||
|
\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.
|
||||||
|
\item \textbf{pushingData} Wenn eine Verbindung zu dem Caster besteht, befindet sich der Client in diesem Zustand und leitet die empfangenen Daten an das GNSS-Modul weiter. Es kann nur in den \texttt{closingConnection} Zustand gewechselt werden.
|
||||||
|
\item \textbf{closingConnection} Sollt der Ntrip Client deaktiviert werden oder ein Timeout festgestellt werden, wird in diesen Zustand gewechselt, damit die Verbindung aus Sicht des Clients ordnungsgemäß beendet wird. Sobald die Verbindung getrennt ist wird der \texttt{waiting} Zustand aktiv.
|
||||||
|
\item \textbf{waiting} Wenn dieser Zustand betreten wird, wurde die Verbindung getrennt und es wird darauf gewartet in den \texttt{openingConnection} Zustand zu wechseln. Dafür muss entweder der Client wieder aktiviert werden oder die automatische Wiederverbindung muss aktiviert sein.
|
||||||
|
\item \textbf{notAvailable} Dieser Zustand wird betreten, wenn keine Verbindung zum Internet bereitsteht.
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
\subsection{Routen Management}
|
||||||
|
\label{ssec:route_management}
|
||||||
|
Die Implementierung der Routen Verwaltung erfolgt über die \mintinline{c++}|class Route|, welche eine Liste zur Speicherung der Punkte nutzt. Die Punkte sind Instanzen der \mintinline{c++}|class Point|. Es herrscht also eine 1 zu n Beziehung zwischen \mintinline{c++}|class Route| und \mintinline{c++}|class Point|.
|
||||||
|
|
||||||
|
\subsubsection{Postionen mit \mintinline{c++}|class Point|}
|
||||||
|
Eine Instanz dieser Klasse besteht unter anderem aus den Koordinaten, welche in dem \mintinline{c++}|struct Coordinates| als zwei \mintinline{c++}|double| Werte gespeichert werden. Zusätzlich kann die Zeit der Erzeugung und die geschätzte Genauigkeit des Punktes angegeben und gespeichert werden. Neben Methoden zur Datenkontrolle und Zugriff wird die Funktionalität der Klasse durch diese beiden Funktionen gegeben:
|
||||||
|
|
||||||
|
\begin{itemize}
|
||||||
|
\item \mintinline{c++}|double distanceTo(Point);| errechnet die Entfernung zwischen den Koordinaten der Instanz zu dem gegeben Punkt. Für die Berechnung wird die Erdkrümmung vernachlässigt, deshalb kann der Satz des Pythagoras genutzt werden. Dafür müssen die Grad angegebenen Koordinaten zunächst in Radianten umgewandelt werden und anschließend in ein kartesisches Koordinatensystem überführt werden. Anschließend kann die Entfernung der beiden Punkte berechnet werden. Dafür werden die beiden Koordinaten einer Achse voneinander abgezogen und anschließend quadriert. Die Ergebnisse der beiden Achsen werden schließlich aufsummiert und radiziert.
|
||||||
|
|
||||||
|
\begin{eqnarray}
|
||||||
|
d = \sqrt{(x_2 - x_1)^2 + (y_2 - y_1)^2}
|
||||||
|
\end{eqnarray}
|
||||||
|
|
||||||
|
\item \mintinline{c++}|int16_t courseTo(Point);| errechnet den Kurs von dem aktuellen Punkt zu dem gegebenen Punkt und gibt ihn in Grad aus. \(0^\circ\) entspricht Norden. Von da an wird im Uhrzeigersinn weiter gezählt, sodass \(270^\circ\) beispielsweise einen Kurs nach Westen angeben würden. Für die Berechnung müssen die Längen- und Breitengrade zunächst in Radianten umgewandelt werden. Anschließend kann dann mit der Formel
|
||||||
|
|
||||||
|
\begin{eqnarray}
|
||||||
|
\theta = \text{atan2}(\sin(\Delta \lambda)cos(\phi_2), \cos(\phi_1)\sin(\phi_2) - \sin(\phi_1)\cos(\phi_2)\cos(\Delta \lambda))
|
||||||
|
\end{eqnarray}
|
||||||
|
|
||||||
|
mit
|
||||||
|
|
||||||
|
\begin{eqnarray}
|
||||||
|
\Delta \lambda &=& \lambda_2 - \lambda_1 \\
|
||||||
|
\phi_1, \phi_2 &\widehat{=}& \text{Breitengrade der Punkte} \\
|
||||||
|
\lambda_1, \lambda_2 &\widehat{=}& \text{Längengrad der Punkte}
|
||||||
|
\end{eqnarray}
|
||||||
|
|
||||||
|
Anschließend muss \(\theta\) wieder in Grad umgewandelt werden und mit modulo auf den Wertebereich \(0 \text{ bis } 360\) normalisiert werden.
|
||||||
|
\end{itemize}
|
||||||
|
|
||||||
|
\subsubsection{Postionsspeicherung mit \mintinline{c++}|class Route|}
|
||||||
|
Die Klasse nutzt die Implementierung der Liste aus der C++ Standardbibliothek. Darüber hinaus wird ein Iterator für diese Liste von der Klasse verwaltet. Mit primitiven Datentypen wird festgehalten ob die Route gestartet ist und der wievielte Punkt gerade aus der Route selektiert ist.
|
||||||
|
\par
|
||||||
|
Die Funktionen der Klasse beschränken sich darauf den Iterator und Liste zu verwalten. Der Liste können nur Daten hinzugefügt werden. Die Entfernung einzelner Punkte ist nicht möglich und erfordert das Löschen der gesamten Liste. Es kann jeweils der nächste oder der vorherige Punkt ausgewählt werden. Die Route kann am Ende oder am Anfang gestartet werden. Soll die Route im Umgekehrter Reihenfolge abgefahren werden muss diese am Ende gestartet werden und immer der vorherige Punkt der Route abgerufen werden. Bei einem Fehler, weil beispielsweise keine Route aufgezeichnet wurde, wird von Funktionen eine Instanz von der \mintinline{c++}|class Point| mit den Koordinaten \(0 \text{ und } 0\) zurückgegeben. Dies kann von aufrufenden Funktion überprüft werden, dafür wurde eigens die Funktion \mintinline{c++}|bool Point::isValid();| implementiert.
|
||||||
|
\par
|
||||||
|
Damit Informationen über die Route abgefragt werden können, wurde ein Datentyp hinzugefügt. Das \mintinline{c++}|struct RouteInfo| enthält die Gesamtzahl der in der Route gespeicherten Punkte und der wievielte davon gerade ausgewählt ist.
|
||||||
|
|
||||||
|
\subsubsection{Verwaltung über das Menü}
|
||||||
|
In die vorhandene Menüstruktur wurde in der ersten Ebene der Punkt \flqq Route\frqq{} als Untermenü hinzugefügt. Dieses Menü stellt die in der folgenden Liste erläuterten Funktionen bereit. Für einige dieser Funktionen wird auf eine entwickelte HTTP-API zugegriffen, deshalb muss für diese Funktionen eine Internetverbindung bestehen. Die serverseitige Implementierung der API wird im Anhang \ref{cha:httpApi} beschrieben. Werden Teile der API auf dem Rover genutzt, zeigt dieser den HTTP-Code an. Mit diesem lässt sich erkennen ob die ausgeführte Operation korrekt ausgeführt wurde.
|
||||||
|
|
||||||
|
\begin{itemize}
|
||||||
|
\item \textbf{Points} - Unter diesem Punkt können die einzelnen Koordinaten der in der Route gespeicherten Punkte betrachtet werden.
|
||||||
|
\item \textbf{Clear} - Löscht die aktuell lokal erstellte Route.
|
||||||
|
\item \textbf{Import} - Bei Auswahl dieses Punktes muss der Benutzter die ID der Route wissen mit der diese Exportiert wurde. Sofern die gewählte ID existiert, wird die Route heruntergeladen und steht dem Rover nun zur Verfügung. Wenn bereits ein Route lokal vorhanden war, wird diese durch importierte überschrieben. In diesem Fall könnte die gefährdete Route vorher exportiert werden.
|
||||||
|
\item \textbf{Export} - Mit dieser Funktionen können Routen für die spätere Verwendung gesichert werden. Dafür muss ihnen eine ID zugewiesen werden, unter dieser ID lässt sich die Route später wieder abrufen.
|
||||||
|
\item \textbf{Delete} - Mit Delete kann eine exportierte Route mit ihrer ID gelöscht werden, dies betrifft allerdings nicht aktuell lokal vorhandene Route.
|
||||||
|
\end{itemize}
|
||||||
@@ -0,0 +1,94 @@
|
|||||||
|
\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.
|
||||||
|
\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.
|
||||||
|
|
||||||
|
\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.
|
||||||
|
\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.
|
||||||
|
\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.
|
||||||
|
\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.
|
||||||
|
\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.
|
||||||
|
\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.
|
||||||
|
|
||||||
|
\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.
|
||||||
|
|
||||||
|
\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?!!!
|
||||||
|
\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.
|
||||||
|
|
||||||
|
\subsubsection{Navigationsanweisungen}
|
||||||
|
Aus der berechneten Kurskorrektur und dem verbleibenden Abstand zum Zielpunkt wird Navigationsanweisung erstellt. Die Informationen in das folgende \mintinline{c++}|struct| verpackt:
|
||||||
|
|
||||||
|
\begin{minted}[linenos, gobble=5, breaklines]{c++}
|
||||||
|
struct CourseCorrection
|
||||||
|
{
|
||||||
|
int16_t correction;
|
||||||
|
double distance;
|
||||||
|
};
|
||||||
|
\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.
|
||||||
|
|
||||||
|
\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:
|
||||||
|
|
||||||
|
\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.
|
||||||
|
\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.
|
||||||
|
|
||||||
|
\begin{table}[]
|
||||||
|
\centering
|
||||||
|
\begin{tabular}{|l|c|c|l|}
|
||||||
|
\hline
|
||||||
|
Zustand & \multicolumn{1}{l|}{Update} & \multicolumn{1}{l|}{Check} & Beschreibung \\ \hline
|
||||||
|
InsufficientAccuracy & x & - & -Warten auf bessere Genauigkeit \\ \hline
|
||||||
|
NoRoute & - & - & -Autopilot nicht verfügbar \\ \hline
|
||||||
|
None & - & - & -Default Zustand zum Programmbeginn \\ \hline
|
||||||
|
NavigationStarted & x & x & \begin{tabular}[c]{@{}l@{}}-Autopilot initialisiert\\ -Auf Benutzereingabe warten\end{tabular} \\ \hline
|
||||||
|
GetToStartPoint & x & - & \begin{tabular}[c]{@{}l@{}}-Warten bis Benutzer den Rover in die \\ Nähe des Startpunktes gebracht hat\\ -Fahren mit dem Joystick möglich\end{tabular} \\ \hline
|
||||||
|
SelfDrivingAvailable & x & x & \begin{tabular}[c]{@{}l@{}}-Autopilot bereit\\ -Auf Benutzereingabe warten\end{tabular} \\ \hline
|
||||||
|
SelfDriving & x & x & \begin{tabular}[c]{@{}l@{}}-Rover fährt geradeaus bis die\\ Abweichung zu groß ist.\end{tabular} \\ \hline
|
||||||
|
SelfDrivingRotate & x & - & -Abweichung korrigieren \\ \hline
|
||||||
|
TargetReached & - & - & -Navigation abgeschlossen \\ \hline
|
||||||
|
\end{tabular}
|
||||||
|
\caption{Auflistung und Beschreibung der Zustände des Autopiloten}
|
||||||
|
\label{tab:autopilot}
|
||||||
|
\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.
|
||||||
|
|
||||||
|
\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.
|
||||||
|
|
||||||
|
\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
|
||||||
|
mittel & 1!!! & 1 \\ \hline
|
||||||
|
nah & 0,75!!! & 0,5 \\ \hline
|
||||||
|
\end{tabular}
|
||||||
|
\caption{Geschwindigkeit der Rovers je nach Abstand zum Zielpunkt}
|
||||||
|
\label{tab:roverSpeed}
|
||||||
|
\end{table}
|
||||||
@@ -1,387 +0,0 @@
|
|||||||
\chapter{Implementierung}
|
|
||||||
Im folgenden Teil dieser Arbeit wird auf den Aufbau der Basisstation eingegangen, dabei wird der mechanische Aufbau sowie die Implementierung und Einrichtung der Station erläutert. Außerdem werden die Erweiterungen des Rovers ausführlich beschrieben, dazu gehören die Implementierung weiterer Softwarekomponenten sowie der Einbau des GY-521 Moduls (siehe Abschnitt \ref{sec:gyroskop}).
|
|
||||||
|
|
||||||
\section{Basisstation}
|
|
||||||
\label{sec:Basisstation}
|
|
||||||
Für die Errichtung der Referenzstation stellte sich zunächst die Frage, wie das System aufgebaut werden soll. Dabei sind die bereits beschriebenen Anforderungen im Abschnitt \ref{sec:referenzstation_req} entstanden. Um das System den Anforderungen entsprechend erstellen zu können wurde die Hardwareauswahl in dem vorangegangenen Kapitel \ref{cha:Hardwareauswahl} bereits beschrieben. Deshalb wird in diesem Abschnitt die noch fehlende Installation und Konfiguration der Komponenten thematisiert. Darüber hinaus werden für die vollständige Montage Formteile benötigt, welche mit einem 3D-Drucker produziert werden sollen.
|
|
||||||
|
|
||||||
\subsection{Installation Betriebssystem}
|
|
||||||
Im ersten Schritt muss der Server betriebsbereit gemacht werden, dafür muss ein Betriebssystem installiert werden. Dazu soll das in Unterabschnitt \ref{ssec:debian} beschriebene Debian genutzt werden.
|
|
||||||
\par
|
|
||||||
Da der Server über übliche Anschlüsse für einen Monitor verfügt, kann die Installation über den Installationsassistenten mittels Tastatur und Bildschirm durchgeführt werden. Dafür wurde die iso-Datei von Debian so auf einen USB-Stick geschrieben, dass dieser Bootfähig ist. Während der Installation wurden die meisten Einstellungen bei ihrem Standard belassen.
|
|
||||||
\par
|
|
||||||
Nach der erfolgreichen Installation des Betriebssystems wurde sich zunächst als root Benutzer angemeldet, um die ersten grundlegenden Einstellungen zu tätigen.
|
|
||||||
|
|
||||||
\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 zweite Datei ist unter dem Pfad \url{/etc/resolv.conf} zu finden. In diese Datei müssen die zu benutzen DNS-Server eingetragen werden. In jeder Zeile kann ein Eintrag getätigt werden. In diesem Fall nach dem Muster \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 !!!command!!! oder einem Neustart des Computers erfolgen.
|
|
||||||
|
|
||||||
\subsubsection{sudo}
|
|
||||||
Sudo ist ein Programm aus den Paketquellen von Debian, dass es anderen Nutzern erlauben kann Befehle mit root-Rechten auszuführen. Diese Vorgehensweise empfiehlt sich, damit nicht alle Befehle automatisch mit root-Rechten ausgeführt werden und das vollständige System über ein normales Benutzerkonto gesteuert werden kann. Das Paket kann mit dem Paketverwaltungstool \mintinline{bash}|apt-get| installiert werden. Davor sollten die Paketquellen jedoch aktualisiert und möglich Paketupdates installiert werden. Um die Aktualisierung und die Installation auszuführen müssen diese Befehle ausgeführt werden:
|
|
||||||
|
|
||||||
\begin{minted}[linenos, gobble=5]{bash}
|
|
||||||
apt-get update
|
|
||||||
apt-get upgrade
|
|
||||||
apt-get install sudo
|
|
||||||
\end{minted}
|
|
||||||
|
|
||||||
Im Anschluss müssen die Benutzer welche neben dem root-Benutzer ebenfalls Befehle mit erweiterten Rechten ausführen können sollen in die Benutzergruppe \mintinline{text}|sudo???| hinzugefügt werden. Für den bei der Installation automatisch erstellen Benutzer \mintinline{text}|rtk| sieht der Befehl wie folgt aus: \mintinline{text}|usermod -aG sudo rtk???|.
|
|
||||||
Danach wird der root-Account abgemeldet und nur noch der rtk-Benutzer verwendet. Befehle können nun mit einem vorangestellten \mintinline{bash}|sudo| als Administrator ausgeführt werden.
|
|
||||||
|
|
||||||
\subsubsection{ssh-server}
|
|
||||||
Der SSH-Server wird ebenfalls über die Paketquellen installiert, der Paketname entspricht der Überschrift dieses Abschnitts. Mit einem SSH-Server wird die Verwaltung des System über das Netzwerk ermöglicht und damit der Zugriff auf das Terminal erheblich zu vereinfacht. Der Server kann in mit den Standardeinstellungen betrieben werden, für eine erhöhte Sicherheit wird jedoch der Login mit dem root-Account verboten. Dafür wird in der Konfigurationsdatei (\url{/etc/ssh/sshd_config}) die Zeile \mintinline{text}|PermitRootLogin no| ergänzt und der SSH-Server anschließend mit \mintinline{bash}|sudo service sshd restart| neugestartet.
|
|
||||||
\par
|
|
||||||
Ab diesem Zeitpunkt der Installation kann der Server headless betrieben werden. Es ist nur noch eine die Netzwerkverbindung und die Stromversorgung notwendig. Zum einloggen wird ein SSH-Client, die Zugangsdaten und die Adresse des Servers benötigt.
|
|
||||||
|
|
||||||
\subsection{ser2net vorbereiten}
|
|
||||||
Die Konfiguration der GNSS-Module von U-Blox lässt sich am einfachsten mit dem u-center (siehe Abschnitt \ref{sssec:u-blox}) erledigen. Da das u-center ausschließlich unter Windows verfügbar und ein Programm mit grafischer Oberfläche ist, kann es nicht auf dem Server ausgeführt werden. Allerdings ist es nicht praktikabel das GNSS-Modul aus dem System der Referenzstation zu entfernen, um es an einem anderen Computer zu konfigurieren. Deshalb bietet sich die Installation von ser2net an, damit die Verbindung zwischen dem u-center und dem GNSS-Modul über eine Netzwerkverbindung aufgebaut werden kann.
|
|
||||||
\par
|
|
||||||
Die Installation erfolgt über die Paketquellen mit \mintinline{bash}|sudo apt-get install ser2net|. Das Programm wird dem Betriebssystem als Service hinzugefügt und läuft damit ständig. Da die Verbindung nur zur Verfügung stehen soll wenn diese auch benötigt wird, kann der automatische Start des Service beim Bootvorgang mit dem Befehl
|
|
||||||
|
|
||||||
\begin{minted}[linenos, gobble=4]{bash}
|
|
||||||
sudo systemctl disable ser2net
|
|
||||||
\end{minted}
|
|
||||||
|
|
||||||
deaktiviert werden. Die nächsten beiden Befehle sind zum stoppen und starten des Services. Nach der Deaktivierung läuft der Service weiter bis der Computer neugestartet wird oder der Service mit dem ersten Befehl gestoppt wird.
|
|
||||||
|
|
||||||
\begin{minted}[linenos, gobble=4]{bash}
|
|
||||||
sudo systemctl stop ser2net
|
|
||||||
sudo systemctl start ser2net
|
|
||||||
\end{minted}
|
|
||||||
|
|
||||||
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 wird 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}
|
|
||||||
|
|
||||||
Sollte der Service zum Zeitpunkt der Konfiguration aktiv gewesen sein, muss es mit dem genannten Befehl gestoppt werden 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.
|
|
||||||
|
|
||||||
\subsection{RTKLib installieren}
|
|
||||||
Die in den Grundlagen unter \ref{sssec:rtklib} beschriebene RTKLib ist nicht über die Paketquellen verfügbar und muss deshalb auf dem Server kompiliert werden. Um das Projekt von GitHub clonen zu können muss Git installiert werden. Außerdem wird als Abhängigkeit die Bibliothek \mintinline[]{text}|libpng-dev| benötigt. Der Compiler inklusive weiterer benötigter Tools wie \mintinline[]{text}|make| ist in dem Paket \mintinline[]{text}|build-essential| enthalten. Für die vollständige Installation wird die folgende Befehlsfolge in dem Home-Verzeichnis des rtk-Benutzers benötigt:
|
|
||||||
|
|
||||||
\begin{minted}[linenos, gobble=4]{bash}
|
|
||||||
sudo apt-get update
|
|
||||||
sudo apt-get install git
|
|
||||||
sudo apt-get install libpng-dev
|
|
||||||
sudo apt-get install build-essential
|
|
||||||
|
|
||||||
git clone https://github.com/rtklibexplorer/RTKLIB.git
|
|
||||||
cd RTKLIB/app/consapp/
|
|
||||||
make
|
|
||||||
make install
|
|
||||||
\end{minted}
|
|
||||||
|
|
||||||
\subsection{Dachinstallation}
|
|
||||||
Die Installation auf dem Dach wurde in ihren groben Zügen bei der in der Einleitung des Kapitels \ref{cha:Hardwareauswahl} beschriebenen Begehung des Installationsortes geplant. Von diesem Plan wurde die in dem Kapitel folgende Hardwareauswahl abgeleitet. Im ersten Schritt sollen nun alle Vorbereitungen getroffen werden, welche von dem Installationsort unabhängig sind. Im Anschluss wird die eigentliche Montage auf dem Dach vorgenommen.
|
|
||||||
|
|
||||||
\subsubsection{Befestigungen}
|
|
||||||
Die anzubringenden Komponenten benötigen Halterungen und Befestigungspunkte. Diese werden im folgenden Beschrieben:
|
|
||||||
|
|
||||||
\begin{itemize}
|
|
||||||
\item die \textbf{Antenne} soll am Ende des C-Profils welches zur Verlängerung des Pfostens dient befestigt werden. Dafür wurde ein Formteil konstruiert (siehe Abbildung !!!). Im wesentlichen besteht diesel Teil aus einem Quader, welcher in das C-Profil eingeführt werden kann. Der Quader verfügt über eine Bohrung, damit dieser mittels einer Schrauben-Mutter-Kombination am C-Profil fixiert werden kann. Am oberen Ende befindet sich ein Gewinde auf welches die Antenne aufgeschraubt werden kann,
|
|
||||||
|
|
||||||
\item der \textbf{Installationskasten} soll unterhalb des vorhandenen Kastens am Pfosten angebracht werden. Als Maße stehen der gemessene Durchmesser des Pfostens (\(90mm\)) und der aus dem Datenblatt !!!cite!!! verfügbare Lochabstand der Befestigungslöcher des Kastens. Mit diesen Werten konnte eine Halterung konstruiert werden, welche aus zwei Halbschalen besteht. Ein Halbschale verfügt über abstehende Arme mit vorhandenen Löchern für M!!!-Schrauben, an denen der Kasten befestigt werden kann. Die M!!!-Schrauben können von hinten mit der passenden Mutter gesichert werden. In die gleich Halbschale können passgenau M8-Muttern eingelegt werden. Die andere Halbschale verfügt über die Löcher und Vertiefungen um diese mit zwei M8-Schrauben an der anderen Halbschale befestigen zu können. Die Halterungen wurde für den oberen und den unteren Teil des Kastens jeweils einmal ausgedruckt. Eine Halterung ist in Abbildung !!!ref!!! zu sehen,
|
|
||||||
|
|
||||||
\item für den \textbf{Server} wird eine Halterung benötigt, damit dieser an der Hutschiene im Installationskasten befestigt werden kann. Es bot sich an die mitgelieferten Winkel und Schrauben von dem Computer in die Konstruktion mit einzubeziehen. Die Winkel sind für die Wandmontage gedacht und werden nach Herstellervorgaben auf der Rückseite des Computers befestigt, so dass nach der Montage der Winkel Befestigungspunkte neben Computer benutzbar sind. Die Winkel haben einen Versatz, der den Computer theoretisch etwas von der Wand hervorstehen lassen würde. Um die Befestigung an der Hutschiene zu ermöglichen, wurden die Winkel um \(180^\circ\) verdreht. Dadurch entsteht auf der Rückseite der Computer ein breites Trapez mit geringer Höhe. Diese Form wurde als Grundplatte für den Adapter genutzt. Auf dieser Grundplatte befinden sich neben der Aufnahme für die Hutschiene herausstehende Kegel, welche genutzt werden um den Adapter mittels der am Winkel vorgesehenen Löcher zur Wandmontage zu fixieren, !!!Bild?!!!
|
|
||||||
|
|
||||||
\item die letzte Konstruktion soll das \textbf{GNSS-Modul} ebenfalls an der Hutschiene fixieren. Das Formteil ist ein etwas in die Länge gezogene Quader. An einem Ende befindet sich der Mechanismus für die Hutschiene. Für das Modul ist eine Vertiefung mit Aussparungen für die Anschlüsse eingefügt worden. Das Modul wird durch das Einschieben einer Deckplatte gesichert. Das Formteil wird in Abbildung !!!ref!!! gezeigt.
|
|
||||||
\end{itemize}
|
|
||||||
|
|
||||||
\subsubsection{Installationskasten bestücken}
|
|
||||||
Der Installationskasten kann weitgehend vorbereitet werden. Dafür wurden zunächst ein Loch an der unteren Seite gebohrt, welches groß genug ist um ein RJ45-Stecker durchzuführen. Weiterhin wurde die Hutschiene außer mittig positioniert, damit im unteren Raum mehr Platz für Kabel bleibt. Danach wurden die beiden Halbschalen an der Rückseite des Kastens befestigt, weil die Löcher für die Befestigungen durch die Komponenten teilweise verdeckt werden. Anschließend konnten die Komponenten an der Hutschiene befestigt werden. Die Komponenten wurden rechtsbündig verbaut. Dabei wurde der PoE-Splitter links neben dem Server und das GNSS-Modul rechts neben dem Server eingehackt. Diese beiden Komponenten auf je eine Seite des Computers zu befestigen, vereinfacht die Kabelführung. Der PoE-Splitter befindet sich auf der linken Seite, weil dieser die beste Klemmwirkung an der Hutschiene aufweist und so das verrücken der anderen Komponenten verhindert.
|
|
||||||
\par
|
|
||||||
Um den Computer über den PoE-Splitter mit Strom zu versorgen wurde ein Kabel mit einem Hohlbuchsenstecker konfektioniert. Das andere Ende des Kabels wurde verzinnt und an dem Blockterminal des Splitters angebracht. Das Netzwerkkabel von dem PoE-Splitter zu dem Server konnte ebenfalls schon eingesetzt werden. Mit einem USB-C auf USB-A Kabel wurde die Verbindung zwischen dem GNSS-Modul und dem Server hergestellt. Das Antennenkabel wurde durch das gebohrte Loch geführt und an dem GNSS-Modul angeschraubt. Der vorbereitete Installationskasten wird in Abbildung !!!ref!!! dargestellt.
|
|
||||||
\par
|
|
||||||
Als weitere Vorbereitung wurden weitere benötigte Netzwerkkabel bereitgelegt und Adapter für die Antennenmontage wurde an dem C-Profil befestigt.
|
|
||||||
|
|
||||||
\subsubsection{Montage}
|
|
||||||
Die Montage began mit der Befestigung des Installationskastens, dafür wurde in je eine Halbschale ein griffiges Klebeband eingebracht, um den Halt zu verbessern. Der Kasten wurde an den Pfosten gehalten und durch die dazugehörigen Halbschalen fixiert. Daraufhin wurde die Antenne an dem C-Profil befestigt und das Antennenkabel angeschlossenen. Das C-Profil wurde an den bei der Begehung besprochen Befestigungspunkten angebracht. Das Antennenkabel wurde mit Kabelbindern an dem C-Profil befestigt.
|
|
||||||
\par
|
|
||||||
Als nächstes musste der PoE-Extender in den vorhanden Anschlusskasten eingebracht werden. Dieser wurde ebenfalls an der Hutschiene befestigt. Das von dem !!!DragiLoRaWAN-Gateway?!!! kommende Ethernetkabel wurde aus der Hutschienen-RJ45-Buchse entnommen und in mit dem ersten Ausgang des Extenders verbunden. Der Eingang wurde mit dem nun freien Port an der Hutschiene verbunden. Danach wurde kontrolliert, ob der vorhandene System wieder einsatzbereit ist. Für die letzte herzustellende Verbindung zwischen dem Poe-Extender und dem Poe-Splitter, musste das Loch in dem vorhanden Installationskasten etwas aufgebohrt werden. Danach konnte das Kabel verlegt werden, wobei die überschüssige Länge des Kabel im neuen Installationskasten aufgewickelt wurde. Durch die Betriebs-LED des Servers und den LEDs des Netzwerkinterfaces konnte schon während der Installation festgestellt werden, dass der Server mit Strom versorgt wird und einen Link aufbauen konnten.
|
|
||||||
|
|
||||||
\subsection{Antennenposition bestimmen}
|
|
||||||
Die nun folgenden Schritte wurde alle von einem Remote-Arbeitsplatz durchgeführt.
|
|
||||||
\par
|
|
||||||
Damit die Antennenposition bestimmt werden kann sind im grundlegenden drei Schritte notwendig:
|
|
||||||
|
|
||||||
\setlist{noitemsep}
|
|
||||||
\begin{enumerate}
|
|
||||||
\item Rohdaten des GNSS-Moduls aufzeichnen,
|
|
||||||
\item die Rohdaten in das RINEX-Format konvertieren
|
|
||||||
\item und die Daten von einem Post Processing Dienst auswerten lassen.
|
|
||||||
\end{enumerate}
|
|
||||||
\setlist{}
|
|
||||||
|
|
||||||
Damit die Rohdaten aufgezeichnet werden können, muss das Modul so konfiguriert werden, dass es diese ausgibt. Dafür wird das u-center und die Verbindung über ser2net genutzt. Die dafür benötigte Installation unter Windows, sowie die grundlegende Nutzung vom u-center wird im Anhang \ref{cha:winAndUcenter} beschrieben. Im u-center muss der Nachrichtentyp RAWX und RAW!!!?!!! für die USB-Schnittstelle aktiviert werden. Ob die benötigten Daten gesendet werden kann in !!!Packet-View?!!! kontrolliert werden.
|
|
||||||
\par
|
|
||||||
Die Aufzeichnung der Daten übernimmt der Kommunikations-Server der RTKLib. Das Programm heißt in der Kommandozeilenversion \mintinline[]{text}|STR2STR| und kann einen Dateneingang auf mehrere Datenausgänge übertragen. In diesem Fall werden die Daten des GNSS-Moduls in eine Datei geschrieben. Die meisten Post Processing Dienst verarbeiten bis zu 24 Stunden Aufzeichnungslänge, deshalb wird für die höchste Genauigkeit genau diese Dauer für die Einmessung verwendet. Die Länge der Aufzeichnung wird über den \mintinline[]{bash}|timeout| Befehl gesteuert. Damit die Aufzeichnung nicht als Kind-Prozess der Remote-Sitzung läuft wird das Hilfsprogramm \mintinline[]{bash}|screen| installiert, da ansonsten ein Abbruch der Verbindung auch die Aufzeichnung frühzeitig beenden würde. Aus dieser Beschreibung ergibt sich diese Befehlsfolge:
|
|
||||||
|
|
||||||
\begin{minted}[linenos, gobble=4, breaklines]{bash}
|
|
||||||
sudo apt-get update
|
|
||||||
sudo apt-get install screen
|
|
||||||
|
|
||||||
screen
|
|
||||||
|
|
||||||
cd ~
|
|
||||||
timeout 24h ./RTKLIB/app/consapp/str2str/gcc/str2str -in serial://ttyACM0:9600:8:n:1:off -out observation.ubx
|
|
||||||
\end{minted}
|
|
||||||
|
|
||||||
Die screen-Sitzung kann mit der Tastenkombinationen \keys{\ctrl + A} gefolgt von \keys{D} verlassen werden.
|
|
||||||
\par
|
|
||||||
Sobald die Aufzeichnung beendet ist, müssen die Daten in das allgemeingültige RINEX-Format umgewandelt werden. Dafür bietet die RTKLib einen RINEX Konverter an. Zur Benutzung im Terminal muss das Programm \mintinline[]{bash}|convbin| aufgerufen werden. Die Konvertierung erfolgt mit:
|
|
||||||
|
|
||||||
\begin{minted}[linenos, gobble=4, breaklines]{bash}
|
|
||||||
cd ~
|
|
||||||
./RTKLIB/app/consapp/convbin/gcc/convbin -od -os -oi -ot -ti 30 observation.ubx
|
|
||||||
\end{minted}
|
|
||||||
|
|
||||||
Für die Erklärung der verwendeten Optionen folgt ein Ausschnitt aus dem Manual der RTKLib !!!cite!!!:
|
|
||||||
|
|
||||||
\setlist{noitemsep}
|
|
||||||
\begin{itemize}[label=-]
|
|
||||||
\item od include doppler frequency in rinex obs
|
|
||||||
\item os include snr in rinex obs
|
|
||||||
\item oi include iono correction in rinex nav header
|
|
||||||
\item ot include time correction in rinex nav header
|
|
||||||
\item ti tint observation data interval (s)
|
|
||||||
\end{itemize}
|
|
||||||
\setlist{}
|
|
||||||
|
|
||||||
Die umgewandelte Datei muss als nächstes zu einem Post Processing Dienst übermittelt werden, der gewählte Dienst erhält die Daten über ein Formular im Browser, deshalb ist die einfachste Variante die Datei \url{ubservation.obs} auf einen Rechner mit einer Desktopumgebung zu kopieren. Dafür wurde die Datei mit dem Programm \mintinline[]{bash}|scp| über ssh kopiert.
|
|
||||||
\par
|
|
||||||
Nach einigen Stunden wird die Auswertung per E-Mail versandt. In dem erhaltenen Archiv befinden sich eine PDF (siehe Anhang \ref{cha:auswerungObservation}) in der die Auswertung grafisch veranschaulicht wird und neben anderen Dateien die Datei \url{observation.sum}. In dieser wird ab Zeile 69 die Position der Antenne im Erdkoordinatensystem angegeben. Zusätzlich werden geschätzt Genauigkeiten angegeben, diese liegen je nach Achse zwischen \(1,8mm\) und \(5,2mm\).
|
|
||||||
\par
|
|
||||||
Die Koordinaten für X, Y und Z müssen nun über das u-center in das GNSS-Modul programmiert werden. Dafür muss in der Konfigurationsansicht der TMODE ausgewählt werden. In den Einstellungen des TMODE muss der Modus auf \texttt{fixed} eingestellt werden, danach können die Koordinaten im gleichen Fenster eingetragen werden. Damit das Modul auch die Korrekturdaten ausgibt kann ich das Fenster zur Konfiguration der Nachrichten gewechselt werden. Dort sollten die Nachrichten für die Rohdaten wieder entfernt werden, um das Datenaufkommen zu reduzieren. Danach können die RTCM3 Nachrichten mit den Nummern 1005, 1074, 1084, 1094, 1124 und 1230 aktiviert werden. Ob die Konfiguration erfolgreich war kann wieder im Packet View Fenster kontrolliert werden. Diese Finale Konfiguration des Moduls sollte in den Flash des Moduls geschrieben werden um auch über einen neustart hinweg verfügbar zu sein. Dafür kann in der Menüleiste der Punkt !!!?!!! ausgewählt werden.
|
|
||||||
|
|
||||||
\subsection{Service einrichten}
|
|
||||||
\label{ssec:pushService}
|
|
||||||
Die von dem GNSS-Modul generierten Korrekturdaten müssen kontinuierlich an den Ntrip-Caster weitergeleitet werden. Dafür wird der bereits zuvor genutzte Kommunikationsserver der RTKLib verwendet. Als Ausgang wird anstelle der Datei nun der Ntrip-Caster angegeben.
|
|
||||||
\par
|
|
||||||
Damit die Ausgabe automatisch protokolliert wird und der Kommunikationsserver auch nach einem Neustart des Servers automatisch startet wird dem Betriebssystem ein Service hinzugefügt. Dafür muss eine Datei mit root-Rechten und der Endung \texttt{.service}, welche den Service definiert unter dem Pfad \url{/etc/systemd/system} erstellt werden. Der Inhalt der erstellten Datei \texttt{rtk.service} sieht wie folgt aus:
|
|
||||||
|
|
||||||
\begin{minted}[linenos, gobble=4, breaklines]{bash}
|
|
||||||
[Unit]
|
|
||||||
Description=Push RTCM correction data from serial to caster
|
|
||||||
After=network-online.target
|
|
||||||
|
|
||||||
[Service]
|
|
||||||
Type=simple
|
|
||||||
ExecStart=/home/rtk/pushRtcm2Caster.sh
|
|
||||||
|
|
||||||
[Install]
|
|
||||||
WantedBy=multi-user.target
|
|
||||||
\end{minted}
|
|
||||||
|
|
||||||
Das auszuführende Skript enthält zum aktuellen Zeitpunkt lediglich den Aufruf des Kommunikationsservers mit den benötigten Parametern.
|
|
||||||
|
|
||||||
\begin{minted}[linenos, gobble=4, breaklines]{bash}
|
|
||||||
#!/bin/bash
|
|
||||||
/home/rtk/RTKLIB/app/consapp/str2str/gcc/str2str -in serial://ttyACM0:9600:8:n:1:off -out ntrips://:password@rtk2go.com:2101/GER-Dortmund
|
|
||||||
\end{minted}
|
|
||||||
|
|
||||||
Anschließend muss der Service aktiviert und gestartet werden.
|
|
||||||
|
|
||||||
\begin{minted}[linenos, gobble=4, breaklines]{bash}
|
|
||||||
sudo systemctl activate rtk
|
|
||||||
sudo systemctl start rtk
|
|
||||||
\end{minted}
|
|
||||||
|
|
||||||
In den Logs kann die übermittelte Datenmenge oder auftretende Fehler betrachtet werden. Wenn der Caster die Daten akzeptiert, erscheint der zuvor bei rtk2go registrierte Mount Point \texttt{GER-Dortmund} in der Mount Point Tabelle unter \url{rtk2go.com:2101}
|
|
||||||
|
|
||||||
\section{Rover}
|
|
||||||
Die Implementierungen für den Rover beginnen mit der Integration des Gyroskops, dies umschließt den Einbau der Hardware und das einbinden der Sensorwerte in die dafür vorgesehene Komponente. Im nächsten Schritt wird der Ntrip-Client dem System hinzugefügt, damit in den folgenden Prozessen die hochgenaue Positionsbestimmung verfügbar ist. Sobald das GNSS-Modul die Korrekturdaten verarbeitet, kann die Implementierung der Verwaltung für die Routen beginnen. Danach sind alle voraussetzungen gegeben um den Modus zum Routen aufzeichnen programmieren zu können. Daraufhin können die Algorithmen für das automatische befahren der Route entwickelt werden.
|
|
||||||
|
|
||||||
\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-Leiste 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.
|
|
||||||
\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 um die Funktion umzusetzen. 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.
|
|
||||||
\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 Funktionen zum Datenerhalt, die Funktion \mintinline{c++}|void enableGyroscope();| hinzugefügt. Diese erzeugt ein Objekt für den MPU6050 und initialisiert sowohl den MPU6050 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 im jeden 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}. Außerdem 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.
|
|
||||||
\par
|
|
||||||
Eine erstellte Instanz verfügt über vier Einstellungsmöglichkeiten. Diese können entweder aktiviert oder deaktiviert werden.
|
|
||||||
|
|
||||||
\setlist{noitemsep}
|
|
||||||
\begin{itemize}[]
|
|
||||||
\item Automatisches Wiederverbinden bei Verbindungsabbrüchen \texttt{(default : true)}
|
|
||||||
\item Die eigene Position übertragen \texttt{(default : false)}
|
|
||||||
\item Ntrip Revision 1 verwenden \texttt{(default : false)}
|
|
||||||
\item Den Client selbst aktivieren \texttt{(default : true)}
|
|
||||||
\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.
|
|
||||||
|
|
||||||
\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.
|
|
||||||
\item \textbf{pushingData} Wenn eine Verbindung zu dem Caster besteht, befindet sich der Client in diesem Zustand und leitet die empfangenen Daten an das GNSS-Modul weiter. Es kann nur in den \texttt{closingConnection} Zustand gewechselt werden.
|
|
||||||
\item \textbf{closingConnection} Sollt der Ntrip Client deaktiviert werden oder ein Timeout festgestellt werden, wird in diesen Zustand gewechselt, damit die Verbindung aus Sicht des Clients ordnungsgemäß beendet wird. Sobald die Verbindung getrennt ist wird der \texttt{waiting} Zustand aktiv.
|
|
||||||
\item \textbf{waiting} Wenn dieser Zustand betreten wird, wurde die Verbindung getrennt und es wird darauf gewartet in den \texttt{openingConnection} Zustand zu wechseln. Dafür muss entweder der Client wieder aktiviert werden oder die automatische Wiederverbindung muss aktiviert sein.
|
|
||||||
\item \textbf{notAvailable} Dieser Zustand wird betreten, wenn keine Verbindung zum Internet bereitsteht.
|
|
||||||
\end{itemize}
|
|
||||||
|
|
||||||
\subsection{Routen Management}
|
|
||||||
\label{ssec:route_management}
|
|
||||||
Die Implementierung der Routen Verwaltung erfolgt über die \mintinline{c++}|class Route|, welche eine Liste zur Speicherung der Punkte nutzt. Die Punkte sind Instanzen der \mintinline{c++}|class Point|. Es herrscht also eine 1 zu n Beziehung zwischen \mintinline{c++}|class Route| und \mintinline{c++}|class Point|.
|
|
||||||
|
|
||||||
\subsubsection{Postionen mit \mintinline{c++}|class Point|}
|
|
||||||
Eine Instanz dieser Klasse besteht unter anderem aus den Koordinaten, welche in dem \mintinline{c++}|struct Coordinates| als zwei \mintinline{c++}|double| Werte gespeichert werden. Zusätzlich kann die Zeit der Erzeugung und die geschätzte Genauigkeit des Punktes angegeben und gespeichert werden. Neben Methoden zur Datenkontrolle und Zugriff wird die Funktionalität der Klasse durch diese beiden Funktionen gegeben:
|
|
||||||
|
|
||||||
\begin{itemize}
|
|
||||||
\item \mintinline{c++}|double distanceTo(Point);| errechnet die Entfernung zwischen den Koordinaten der Instanz zu dem gegeben Punkt. Für die Berechnung wird die Erdkrümmung vernachlässigt, deshalb kann der Satz des Pythagoras genutzt werden. Dafür müssen die Grad angegebenen Koordinaten zunächst in Radianten umgewandelt werden und anschließend in ein kartesisches Koordinatensystem überführt werden. Anschließend kann die Entfernung der beiden Punkte berechnet werden. Dafür werden die beiden Koordinaten einer Achse voneinander abgezogen und anschließend quadriert. Die Ergebnisse der beiden Achsen werden schließlich aufsummiert und radiziert.
|
|
||||||
|
|
||||||
\begin{eqnarray}
|
|
||||||
d = \sqrt{(x_2 - x_1)^2 + (y_2 - y_1)^2}
|
|
||||||
\end{eqnarray}
|
|
||||||
|
|
||||||
\item \mintinline{c++}|int16_t courseTo(Point);| errechnet den Kurs von dem aktuellen Punkt zu dem gegebenen Punkt und gibt ihn in Grad aus. \(0^\circ\) entspricht Norden. Von da an wird im Uhrzeigersinn weiter gezählt, sodass \(270^\circ\) beispielsweise einen Kurs nach Westen angeben würden. Für die Berechnung müssen die Längen- und Breitengrade zunächst in Radianten umgewandelt werden. Anschließend kann dann mit der Formel
|
|
||||||
|
|
||||||
\begin{eqnarray}
|
|
||||||
\theta = \text{atan2}(\sin(\Delta \lambda)cos(\phi_2), \cos(\phi_1)\sin(\phi_2) - \sin(\phi_1)\cos(\phi_2)\cos(\Delta \lambda))
|
|
||||||
\end{eqnarray}
|
|
||||||
|
|
||||||
mit
|
|
||||||
|
|
||||||
\begin{eqnarray}
|
|
||||||
\Delta \lambda &=& \lambda_2 - \lambda_1 \\
|
|
||||||
\phi_1, \phi_2 &\widehat{=}& \text{Breitengrade der Punkte} \\
|
|
||||||
\lambda_1, \lambda_2 &\widehat{=}& \text{Längengrad der Punkte}
|
|
||||||
\end{eqnarray}
|
|
||||||
|
|
||||||
Anschließend muss \(\theta\) wieder in Grad umgewandelt werden und mit modulo auf den Wertebereich \(0 \text{ bis } 360\) normalisiert werden.
|
|
||||||
\end{itemize}
|
|
||||||
|
|
||||||
\subsubsection{Postionsspeicherung mit \mintinline{c++}|class Route|}
|
|
||||||
Die Klasse nutzt die Implementierung der Liste aus der C++ Standardbibliothek. Darüber hinaus wird ein Iterator für diese Liste von der Klasse verwaltet. Mit primitiven Datentypen wird festgehalten ob die Route gestartet ist und der wievielte Punkt gerade aus der Route selektiert ist.
|
|
||||||
\par
|
|
||||||
Die Funktionen der Klasse beschränken sich darauf den Iterator und Liste zu verwalten. Der Liste können nur Daten hinzugefügt werden. Die Entfernung einzelner Punkte ist nicht möglich und erfordert das Löschen der gesamten Liste. Es kann jeweils der nächste oder der vorherige Punkt ausgewählt werden. Die Route kann am Ende oder am Anfang gestartet werden. Soll die Route im Umgekehrter Reihenfolge abgefahren werden muss diese am Ende gestartet werden und immer der vorherige Punkt der Route abgerufen werden. Bei einem Fehler, weil beispielsweise keine Route aufgezeichnet wurde, wird von Funktionen eine Instanz von der \mintinline{c++}|class Point| mit den Koordinaten \(0 \text{ und } 0\) zurückgegeben. Dies kann von aufrufenden Funktion überprüft werden, dafür wurde eigens die Funktion \mintinline{c++}|bool Point::isValid();| implementiert.
|
|
||||||
\par
|
|
||||||
Damit Informationen über die Route abgefragt werden können, wurde ein Datentyp hinzugefügt. Das \mintinline{c++}|struct RouteInfo| enthält die Gesamtzahl der in der Route gespeicherten Punkte und der wievielte davon gerade ausgewählt ist.
|
|
||||||
|
|
||||||
\subsubsection{Verwaltung über das Menü}
|
|
||||||
In die vorhandene Menüstruktur wurde in der ersten Ebene der Punkt \flqq Route\frqq{} als Untermenü hinzugefügt. Dieses Menü stellt die in der folgenden Liste erläuterten Funktionen bereit. Für einige dieser Funktionen wird auf eine entwickelte HTTP-API zugegriffen, deshalb muss für diese Funktionen eine Internetverbindung bestehen. Die serverseitige Implementierung der API wird im Anhang \ref{cha:httpApi} beschrieben. Werden Teile der API auf dem Rover genutzt, zeigt dieser den HTTP-Code an. Mit diesem lässt sich erkennen ob die ausgeführte Operation korrekt ausgeführt wurde.
|
|
||||||
|
|
||||||
\begin{itemize}
|
|
||||||
\item \textbf{Points} - Unter diesem Punkt können die einzelnen Koordinaten der in der Route gespeicherten Punkte betrachtet werden.
|
|
||||||
\item \textbf{Clear} - Löscht die aktuell lokal erstellte Route.
|
|
||||||
\item \textbf{Import} - Bei Auswahl dieses Punktes muss der Benutzter die ID der Route wissen mit der diese Exportiert wurde. Sofern die gewählte ID existiert, wird die Route heruntergeladen und steht dem Rover nun zur Verfügung. Wenn bereits ein Route lokal vorhanden war, wird diese durch importierte überschrieben. In diesem Fall könnte die gefährdete Route vorher exportiert werden.
|
|
||||||
\item \textbf{Export} - Mit dieser Funktionen können Routen für die spätere Verwendung gesichert werden. Dafür muss ihnen eine ID zugewiesen werden, unter dieser ID lässt sich die Route später wieder abrufen.
|
|
||||||
\item \textbf{Delete} - Mit Delete kann eine exportierte Route mit ihrer ID gelöscht werden, dies betrifft allerdings nicht aktuell lokal vorhandene Route.
|
|
||||||
\end{itemize}
|
|
||||||
|
|
||||||
\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.
|
|
||||||
\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.
|
|
||||||
|
|
||||||
\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.
|
|
||||||
\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.
|
|
||||||
\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.
|
|
||||||
\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.
|
|
||||||
\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.
|
|
||||||
\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.
|
|
||||||
|
|
||||||
\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.
|
|
||||||
|
|
||||||
\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?!!!
|
|
||||||
\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.
|
|
||||||
|
|
||||||
\subsubsection{Navigationsanweisungen}
|
|
||||||
Aus der berechneten Kurskorrektur und dem verbleibenden Abstand zum Zielpunkt wird Navigationsanweisung erstellt. Die Informationen in das folgende \mintinline{c++}|struct| verpackt:
|
|
||||||
|
|
||||||
\begin{minted}[linenos, gobble=5, breaklines]{c++}
|
|
||||||
struct CourseCorrection
|
|
||||||
{
|
|
||||||
int16_t correction;
|
|
||||||
double distance;
|
|
||||||
};
|
|
||||||
\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.
|
|
||||||
|
|
||||||
\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:
|
|
||||||
|
|
||||||
\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.
|
|
||||||
\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.
|
|
||||||
|
|
||||||
\begin{table}[]
|
|
||||||
\centering
|
|
||||||
\begin{tabular}{|l|c|c|l|}
|
|
||||||
\hline
|
|
||||||
Zustand & \multicolumn{1}{l|}{Update} & \multicolumn{1}{l|}{Check} & Beschreibung \\ \hline
|
|
||||||
InsufficientAccuracy & x & - & -Warten auf bessere Genauigkeit \\ \hline
|
|
||||||
NoRoute & - & - & -Autopilot nicht verfügbar \\ \hline
|
|
||||||
None & - & - & -Default Zustand zum Programmbeginn \\ \hline
|
|
||||||
NavigationStarted & x & x & \begin{tabular}[c]{@{}l@{}}-Autopilot initialisiert\\ -Auf Benutzereingabe warten\end{tabular} \\ \hline
|
|
||||||
GetToStartPoint & x & - & \begin{tabular}[c]{@{}l@{}}-Warten bis Benutzer den Rover in die \\ Nähe des Startpunktes gebracht hat\\ -Fahren mit dem Joystick möglich\end{tabular} \\ \hline
|
|
||||||
SelfDrivingAvailable & x & x & \begin{tabular}[c]{@{}l@{}}-Autopilot bereit\\ -Auf Benutzereingabe warten\end{tabular} \\ \hline
|
|
||||||
SelfDriving & x & x & \begin{tabular}[c]{@{}l@{}}-Rover fährt geradeaus bis die\\ Abweichung zu groß ist.\end{tabular} \\ \hline
|
|
||||||
SelfDrivingRotate & x & - & -Abweichung korrigieren \\ \hline
|
|
||||||
TargetReached & - & - & -Navigation abgeschlossen \\ \hline
|
|
||||||
\end{tabular}
|
|
||||||
\caption{Auflistung und Beschreibung der Zustände des Autopiloten}
|
|
||||||
\label{tab:autopilot}
|
|
||||||
\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.
|
|
||||||
|
|
||||||
\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.
|
|
||||||
|
|
||||||
\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
|
|
||||||
mittel & 1!!! & 1 \\ \hline
|
|
||||||
nah & 0,75!!! & 0,5 \\ \hline
|
|
||||||
\end{tabular}
|
|
||||||
\caption{Geschwindigkeit der Rovers je nach Abstand zum Zielpunkt}
|
|
||||||
\label{tab:roverSpeed}
|
|
||||||
\end{table}
|
|
||||||
@@ -28,6 +28,6 @@
|
|||||||
\end{table}
|
\end{table}
|
||||||
|
|
||||||
\section{Auswertung}
|
\section{Auswertung}
|
||||||
Nachfolgend ist die von dem Post Processing Dienst erstelle PDF eingefügt. Diese enthält Informationen und Grafiken zur Auswertung. Da die PDF unverändert auf den nächsten Seiten eingefügt wird, findet dort keine Seitengestaltung im Sinne dieser Arbeit statt. Das betrifft auch die Seitenzahlen, welche zwar mitgezählt werden, aber erst wieder nach der eingefügten Auswertung angezeigt werden. Die angezeigten Seitenzahlen beziehen sich lediglich auf das eingefügte Dokument.
|
Nachfolgend ist die von dem Post Processing Dienst erstelle PDF eingefügt. Diese enthält Informationen und Grafiken zur Auswertung. Da diese PDF unverändert auf den nächsten Seiten eingefügt wird, findet dort keine Seitengestaltung im Sinne dieser Arbeit statt. Das betrifft auch die Seitenzahlen, welche zwar mitgezählt werden, aber erst wieder nach der eingefügten Auswertung angezeigt werden. Die angezeigten Seitenzahlen beziehen sich lediglich auf das eingefügte Dokument.
|
||||||
|
|
||||||
\includepdf[pages=-]{observation.pdf}
|
\includepdf[pages=-]{observation.pdf}
|
||||||
|
|||||||
@@ -193,4 +193,44 @@
|
|||||||
urldate = {2024-08-08},
|
urldate = {2024-08-08},
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@Manual{poeextender,
|
||||||
|
author = {TRENDnet},
|
||||||
|
title = {Industrieller 2-Port Gigabit PoE++ Extender für denAußenbereich},
|
||||||
|
subtitle = {TI-BE200 (v1.0R)},
|
||||||
|
url = {https://downloads.trendnet.com/ti-be200/datasheets/ge_datasheet_ti-be200_(v1.0r).pdf},
|
||||||
|
urldate = {2024-08-10},
|
||||||
|
}
|
||||||
|
|
||||||
|
@Manual{poesplitter,
|
||||||
|
author = {EXsys},
|
||||||
|
date = {2022},
|
||||||
|
title = {EX-60326},
|
||||||
|
url = {https://www.exsys-shop.de/shopware/media/pdf/56/66/27/datenblatt_datasheet_ex-60326.pdf},
|
||||||
|
urldate = {2024-08-10},
|
||||||
|
}
|
||||||
|
|
||||||
|
@Online{server,
|
||||||
|
author = {{ICO Innovative Computer GmbH}},
|
||||||
|
title = {PicoSYS 2880 Embedded-PC, J 4105, 4GB, 64GB SSD},
|
||||||
|
url = {https://www.ico.de/picosys-2880-embedded-pc-j-4105-4gb-64gb-ssd--9eh4351?referer=froogle&gad_source=1},
|
||||||
|
urldate = {2024-08-10},
|
||||||
|
}
|
||||||
|
|
||||||
|
@Manual{lorawangateway,
|
||||||
|
author = {{Dragino Technology Co., Limited}},
|
||||||
|
title = {Outdoor LoRaWAN Gateway - DLOS8N},
|
||||||
|
url = {https://iot-shop.de/web/content/92866?download=true},
|
||||||
|
urldate = {2024-08-10},
|
||||||
|
}
|
||||||
|
|
||||||
|
@Online{zed-f9p,
|
||||||
|
author = {u-blox},
|
||||||
|
date = {2024-03-21},
|
||||||
|
title = {ZED-F9P-04B - Datasheet},
|
||||||
|
url = {https://content.u-blox.com/sites/default/files/ZED-F9P-04B_DataSheet_UBX-21044850.pdf},
|
||||||
|
subtitle = {High precision GNSS module Professional grade},
|
||||||
|
urldate = {2024-08-10},
|
||||||
|
version = {R05},
|
||||||
|
}
|
||||||
|
|
||||||
@Comment{jabref-meta: databaseType:biblatex;}
|
@Comment{jabref-meta: databaseType:biblatex;}
|
||||||
|
|||||||
@@ -23,3 +23,6 @@ Fehlende Abschnitte:
|
|||||||
|
|
||||||
- Resümee
|
- Resümee
|
||||||
- Fazit
|
- Fazit
|
||||||
|
|
||||||
|
|
||||||
|
Alle V-spaces bei bildern entfernen? oder überall welchenm hin machen
|
||||||
|
|||||||
Binary file not shown.
|
After Width: | Height: | Size: 4.1 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 7.0 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 7.6 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 84 KiB |
Reference in New Issue
Block a user