From 193f1aae00f35a34271ebe733e281e8ef1e22ab2 Mon Sep 17 00:00:00 2001 From: Alexander Date: Thu, 1 Aug 2024 14:05:34 +0200 Subject: [PATCH] - evaluation ntrip revision - first spelling and grammar fixes --- .vscode/ltex.dictionary.de-DE.txt | 2 ++ .vscode/ltex.hiddenFalsePositives.de-DE.txt | 1 + .vscode/settings.json | 1 + 060_implementierung.tex | 10 +++++----- 065_bewertung.tex | 16 +++++++++------- 5 files changed, 18 insertions(+), 12 deletions(-) create mode 100644 .vscode/ltex.dictionary.de-DE.txt create mode 100644 .vscode/ltex.hiddenFalsePositives.de-DE.txt diff --git a/.vscode/ltex.dictionary.de-DE.txt b/.vscode/ltex.dictionary.de-DE.txt new file mode 100644 index 0000000..0125ecc --- /dev/null +++ b/.vscode/ltex.dictionary.de-DE.txt @@ -0,0 +1,2 @@ +Ntrip +Caster diff --git a/.vscode/ltex.hiddenFalsePositives.de-DE.txt b/.vscode/ltex.hiddenFalsePositives.de-DE.txt new file mode 100644 index 0000000..deaa65b --- /dev/null +++ b/.vscode/ltex.hiddenFalsePositives.de-DE.txt @@ -0,0 +1 @@ +{"rule":"GERMAN_SPELLER_RULE","sentence":"^\\QDafür existiert der Menüeintrag Clear oder der Rover wird neugestartet.\\E$"} diff --git a/.vscode/settings.json b/.vscode/settings.json index 89f4359..f9459c2 100644 --- a/.vscode/settings.json +++ b/.vscode/settings.json @@ -2,6 +2,7 @@ "editor.wordWrap": "on", "editor.formatOnSave": true, "editor.suggest.snippetsPreventQuickSuggestions": false, + "ltex.language": "de-DE", "latex-workshop.latex.outDir": "%WORKSPACE_FOLDER%/build", "latex-workshop.latex.autoBuild.run": "onFileChange", "latex-workshop.latexindent.path": "latexindent", diff --git a/060_implementierung.tex b/060_implementierung.tex index 4b9bcfd..b7a43e3 100644 --- a/060_implementierung.tex +++ b/060_implementierung.tex @@ -3,14 +3,14 @@ \section{Basisstation} \label{sec:Basisstation} - Für den 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 vorangegangen 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. 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 das 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 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 Betriebssystem 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} 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. @@ -239,7 +239,7 @@ \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. + \item \textbf{notAvailable} Dieser Zustand wird betreten, wenn keine Verbindung zum Internet bereitsteht. \end{itemize} \subsection{Routen Management} @@ -250,7 +250,7 @@ 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. + \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} diff --git a/065_bewertung.tex b/065_bewertung.tex index 59db5e7..ffa132a 100644 --- a/065_bewertung.tex +++ b/065_bewertung.tex @@ -18,19 +18,19 @@ Die Anforderungen an Rover stammen aus der übergeordneten Forderung. Laut dieser soll der Rover so erweitert werden, dass dieser eine zuvor aufgezeichnete Route eigenständig abfahren kann. Dafür wurden die folgenden Komponenten als Anforderungen definiert: \begin{itemize} - \item Der Rover muss über einen \textbf{Ntrip-Client} verfügen. Die Implementation wurde in Abschnitt \ref{ssec:ntripclient} beschrieben. Dafür wurde ein Dokument von der RTCM herangezogen welches Anmerkungen und Hilfestellung für die erfolgreiche Implementation eines Clients gibt. Durch die Umsetzung als Zustandsautomat kann der aktuelle Zustand des Clients einfach an andere Komponenten weitergegeben werden. Die Anforderungen verloren gegangene Verbindung automatisch wieder aufzubauen wurde für die Verbindung zu dem Caster umgesetzt. Die Umsetzung der W-Lan-Verbindung und deren Funktion zum automatischen Wiederverbinden wurde bereits in der vorhanden Software des Rovers umgesetzt. + \item Der Rover muss über einen \textbf{Ntrip-Client} verfügen. Die Implementation wurde in Abschnitt \ref{ssec:ntripclient} beschrieben. Dafür wurde ein Dokument von der RTCM herangezogen welches Anmerkungen und Hilfestellungen für die erfolgreiche Implementation eines Clients gibt. Durch die Umsetzung als Zustandsautomat kann der aktuelle Zustand des Clients einfach an andere Komponenten weitergegeben werden. Die Anforderungen verloren gegangene Verbindung automatisch wieder aufzubauen wurde für die Verbindung zu dem Caster umgesetzt. Die Umsetzung der W-Lan-Verbindung und deren Funktion zum automatischen Wiederverbinden wurde bereits in der vorhanden Software des Rovers umgesetzt. \item Für die Navigation müssen die Daten für eine \textbf{Route} gespeichert werden. Das Management der Routen wurde den Anforderungen entsprechend vollständig implementiert und wird in Abschnitt \ref{ssec:route_management} beschrieben. Dabei wurde die Speicherung von einzelnen Punkten mit Metadaten, welche durch eine verkette Liste in eine feste Reihenfolge gebracht werden umgesetzt. Außerdem wurde die Schnittstelle zu einer HTTP-API implementiert damit die Routen unabhängig von dem ESP32 persistiert werden können. Eine neue Route kann mit dem dafür angelegten Betriebsmodus des Rovers aufgenommen werden. \item Die neue Kernfunktion wurde in zwei Funktionen aufgeteilt, davon ist die erste die \textbf{Navigation}. Mit dieser wird die Route lesend verarbeitet und die Informationen über Distanz und Kurs zum nächsten Punkt werden über einen erstellten Datentypen der Nutzenden Komponente zur Verfügung gestellt. Eine nähere Beschreibung der Vorgehensweise ist in Abschnitt \ref{ssec:navigation_implementation} zu finden. Die Eigenständig der Navigation wurde durch die Implementierung als Komponente erreicht. \item Die zweite Funktion zur Realisierung der Kernfunktion ist der \textbf{Autopilot}. Dessen Anforderung werden durch die Implementierungen ab Abschnitt \ref{ssec:route_drive} erfüllt. Dafür wurde der Autopilot und der dazu passende Betriebsmodus entwickelt. Die Kernfunktionen werden zusätzlich mit den Test in Abschnitt \ref{sec:tests} überprüft. \end{itemize} \section{Referenzstation} - Die Abschnitt beschreibt und bewertet die Errichtung der Referenzstation. Dafür sind zunächst die Empfangenen Satelliten und die Fehler der Signale interessant. Des weiteren erfordert der Server zwar wenig wartungsarbeit, aber dieser ist schwer auszuführen, da alle Einstellungen manuell und textbasiert getätigt wurden. + Dieser Abschnitt beschreibt und bewertet die Errichtung der Referenzstation. Dafür sind zunächst die empfangenen Satelliten und die Fehler der Signale interessant. Des Weiteren erfordert der Server zwar wenig Wartungsarbeit, aber dieser ist schwer auszuführen, da alle Einstellungen manuell und textbasiert getätigt wurden. \par Der Ntrip-Client welcher auf dem Rover implementiert wurde kann mit beiden Revisionen von Ntrip betrieben werden, daher ist es interessant ob Unterschiede erkennbar sind. \subsection{Signalqualität} - Das in Anhang \ref{cha:winAndUcenter} beschriebene U-Center bietet verschieden Möglichkeiten die Signalqualität des Systems zu bestimmen. Einer dieser Möglichkeiten ist die im Programm sogenannte SkyView zu betrachten. Die Abbildungen !!!ref!!! zeigt einen Screenshot dieser Ansicht. Dort sind alle aktuell empfangen Satelliten und deren Positionsverlauf aus Sicht der Antenne eingezeichnet. Die einzelnen Satelliten sind mit einem Buchstaben für das jeweilige GNSS und einer Nummer gekennzeichnet (G - GPS, E - Galileo, R - GLONASS, B - Beidou, S - SBAS). Durch die Farbgebung der Satelliten wird angezeigt wie der betroffene Satellit in die Auswertung der Position mit einbezogen werden kann, !!!Folgende Farben checken lassen!!! dabei sind grüne Satelliten, die die ohne Einschränkungen genutzt werden können weil alle Informationen übertragen wurden. Von den blauen hingegen sind nicht alle Informationen empfangen worden oder das Signal wird nicht immer fehlerfrei empfangen. Daher tragen diese einen geringeren Teil zur Positionsbestimmung bei. Zu den roten Satelliten besteht keine Verbindung mehr. Dies lässt sich gut durch die Position am äußerten Horizont dieser Satelliten erklären. Auch die blauen Satelliten zeichnen sich dadurch aus, das die meisten sich am Rand des empfangbaren Bereichs befinden. + Das in Anhang \ref{cha:winAndUcenter} beschriebene U-Center bietet verschieden Möglichkeiten die Signalqualität des Systems zu bestimmen. Einer dieser Möglichkeiten ist die im Programm sogenannte SkyView zu betrachten. Die Abbildungen !!!ref!!! zeigt einen Screenshot dieser Ansicht. Dort sind alle aktuell empfangen Satelliten und deren Positionsverlauf aus Sicht der Antenne eingezeichnet. Die einzelnen Satelliten sind mit einem Buchstaben für das jeweilige GNSS und einer Nummer gekennzeichnet (G - GPS, E - Galileo, R - GLONASS, B - Beidou, S - SBAS). Durch die Farbgebung der Satelliten wird angezeigt wie der betroffene Satellit in die Auswertung der Position mit einbezogen werden kann, !!!Folgende Farben checken lassen!!! dabei sind grüne Satelliten, die die ohne Einschränkungen genutzt werden können, weil alle Informationen übertragen wurden. Von den blauen hingegen sind nicht alle Informationen empfangen worden oder das Signal wird nicht immer fehlerfrei empfangen. Daher tragen diese einen geringeren Teil zur Positionsbestimmung bei. Zu den roten Satelliten besteht keine Verbindung mehr. Dies lässt sich gut durch die Position am äußerten Horizont dieser Satelliten erklären. Auch die blauen Satelliten zeichnen sich dadurch aus, das die meisten sich am Rand des empfangbaren Bereichs befinden. In der nächsten Abbildung !!!ref!!! werden die Satelliten Signale als Balkendiagramm dargestellt die Tabelle !!!ref!!! fasst die Daten der Abbildung zusammen. Dabei wird deutlich, dass von allen GNSS mehr als die benötigten vier Satelliten für eine Positionsbestimmung mit diesem System empfangen werden. !!!Bild @@ -47,15 +47,17 @@ Zusammen mit der Erfüllung der gestellten Anforderungen an die Referenzstation lässt sich diese als voll Funktionsfähig beschreiben. Da der Wartungsaufwand voraussichtlich sehr gering ausfallen wird, reduziert dies die Relevanz der eben genannten Einschränkungen. Einiger dieser Einschränkungen lassen sich mit einem Projekt auf GitHub Namens \texttt{rtkbase!!!Name checken} !!!ref beheben und die Referenzstation damit mit Flexibilität ausstatten. Diese mögliche Änderung wird kurz im Abschnitt \ref{sec:ausblick} Ausblick !!!gibt ref auch mit auto name?!!! beschrieben. \subsection{Ntrip Revision 1} - Ntrip rev 1 oder 2 Ergebnis (Sapos auch testen) + Es wurden beide Revision des Ntrip-Protokolls jeweils mit dem Caster \url{rtk2go.com} und \url{sapos-ni-ntrip.de} getestet. Dabei wurde aufgrund der Abwärtskompatibilität erwartet, dass beide Caster die aktuelle Revision von Ntrip akzeptieren. Bei der Erstellung des Mountpoints auf \url{rtk2g0.com} wurde aufgrund der Empfehlungen des Formulars die Revision 1 von Ntrip gewählt. Welche Version von Ntrip der Caster von Sapos nutzt ist auf der Website nicht ersichtlich, da jedoch von beiden Castern Anfragen beider Ntrip Revisionen akzeptiert wurden, wird davon ausgegangen, dass auch beide die Revision 1 nutzen. + \par + Durch die vorhandene und funktionierende Abwärtskompatibilität kann daher problemlos auf die veraltete Revision verzichtet werden. Sollte doch mal ein Caster aus unerwarteten Gründen die nur die Revision 1 akzeptieren, kann dies durch den implementierten Client berücksichtigt werden. \section{Tests} \label{sec:tests} \subsection{Route aufzeichnen} \subsubsection{Koordinaten Plausibilität} - \subsection{Routen management} - Die Verwaltung der Routen kann getestet werden, indem die einzelnen Aktionen zur Routen Verwaltung ausgeführt werden. Als Vorbereitung muss eine Route aufgezeichnet werden, dementsprechend muss der vorausgegangene Test \texttt{Route aufzeichnen} erfolgreich abgeschlossen worden sein. Für den Umfang dieses Tests wurde festgelegt, dass die Route 10 Punkte beinhalten soll. Die Anzahl der bereits aufgezeichneten Punkte kann im Menü des Aufzeichnungsmodus verfolgt werden und Abschließend im Menü \texttt{Route} überprüft werden. In diesem Menü können die einzelnen Koordinaten der Punkte betrachtet werden, diese werden wieder notiert um die Richtigkeit der Daten im Verlauf des Tests prüfen zu können. + \subsection{Routen Management} + Die Verwaltung der Routen kann getestet werden, indem die einzelnen Aktionen zur Routenverwaltung ausgeführt werden. Als Vorbereitung muss eine Route aufgezeichnet werden, dementsprechend muss der vorausgegangene Test \texttt{Route aufzeichnen} erfolgreich abgeschlossen worden sein. Für den Umfang dieses Tests wurde festgelegt, dass die Route 10 Punkte beinhalten soll. Die Anzahl der bereits aufgezeichneten Punkte kann im Menü des Aufzeichnungsmodus verfolgt werden und abschließend im Menü \texttt{Route} überprüft werden. In diesem Menü können die einzelnen Koordinaten der Punkte betrachtet werden, diese werden wieder notiert um die Richtigkeit der Daten im Verlauf des Tests prüfen zu können. \subsubsection{Route exportieren} Nach Abschluss der Vorbereitung kann die Route exportiert werden, dafür muss der zugehörige Menüpunkt aufgerufen werden. In diesem muss eine \texttt{ID} für die Route vergeben werden. In diesem Fall wird dafür die Zahl \(98\) gewählt. Nach der Bestätigung wird der Ausgang des Exports mitgeteilt. In diesem Fall erscheint die Meldung \glqq \texttt{Export complete}\grqq\ mit dem Code \(201\). Zur Überprüfung der gespeicherten Daten kann die Route über die folgende URL abgerufen werden: \url{https://rover.kleiax.de/api/98}. Die empfangenen Daten des Endpunktes der API entsprechen den übermittelten Daten. @@ -63,7 +65,7 @@ Ein erneuter Versuch die Route mit der selben \texttt{ID} zu exportieren schlägt richtigerweise mit dem Code \(419\) fehl, da die \texttt{ID} bereits verwendet wird und dadurch sichergestellt werden kann, dass diese nicht durch eine fehlerhafte Eingabe überschrieben oder verfälscht wird. \subsubsection{Route importieren} - Um überprüfen zu können, ob die exportierte Route bei dem folgenden Test auch tatsächlich wieder geladen wird, muss zunächst die zwischengespeicherte Route gelöscht werden. Dafür existiert der Menüeintrag \texttt{Clear} oder der Rover wird neugestartet. Für den Test wurde ein Neustart über das Menü ausgeführt. In dem Menüeintrag \texttt{Points} kann zusätzlich überprüft werden, ob eine Route vorhanden ist. Der eigentliche Test besteht darin, über den Menüpunkt \texttt{import} die zuvor gewählte \texttt{ID} zu selektieren und anschließend durch die Bestätigung den Import auszuführen. Bei einem Erfolg wird die Meldung \glqq \texttt{Import Complete}\grqq\ mit dem Code \(202\) erwartet. + Um überprüfen zu können, ob die exportierte Route bei dem folgenden Test auch tatsächlich wieder geladen wird, muss zunächst die zwischengespeicherte Route gelöscht werden. Dafür existiert der Menüeintrag \glqq\texttt{Clear}\grqq\ oder der Rover wird neugestartet. Für den Test wurde ein Neustart über das Menü ausgeführt. In dem Menüeintrag \texttt{Points} kann zusätzlich überprüft werden, ob eine Route vorhanden ist. Der eigentliche Test besteht darin, über den Menüpunkt \texttt{import} die zuvor gewählte \texttt{ID} zu selektieren und anschließend durch die Bestätigung den Import auszuführen. Bei einem Erfolg wird die Meldung \glqq \texttt{Import Complete}\grqq\ mit dem Code \(202\) erwartet. \par Nach dem Erhalt der Erfolgsbestätigung wurden die importierten Koordinaten mit den exportierten Koordinaten abgeglichen und es wurde Gleichheit festgestellt. Der Versuch eine nicht existierende Route zu importierten, schlägt erfolgreich mit dem Code \(418\) fehl.