Archived
- more pictures
- more fixes - more literatur
This commit is contained in:
Vendored
+57
@@ -104,3 +104,60 @@ PoE-fähige
|
|||||||
PoE-Extender
|
PoE-Extender
|
||||||
GPS-RTK-SMA
|
GPS-RTK-SMA
|
||||||
Breakout
|
Breakout
|
||||||
|
iso-Datei
|
||||||
|
root-Benutzer
|
||||||
|
text
|
||||||
|
nameserver
|
||||||
|
xxx.xxx.xxx.xxx
|
||||||
|
interface
|
||||||
|
ifdown
|
||||||
|
ifup
|
||||||
|
bash
|
||||||
|
Sudo
|
||||||
|
root-Rechten
|
||||||
|
apt-get
|
||||||
|
sudo
|
||||||
|
rtk
|
||||||
|
rtk-Benutzer
|
||||||
|
usermod
|
||||||
|
aG
|
||||||
|
PermitRootLogin
|
||||||
|
no
|
||||||
|
service
|
||||||
|
sshd
|
||||||
|
restart
|
||||||
|
u-center
|
||||||
|
install
|
||||||
|
tty
|
||||||
|
Yaml-Block
|
||||||
|
rtk-Benutzers
|
||||||
|
make
|
||||||
|
Extenders
|
||||||
|
Packet-View
|
||||||
|
RAWX
|
||||||
|
timeout
|
||||||
|
screen-Sitzung
|
||||||
|
convbin
|
||||||
|
scp
|
||||||
|
TMODE
|
||||||
|
.service
|
||||||
|
rtk.service
|
||||||
|
Auxiliary-I
|
||||||
|
class
|
||||||
|
SensorData
|
||||||
|
void
|
||||||
|
developers
|
||||||
|
outdated
|
||||||
|
Casters
|
||||||
|
NTRIPClientStates
|
||||||
|
enum
|
||||||
|
openingConnection
|
||||||
|
pushingData
|
||||||
|
closingConnection
|
||||||
|
notAvailable
|
||||||
|
waiting
|
||||||
|
struct
|
||||||
|
Coordinates
|
||||||
|
Postionsspeicherung
|
||||||
|
bool
|
||||||
|
RouteInfo
|
||||||
|
|||||||
+6
@@ -17,3 +17,9 @@
|
|||||||
{"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":"^\\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":"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$"}
|
{"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$"}
|
||||||
|
{"rule":"UPPERCASE_SENTENCE_START","sentence":"^\\Qsudo.\\E$"}
|
||||||
|
{"rule":"UPPERCASE_SENTENCE_START","sentence":"^\\Qdeaktiviert werden.\\E$"}
|
||||||
|
{"rule":"LT_RECOMMENDATION_ESSENTIAL","sentence":"^\\QDer Compiler inklusive weiterer benötigter Tools wie []text|make| ist in dem Paket []text|build-essential| enthalten.\\E$"}
|
||||||
|
{"rule":"UPPERCASE_SENTENCE_START","sentence":"^\\Qdie Antenne soll am Ende des C-Profils, welches zur Verlängerung des Pfostens dient, befestigt werden.\\E$"}
|
||||||
|
{"rule":"ALTERNATIVEN_FUER_ANGLIZISMEN","sentence":"^\\QDamit die Aufzeichnung nicht als Kind-Prozess der Remote-Sitzung läuft wird das Hilfsprogramm []bash|screen| installiert, da ansonsten ein Abbruch der Verbindung auch die Aufzeichnung frühzeitig beenden würde.\\E$"}
|
||||||
|
{"rule":"ALTERNATIVEN_FUER_ANGLIZISMEN","sentence":"^\\QDamit die Aufzeichnung nicht als Kind-Prozess der Remote-Sitzung läuft, wird das Hilfsprogramm []bash|screen| installiert, da ansonsten ein Abbruch der Verbindung auch die Aufzeichnung frühzeitig beenden würde.\\E$"}
|
||||||
|
|||||||
Vendored
+2
-3
@@ -32,9 +32,9 @@
|
|||||||
"\\begin{figure}[ht]",
|
"\\begin{figure}[ht]",
|
||||||
"\t\\vspace{1cm}",
|
"\t\\vspace{1cm}",
|
||||||
"\t\\centering",
|
"\t\\centering",
|
||||||
"\t\\includegraphics[width=\\linewidth]{Bilder/$1.jpg}",
|
"\t\\includegraphics[width=\\linewidth]{img/$1.png}",
|
||||||
"\t\\caption{$0}",
|
"\t\\caption{$0}",
|
||||||
"\t\\label{fig:$0}",
|
"\t\\label{fig:$1}",
|
||||||
"\\end{figure}",
|
"\\end{figure}",
|
||||||
],
|
],
|
||||||
"description": "Rahmen zum Einfügen eines Bildes"
|
"description": "Rahmen zum Einfügen eines Bildes"
|
||||||
@@ -91,5 +91,4 @@
|
|||||||
],
|
],
|
||||||
"description": "Fügt eine Zeile mit 2 Spalten hinzu"
|
"description": "Fügt eine Zeile mit 2 Spalten hinzu"
|
||||||
},
|
},
|
||||||
|
|
||||||
}
|
}
|
||||||
@@ -79,7 +79,7 @@
|
|||||||
\begin{figure}[ht]
|
\begin{figure}[ht]
|
||||||
\centering
|
\centering
|
||||||
\includegraphics[width=\linewidth]{img/satellite.jpg}
|
\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}}}
|
\caption{Modell eines Satelliten von dem GNSS Galileo \protect\footnote[1]{Bild eines Galileo Satellit from Science Museum Collections made by Paragon Creative, lizenziert unter [CC BY 4.0] \url{https://creativecommons.org/licenses/by/4.0/legalcode}, abgerufen von \url{https://commons.wikimedia.org/wiki/File:Galileo_satellite_model.jpg}}}
|
||||||
\label{fig:satellite}
|
\label{fig:satellite}
|
||||||
\end{figure}
|
\end{figure}
|
||||||
|
|
||||||
|
|||||||
+13
-5
@@ -36,27 +36,35 @@
|
|||||||
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.
|
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 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\).
|
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 \cite[]{sparkZedf9p} 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, 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.
|
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]
|
\begin{figure}[ht]
|
||||||
\centering
|
\centering
|
||||||
\includegraphics[width=\linewidth]{img/zed-f9p.jpg}
|
\includegraphics[width=0.5\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}}}
|
\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}
|
\label{fig:zedf9p}
|
||||||
\end{figure}
|
\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 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?!!!
|
Bei der gewählten Antenne, welche in Abbildung \ref{fig:antenneDach} zu sehen ist, handelt es sich um das Modell JCA228F von der Firma Jinchang Electron \cite[]{antenneDach}. 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.
|
||||||
|
|
||||||
|
\begin{figure}[ht]
|
||||||
|
\vspace{1cm}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=0.5\linewidth]{img/antenneDach.jpg}
|
||||||
|
\caption{Seitliche Ansicht auf die Antenne}
|
||||||
|
\label{fig:antenneDach}
|
||||||
|
\end{figure}
|
||||||
|
|
||||||
\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 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.
|
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 \texttt{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 (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.
|
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 (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.
|
Die Anforderung ein Gyroskop zu integrieren soll durch das GY-521 Modul \cite[]{gyroskop} 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 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.
|
||||||
|
|||||||
@@ -1,25 +1,25 @@
|
|||||||
|
|
||||||
\section{Basisstation}
|
\section{Basisstation}
|
||||||
\label{sec: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.
|
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. Weiterhin werden für die vollständige Montage Formteile benötigt, welche mit einem 3D-Drucker produziert werden sollen.
|
||||||
|
|
||||||
\subsection{Installation Betriebssystem}
|
\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.
|
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
|
\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.
|
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
|
\par
|
||||||
Nach der erfolgreichen Installation des Betriebssystems wurde sich zunächst als root Benutzer angemeldet, um die ersten grundlegenden Einstellungen zu tätigen.
|
Nach der erfolgreichen Installation des Betriebssystems wurde sich zunächst als root-Benutzer angemeldet, um die ersten grundlegenden Einstellungen zu tätigen.
|
||||||
|
|
||||||
\subsubsection{Netzwerk}
|
\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.
|
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 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|
|
Die zweite Datei ist unter dem Pfad \url{/etc/resolv.conf} zu finden und definiert die zu benutzenden DNS-Server. Dabei wird in jeder Zeile nach dem folgenden Muster ein Nameserver angegeben: \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
|
\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.
|
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 \mintinline{bash}|ifdown <interface>| gefolgt von \mintinline{bash}|ifup <interface>| oder einem Neustart des Computers erfolgen.
|
||||||
|
|
||||||
\subsubsection{sudo}
|
\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:
|
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 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}
|
\begin{minted}[linenos, gobble=5]{bash}
|
||||||
apt-get update
|
apt-get update
|
||||||
@@ -27,34 +27,34 @@
|
|||||||
apt-get install sudo
|
apt-get install sudo
|
||||||
\end{minted}
|
\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???|.
|
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{bash}|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.
|
Danach wird der root-Benutzer 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}
|
\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.
|
Der SSH-Server wird ebenfalls über die Paketquellen installiert, der Paketname entspricht der Überschrift dieses Abschnitts. Mit einem SSH-Server wird die Verwaltung des Systems ü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 Log-in mit dem root-Benutzer 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| neu gestartet.
|
||||||
\par
|
\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.
|
Ab diesem Zeitpunkt der Installation kann der Server ohne Monitor und Tastatur betrieben werden. Es ist nur noch eine die Netzwerkverbindung und die Stromversorgung notwendig. Für den Log-in wird ein SSH-Client, die Zugangsdaten und die Adresse des Servers benötigt.
|
||||||
|
|
||||||
\subsection{ser2net vorbereiten}
|
\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.
|
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
|
\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
|
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}
|
\begin{minted}[linenos, gobble=4]{bash}
|
||||||
sudo systemctl disable ser2net
|
sudo systemctl disable ser2net
|
||||||
\end{minted}
|
\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.
|
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 neu gestartet oder der Service mit dem ersten Befehl gestoppt wird.
|
||||||
|
|
||||||
\begin{minted}[linenos, gobble=4]{bash}
|
\begin{minted}[linenos, gobble=4]{bash}
|
||||||
sudo systemctl stop ser2net
|
sudo systemctl stop ser2net
|
||||||
sudo systemctl start ser2net
|
sudo systemctl start ser2net
|
||||||
\end{minted}
|
\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:
|
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 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}
|
% \begin{minted}[linenos, gobble=4, tabsize=4, showtabs=no]{yaml}
|
||||||
% connection: &con0096
|
% connection: con0096
|
||||||
% accepter: tcp,2000
|
% accepter: tcp,2000
|
||||||
% enable: on !!!mach mal richtig hier!!!
|
% enable: on !!!mach mal richtig hier!!!
|
||||||
% options:
|
% options:
|
||||||
@@ -64,10 +64,10 @@
|
|||||||
% connector: serialdev,/dev/ttyS0,9600n81,local
|
% connector: serialdev,/dev/ttyS0,9600n81,local
|
||||||
% \end{minted}
|
% \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.
|
Sollte der Service zum Zeitpunkt der Konfiguration aktiv gewesen sein, muss es mit dem genannten Befehl gestoppt 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}
|
\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:
|
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 klonen 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}
|
\begin{minted}[linenos, gobble=4]{bash}
|
||||||
sudo apt-get update
|
sudo apt-get update
|
||||||
@@ -85,14 +85,51 @@
|
|||||||
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.
|
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}
|
\subsubsection{Befestigungen}
|
||||||
Die anzubringenden Komponenten benötigen Halterungen und Befestigungspunkte. Diese werden im folgenden Beschrieben:
|
Die anzubringenden Komponenten benötigen Halterungen und Befestigungspunkte. Diese werden im Folgenden beschrieben:
|
||||||
|
|
||||||
\begin{itemize}
|
\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 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 \ref{fig:antenneHalterung}). Im Wesentlichen besteht dieses 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 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[]{kasten} verfügbare Lochabstand der Befestigungslöcher des Kastens. Mit diesen Werten konnte eine Halterung konstruiert werden, welche aus zwei Halbschalen besteht. Eine Halbschale verfügt über abstehende Arme mit vorhandenen Löchern für M4-Schrauben, an denen der Kasten befestigt werden kann. Die M4-Schrauben können von hinten mit der passenden Mutter gesichert werden. In die gleiche 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{fig:halbschalen} 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 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 einzubeziehen. Die Winkel sind für die Wandmontage gedacht und werden nach Herstellervorgaben auf der Rückseite des Computers befestigt, sodass 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, (siehe Abbildung \ref{fig:pcHalter})
|
||||||
|
|
||||||
\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.
|
\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{fig:gnssHalter} gezeigt.
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
|
|
||||||
|
|
||||||
|
\begin{figure}[htbp]
|
||||||
|
\centering
|
||||||
|
\begin{minipage}[b]{0.40\textwidth}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=\textwidth]{img/antenneHalterung.png}
|
||||||
|
\caption{Formteil für die Befestigung der Antenne}
|
||||||
|
\label{fig:antenneHalterung}
|
||||||
|
\end{minipage}
|
||||||
|
\hfill
|
||||||
|
\begin{minipage}[b]{0.40\textwidth}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=\textwidth]{img/halbschalen.png}
|
||||||
|
\caption{Halterung für den Installationskasten am Mast}
|
||||||
|
\label{fig:halbschalen}
|
||||||
|
\end{minipage}
|
||||||
|
\end{figure}
|
||||||
|
|
||||||
|
|
||||||
|
\begin{figure}[htbp]
|
||||||
|
\centering
|
||||||
|
\begin{minipage}[b]{0.40\textwidth}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=\textwidth]{img/pcHalter.png}
|
||||||
|
\caption{Montageplatte für den Server auf einer Hutschiene}
|
||||||
|
\label{fig:pcHalter}
|
||||||
|
\end{minipage}
|
||||||
|
\hfill
|
||||||
|
\begin{minipage}[b]{0.40\textwidth}
|
||||||
|
\centering
|
||||||
|
\includegraphics[width=\textwidth]{img/gnssHalter.png}
|
||||||
|
\caption{Gehäuse für das GNSS-Modul zur Befestigung auf einer Hutschiene}
|
||||||
|
\label{fig:gnssHalter}
|
||||||
|
\end{minipage}
|
||||||
|
\centering
|
||||||
|
\end{figure}
|
||||||
|
|||||||
@@ -1,7 +1,7 @@
|
|||||||
\subsubsection{Installationskasten bestücken}
|
\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.
|
Der Installationskasten kann weitgehend vorbereitet werden. Dafür wurden zunächst ein Loch an der unteren Seite gebohrt, welches groß genug ist, um einen 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
|
\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.
|
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
|
\par
|
||||||
Als weitere Vorbereitung wurden weitere benötigte Netzwerkkabel bereitgelegt und Adapter für die Antennenmontage wurde an dem C-Profil befestigt.
|
Als weitere Vorbereitung wurden weitere benötigte Netzwerkkabel bereitgelegt und Adapter für die Antennenmontage wurde an dem C-Profil befestigt.
|
||||||
|
|
||||||
@@ -16,7 +16,7 @@
|
|||||||
\subsubsection{Montage}
|
\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.
|
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
|
\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.
|
Als Nächstes musste der PoE-Extender in den vorhandenen Anschlusskasten eingebracht werden. Dieser wurde ebenfalls an der Hutschiene befestigt. Das von dem LoRaWAN-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 das vorhandene System wieder einsatzbereit ist. Für die letzte herzustellende Verbindung zwischen dem PoE-Extender und dem PoE-Splitter, musste das Loch in dem vorhandenen Installationskasten etwas aufgebohrt werden. Danach konnte das Kabel verlegt werden, wobei die überschüssige Länge des Kabels 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]
|
\begin{figure}[ht]
|
||||||
\vspace{1cm}
|
\vspace{1cm}
|
||||||
@@ -27,9 +27,9 @@
|
|||||||
\end{figure}
|
\end{figure}
|
||||||
|
|
||||||
\subsection{Antennenposition bestimmen}
|
\subsection{Antennenposition bestimmen}
|
||||||
Die nun folgenden Schritte wurde alle von einem Remote-Arbeitsplatz durchgeführt.
|
Die jetzt folgenden Schritte wurde alle von einem Remote-Arbeitsplatz durchgeführt.
|
||||||
\par
|
\par
|
||||||
Damit die Antennenposition bestimmt werden kann sind im grundlegenden drei Schritte notwendig:
|
Damit die Antennenposition bestimmt werden kann, sind im grundlegenden drei Schritte notwendig:
|
||||||
|
|
||||||
\setlist{noitemsep}
|
\setlist{noitemsep}
|
||||||
\begin{enumerate}
|
\begin{enumerate}
|
||||||
@@ -39,9 +39,9 @@
|
|||||||
\end{enumerate}
|
\end{enumerate}
|
||||||
\setlist{}
|
\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.
|
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 für die USB-Schnittstelle aktiviert werden. Ob die benötigten Daten gesendet werden, kann in Packet-View vom u-center kontrolliert werden.
|
||||||
\par
|
\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:
|
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 PostProcessing Dienste 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}
|
\begin{minted}[linenos, gobble=4, breaklines]{bash}
|
||||||
sudo apt-get update
|
sudo apt-get update
|
||||||
@@ -62,7 +62,7 @@
|
|||||||
./RTKLIB/app/consapp/convbin/gcc/convbin -od -os -oi -ot -ti 30 observation.ubx
|
./RTKLIB/app/consapp/convbin/gcc/convbin -od -os -oi -ot -ti 30 observation.ubx
|
||||||
\end{minted}
|
\end{minted}
|
||||||
|
|
||||||
Für die Erklärung der verwendeten Optionen folgt ein Ausschnitt aus dem Manual der RTKLib !!!cite!!!:
|
Für die Erklärung der verwendeten Optionen folgt ein Ausschnitt aus dem Manual der RTKLib \cite[97]{rtklibMan}:
|
||||||
|
|
||||||
\setlist{noitemsep}
|
\setlist{noitemsep}
|
||||||
\begin{itemize}[label=-]
|
\begin{itemize}[label=-]
|
||||||
@@ -74,17 +74,17 @@
|
|||||||
\end{itemize}
|
\end{itemize}
|
||||||
\setlist{}
|
\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.
|
Die umgewandelte Datei muss anschließend an einen PostProcessing 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
|
\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\).
|
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
|
\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.
|
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 in 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, damit auch über einen Neustart hinweg verfügbar zu sein. Dafür kann in der Menüleiste der Punkt \texttt{Save Config} ausgewählt werden.
|
||||||
|
|
||||||
\subsection{Service einrichten}
|
\subsection{Service einrichten}
|
||||||
\label{ssec:pushService}
|
\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.
|
Die von dem GNSS-Modul generierten Korrekturdaten müssen kontinuierlich an den Ntrip-Caster weitergeleitet werden. Dafür wird der bereits zuvor genutzte Kommunikations-Server der RTKLib verwendet. Als Ausgang wird anstelle der Datei nun der Ntrip-Caster angegeben.
|
||||||
\par
|
\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:
|
Damit die Ausgabe automatisch protokolliert wird und der Kommunikations-Server 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}
|
\begin{minted}[linenos, gobble=4, breaklines]{bash}
|
||||||
[Unit]
|
[Unit]
|
||||||
|
|||||||
@@ -1,19 +1,19 @@
|
|||||||
\section{Rover}
|
\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.
|
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}
|
\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.
|
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
|
\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.
|
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
|
\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.
|
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, damit die Funktion umzusetzen werden kann. 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
|
\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.
|
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 Funktion zum Datenerhalt, die Funktion \mintinline{c++}|void enableGyroscope(); | hinzugefügt. Diese erzeugt ein Objekt für den MPU-6050 und initialisiert sowohl den MPU-6050 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 in jedem Durchgang, ob neue Daten des Sensors verfügbar sind und verarbeitet diese dann.
|
||||||
|
|
||||||
|
|
||||||
\subsection{Ntrip Client}
|
\subsection{Ntrip Client}
|
||||||
\label{ssec:ntripclient}
|
\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.
|
Die Implementierungen des Clients orientiert sich an dem von der RTCM herausgegebenen Paper \glqq Best Practices for NTRIP Client developers\grqq \cite{NTRIPWorkingGroup2023}. Zudem 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}
|
\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.
|
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.
|
||||||
@@ -30,13 +30,13 @@
|
|||||||
\setlist{}
|
\setlist{}
|
||||||
|
|
||||||
\subsubsection{Zustandsautomaten}
|
\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.
|
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}
|
\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{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{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{closingConnection} Sollte der Ntrip Client deaktiviert 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{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.
|
\item \textbf{notAvailable} Dieser Zustand wird betreten, wenn keine Verbindung zum Internet bereitsteht.
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
|
|
||||||
@@ -45,16 +45,16 @@
|
|||||||
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|.
|
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|}
|
\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:
|
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 den Methoden zur Datenkontrolle und Zugriff wird die Funktionalität der Klasse durch diese beiden Funktionen gegeben:
|
||||||
|
|
||||||
\begin{itemize}
|
\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.
|
\item \mintinline{c++}|double distanceTo(Point); | errechnet die Entfernung zwischen den Koordinaten der Instanz zu dem gegebenen Punkt. Für die Berechnung wird die Erdkrümmung vernachlässigt, deshalb kann der Satz des Pythagoras genutzt werden. Dafür müssen die in Grad angegebenen Koordinaten zunächst in Radianten umgewandelt 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}
|
\begin{eqnarray}
|
||||||
d = \sqrt{(x_2 - x_1)^2 + (y_2 - y_1)^2}
|
d = \sqrt{(x_2 - x_1)^2 + (y_2 - y_1)^2}
|
||||||
\end{eqnarray}
|
\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
|
\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\) etwa 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}
|
\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))
|
\theta = \text{atan2}(\sin(\Delta \lambda)cos(\phi_2), \cos(\phi_1)\sin(\phi_2) - \sin(\phi_1)\cos(\phi_2)\cos(\Delta \lambda))
|
||||||
@@ -68,23 +68,23 @@
|
|||||||
\lambda_1, \lambda_2 &\widehat{=}& \text{Längengrad der Punkte}
|
\lambda_1, \lambda_2 &\widehat{=}& \text{Längengrad der Punkte}
|
||||||
\end{eqnarray}
|
\end{eqnarray}
|
||||||
|
|
||||||
Anschließend muss \(\theta\) wieder in Grad umgewandelt werden und mit modulo auf den Wertebereich \(0 \text{ bis } 360\) normalisiert werden.
|
Anschließend muss \(\theta\) wieder in Grad umgewandelt und mit dem modulo-Operator auf den Wertebereich \(0 \text{ bis } 360\) normalisiert werden.
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
|
|
||||||
\subsubsection{Postionsspeicherung mit \mintinline{c++}|class Route|}
|
\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.
|
Die Klasse nutzt die Implementierung der Liste aus der C++ Standardbibliothek. Überdies wird ein Iterator für diese Liste von der Klasse verwaltet. Mit primitiven Datentypen wird festgehalten, ob die Route gestartet und der wievielte Punkt gerade aus der Route selektiert ist.
|
||||||
\par
|
\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.
|
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 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 der aufrufenden Funktion überprüft werden, dafür wurde eigens die Funktion \mintinline{c++}|bool Point::isValid(); | implementiert.
|
||||||
\par
|
\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.
|
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 sowie den Index des selektierten Punktes.
|
||||||
|
|
||||||
\subsubsection{Verwaltung über das Menü}
|
\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.
|
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 kann erkannt werden, ob die ausgeführte Operation korrekt ausgeführt wurde.
|
||||||
|
|
||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
\item \textbf{Points} - Unter diesem Punkt können die einzelnen Koordinaten der in der Route gespeicherten Punkte betrachtet werden.
|
\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{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{Import} - Bei Auswahl dieses Punktes muss der Benutzer 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 eine 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{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.
|
\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}
|
\end{itemize}
|
||||||
|
|||||||
@@ -233,4 +233,30 @@
|
|||||||
version = {R05},
|
version = {R05},
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@Online{sparkZedf9p,
|
||||||
|
author = {sparkfun},
|
||||||
|
title = {SparkFun GPS-RTK-SMA Breakout - ZED-F9P (Qwiic)},
|
||||||
|
url = {https://www.sparkfun.com/products/16481},
|
||||||
|
urldate = {2024-08-10},
|
||||||
|
}
|
||||||
|
|
||||||
|
@Manual{antenneDach,
|
||||||
|
author = {{JIAXING JINCHANG ELECTRONIC TECHNOLOGY CO.,LTD}},
|
||||||
|
title = {GNSS Surveying Antenna - JCA228F},
|
||||||
|
}
|
||||||
|
|
||||||
|
@Manual{gyroskop,
|
||||||
|
author = {AZ-Delivery},
|
||||||
|
title = {GY-521 6-Achsen Gyroskop und Beschleunigungssensor},
|
||||||
|
url = {https://cdn.shopify.com/s/files/1/1509/1638/files/GY-521_6-Achsen_Gyroskop_und_Beschleunigungssensor_Datenblatt_AZ-Delivery_Vertriebs_GmbH_b35673f3-1fb8-423c-a533-524c216d92dd.pdf?v=1627564500},
|
||||||
|
urldate = {2024-08-10},
|
||||||
|
}
|
||||||
|
|
||||||
|
@Manual{rtklibMan,
|
||||||
|
author = {T. Takasu},
|
||||||
|
date = {2013-04-29},
|
||||||
|
title = {RTKLIB ver. 2.4.2 Manual},
|
||||||
|
urldate = {2024-08-11},
|
||||||
|
}
|
||||||
|
|
||||||
@Comment{jabref-meta: databaseType:biblatex;}
|
@Comment{jabref-meta: databaseType:biblatex;}
|
||||||
|
|||||||
Binary file not shown.
|
After Width: | Height: | Size: 11 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 16 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 18 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 26 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 17 KiB |
Reference in New Issue
Block a user