- evaluation rover started

- outlook started

.vscode/ltex.dictionary.de-DE.txt

@@ -1,2 +1,4 @@
 Ntrip
 Caster
+Routenverwaltung
+Taskverwaltung

.vscode/settings.json

@@ -114,6 +114,7 @@
         "Remotedesktop",
         "RINEX",
         "Röhrig",
+        "Routenverwaltung",
         "RTCM",
         "Rucken",
         "Rückwärtstransformation",

040_grundlagen.tex

@@ -184,6 +184,7 @@ User-Agent: NTRIP ProductName/Version<CR><LF>
 			Wie auch das HTTP, verwendet das Ntrip Protokoll, TCP (Transmission Control Protocol) für die Verbindung zwischen den Komponenten.
 
 		\subsection{WLAN}
+			\label{ssec:wlan-description}
 			Das Akronym WLAN wird ausgeschrieben zu \textbf{W}ireless \textbf{L}ocal \textbf{A}rea \textbf{N}etwork. Dabei handelt es sich um drahtlose lokal begrenzte Netzwerke, welche dafür vorgesehen sind mobile Endgeräte direkt oder über eine Vermittlungsstelle, wie einem Router, miteinander oder anderen Netzwerken zu verbinden. Diese Art von Netzwerken werden am häufigsten durch den IEEE 802.11 Standard \cite{WLAN} realisiert.
 			\par
 			Der genannte Standard wurde erstmals 1997 veröffentlicht und wird seit dem immer wieder dem aktuellen Anforderungen angepasst. Zunächst wurde die Physikalische Ebene in dem \( 2,4 GHz\) Frequenzband definiert. In der ersten Erweiterung (IEEE 802.11a) von 1999 wurde das \(5GHz\) Band dem Standard hinzugefügt. In dem ersten Frequenzband können die Frequenzen \( 2,3995GHz - 2,4845GHz\) genutzt werden, dafür wird dieser Bereich in 13 sogenannten Kanäle aufgeteilt. Es werden Kanalbreiten von \(20MHz\) und \(40MHz\) genutzt. Das \(5GHz\) ist in zwei Frequenzbereiche aufgeteilt, zum einen von \(5,15GHz - 5,35GHZ\) und zum anderen von \(5,5GHz - 5,7GHz\), dabei werden die Kanäle von 36 bis 64 und von 100 bis 140 angeben. Die Kanalbreite kann zwischen \(20MHz\), \(40MHz\), \(80MHz\) und \(1600MHz\) variiert werden. Dabei ist zu beachten, dass die verschiedenen Kanalbreiten erst mit späteren Standards implementiert wurden.
@@ -210,6 +211,7 @@ User-Agent: NTRIP ProductName/Version<CR><LF>
 			Die Verbreitung von WLAN in das alltägliche private Leben begann mit dem 802.11b Standard, weil mehrere Hersteller begannen Geräte für einen moderaten Preis zu verkaufen und diese durch den Standard Kompatibel zu einander sein müssen. Dadurch wurde es viel leichter Laptops und andere mobile Gräte kabellos mit dem Netzwerk zu verbinden. Heute sind in fast jedem Gebäude WLAN-Netzwerke zu finden.
 			\par
 			Auch in der Industrie ist WLAN eine essentielle Technik, zum Beispiel für automatisierte Lagersysteme mit mobilen Robotern.
+			!!!Reichweiten hinzufügen - wird in bewertung für rover referenziert!!!
 
 		\subsection{Ethernet}
 			Ethernet beschreibt nach dem Standard IEEE 802.3 \cite{Ethernet} verschiedene kabelgebundene Möglichkeiten \textbf{L}ocal \textbf{A}rea \textbf{N}etworks (LANs) aufzubauen. Diese Netzwerke werden typischerweise in Gebäuden eingesetzt mit einer Sterntopologie. Bei der installation wird hauptsächlich mehradriges Kupferkabel oder Glasfaserkabel genutzt. Das Kupferkabel wird auch Twisted-Pair-Kabel genannt und wird in verschiedene Kategorien eingeteilt, durch diese ist es möglich die maximale Geschwindigkeit des Kabels abzulesen. Einige dieser Kategorien können in der Tabelle \ref{tab:ethernet} abgelesen werden.

065_bewertung.tex

@@ -1,4 +1,5 @@
 \chapter{Bewertung}
+	\label{cha:bewertung}
 	Im vorletzten Kapitel dieser Arbeit werden die umgesetzten Implementierungen und Aufbauten bewertet. Dafür werden zunächst die gestellten Anforderungen betrachtet und ausgewertet, im Anschluss wird auf die Referenzstation und die durch den Aufbau errungenen Erkenntnisse eingegangen. Abgeschlossen wird dieses Kapitel mit Einschätzungen zu den Implementierungen, welche im Zuge der Erweiterung des Rovers vorgenommen wurden und einigen Testszenarien. Diese sollen Aufschluss über die Funktionalität des Gesamtsystems geben.
 
 	\section{Anforderungsauswertung}
@@ -40,7 +41,7 @@
 			Um die Positionslösung der Station beobachten zu können, kann die \texttt{Deviation Map} !!!Namen kontrollieren!!! aus Abbildung !!!ref!!! betrachten werden. Diese zeigt alle bestimmten Positionen als Punkte an. Dabei ist die aktuellste Position zentriert dargestellt und alle anderen in Abhängigkeit zu ihr. In der Abbildung werden die Punkte von einer dreistündigen Beobachtungsphase dargestellt. Mit den eingezeichneten Radien kann der Drift der Positionslösung abgelesen werden. In diesem Fall ist der Drift selten größer als ein halber Meter. Diese Genauigkeit kann durch die Anwendung von SBAS und der optimalen Antennenposition erklärt werden. Ohne diese Vorteile könnte der Drift über \(10m\) betragen. Der geringe Drift spricht für eine gelungene des Systems.
 
 		\subsection{Verwaltungsoberfläche}
-			Die Einstellungen des Servers sind zum Abschluss dieser Arbeit lediglich über den Zugriff auf die Kommandozeile möglich. Damit sich spätere Benutzter leichter zurecht finden wurden kurze Beschreibungen der Einstellungen in dem \texttt{Home-Verzeichnis} des rtk-Benutzer abgelegt. Bei einem Neustart des Systems wird der benötigte Dienst automatisch gestartet. Der Server startet auch nach einem Stromausfall automatisch. Sollte der benötigte Dienst jedoch aus irgendeinem Grund abstürzen, erfordert dies einen manuellen Eingriff in das System um den Dienst erneut zu starten und das Problem möglicherweise zu Lösen. Außerdem wurde keine Monitoring- oder Benachrichtigungslösung eingebaut. Dadurch wird ein möglicher Fehler erst an anderer Stelle festgestellt und es kann dementsprechend nicht direkt auf die Ursache geschlossen werden.
+			Die Einstellungen des Servers sind zum Abschluss dieser Arbeit lediglich über den Zugriff auf die Kommandozeile möglich. Damit sich spätere Benutzter leichter zurechtfinden wurden kurze Beschreibungen der Einstellungen in dem \texttt{Home-Verzeichnis} des rtk-Benutzers abgelegt. Bei einem Neustart des Systems wird der benötigte Dienst automatisch gestartet. Der Server startet auch nach einem Stromausfall automatisch. Sollte der benötigte Dienst jedoch aus irgendeinem Grund abstürzen, erfordert dies einen manuellen Eingriff in das System um den Dienst erneut zu starten und das Problem möglicherweise zu lösen. Außerdem wurde keine Monitoring- oder Benachrichtigungslösung eingebaut. Dadurch wird ein möglicher Fehler erst an anderer Stelle festgestellt und es kann dementsprechend nicht direkt auf die Ursache geschlossen werden.
 			\par
 			Eine erneute Konfiguration des GNSS-Moduls ist nur durch mehrere Schritte möglich, siehe dafür Anhang \ref{cha:winAndUcenter}. Der Gründe für eine erneute Konfiguration sind zwar kaum vorhanden, jedoch könnte jederzeit ein Defekt auftreten, welcher ein neues GNSS-Modul erfordert. Dieses wäre natürlich noch nicht konfiguriert.
 			\par
@@ -51,8 +52,11 @@
 			\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.
 
+		\subsection{Vergleich der Korrekturdatenqualität durch Nutzung von Spaos}
+
 	\section{Tests}
 		\label{sec:tests}
+
 		\subsection{Route aufzeichnen}
 			\subsubsection{Koordinaten Plausibilität}
 
@@ -77,5 +81,16 @@
 
 
 	\section{Rover}
+		Während der Nutzung im Zuge der Entwicklung und der Tests sind allgemeine Erkenntnisse zu dem Rover erlangt worden. Diese werden im Folgenden thematisiert und beziehen sich hauptsächlich auf die Handhabung und die Umweltanforderungen welche durch die Architektur des Rovers gestellt werden.
+
 		\subsection{W-LAN}
-			Bisschen doof mit der Abdeckung und Handy mitfahren lassen nur ein Provisorium
+			Durch die benötigten Korrekturdaten für das GNSS-Modul, welche über das Internet übertragen werden, muss der Rover stets auf eine Internetverbindung zugreifen können. Der Vorteil dieser Übertragungsmethode liegt in der Verfügbarkeit im Gegensatz zu spezielleren Lösungen, dadurch wird nicht zwingend eine eigene Basisstation benötigt. Das Problem liegt darin, wie die Verbindung hergestellt wird. Im aktuellen Ausbau verfügt der Rover lediglich über W-LAN. Den bereits in Kapitel \ref{ssec:wlan-description} beschriebenen Spezifikationen, kann die Reichweite von W-LAN Netzwerken entnommen werden. Mit den vom Rover unterstützen \(2,4 GHz\) Band, mit der besten Reichweite, ist eine Abdeckung des Einsatzgebietes sehr aufwendig. Außerdem ist Konfiguration des Rovers für Änderungen des W-LANs durch Konfiguration oder Standortwechsel anfällig.
+			\par
+			Die aktuelle Lösung besteht darin ein Mobilfunktelefon mit aktivierten W-LAN Access Point in der Nähe des Rovers zu halten oder dieses in dem Rover mitfahren zu lassen. Allerdings werden dadurch nicht alle zuvor genannten Probleme behoben, daher wäre an dieser Stelle eine Optimierung, welche diesen Umweg überflüssig werden lässt, angebracht.
+
+		\subsection{Handhabung}
+			Die Steuerung des Rovers ist an die Fernbedienung gebunden, welche ebenfalls das \(2,4 GHz\) Band nutzt und damit denselben Reichweiten Einschränkungen unterliegt. Für den aktuellen Entwicklungsstand des Rovers reicht dies aus, insbesondere weil das Bedienkonzept zu diesem Zeitpunkt den Sichtkontakt zu dem Rover für viele Aktionen voraussetzt.
+			\par
+			Des Weiteren gibt es nur wenige Fehler, auf welche der Rover reagieren kann, wie der Verlust der Korrekturdaten oder eine zu geringe Spannung des Akkus. Alle anderen Fehler können nicht detektiert werden. Die erkennbaren Fehler können dem Nutzer nur mitgeteilt werden, wenn sich dieser mit der aktivierten Fernbedienung in Reichweite befindet und der Nutzer sich in dem richtigen Menüpunkt befindet. Lediglich die Abschaltung des Rovers aufgrund eines zu geringen Ladestands wird auf dem Display ohne Benutzereingabe angezeigt.
+
+		\subsection{mehr?}

070_resuemee.tex

@@ -1,12 +1,43 @@
 \chapter{Resümee}
 
 	\section{Zusammenfassung}
+
 	\section{Fazit}
+
 	\section{Ausblick}
 		\label{sec:ausblick}
-		neue Oberfläche Referenzstation
+		Diese Arbeit wird mit einem Ausblick auf die mögliche Zukunft des Projekts abgeschlossen. Die einzelnen Punkte des Ausblicks ergeben sich aus dem eben geschlossenen Fazit und den im vorherigen Kapitel \ref{cha:bewertung} gemachten Bewertungen. Dabei steht die Bedienung und Umstrukturierung des Rovers im Mittelpunkt und wird von Erweiterungen des Rovers für eine gesteigerte Autonomie begleitet. Zusätzlich wird die Option der Softwareänderung auf dem Server der Referenzstation erläutert.
-		Bumper und weitere Sensoren
+
-		Umstellen von Component auf rtos task
+		\subsection{Erweiterung des Bedienkonzepts mittels Web-App}
-		Rover eigene Sim karte für beständige Internetverbindung
+			Die Fernbedienung eignet sich besonders gut für die Einrichtung des Rovers. Darüber hinaus ist die Bedienung jedoch sehr eingeschränkt. In dem angestrebten Anwendungsfall des Patrouille fahrenden Rovers ist eine Steuerung unabhängig des Standorts des Rovers, angebracht. Diese könnte über eine Webapplikation, welche dem Rover als Server dient, umgesetzt werden. Die bereits minimal als Webapplikation bestehende Routenverwaltung könnte mit dieser Erweiterungen zusammengefügt werden. Für die Anwendung sind die folgen Punkte als Features denkbar.
-		Rover steuerung über eine Web oberfläche
+
-		Erweiterte Routen verwaltung in web mit ansicht der Routen vielleicht mit Kontrollzenter kombinieren
+			\begin{itemize}
+				\item Eine Hauptfunktion könnte die Verwaltung der gespeicherten Routen darstellen. Die verschiedenen Routen könnten in Karten dargestellt werden. Wenn der Rover zurzeit eine Route abfährt, kann die aktuelle Position, der Fortschritt, die restliche Route und der aktuelle Zielpunkt sowie die Geschwindigkeit und geschätzte Ankunftszeiten angezeigt werden.
+				\item Als weitere Funktion ist die Planung der Aufgaben des Rovers vorstellbar, beispielsweise wann eine Route abgefahren werden soll oder in welchen Abständen und wie oft diese wiederholt werden soll.
+				\item Über diese Anwendung könnten auch Push-Benachrichtigungen Versand werden, die über den aktuellen Zustand oder etwaige Probleme informieren.
+				\item Dem Rover könnten auch allgemeine Befehle und Konfiguration übermittelt werden. Dazu könnte die Rückkehr zum Ausgangspunkt (Ladestation) oder die angestrebte Geschwindigkeit gehören.
+				\item Der Vorteil einer Webapplikation besteht darin, dass diese mit geringem Entwicklungsaufwand für unterschiedliche Endgeräte verfügbar gemacht werden könnte. Die Kommunikation mit dem Rover würde über die bereits erforderliche Internetverbindung abgewickelt werden.
+				\item Zusätzlich bestünde durch die Client-Server-Architektur die Möglichkeit Programmcode von dem Rover auf den Server zu verlegen.
+			\end{itemize}
+
+
+		\subsection{Umstrukturierung und Erweiterung des Rovers}
+			Durch die zu Anfang des Projektes gesetzte Anforderung den Hardwareaufwand des Rovers möglichst gering zu halten und die Nähe zu dem ArduinoCore zu halten wurde das System des Rovers in Komponenten unterteilt welche durch das Interface \mintinline{c++}|class Component| definiert werden. Dieses wird den Ansprüchen an eine Taskverwaltung nicht gerecht. Daher sollte in zukünftigen Versionen das System auf die Nutzung von \texttt{FreeRTOS} umstrukturiert werden. Dies erfordert keine komplette Abkehr von dem ArduinoCore, da dieser im auf FreeRTOS aufbaut.
+			\par
+			Sollte das Projekt weiter wachsen und auf stärkere Hardware setzen, kann auch der Einsatz von dem speziellen Betriebssystem \texttt{ROS} !!!cite!!! für Roboter in betracht gezogen werden. Dies würde allerdings sehr bedeutende Veränderungen für Soft- und Hardware herbeiführen. Daher wäre auch der Einsatz von \texttt{micro-ROS} !!!cite!!! vorstellbar, da so die Änderungen an der Hardware eingespart werden könnten.
+			\par
+			Um die Bedingungen für den Einsatz und den Konfigurationsaufwand des Rovers zu minimieren, könnte ein Mobilfunkmodul hinzugefügt werden. Mit diesem wäre es möglich die Internetverbindung an den meisten Orten herzustellen und dadurch den Rover zuverlässig mit Korrekturdaten zu versorgen sowie die Verbindung zu dem möglichen Server der Webapplikation herzustellen.
+			\par
+			Die Hardware des Rovers könnte mit weiteren Sensoren ausgestattet werden. Bumper an der Vorderseite würden die Erkennung von Hindernissen ermöglichen. Mit dieser Information könnte der Rover gestoppt werden oder es könnte versucht werden das Hindernis zu umfahren. Für weitere Informationen über die Umwelt würden sich weitere Sensoren wie Infrarot- und Ultraschallabstandsensoren eignen. Sollte die Hardware aufgestockt werden, sind natürlich weitere Optionen wie Kamera und Bildverarbeitung oder komplexere Sensoren wie ein Radar vorstellbar.
+
+		\subsection{Server umstellen auf \href{https://github.com/Stefal/rtkbase}{RTKBase}}
+
+
+
+
+
+
+
+
+
+			Bumper und weitere Sensoren

Notes.txt

@@ -22,8 +22,12 @@ Fehlende Abschnitte:
         - Genauigkeit der Positionsbestimmung | Vielleicht rausschmeißen
     - Bewertung
         - Tests
+            - Route aufzeichnen
         - Rover
-        - Ntrip
         
-    - Resümee komplett
+    - Resümee
+        - Zusammenfassung
+        - Fazit
+        - Ausblick
+            - Server umstellen