|
|
@@ -1,611 +0,0 @@
|
|
|
|
\documentclass[11pt,final]{scrreprt}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\usepackage[utf8]{inputenc}
|
|
|
|
|
|
|
|
\usepackage[english, ngerman]{babel}
|
|
|
|
|
|
|
|
\usepackage[T1]{fontenc}
|
|
|
|
|
|
|
|
% \usepackage{parskip}
|
|
|
|
|
|
|
|
\usepackage{scrhack}
|
|
|
|
|
|
|
|
\usepackage{graphicx}
|
|
|
|
|
|
|
|
\usepackage{svg}
|
|
|
|
|
|
|
|
\usepackage{float}
|
|
|
|
|
|
|
|
\usepackage{color} %May be necessary if you want to color links
|
|
|
|
|
|
|
|
\usepackage{hyperref}
|
|
|
|
|
|
|
|
\hypersetup{
|
|
|
|
|
|
|
|
colorlinks=false, %set true if you want colored links
|
|
|
|
|
|
|
|
linktoc=all, %set to all if you want both sections and subsections linked
|
|
|
|
|
|
|
|
linkcolor=blue, %choose some color if you want links to stand out
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
\setlength{\parindent}{0pt}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
% Codepakete
|
|
|
|
|
|
|
|
\usepackage{minted}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
% Mathe Pakete
|
|
|
|
|
|
|
|
\usepackage{amsfonts}
|
|
|
|
|
|
|
|
\usepackage{amsmath}
|
|
|
|
|
|
|
|
\usepackage{tikz}
|
|
|
|
|
|
|
|
\usetikzlibrary{intersections}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\usepackage[backend=biber,style=numeric,]{biblatex}
|
|
|
|
|
|
|
|
\usepackage{csquotes}
|
|
|
|
|
|
|
|
\addbibresource{literatur.bib}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\title{Projektarbeit - Autonomer Rover}
|
|
|
|
|
|
|
|
\author{A. Klein}
|
|
|
|
|
|
|
|
\date{24. Mai 2022}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\begin{document}
|
|
|
|
|
|
|
|
\pagenumbering{Roman}
|
|
|
|
|
|
|
|
\begin{titlepage}
|
|
|
|
|
|
|
|
\centering
|
|
|
|
|
|
|
|
{\scshape\LARGE Dortmund University of Applied Sciences and Arts \par}
|
|
|
|
|
|
|
|
{\scshape\large Department of computer science \par}
|
|
|
|
|
|
|
|
\vspace{1cm}
|
|
|
|
|
|
|
|
{\scshape\Large Projektarbeit im Studiengang technische Informatik\par}
|
|
|
|
|
|
|
|
\vspace{1.5cm}
|
|
|
|
|
|
|
|
{\huge\bfseries Anhand eines GNSS autonom fahrender Rover\par}
|
|
|
|
|
|
|
|
\vspace{2cm}
|
|
|
|
|
|
|
|
{\Large\itshape von
|
|
|
|
|
|
|
|
\linebreak Alexander Klein
|
|
|
|
|
|
|
|
\linebreak geboren am 19.07.1995
|
|
|
|
|
|
|
|
\linebreak Matr.-Nr. 7101654\par}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\vspace{3cm}
|
|
|
|
|
|
|
|
Betreuer:
|
|
|
|
|
|
|
|
\linebreak Dipl.-Ing Dieter Zumkehr
|
|
|
|
|
|
|
|
\linebreak Prof. Dr. Christof Röhrig
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\vfill
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
% Bottom of the page
|
|
|
|
|
|
|
|
{\large Dortmund, \today\par}
|
|
|
|
|
|
|
|
\end{titlepage}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\tableofcontents
|
|
|
|
|
|
|
|
\pagebreak
|
|
|
|
|
|
|
|
\listoffigures
|
|
|
|
|
|
|
|
\pagebreak
|
|
|
|
|
|
|
|
\pagenumbering{arabic}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\part{Projektarbeit}
|
|
|
|
|
|
|
|
\chapter{Einführung}
|
|
|
|
|
|
|
|
\section{Motivation}
|
|
|
|
|
|
|
|
Seit beginn der Industrialisierung ist es das bestreben der Marktwirtschaft möglichst viele Prozesse zu automatisieren. Die ersten Schritte auf diesem Weg waren die Erbauung von Fabriken und in diesen das Einsetzten von Fließbändern. Dieses wurde jedoch noch bevor sie zur Produktion eingesetzt wurden in Schlachtbetrieben benutzt und haben das auseinander nehmen von Tierkadavern erheblich beschleunigt. Ein paar Jahrzehnte später wurden Fließbänder dann von Henry Ford für die vereinfachte Herstellung von Automobilen genutzt. \cite{fliessbandSchalchthof} \cite{HenreyFliessband}
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Seit dem ist einige Zeit vergangen. Nun wird viel daran gesetzt nicht nur die Produktions eines Produktes zu automatisieren sonder auch das Produkt selbst zu automatisieren. In dem Kontext dieser Arbeit geht es dabei um das autonome Fahren von Fahrzeugen.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Der Autonomie Grad von Fahrzeugen wird of in Level angeben um anzeigen zu können wie weit das Fahrzeug auf dem weg ist, autonom fahren zu können. Dabei wird mit dem Level 0 angeben, dass das Fahrzeug ausschließlich vom Menschen gesteuert wird und über keine Assistenzsysteme verfügt. Die nächsten beiden Level werden als \grqq{}assistierter Modus\grqq{} beschrieben. Dabei ist der Mensch immer noch der Hauptverantwortliche des Fahrzeugs und wird dabei in Form von Geschwindigkeitsreglung im ersten Level oder Spurhalteassistenz im zweiten Level unterstützt. Richtig spanned wird es ab Level 3. In diesem Level wird von dem automatisierten Modus gesprochen. Mit diesem kann das Fahrzeug Teilstrecken selbstständig befahren ist dabei aber auf die Anwesenheit eines Fahrers angewiesen, welcher übernehmen kann wenn das System an seine Grenzen kommt. Hier ist der Fahrer allerdings schon nicht mehr dazu verpflichtet dauernd den Straßenverkehr zu beobachten und das Fahrzeug zu überwachen. Seit dem letzten Jahr (2022) gibt es Autos der Marke Mercedes-Benz, die für dieses Level eine Zulassung in Deutschland bekommen haben. Allerdings kann das Fahrzeug nur Autobahnfahrten bis 60km/h übernehmen. Erst die letzten beiden Level werden als autonomer Modus bezeichnet. Das vierte Level beschreibt lediglich, dass ein Fahrer vorhanden sein muss um das System abzulösen in Situationen, die dieses nicht bewältigen kann. Nur wenn dieser Fall eintritt muss der Fahrer mit Vorankündigung die Steuerung übernehmen, ansonsten fährt das Fahrzeug selbstständig. Im letzten Level werden dann keine Ausnahmen mehr beschrieben. Es ist das einzige Level in dem kein Fahrer anwesend sein muss. So könnte ein autonomes Taxi oder das eigene Auto angefordert werden um jemanden oder sich abholen zu lassen.\cite{wikiAutonomesFahren}
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Ein Projekt welches sich durch minimalistischen Anforderungen für autonomes Fahren definierte wurde vor einige Jahren schon einmal im Hochschulkontext angegangen und ist schließlich zum erliegen gekommen. Jedoch ist dadurch die Frage offen geblieben, ob sich dieses Projekt, in welcher Größenordnung, umsetzten lässt. Diese Frage und der Wunsch, dass sich diese mit einem "Ja" beantworten lässt war ein wichtiger Punkt bei der Wahl dieses Projektes. Außerdem ermöglicht dieses Projekt einen eigenen Einblick in die Thematik der selbstfahrenden Fahrzeuge erhalten zu können und deren Komplexität begreifen zu können.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\section{Ausgangssituation}
|
|
|
|
|
|
|
|
Als Grundlage dieses Projektes steht ein modellhaftes Fahrzeug zur Verfügung welches drei Achsen besitzt. Diese drei Achsen werden jeweils pro Fahrzeugseite von jeweils einem Elektromotor angetrieben. Bei optimalen Bedingungen können mit diesen Motoren Geschwindigkeiten von bis 20 km/h erreicht werden. Das Gehäuse des Fahrzeugs hat eine Wannenform und misst in der Länge 38cm und in der breite 19cm. Die Räder haben einen Durchmesser von 11,5cm, da die Räder ausliegend sind verbreitern sie das Fahrzeug auf eine Gesamtbreite von 32cm.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Zu beginn des Projektes wurde der beiliegende Nickel-Metallhydrid-Akkumulator verwendet. Es stellte sich jedoch direkt zu Projektstart heraus, dass dieser nicht mehr die benötigte Energie zur Verfügung stellen konnte. Deshalb wurde dieser gegen einen modernen Lithium-Ionen-Akkumulator ausgetauscht. Außerdem wurden aus der Vergangenheit des Fahrzeugs diverse Steuerungsplatinen von älteren Projekten entfernt, da diese keinem Verwendungszweck mehr zugeführt werden konnten. Diese wurden für verschiedene Betriebszustände des Rovers genutzt.
|
|
|
|
|
|
|
|
Ebenfalls wurde der Motortreiber ausgetauscht, dies war nötig da dieser auf Grund von fehlender Dokumentation nicht mehr in Betrieb genommen werden konnte. Im verlauf des Projektes kam es zu einem defekt an den Encoder zur Drehzahlbestimmung. Deshalb wurden diese ebenfalls ausgetauscht. Dabei wurde leider Funktionalität eingebüßt, da mit den defekten Encoder eine Quadratur Auswertung angewendet werden konnte. Mit den Austausch encoder ist lediglich eine einfache Auswertung möglich.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Im weiteren verlauf wird von dem Fahrzeug als Rover gesprochen.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\section{Ziele}
|
|
|
|
|
|
|
|
Ziele dieser Arbeit sind zum einem die geringste Hardwareanforderungen zu ermitteln, die nötig sind um unter den gegebenen Bedingungen ein autonomes fahren zu ermöglichen. Dabei wird die Wahrnehmung der Umgebung und alles was damit zusammenhängt, wie beispielsweise das Ausweichen von Hindernissen nicht betrachtet.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Das Hauptaugenmerk des Projektes liegt allerdings darauf die Software für den Mikrocontroller zu entwickeln. Diese soll es dem Rover ermöglichen autonom eine gegebene Strecke entlang zufahren. Die Strecke soll als eine Sammlung von geographische Koordinaten zur Verfügung gestellt werden, welche dann in der gegeben Reihenfolge direkt und mit dem kürzesten Weg angefahren werden sollen. Alternativ soll das Fahrzeug selbst in der Lage sein diese Koordinaten zu erfassen, wenn es manuell gesteuert wird.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Um die Funktionalitäten des Rovers zugänglich zu gestalten soll dieser Ferngesteuert werden können. Die Fernsteuerung soll den Rover allgemein Steuern können, aber auch die Möglichkeit besitzen komplexere Eingaben zu tätigen. Etwa das navigieren durch ein Menü oder das Einstellen spezifischer Werte.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Als Einsatzzweck lässt sich exemplarisch folgendes Szenario skizzieren. Um präventiv gegen Vandalismus vorzugehen soll um das Gebäude des Fachbereichs Informatik der Fachhochschule Dortmund eine Patrouille eingesetzt werden. Diese könnte dann von diesem Rover übernommen werden. Der Rover könnte als Nutzlast, dem Szenario entsprechend, weitere Sensoren mitführen welche Unregelmäßigkeiten erkennen und melden können.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\section{Konzept}
|
|
|
|
|
|
|
|
Die zugrundeliegende Idee ist es, den Rover mittels Positionsbestimmung lokalisieren zu können. So könnte festgestellt werden ob sich der Rover auf einer Router befindet und wenn nicht welche Abweichungen korrigiert werden müssen. Dazu soll ein GNSS-Empfänger genutzt werden. Da die allgemeine Genauigkeit von GNSS allerdings im Bereich von mehreren Metern liegt, ist es zwingend erforderlich, ein Modul zu verwenden welches ein Protokoll zur Korrekturdatenübertragung unterstützt. Dadurch sollte es möglich sein eine Genauigkeit zu erzielen, welche dem Mindestmaß zur Erfüllung der Ziele entspricht. Zusätzlich sollen die Daten eines Kompasses verfügbar sein, um damit die Richtungsbestimmung wesentlich zu vereinfachen. Darüber hinaus sind für dieses erste Stufe des Projektes keine weiteren Sensoren zur Erkennung der Position oder des Umfeldes geplant.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Die Schnittstellen zur Steuerung und Überwachung des Rovers sollen zunächst über die in dem Mikrocontroller verbauten Funkstandards realisiert werden. Diese umfassen WLAN nach IEEE 802.11 b/g/n,Bluetooth in der Version 4.2 und Bluetooth Low Energy. \cite{Esp32Datasheet} Espressif bietet ein eigenes Protokoll an, welches das WiFi-Modul nutzt. Diese Protokoll dient der Kommunikation zwischen verschieden ESPs. \cite{ESPnow}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\chapter{Grundlage}
|
|
|
|
|
|
|
|
\section{Hardware}
|
|
|
|
|
|
|
|
Diese Kapitel beschäftigt sich mit allen Hardwarekomponenten die zum Betrieb des Rovers nötig sind. Dies umfasst sowohl Hardware welche eigene Logik bereitstellt sowie auch passive Komponenten. Die Hardware war zum Teil bereits zum Projektstart verfügbar. Teileweise wurde diese auch ergänzt oder ersetzt. Es wird nachfolgend nur Hardware aufgezählt und beschrieben, die dem aktuellen Stand der Arbeit entspricht.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{Antrieb}
|
|
|
|
|
|
|
|
Ursprünglich handelte es sich bei dem genannten Rover um ein Modellauto mit der Bezeichnung "Kaiman 6x6" der Marke "Reely Road". Von dem Modell ist das grundlegende Gehäuse erhalten geblieben. Dieses hat die From einer Wanne und dient als Halterung für den, zum großen Teil originalen, Antriebsstrang. Dieser besteht je Seite jeweils aus einem Motor, einem Getriebe mit Untersetzung, Riementrieb, drei Achsen und den jeweiligen Rädern. Bei den Rädern wurden die Felgen durch 3D-gedruckte ersetzt, diese haben das Ziel, den Schlupf zwischen Reifen und Felge zu minimieren. Über die Riemen sind alle Räder einer Fahrzeugseite fest mit der Ausgangswelle des Getriebes verbunden.\cite{FabianProjektarbeit}
|
|
|
|
|
|
|
|
Das Fahrzeug verfügt über keinerlei lenkbare Achsen. Ein Rotation um die Z-Achse kann lediglich stattfinden, durch die Anwendung der Mechaniken eines Skid-Antriebs. Für den Rover ist es im allgemeinen von vorteil, dass auf jeder Seite 3 Räder montiert sind, dadurch ist es bedeutend unwahrscheinlicher, dass ein ganze Seite den Kontakt zum Boden verliert. So ist in den meisten Situationen eine Steuerbarkeit sichergestellt. Der Nachteil besteht darin, dass dadurch keine Rotation um die Z-Achse mit geringem verschleiß möglich ist. Es werden bei einer Drehung immer Räder über den Boden geschoben, dies verursacht erhöhten Kraftaufwand und verschleiß. \cite{FabianProjektarbeit}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsubsection{Motoren}
|
|
|
|
|
|
|
|
Jeder Seite verfügt über einen bürstenbehafteten Gleichstrommotor. Diese werden mit einer nominalen Spannung von 12V angegeben. Im unbelasteten Zustand können 4800 Umdrehungen pro Minute erreicht werden. Dabei würde ein Strom von 0,2A benötigt werden. Wenn der Motor blockiert wird, kann ein maximaler Strom von 5,0A erreicht werden. \cite{Motor} Auf die Welle des Motors ist ein Getriebe geflanscht. Dieses reduziert die Ausgangsdrehzahl und erhöht somit das Drehmoment. Allerdings ist es nicht ersichtlich in welchem Verhältnis dies geschieht.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Der Motor und das Getriebe sind auf einer kleinen Plastik Platte befestigt und diese ist wiederrum auf dem Boden des Gehäuses angeschraubt. Dadurch wird der vordere und der hintere Teil des Gehäuses jeweils durch einen Motor belegt. An die Anschlüsse der Motoren wurden Kabel angelötet deren Enden einmal an einer XT60 Buchse und einmal an einem XT60 Stecker angelötet wurden. \cite{xt60} Damit die Motoren einfach von der Steuerung getrennt werden können. Dadurch das einmal ein Stecker und einmal ein Buchse verwendet wurde, kann sichergestellt werden, dass die Motoren mit dem richtigen Ausgang der Motorteuerung verbunden werden.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsubsection{Steuerung}
|
|
|
|
|
|
|
|
Um die Motoren kontrolliert mit Energie zu versorgen, ist ein Modul mit einer eingebauter Zweikanal-H-Brücke von der Firma Akozon verbaut. Dieses ist in der Lage jeden Kanal mit einer Spitzenleistung von 30 Ampere zu betreiben. Die Versorgungsspannung für die Motoren muss zwischen 5V und 12V betragen. Die Logikspannung zum schalten der Richtung und die des PWM-Signals muss mindestens 2,5V betragen um von dem Modul als High-Signal erkannt zu werden. Es ist zu beachten, dass das PWM-Signal einen maximalen Dutycycle von 98\% aufweisen darf. \cite{Motortreiber}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{Sensorik}
|
|
|
|
|
|
|
|
\subsubsection{GNSS}
|
|
|
|
|
|
|
|
Da der Rover für die Navigation ausreichend genaue Standortdaten benötigt, wurde ein Modul gewählt, dass Korrekturdaten im Format RTCM3 verarbeiten kann. Das Modul ist von der Firma SparkFun und heißt GPS-RTK-SMA Breakout - ZED-F9K, der Name gibt Aufschluss über den auf dem Modul verbauten Chip. Der ZED-F9K ist ein hochpräziser multi-band GNSS Receiver. Sofern dieser mit unter guten Bedingungen mit den Korrekturdaten versorgt wird, sind Genauigkeiten im niedrigen Zentimeterbereich möglich. \cite{ZEDF9P} Das Modul ermöglicht es eine GNSS-Antenne über den SMA-Stecker zu verbinden und diese unabhängig von dem Modul zu platzieren. Es ist ebenfalls ein USB-Anschluss verbaut, mit diesem ist es möglich über das U-Blox Center die Daten mitzulesen und den ZED-F9K zu konfigurieren. Das Modul hat an der linken und der rechten Seiten jeweils eine Pinleiste. Über verschiedene Pins sind unterschiedliche Protokolle verfügbar. Über jede dieser Schnittstellen lässt sich das Modul ebenfalls konfigurieren, da über alle das gleiche U-Blox Protokoll übertragen wird. Mit diese Breakout Design ist das Modul auf der Hauptplatine des Rovers gesockelt. \cite{ZEDHookUp} Die Kommunikation zwischen ESP und ZED-F9K kann auf Grund der Gegebenheiten der Hauptplatine und des Moduls nur über IC2 oder nur über SPI stattfinden. Aktuell wird lediglich die SPI-Schnittstelle verwendet, da diese eine höhere Übertragungsgeschwindigkeit bietet. \cite{i2cvsspi}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsubsection{Encoder}
|
|
|
|
|
|
|
|
Um die Geschwindigkeit des Rovers zu ermitteln und unter anderem mit diesen Daten die Geschwindigkeit der Motoren zu steuern, sind zwei Lichtschranken verbaut. Diese befinden sich jeweils an der Ausgangswelle des Getriebes mit Untersetzung von den Motoren. Da es sich um einfache Gabellichtschranken handelt ist nur die Geschwindigkeit, aber nicht die Richtung herleitbar. Aus Messungen ging hervor, dass circa 300 Impulse der Lichtschranke eine volle Umdrehung des Rades ergeben. Die Lichtschranke hat an der einen Zinke eine IR-Diode verbaut, diese ist über einen Vorwiderstand durchgehend mit der 5V Spannungsversorgung verbunden. Auf der anderen Zinke befindet sich Phototransistor. \cite{Encoder} Dieser wird über einen Spannungsteiler mit Strom versorgt und gibt die Impulse an den ESP weiter. Der ESP zählt die Impulse mit der eingebauten Pulse-Counter-Unit.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsubsection{Kompass}
|
|
|
|
|
|
|
|
Damit der Rover im freien Feld direkt bestimmen kann in welcher Richtung sich das Ziel von der derzeitigen Ausrichtung befindet, wurde ein Kompassmodul verbaut. Dabei wurde auf das Modul GY-271 von AZ-Delivery zurückgegriffen. Die Hauptfunktion dieses Moduls ist es den verbauten QMC5883L Chip zugänglicher zu machen. Dafür gibt es eine Pinleiste. Außerdem sind Komponenten zur Spannungsreglung verbaut. \cite{GY-271} Der QMC5883L ist ein 3 Achsen magnetoresistiv Sensor. Mit verbaut ist ein 16bit ADC um die analogen Werte des Sensors digital ausgeben können. Dafür steht ein I2C Interface zur Verfügung. Das Interface ist über die Hauptplatine mit dem ESP verbunden. Der Sensor kann eine Genauigkeit von bis zu 2° erreichen. \cite{QMC5883L}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{Energie}
|
|
|
|
|
|
|
|
Als Energiequelle kommt ein drei Zellen Lithium-Polymer Akkumulator zum Einsatz. Dieser hat auf Grund seiner drei Zellen eine nominal Spannung von 11,1V, bei einer vollständigen Ladung steigt die Spannung auf 12,6V. Bei der Entladung sollte niemals eine Spannung von unter 9,8V unterschritten werden um Schäden am Akku zu verhindern. Mit einer Kapazität von 4000mAh ist ein ausreichend langer Betrieb möglich. Der maximale Strom von über 40 Ampere wird benötigt um den Anlaufstrom der Motoren bereitstellen zu können. Der Akkumulator wird zum Laden aus dem Rover ausgebaut und an ein geeignetes Ladegerät angeschlossen. Der eingebaute Mikrocontroller kann die Spannung über einen ADC mit vorgeschalteten Spannungsteiler messen und so eine Tiefentladung durch Abschaltung verhindern. \cite{battery}
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Die Motoren werden über den Motortreiber direkt mit der Spannung des Akkumulators betrieben. Die restlichen Lasten benötigen alle 5V und werden deshalb über einem LM2596 Step-Down Voltage Regulator betrieben. Dieser reguliert eine ausreichend hohe Spannung immer auf den eingestellten Wert herunter und kann dabei einen kurzzeitigen maximalen Strom von 4,5A bereitstellen. \cite{stepdownmodul} Dieses Modul ist auf der Hauptplatine aufgelötet. Der Akku wird deshalb ebenfalls an einem Terminal der Hauptplatine angeschlossen. Dies ermöglicht auch die Messung der aktuellen Akkuspannung. Der Akku ist über einen Geräteschutzschalter mit einem Nennstrom von 16A gesichert. Diese lässt sich über einen Knopfdruck zurücksetzten. \cite{sicherung}. Um das gesamte System spannungsfrei schalten zu können ist noch ein zusätzlicher Kippschalter verbaut.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{Mikrocontroller}
|
|
|
|
|
|
|
|
Bei dem verwendeten Mikrocontroller handelt es sich um einen
|
|
|
|
|
|
|
|
\newline ESP32-WROOM-32E. Dieser besitzt zwei Xtensa 32bit LX6 Kerne, welche mit bis zu 240 MHz takten. Dem Controller stehen 520KB SRAM und 4 Megabyte Flash zur Verfügung. Als drahtlose Schnittstellen ist ein WiFi- und ein Bluetooth Modul verbaut. Es wird für WiFi der Standard IEEE 802.11b/g/n unterstützt. Bluetooth steht in der Version 4.2 bereit und Bluetooth Low Energy wird ebenfalls unterstützt. Zu den drahtlosen Schnittstellen sind auch einige Hardware Schnittstellen verbaut. Darunter fallen unter anderem die Bussysteme SPI, I2C. Für die Kommunikation kann UART verwendet werden. 26 GPIO Pins können als digitale Ein- und Ausgänge verwendet werden. Diese können zum Teil auch als ADC (ADC1 8 x 12bit, ADC2 10 x 12bit), DAC (2 x 8bit) oder für PWM genutzt werden. Es lassen sich bis zu 16 channel einstellen mit einer Auflösung von bis zu 16 bit. Bei Frequenzen von über 300 kHz muss die Auflösung kann die 16 bit Auflösung nicht mehr erreicht werden. Für dieses Projekt ist außerdem der eingebaute Pulsecounter des ESP32 wichtig. Der Controller benötigt eine Spannung zwischen 3,0V und 3,6V. \cite{Esp32Datasheet} Im mittel werden 80mA benötigt.
|
|
|
|
|
|
|
|
Der ESP ist auf einem Entwicklerboard der Firma AZ-Delivery, nach vorgaben der Open Source IoT Plattform NodeMCU. Neben dem ESP sind auf dem Board einige Debug LEDs verbaut, diese zeigen zum Beispiel an ob gerade Daten per UART gesendet oder Empfangen werden. Ein Spannungsregulator, damit das Entwicklungsboard mit 5V betrieben werden kann. Ein MicroUSB-Anschluss, über diesen kann das Board mit 5V versorgt werden und es kann unter Zuhilfenahme des ebenfalls verbauten CP2102 der ESP neu programmiert werden oder die serielle Schnittstelle genutzt werden. Außerdem werden die meisten Pins des ESPs über zwei Stiftleisten nach außen geführt, sodass es einfach ist ihn in Projekt einzubinden. \cite{AZDeliveryESP32} Das Board befindet sich einmal auf der selbst erstellten Hauptplatine des Rovers und in der selbst entwickelten Fernbedienung des Rovers.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{Display}
|
|
|
|
|
|
|
|
Es sind zwei baugleiche LCD in diesem Projekt vorhanden. Eines ist auf dem Rover verbaut und das andere in der Fernbedienung, beide sollen die gleichen Informationen für den Nutzer bereitstellen. Es handelt sich dabei um 16 x 2 Character LCD, diese können zwei Zeilen anzeigen und in jeder Zeile 16 Zeichen. Jedes Zeichen besteht dabei aus einer 5 x 8 Pixel dot Matrix. Die Displays verfügen über eine Hintergrundbeleuchtung, die über die Bibliothek ein und ausgeschaltet werden kann. Die darstellbaren Zeichen sind bereits in dem Display gespeichert. Welches Zeichen angezeigt werden soll wird dem Displaytreiber über 8 Datenleitungen, die parallel ausgelesen werden, mitgeteilt. \cite{LCD}
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Um die benötigten Leitungen und den implementierungsaufwand zu minimieren, ist vor jedem Display ein I2C Seriell Adapterinterface verbaut. Das Adapterinterface übernimmt die völlige Kontrolle über das Display und wird selbst über I2C vom ESP gesteuert. Damit fallen alle Datenleitungen weg und das Display ist lediglich ein zusätzlicher Teilnehmer am I2C-Bus. Zusätzlich kann an dem Modul der Kontrast des Displays mit einem verbauten Potentiometer eingestellt werden. \cite{I2CLCD}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{Fernbedienung}
|
|
|
|
|
|
|
|
Um die Benutzereingaben an den Rover zu übermitteln wird eine selbstkonstruierte Fernbedienung verwendet. Diese verfügt über insgesamt 7 Buttons, einen Joystick und eins der oben genannten Displays. Alle Komponenten sind mit dem ebenfalls weiter oben beschriebenen ESP32 verbunden. Die Fernbedienung wird über USB von einer Powerbank mit Strom versorgt. Die Buttons verteilen sich wie folgt. Vier der Buttons sind auf der linken Seite in Form eines Karos angeordnet und sollen so ein einfaches Steuerkreuz abbilden. Zwei weitere Buttons befinden sich auf der rechten Seite, nah beieinander, auf einer horizontalen Linie. Diese sind zum bestätigen und ablehnen gedacht. Der Joystick verfügt über den letzten Button, dieser wird aufgelöst, wenn auf den Joystick gedrückt wird. Dieser ist für besondere im Fokus stehende Aktionen vorgesehen. Der Joystick selbst besteht dazu aus zwei Potenziometern, mit diesen kann gleichzeitig ein Wert für die horizontale und die vertikale Ausrichtung des Joysticks bestimmt werden.\cite{joystick} Das Display ist an der Rückseite befestigt und so angewinkelt, dass der Benutzter dieses leicht ablesen kann. Das Gehäuse der Fernbedienung stammt aus einem 3D-Drucker und besteht aus einer Oberschale mit allen Durchführungen und der Unterschale um das Gehäuse zu schließen. Das USB-Kabel zur Stromversorgung und etwaige Softwareupdates wird hinten an der Fernbedienung herausgeführt.
|
|
|
|
|
|
|
|
\begin{figure}[ht]
|
|
|
|
|
|
|
|
\vspace{1cm}
|
|
|
|
|
|
|
|
\centering
|
|
|
|
|
|
|
|
% \includegraphics[width=\linewidth]{Bilder/fernbedienung.jpg}
|
|
|
|
|
|
|
|
\includegraphics[width=10cm]{Bilder/fernbedienung.jpg}
|
|
|
|
|
|
|
|
\caption{Fernbedienung}
|
|
|
|
|
|
|
|
\label{fig:fernbedienung}
|
|
|
|
|
|
|
|
\end{figure}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{Basisstation}
|
|
|
|
|
|
|
|
Für die Basissation wird ein handelsüblicher Computer mit dem x86\_64 Befehlssatz verwendet. Dieser verfügt über 4 GB Arbeitsspeicher und Intel i5 der 4ten Generation. Als Betriebssystem kommt Windows 10 zum Einsatz. Die Basisstation benötigt eine Internetverbindung, um die Korrekturdaten an den NTRIP Caster übermitteln zu können. Diese wird im aktuellen Zustand über eine Ethernet Verbindung via RJ45 bereitgestellt.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Des Weiteren ist über USB eine weiteres Modul angebunden. Bei diesem handelt es sich das Application Board C099-F9P. Das GNSS-Modul auf dem Board ist sehr ähnlich zu dem, das in dem Rover verbaut ist. Der Unterschied besteht darin, dass dieses auch in der Lage ist Korrekturdaten für andere Module bereitzustellen und nicht nur anzuwenden. Zum Empfang der GPS-Signale wird ebenfalls eine Antenne benutzt, die via SMA verbunden werden kann. Auf dem Board befindet sich dazu noch ein weiteres Modul, dieses dient der drahtlosen Kommunikation und kann dazu genutzt werden Korrekturdaten und Logs per WiFi zu versenden oder Korrekturdaten zu empfangen. \cite{C099F9P}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\section{Grundaufbau}
|
|
|
|
|
|
|
|
\subsection{Rover}
|
|
|
|
|
|
|
|
Zusätzlich zu dem vorgegeben Unterbau wurden die anderen Komponenten des Rovers mittels einer eigenen Platine und 3D gedruckten Teilen mit einander verbunden und an dem Unterbau befestigt. Die GPS-Antenne wurde mit einem "T" ähnlichem Formteil im hinteren Bereich befestigt. Das überflüssige Kabel wurden in Schlaufen um die Antenne herum aufgewickelt und ebenfalls an dem Formteil befestigt. Dadurch konnte die originale Konfektionierung beibehalten werden und die Funktion sichergestellt werden. Im vorderen Bereich befindet sich eine, ebenfalls gedruckte, Bodenplatte. Diese wird durch zwei aufnahmen an den Seiten befestigt und dient als Adapterstück für die restlichen Komponenten. Auf der Unterseite befinden sich Löcher zum montieren des Motortreibers inklusive Kabeldurchführungen. Auf der Oberseite befindet sich ein Halterahmen in dem die Hauptplatine platz findet. In den Ecken der Grundplatten befinden sich Löcher in denen der Oberrahmen eingesteckt wird. Der Oberrahmen hält das Display und den digitalen Kompass. Besonders für den Kompass ist die Entfernung zu den Magneten der Motoren wichtig um seine Funktion erfüllen zu können. Der Akku befindet sich ebenfalls unterhalb der Bodenplatte in einer dafür vorgesehenen Nische. Der Akku wird gegen das Herausrutschen durch ein kleines Gummiband gesichert. Verbindungen, welche stärkere Ströme aushalten müssen werden über XT60 Steckverbindungen hergestellt. Das trifft auf die Verbindung zum Akku und zu den Motoren zu. Die restliche Verbindungen werden einfach auf der Platine gesteckt. Der ESP32 und das GPS-Modul werden ebenfalls auf die Platine gesteckt. Der Spannungsregler ist fest verlötet. Eine LED auf der Platine zeigt an ob Spannung anliegt. In Abbildung \ref{fig:Grundaufbau} ist ein Schematische Verbindung der einzelnen Komponenten dargestellt. Ein Schaltplan der Hauptplatine findet sich im Anhang \ref{fig:hauptplatine}.
|
|
|
|
|
|
|
|
\begin{figure}[ht]
|
|
|
|
|
|
|
|
\vspace{1cm}
|
|
|
|
|
|
|
|
\centering
|
|
|
|
|
|
|
|
\includegraphics[width=10cm]{Bilder/grunaufbau.png}
|
|
|
|
|
|
|
|
\caption{Grundaufbau Schema}
|
|
|
|
|
|
|
|
\label{fig:Grundaufbau}
|
|
|
|
|
|
|
|
\end{figure}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{Basisstation}
|
|
|
|
|
|
|
|
Damit die Basisstation für den Rover brauchbare Korrekturdaten erzeugen kann, sollte diese nicht weiter als 10 km von dem eigentlichen Einsatzort des Rovers entfernt sein. \cite{BaseStaionDistance} Die GNSS-Antenne sollte unter freiem Himmel positioniert sein und von keinen Gebäuden, Gewächsen oder anderen Strukturen beschattet werden. Um die Korrekturdaten errechnen zu können muss die möglichst genau Position der GNSS-Antenne bekannt sein. Daraus könnte sich ein Henne-Ei Problem ergeben, wenn es nicht auch eine Möglichkeit gäbe durch Sammeln von Messdaten eine nachträgliche Korrektur von einer externen Organisation zu beauftragen. Der aktuelle provisorische Aufbau der Basisstation befindet sich in einem Dachstuhl eine Scheune. Dadurch konnte die Antenne auf einer Dachlatte befestigt werden und diese dann aus einer Dachluke geschoben werden (Abbildung \ref{fig:GNSSAntenneDach}) und innen gesichert werden. Sodass eine feste Positionierung erreicht werden kann. \cite{sparkfunBasisStation} Die Netzwerkverbindung konnte einfach durch einen naheliegenden Switch hergestellt werden. Die Wartung der Basissation wird vollständig über Remotedesktop von Microsoft Windows ausgeführt, daher sind keine weiteren Ein- oder Ausgabegeräte erforderlich.
|
|
|
|
|
|
|
|
\begin{figure}
|
|
|
|
|
|
|
|
\vspace{1cm}
|
|
|
|
|
|
|
|
\centering
|
|
|
|
|
|
|
|
\includegraphics[width=10cm]{Bilder/dachantenne.jpg}
|
|
|
|
|
|
|
|
\caption{GNSS Antenne Dach}
|
|
|
|
|
|
|
|
\label{fig:GNSSAntenneDach}
|
|
|
|
|
|
|
|
\end{figure}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\section{Software}
|
|
|
|
|
|
|
|
\subsection{Rover}
|
|
|
|
|
|
|
|
Da auf dem ESP32 Bare Metal programmiert wird, werden im folgenden nun einige der relevanten und verwendete externen Bibliotheken und deren Funktion genannt und erläuter. Zur Erleichterung wird das auf den ESP32 adaptierte Arduinoframework verwendet. Dieses vereinfacht die Handhabung der Hardware indem unter anderem Bibliotheken für WiFi, I2C, SPI und HTTP sowie die klassischen Arduino Funktionen bereitgestellt werden. So entsteht die erste Abstraktionsschicht. \cite{ArduinoCore} Durch die weite Verbreitung des ArduinoCore sind bereits über 8.000 Bibliotheken nur in der Registry von PlatformIO verfügbar. \cite{AnzahlBibliotheken} Alle in diesem Abschnitt genannten Bibliotheken wurden über die Registry eingebunden.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsubsection{SparkFunGNSS}
|
|
|
|
|
|
|
|
Diese Bibliothek bildet eine vollständige Abstraktionsschicht zur Kommunikation mit dem GNSS-Modul, es kann auf unterschiedliche Kommunikationsschnittstellen zurückgegriffen werden. Es stehen I2C, SPI und Seriell zur Verfügung. In diesem Projekt ist das Modul über SPI angebunden. Dies ermöglicht die höchste Kommunikationsgeschwindigkeit, dies ist von Vorteil, da die Korrekturdaten eine nicht unerhebliche Menge des Daten Aufkommens ausmachen. Über die Callbacks ist es möglich eine Polling-Architektur zu vermeiden. Es werden zudem einige Funktionen genutzt um das Modul zu konfigurieren, damit nur relevante Daten an den ESP gesendet werden und damit die Korrekturdaten empfangen und verarbeitet werden können. Neben den eigentlichen Koordinaten werden auch unter anderem die Anzahl der aktuell sichtbaren Satelliten, die geschätzte aktuelle Genauigkeit, die Uhrzeit und der aktuelle Zustand des Algorithmus zur Korrekturdatenverarbeitung ausgelesen. \cite{sparkfunGNSSLib}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsubsection{MQTT Client}
|
|
|
|
|
|
|
|
Der PubSubClient wird genutzt um eine zusätzlich Ausgabemöglichkeit zu schaffen. Dieser kann sich mit einem MQTT-Broker verbinden und von diesem Nachrichten Empfangen oder Nachrichten an diese Senden. Dabei werden verschiedene Quality of Service Modi unterstützt. Hier werden ebenfalls callbacks bei eingehenden Nachrichten verwendet um ein Polling-Architektur zu vermeiden.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Der Client wird hauptsächlich dafür verwendet den normalen Output Stream zu doppeln. Damit ist es möglich die Ausgaben des Rovers auch während des Betriebs draußen zu verfolgen oder loggen zu können. \cite{mqttArduino}
|
|
|
|
|
|
|
|
\begin{minted}{c++}
|
|
|
|
|
|
|
|
std::streambuf::int_type OutputBuf::overflow(std::streambuf::int_type c) {
|
|
|
|
|
|
|
|
if (c != EOF) {
|
|
|
|
|
|
|
|
this->debugMqtt->addCharacter((char) c);
|
|
|
|
|
|
|
|
Serial.print((char) c);
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
return c;
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
\end{minted}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsubsection{PID Regler}
|
|
|
|
|
|
|
|
Diese Bibliothek implementiert ein PID Regler. In diesem Projekt werden zwei Instanzen davon verwendet. Jeweils eine je Motor. Dadurch ist es möglich die Werte für jede Seit des Antriebs vom Rover zu justieren um Unregelmäßigkeiten ausgleichen zu können. Die Bibliothek erlaubt ebenfalls die Werte des Reglers im laufenden Betrieb zu wechseln, das erlaubt ein komfortables ermitteln der Werte. \cite{PIDlib}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsubsection{Display Treiber}
|
|
|
|
|
|
|
|
Durch dieses Bibliothek wird das IC2-Modul angesprochen, welches dann wiederum das eigentliche Display anspricht. Das schreiben auf das Display wird über das Setzten des Coursers auf Zeile und Spalte gesteuert. Weitere Funktionen unterstützen Löschen des Displays so wie das Ein- und Ausschalten der Hintergrundbeleuchtung. Diese Bibliothek wird ebenfalls für die Fernbedienung benutzt. \cite{displayLib}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsubsection{Json}
|
|
|
|
|
|
|
|
Die ArduinoJson Library bietet Funktionen um Json zu Parsen oder eigene Json Dokumente zu erstellen. Dabei zeichnet sich diese Bibliothek durch besonders gutes Speichermanagement und Vielfältigkeit aus. So ist es möglich die erforderlichen Daten im Heap oder im Stack abzulegen. Anwendung findet diese beim Importieren und Exportieren der Routen zum navigieren. \cite{JsonLib}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsubsection{Kompass}
|
|
|
|
|
|
|
|
Dies ist die zweite Bibliothek um mit einem am I2C Bus angeschlossenem Gerät zu kommunizieren. In diesem Fall mit dem QMC5883L. Die Bibliothek kann durch schreiben und lesen der unterschiedlichen Register das Modul konfigurieren und die Rohwerte der einzelnen Achsen lesen. Diese werden dann weiter verarbeitet. Es können hier Kalibrierungsdaten angewendet werden, damit können die erhobenen Daten geglättet werden. Die Bibliothek wurde im Verlauf des Projektes erweitert, sodass angewendete Kalibrierungsdaten wieder entfernt werden können. Dies war nötig um den Kompass im laufenden Betrieb kalibrieren zu können. Aus den Rohwerten wird am Ende ein Winkel berechnet. Norden entspricht 0° dann wird im Uhrzeigersinn weiter gezählt bis 359 nahezu wieder Norden entspricht. \cite{kompassLib}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{Fernbedienung}
|
|
|
|
|
|
|
|
\subsubsection{Entprellung}
|
|
|
|
|
|
|
|
Um ein prellen der Tasten zu verhindern wird die Debounce Bibliothek eingefügt. Mit dieser können einzelne Pins beobachtet werden. Es werden die Zeiten gespeichert, wann sich der Status der Taste bzw. des Pins zuletzt geändert hat und wenn diese Zeiten zu nah beieinander liegen wird der Wechsel des Zustandes verworfen. So kann logisch mit Software ein prellen verhindert werden. \cite{bounceLib}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsubsection{ESPnow}
|
|
|
|
|
|
|
|
ESPnow ist eine von Espressif zur Verfügung gestellte Bibliothek, die es erlaubt Daten in einem eigenen kleinen Netzwerk über 2,4 GHz zu versenden. Dabei entsteht weniger Overhead als bei der Verwendung von WiFi. Diese Bibliothek wird dementsprechend zwingend auch auf dem Rover benötigt um die Daten der Fernbedienung zu Empfangen und selbst Daten zum anzeigen auf dem Display der Fernbedienung zu versenden. Es tritt ein erschwerender Zustand ein der die Implementierung etwas verkompliziert, da der Rover gleichzeitig WiFi und ESPnow benutzt. Die beide Technologien können nur gleichzeitig genutzt werden, wenn lediglich ein Channel verwendet wird. Da der Rover je nach genutztem WiFi einen Kanal zugewiesen bekommt, wird dieser auf dem Display angezeigt sofern keine Verbindung zu der Fernbedienung besteht. Auf der Fernbedienung lässt sich dann der Kanal vom Rover einstellen. \cite{espNowLib} \cite{ESPnow}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{Basissation}
|
|
|
|
|
|
|
|
\label{sec:software-basisstation}
|
|
|
|
|
|
|
|
Als Grundlage wird das Betriebssystem Microsoft Windows in der Pro Variante verwendet. Dies ist nötig um das System via Microsoft Remotedesktop fernwarten zu können. \cite{remoteDesktop} Zur einfacheren Erreichbarkeit des Computers wurde in den Netzwerkeinstellungen eine statische IP-Adresse vergeben. Zum konfigurieren des GPS-Moduls ist das u-center von U-Blox installiert. Dieses ist insbesondere zum Debugging und zur Ersteinrichtung sehr wichtig.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsubsection{Routen API}
|
|
|
|
|
|
|
|
Damit es eine Möglichkeit gibt Navigationsrouten für den Rover extern zu speichern und zu verwalten, wurde eine kleine HTTP-API programmiert. Diese Implementiert die HTTP-Methoden GET, POST und DELETE. Bei jeder Methode wird über die URL die Nummer der Route verlangt. Die Routen werden im JSON-Format gespeichert, ausgegeben und empfangen. Jede Route besteht aus einer dezimalen ID, der Anzahl der enthaltenen Punkte und dem Array mit den eigentlichen Punkten zum navigieren. Die Punkte werden als Gleitkommazahl gespeichert. Die Api wird von dem Rover selbst in einem extra Menüpunkt genutzt. Die Website zeigt die Anzahl an gespeicherten Routen an und die einzelnen Routen mit den enthaltenen Punkten. Die Website und die Api werden über einen öffentlich erreichbaren Webserver auf der Basissation zugänglich gemacht. Dieses Teilprojekt wurde mit Javascript umgesetzt. Dafür wurde das Framework Express für die Plattform Node.js genutzt. Die Node.js Instanz wird als Dienst ausgeführt und stellt neben der Implementierung der API auch die statischen Daten für die Website zur Verfügung. Die Website selbst nutzt auch die API um auf die Daten zugreifen zu können.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsubsection{STRSVR - NTRIP Server}
|
|
|
|
|
|
|
|
Das Programm STRSVR aus der RTKLib wird verwendet um die Korrekturdaten seriell von dem GNSS-Modul zu Empfangen. Mit dem Programm kann dann eingestellt werden wohin die Daten weiter gesendet werden sollen. Aktuell wird NTRIP-Caster RTK2go.com verwendet. Dieser ist kostenlos nutzbar. Dafür werden die gesendeten Korrekturdaten allen Nutzern frei zur Verfügung gestellt, die Interesse daran haben. Der Rover kann sich somit als Client bei RTK2go.com einloggen und erhält so die Korrekturdaten. Da das Programm erlaubt die Daten zu mehreren Abnehmern gleichzeitig zu verschicken, sind auch zusätzliche Anwendungen und parallele Lösungen denkbar. Das Programm läuft auf Benutzerlevel und wird aktuell nicht automatisch gestartet. Allerdings wird die Konfiguration automatisch gespeichert. Deshalb könnte das Programm automatisch über Batch Skript gestartet werden und so den Umstand umgehen, dass bei einem Neustart erst manuell das Programm wieder gestartet werden muss. \cite{sparkfunBasisStation}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\chapter{Anforderungen}
|
|
|
|
|
|
|
|
\label{cha:Anforderung}
|
|
|
|
|
|
|
|
\section{Motorteuerung}
|
|
|
|
|
|
|
|
Eine sehr hardwarenahe Anforderung ist die Motorsteuerung. Diese ist sehr kritisch, wenn Fehler in dieser auftreten, kann das zu unkontrollierten Verhalten des Rovers führen. Es könnten Beschädigungen aus verschiedenen Ursachen an unterschiedlichen Komponenten entstehen. Wenn der Rover unkontrolliert beschleunigt könnte dieser Gegen Hindernisse fahren und so zum Beispiel das Gehäuse beschädigen. Ein weiteres Szenario für Beschädigungen könnte auftreten, wenn der Strom zu groß wird, weil die Motoren einen radikalen Richtungswechsel vollziehen sollen. Dabei könnte der Motortreiber auf Grund der hohen Last Schaden nehmen oder der Akku könnte über sein maximalen Strom hinaus belastet werden und ebenfalls Schaden nehmen.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Daraus lassen sich dann die Anforderungen ableiten, dass die Motoren über eine Anfahrkurve angesteuert werden müssen. Dafür und um die Geschwindigkeit zu regulieren, soll zur Reglung Pulsweitenmodulation angewendet werden. Des Weiteren sollte eine Funktion zur Verfügung stehen, die die Motoren möglichst schnell stoppt ohne die Steuerungskurve zu beachten.
|
|
|
|
|
|
|
|
Darüber hinaus wären Einstellungsmöglichkeiten, in welchen Leistungsbereichen der Motor betrieben werden soll, wünschenswert.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\section{Geschwindigkeitssteuerung}
|
|
|
|
|
|
|
|
Der Rover soll sich mit vorgegebenen Geschwindigkeiten bewegen. Dafür soll sich jeder Motor in einer Regelungsschleife befinden. Außerdem muss gewährleistet werden, dass die Motoren auch untereinander synchronisiert werden. Genauer, wenn beide Motoren eine unterschiedliche Zielgeschwindigkeit vorgegeben wird, sollte diese die möglichst gleichzeitig erreichen. Da ansonsten berechnete Manöver deutlicher von dem vorgegeben Verlauf abweichen könnten.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\section{Energieversorgung}
|
|
|
|
|
|
|
|
Da dieses Projekt autonom unterwegs sein soll, ist eine interne Stromversorgung zwingend erforderlich. Dazu wird ein Akku vorgesehen. Dieser sollte einen ausreichenden Strom bereitstellen, um die Motoren und die restliche Elektronik anzutreiben. Es wird eine externe Ladung des Akkus vorgesehen, deshalb ist kein Ladeelektronik vonnöten. Allerdings muss die Entladung im Betrieb überwacht werden, um eine Tiefentladung des Akkus zu verhindern. Die Spannung des Akkus soll ausgelesen werden können. Im Fall einer drohenden Tiefentladung soll das ansteuern der Motoren von der Software verhindert werden.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\section{Fahrsteuerung}
|
|
|
|
|
|
|
|
Um eine allgemeine Manövrierbarkeit zur Verfügung zu stellen, sodass der Rover zum Beispiel in die Ausgangsposition oder zur Aufzeichnung der Route bewegt werden kann, soll dieser mit intuitiven Benutzereingaben gesteuert werden. Dies betrifft die Richtung und die Geschwindigkeit, mit der der Rover manuell fahren soll. Wünschenswert wäre die maximale Geschwindigkeit in diesem Modus begrenzen zu können.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\section{Route eingeben}
|
|
|
|
|
|
|
|
Um die Kernfunktion des Projektes erfüllen zu können, müssen Daten zum navigieren vorhanden sein. Diese sollen von dem Rover selbst aufgenommen werden können. Dazu soll die oben genannte Fahrsteuerung genutzt und erweitert werden. Dem Nutzer wird überlassen, festzulegen welche Punkte genau in die Route aufgenommen werden. Ein einzelner Punkt soll gespeichert werden, wenn der Nutzer die Eingabe dazu tätig. Punkte die der Nutzer speichern möchte sollen vorher überprüft werden. Dazu soll die vorhanden Genauigkeit und die Entfernung zu dem letzten gespeicherten Punkt genutzt werden. Wenn eines von beiden zu gering ausfällt soll der Nutzer über den Fehlschlag informiert werden und die aktuelle Position nicht gespeichert werden. Es wäre von Vorteil wenn Routen auch aus einer externen Quelle geladen werden könnten.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\section{Navigation}
|
|
|
|
|
|
|
|
Es ist obligatorisch, dass der Rover mit dem ihn zur Seite stehenden Ressourcen in der Lage sein muss, eigenständig von einer aktuellen Position zu einem gegeben Punkt navigieren zu können. Es wird vorausgesetzt, dass der Zielpunkt in einer geraden Linie, welche für den Rover befahrbar ist, erreichbar ist. Des Weiteren muss die zu der Zeit zur Verfügung stehende Genauigkeit den Anforderungen entsprechen. Die Navigationsanweisungen sollen dem Nutzer und dem Autopiloten zur Verfügung stehen. Der Autopilot soll die Fahrsteuerung des Rover auf Aufforderung übernehmen. Wenn dies geschehen ist soll sich der Rover zum Zielpunkt ausrichten und dann in einer konstanten Geschwindigkeit auf ihn zufahren. Wenn die Abweichung vom Kurs zu groß wird, müssen Korrekturen ausgeführt werden. Dazu soll der Rover stehen bleiben, sich dann neu ausrichten und wieder fahrt aufnehmen. Die automatisierte Fahrsteuerung muss jederzeit vom Nutzer beendet werden können.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\section{Genauigkeit der Positionsbestimmung}
|
|
|
|
|
|
|
|
Die Genauigkeit der Positionsbestimmung ist in diesem Projekt von elementarer Bedeutung. Verschärft wird diese Anforderung durch den Umstand, dass sich die eigentliche Abweichung der gemessenen Position von der wirklichen Position im Betrieb verdoppeln kann. Diese Verdopplung kann entstehen, weil die gespeicherte Route aus den vom Rover gemessenen Positionen besteht. Während der Navigation kann sich die bestehende Abweichung dann verringern oder erhöhen, je nach dem in welche Richtung die Positionsbestimmung neben der eigentlichen Position liegt.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Der Rover soll maximal 50cm von eigentlichen ursprünglichen Route abweichen. Das heißt, dass zu jeder Zeit die aktuelle Abweichung maximal 25 cm betragen darf. Um diese Genauigkeit mit GNSS erreichen zu können, müssen Korrekturdaten auf die Messungen des des GNSS-Moduls angewendet werden. Deshalb muss das verwendete Modul diese Funktion bereitstellen. Des Weiteren müssen die Korrekturdaten an das Modul übertragen werden. Dafür muss ebenfalls eine Möglichkeit bestehen. Die Daten selbst werden sollen von verschiedenen Quellen bezogen werden können, zum Beispiel von der bereits genannten Basisstation in \ref{sec:software-basisstation}.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Die aktuelle Genauigkeit soll mit den Koordinaten zusammen abgespeichert werden. Wenn die minimale Genauigkeit nicht erreicht wird sollen Funktionen eingreifen, um zum Beispiel auf bessere Werte zu warten. Eine mangelhafte Ungenauigkeit muss also zu einem mindestens temporären Funktionsausfall führen.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\section{Benutzerinterface}
|
|
|
|
|
|
|
|
Der Benutzer soll in der Lage sein, alle Funktionen strukturiert abzurufen. Diese Struktur soll in Form von Menus mit Untermenüs und Aktionen realisiert werden. Die Menüstruktur muss an das zweizeilige Display angepasst sein und gut mit der Steuerungsfunktionen der Fernbedienung harmonieren. Es sollen außerdem allgemeine Informationen und Informationen über den aktuellen Betriebszustand angezeigt werden können.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\chapter{Projekt Struktur und Implementierung}
|
|
|
|
|
|
|
|
Bei der Planung des gesamten Systems wurde darauf geachtet die Erweiterbarkeit und eine offene Struktur zu gewährleisten. Deshalb können viele Teile der Software als einzelne Komponenten betrachtet werden. Diese sind normalerweise als Klasse implementiert. Da in diesem Projekt nur das Arduinoframework genutzt wurde und deshalb keine Task Verwaltung oder ähnliches verfügbar ist, besitzen die einzelnen Komponenten jeweils eine eigene \mintinline{c++}|void loop()|. Diese wird dann in der Funktion \mintinline{c++}|loop()| vom Arduinoframework oder in der \mintinline{c++}|loop()| Funktion einer anderen Komponente aufgerufen. So werden dann nach und nach alle aktiven Komponenten aufgerufen. Wenn möglich sind sind early-exit Funktionalitäten implementiert. Eine beispielhafte \mintinline{c++}|void loop()| Funktionen sieht so aus:
|
|
|
|
|
|
|
|
\begin{minted}{c++}
|
|
|
|
|
|
|
|
void KomponenteA::loop() {
|
|
|
|
|
|
|
|
this->KomponenteB->loop();
|
|
|
|
|
|
|
|
this->KomponenteC->loop();
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
if (millis() - this->lastMillis < this->delayMillis)
|
|
|
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
this->doSomething();
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
\end{minted}
|
|
|
|
|
|
|
|
Das Arduino Framework teilt die Kerne des Mikrocontroller direkt auf. Der eine Kern kümmert sich um die Hardware Aufgaben, wie zum Beispiel Keep-Alive Maßnahmen beim WiFi. Der andere Kern führt den Code vom Benutzer aus. Diese Trennung ermöglicht es, dass dieses Projekt nicht auf solche Gegebenheiten achten muss.
|
|
|
|
|
|
|
|
Im Folgenden werden die Hauptkomponenten der Software beschrieben.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\section{DriveManager}
|
|
|
|
|
|
|
|
Der DriveManager bildet eine der Hauptkomponenten der Software des Rovers. Die Hauptfunktion dieser Komponente besteht darin zwischen den verschiedenen Betriebsmodi des Rovers zu wechseln und diese auszuführen. Es kann immer nur ein Modus ausgeführt werden. Wenn von einem zum anderen Modus gewechselt wird, wird das vorherige Modus Objekt gelöscht und für den neuen Modus eines erstellt. Es wurde das Konzept der Polymorphie angewendet, alle Modi müssen von dem vorgesehen Interface erben. Dadurch kann der aktuelle Modus immer im gleichen Pointer gespeichert werden. Die einzelnen Modi des Rovers sind jeweils auch als Komponenten zu verstehen und werden in folgenden Unterkapiteln beschrieben. Jeder Modus erhält Zugriff auf die MoveControl Komponente und ein Input Objekt. Andere Modi erhalten zum Teil zusätzlich Zugriff auf die Navigation.
|
|
|
|
|
|
|
|
Der DriveManager enthält zwei weiter wichtige Komponenten. Das ist zum einen die Komponente ManualControl und zum anderen die navigation's Komponente.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{ManualControl}
|
|
|
|
|
|
|
|
\label{sec:ManualControl}
|
|
|
|
|
|
|
|
Diese Modus soll es dem Benutzer erlauben den Rover wie ein normales ferngesteuertes Auto zu benutzten. Dazu wird aus dem Input Objekt der x und y Wert verwendet. Diese haben den Datentypen \mintinline{c++}|uint8_t| und sollen die analogen Werte eines Joysticks darstellen. Da der Joystick in Ruheposition mit mittleren Werten ausgelesen wird, müssen diese zunächst abgezogen werden. Dazu wird der neue Wert in einer vorzeichenbehafteten Variablen abgespeichert. Diese werden dann auf die maximale Vorwärts- und Rotationsgeschwindigkeit umgewandelt und schließlich an die MoveControl Komponente weiter gegeben.
|
|
|
|
|
|
|
|
\begin{minted}{c++}
|
|
|
|
|
|
|
|
int16_t y = this->input->x - 127;
|
|
|
|
|
|
|
|
int16_t x = this->input->y - 127;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
double value_per_step = this->max_speed * 2 / UINT8_MAX;
|
|
|
|
|
|
|
|
this->moveControl->setSpeed(-y * value_per_step);
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
value_per_step = this->max_rotation * 2 / UINT8_MAX;
|
|
|
|
|
|
|
|
this->moveControl->setRotationSpeed(x * value_per_step);
|
|
|
|
|
|
|
|
\end{minted}
|
|
|
|
|
|
|
|
Zusätzlich sind Schnittstellen gegeben mit denen sich die maximalen Geschwindigkeiten anpassen lassen.
|
|
|
|
|
|
|
|
Um den Kompass zu kalibrieren kann die Komponente für diesen Zweck übergeben werden und wird sofern verfügbar als untergeordnete Komponente ausgeführt.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{CaptureRoute}
|
|
|
|
|
|
|
|
\label{sec:CaptureRoute}
|
|
|
|
|
|
|
|
Diese Komponente wird verwendet um Routen händisch aufzeichnen zu können. Welche Koordinaten gespeichert werden bestimmt dabei der Benutzer indem dieser das Kommando dazu gibt. Ob das Kommando gegeben wurde wird aus dem Input Objekt entnommen. Die einzelnen Punkte werden mithilfe der Navigation Komponente gespeichert, da diese die aktuelle Route verwaltet. Beim Speichern wird auf die aktuelle Genauigkeit der GNSS-Signale geachtet und auf den Abstand zum vorherigen Punkt. So sind die einzelnen Koordinaten nie zu nah beieinander oder zu weit auseinander, dies würde nämlich die Navigation erschweren. Durch die Kontrolle der Genauigkeit wird sichergestellt, dass die Route später präzise abgefahren werden kann. Dies ist wichtig weil, der Rover sich ausschließlich nach den Koordinaten richtet und keine anderen Möglichkeiten hat um beispielsweise Hindernissen auszuweichen. Während dieser Modus aktiv ist, können Informationen über den aktuellen Status der GNSS Komponente und Route abgefragt werden.
|
|
|
|
|
|
|
|
Um den Rover zu bewegen, erbt diese Komponente von der ManualControl Komponente.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{Autopilot}
|
|
|
|
|
|
|
|
\label{sec:Autopilot}
|
|
|
|
|
|
|
|
Der Autopilot erbt ebenfalls von der ManualControl Komponente, um den Rover an den Start der Route manövrieren zu können. Erst wenn der Rover sich am ausreichend nah an dem Startpunkt befindet, kann der Benutzer die automatische NAvigation starten. Wenn diese im Betrieb ist erhält sie von der Navigation Komponente Informationen darüber in welcher Entfernung und in welchem Winkel sich der nächste anzusteuernde Punkt zur aktuellen Rover Position befindet. Dabei stellt die Längsachse des Rovers die 0° Marke dar. Die Strategie der Komponente ist es sich zunächst auf den angepeilten Punkt auszurichten und dann die Strecke geradeaus zurückzulegen. Wenn während der fahrt, der Winkel zum Ziel den eingestellten Wert überschreitet, bleibt der Rover stehen und versucht sich neu auszurichten.
|
|
|
|
|
|
|
|
Zum ausrichten auf den Zielpunkt wird der installierte Kompass genutzt. Die Abweichung vom Kurs und die Entfernung zum Ziel zu berechnen ist ebenfalls Aufgabe der Komponente Navigation. Es wird auch beim abfahren der Route auf eine ausreichend genau Positionsbestimmung geachtet. Die Abweichung von der Route sollte nicht mehr als einen halben Meter betragen.
|
|
|
|
|
|
|
|
Über Schnittstellen können im laufenden Betrieb Einstellungen am Autopiloten vorgenommen werden. So lassen sich auch hier die Verfahr- und die Rotationsgeschwindigkeit einstellen und der aktuelle Zustand der Komponente erfragen. Die verschiedenen Zustände sind über ein \mintinline{c++}|enum| in der Klasse definiert:
|
|
|
|
|
|
|
|
\begin{minted}{c++}
|
|
|
|
|
|
|
|
enum State {
|
|
|
|
|
|
|
|
InsufficientAccuracy = -2,
|
|
|
|
|
|
|
|
NoRoute = -1,
|
|
|
|
|
|
|
|
None = 0,
|
|
|
|
|
|
|
|
NavigationStarted,
|
|
|
|
|
|
|
|
GetToStartPoint,
|
|
|
|
|
|
|
|
SelfDrivingAvailable,
|
|
|
|
|
|
|
|
SelfDriving,
|
|
|
|
|
|
|
|
SelfDrivingBackAndForth,
|
|
|
|
|
|
|
|
SelfDrivingCircle,
|
|
|
|
|
|
|
|
TargetReached
|
|
|
|
|
|
|
|
};
|
|
|
|
|
|
|
|
\end{minted}
|
|
|
|
|
|
|
|
Diese Zustände werden dazu genutzt um eine Struktur ähnlich einer State Machine im Programmcode abzubilden.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{TestMode}
|
|
|
|
|
|
|
|
In diesem Modus kann der Rover nicht wie ein normales Fahrzeug bewegt werden. Um die möglichst viele Bauteile und Baugruppen des Rovers Testen zu können werden verschiedene Ansprechmöglichkeiten bereit gestellt. Die komplexeste von diesen ist es ein einfaches Manöver anzugeben welches abgefahren werden soll. Dazu wird eine Distanz und ein Winkel angegeben. Mit diesem Test kann das Zusammenspiel von den Motoren, den Encoder und dem Kompass getestet werden.
|
|
|
|
|
|
|
|
Eine weitere Testmöglichkeit ist es die Motoren einzeln anzusteuern. Dabei wird der Dutycycle angegeben und die Dauer in Sekunden die der Motor angesteuert werden soll. Mit diesem Test lässt sich besonders gut das Ansprechverhalten der Motoren bei verschiedenen Dutycycle betrachten. Außerdem lässt sich so der Motortreiber auf Funktion prüfen und ob die Drehrichtung des Motors korrekt ist.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\section{MoveControl}
|
|
|
|
|
|
|
|
\label{sec:MoveControl}
|
|
|
|
|
|
|
|
In der MoveControl Komponente wird die Motorsteuerung mit den Encoder für die Raddrehzahl verbunden. Des Weiteren wird eine Abstraktionsschicht implementiert, die es erlaubt Geschwindigkeiten anzugeben anstelle von relativen Werten.
|
|
|
|
|
|
|
|
Um diese Funktionalitäten bereitstellen zu können, beherbergt MoveControl die MotorControl und die Speedometer Komponente jeweils mit zwei Instanzen für jeweils eine Seite des Rovers. Je Seite werden diese beiden Komponenten über eine Bibliothek verbunden welche einen PID-Regler zu Verfügung stellt. Das Speedometer stellt dabei den Eingang vom Regler dar, während MotorControl die vom Regler angesteuerte Komponente ist.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Der Sollwert wird indirekt durch den Benutzer oder eine andere Komponente beigetragen. Dieser wird zunächst in einer Geschwindigkeit für x-Richtung und einer Geschwindigkeit für die Rotation um die Z-Achse angeben. Dazu werden Formeln aus der Robotik verwendet, mit der Spezialisierung auf den Skid-Antrieb. Zum einen die Rückwärtstransformation:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\[
|
|
|
|
|
|
|
|
\begin{pmatrix}
|
|
|
|
|
|
|
|
\dot{\varphi_l} \\ \dot{\varphi_r}
|
|
|
|
|
|
|
|
\end{pmatrix}
|
|
|
|
|
|
|
|
= \frac{1}{r}
|
|
|
|
|
|
|
|
\begin{pmatrix}
|
|
|
|
|
|
|
|
1 & b \\
|
|
|
|
|
|
|
|
1 & -b
|
|
|
|
|
|
|
|
\end{pmatrix}
|
|
|
|
|
|
|
|
\begin{pmatrix}
|
|
|
|
|
|
|
|
\dot{\chi_R} \\ \dot{\theta }
|
|
|
|
|
|
|
|
\end{pmatrix}
|
|
|
|
|
|
|
|
\\
|
|
|
|
|
|
|
|
\]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Und zum anderen die Vorwärtstransformation:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\[
|
|
|
|
|
|
|
|
\begin{pmatrix}
|
|
|
|
|
|
|
|
\dot{\chi_R} \\ \dot{\theta }
|
|
|
|
|
|
|
|
\end{pmatrix}
|
|
|
|
|
|
|
|
= \frac{r}{2}
|
|
|
|
|
|
|
|
\begin{pmatrix}
|
|
|
|
|
|
|
|
1 & 1 \\
|
|
|
|
|
|
|
|
\frac{1}{b} & -\frac{1}{b}
|
|
|
|
|
|
|
|
\end{pmatrix}
|
|
|
|
|
|
|
|
\begin{pmatrix}
|
|
|
|
|
|
|
|
\dot{\varphi_l} \\ \dot{\varphi_r}
|
|
|
|
|
|
|
|
\end{pmatrix}
|
|
|
|
|
|
|
|
\\
|
|
|
|
|
|
|
|
\]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Die angegebenen Werte werden dann mit der Formel für die Vorwärtstransformation in Rad-Geschwindigkeiten umgerechnet. Dabei wird die Geschwindigkeit für $ \dot{\chi_R} $ eingesetzt und die Rotation wird von $ \dot{\theta } $ dargestellt.
|
|
|
|
|
|
|
|
Die errechneten Rad-Geschwindigkeiten pro Seite wird dann schließlich als Sollwert an den Regler übergeben.
|
|
|
|
|
|
|
|
\cite{skidFormeln} In der Implementierung wurden alle statischen Werte soweit möglich vorher zusammengerechnet, um die Berechnungszeit zu minimieren.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{MotorControl}
|
|
|
|
|
|
|
|
\label{sec:MotorControl}
|
|
|
|
|
|
|
|
MotorControl hat einen direkten Hardwarezugriff auf den Motortreiber. Es werden Sollwerte für die prozentuale Leistung des Motors angenommen. Diese werden dann versucht zu erreichen. Allerdings wird dabei auf einen gewissen Schutz für die Hardware geachtet.
|
|
|
|
|
|
|
|
Deshalb wird die Leistung für den Motor nur über die Zeit erhöht und verringert. Jedes mal wenn die \mintinline{c++}|void MotorControl::loop()| Funktion aufgerufen wird und die Mindestzeit seit dem letzten Aufruf vergangen ist wird der Istzustand dem Sollzustand um einen Wert x angepasst. Daraus ergibt sich eine Gerade.
|
|
|
|
|
|
|
|
In der aktuellen Konfiguration gilt die Steigung $m = 2$:
|
|
|
|
|
|
|
|
\[ f(x) = mx \]
|
|
|
|
|
|
|
|
dabei steht $x$ für die Zeit in Sekunden und der $y$-Wert für die aktuelle relative Leistung. $ y = 1 = 100\% $
|
|
|
|
|
|
|
|
An dieser Gerade kann abgelesen werden kann welche Zeit benötigt wird um beispielsweise von 50\% der Leistung in die eine Drehrichtung zu 30\% der Leistung in die andere Richtung zu gelangen. Die Formel zur Berechnung der Zeit lautet:
|
|
|
|
|
|
|
|
\[
|
|
|
|
|
|
|
|
t[s] = \frac{y_{start} - y_{end}}{m}
|
|
|
|
|
|
|
|
\]
|
|
|
|
|
|
|
|
Es gibt eine Ausnahme um diese zeitliche Abhängigkeit zu umgehen, diese Ausnahme ist in der Funktion \mintinline{c++}|void MotorControl::emergencyStop()| realisiert um ein möglichst schnellen Stopp mit dem Rover ausführen zu können, wenn das vonnöten sein sollte.
|
|
|
|
|
|
|
|
Bei diesem Verfahren ist allerdings nur die dem Motor zur Verfügung gestellten Leistung bekannt. Die tatsächliche Drehzahl hängt von vielen Faktoren ab und kann zum Beispiel mit einer Encoder-Scheibe an der Achse gemessen werden. Diese wird von der Speedometer Komponente verwaltet.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{Speedometer}
|
|
|
|
|
|
|
|
\label{sec:Speedometer}
|
|
|
|
|
|
|
|
Die Speedometer Komponente nutzt einen Encoder an der Ausgangswelle des Getriebes um die Drehzahl dieser feststellen zu können. Allerdings ist die Drehzahl der Ausgangswelle nicht gleich der der Räder, da sich dazwischen noch mal ein Zahnradkombination befindet, das Übersetzungsverhältnis müsste bei der Berechnung beachtet werden.
|
|
|
|
|
|
|
|
Da die Scheibe des Encoder für eine volle Umdrehung der Achse 120 Pulse erzeugt und eine volle Drehung des Rads ca 360 Pulse erzeugt, kann von einem Verhältnis von 1:3 ausgegangen werden.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Um die Menge der Pulse zählen zu können, bietet es sich an den im ESP32 verbauten Pulsecounter zu verwenden. Dies ist eine Hardwareeinheit, die ohne Prozessorzeit auskommt und zusätzlich über einen Filter verfügt mit welchem sich ein prellendes Signal glätten lässt. Da in diesem Projekt nur ein einfacher Encoder verwendet wird muss der Komponente die aktuelle Richtung bekannt sein um die Pulse richtig einordnen zu können. Wenn ein doppelter Encoder verbaut wäre, könnte die Drehrichtung automatisch ermittelt werden.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Bei jeden Aufruf von \mintinline{c++}|void Speedometer::loop()|, sofern ausreichend Zeit vergangen ist, wird die vergangene Zeit seit dem das letzte mal die Anzahl der Pulse ausgelesen wurde berechnet ($\Delta t$) und die aktuellen Pulse ausgelesen und zurückgesetzt. Um den am Ende der Berechnungen resultierenden Wert noch weiter zu glätten, können die letzten x Werte der gezählten Impulse in einem Buffer gespeichert werden um daraus den Durchschnitt bilden zu können.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Zunächst muss die Anzahl der $\frac{Umdrehung}{s}$ seit der letzten Messung berechnet werden. Dazu werden die gezählten Pulse durch die Anzahl an Pulse einer vollständigen Umdrehung des Rades geteilt. Um die zeitlich Abhängigkeit zu beachten, wird das Ergebnis mit $\Delta t$ multipliziert. Um nun von den $\frac{Umdrehung}{s}$ auf $\frac{m}{s}$ zu kommen wird der Umfang des Rades dividiert. Daraus entsteht die Formel mit $x = Pulse$ und $ P_{max} = 360 $ für die Pulse einer gesamten Umdrehung:
|
|
|
|
|
|
|
|
\[
|
|
|
|
|
|
|
|
\frac{m}{s} = \frac{x \cdot \Delta t}{P_{max} \cdot 2\pi r}
|
|
|
|
|
|
|
|
\]
|
|
|
|
|
|
|
|
Um die Funktion des Encoder Testen zu können, wurde ein auch ein Testmodus implementiert. Wenn dieser aktiviert ist, werden die gezählten Impulse nicht mehr automatisch verarbeitet. Stattdessen werden diese Ausgegeben, wenn der Modus beendet wird. So lässt sich zum Beispiel die Genauigkeit erahnen wenn der Modus aktiviert wird und das Rad dann per Hand ein paar Umdrehungen gedreht wird und anschließen genau um die selbe Anzahl Umdrehungen zurück gedreht wird. Wenn das Ergebnis dann weit von 0 entfernt ist, könnte ein Defekt in der Verarbeitungskette vorliegen. Zur Vereinfachung der Berechnungen wurde dieser Test ausgeführt um die Pulse einer kompletten Radumdrehung auszulesen ohne theoretische Abhängigkeiten. Der ermittelte Wert wurde dann direkt in die Berechnung eingebettet.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\section{Energie}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\section{Navigation}
|
|
|
|
|
|
|
|
\label{sec:Navigation}
|
|
|
|
|
|
|
|
Die Navigation gehört ebenfalls zu den Hauptkomponenten und benötigt die Komponenten Route und NTRIPClient. Zusätzlich wird die Hardware des Kompass und des GNSS Moduls verwaltet, dies geschieht in der \mintinline{c++}|void Navigation::loop()| Funktion.
|
|
|
|
|
|
|
|
Das Interface dieser Komponente wird hauptsächlich von den Komponenten CaptureRoute und Autopilot verwendet, andere Komponenten greifen nur zu Informationszwecken auf diese zu. Für CaptureRoute wird hauptsächlich die Funktion
|
|
|
|
|
|
|
|
\newline \mintinline{c++}|Status Navigation::addCurrentPosToRoute()| verwendet. Der Rückgabewert informiert darüber ob der Punkt angenommen wurde oder wenn er nicht wurde aus welchen Gründen dieser abgelehnt wurde.
|
|
|
|
|
|
|
|
Der Autopilot hingegen nutzt hauptsächlich die Funktion
|
|
|
|
|
|
|
|
\begin{minted}{c++}
|
|
|
|
|
|
|
|
Status Navigation::getCourseCorrection
|
|
|
|
|
|
|
|
(CourseCorrection& correction, bool forceUpdate = false)
|
|
|
|
|
|
|
|
\end{minted}
|
|
|
|
|
|
|
|
. Die übergebene Referenz auf das CourseCorrection Objekt dient zur Datenübermittlung. Darin wird die Distanz und der Winkel zum nächsten Punkt gespeichert. Mit dem zweiten Argument lässt sich ein Update dieser Daten erzwingen, da die Funktion die Daten im normalen Zustand nur aktualisiert wenn sich die Position des Rovers signifikant zu der verändert hat, als die Daten zuletzt angepasst wurden. Außerdem wird der folgende Punkt der Route selektiert wenn aktuelle Punkt annähernd erreicht wurde. Für Testzwecke lässt sich die automatische neu Selektion deaktivierten mit der Funktion \mintinline{c++}|void Navigation::freezeTargetPoint(bool val = true)| Sollte die Genauigkeit der Positionsbestimmung ungenügend sein, wird das über den Rückgabewert \mintinline{c++}|Status| mitgeteilt.
|
|
|
|
|
|
|
|
Es werden außerdem Funktionen bereitgestellt, mit denen indirekt auf die Route zugegriffen werden kann um diese beispielsweise zu löschen oder zu starten. Eine weiter Funktion gibt Auskunft über die Anzahl der Punkte die in der Route gespeichert sind und bei welchem Teilabschnitt sich der Rover gerade befindet.
|
|
|
|
|
|
|
|
Für andere Komponenten wird der Zugriff auf den Kompass bereitgestellt und den NTRIPClient bereitgestellt.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{Route}
|
|
|
|
|
|
|
|
In der Route werden die einzelnen Punkten als Liste abgespeichert. Dazu werden Instanzen der Point Komponente verwendet. Mit dem Interface von Route ist es möglich einzelne Punkte der Route hinzuzufügen und alle Punkte zu löschen. Um mit der Route interagieren zu können kann der erste oder der letzte Punkt über die jeweilige Funktion selektiert werden. Danach kann dann mit den Funktionen \mintinline{c++}|Point Route::getNextPoint()| und \mintinline{c++}|Point Route::getPreviousPoint()| der jeweils nächste oder vorherige
|
|
|
|
|
|
|
|
\newline Point ausgewählt werden.
|
|
|
|
|
|
|
|
ZUsätzlich lassen sich allgemeine Informationen mit
|
|
|
|
|
|
|
|
\newline \mintinline{c++}|RouteInfo Route::getRouteInfo()| abfragen.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsubsection{Point}
|
|
|
|
|
|
|
|
\label{sec:Point}
|
|
|
|
|
|
|
|
Diese Komponente soll das abspeichern und arbeiten mit Koordinaten erleichtern. Immer wenn ein neuer Point erzeugt wird, wird auch die Genauigkeiten des Punktes zum Zeitpunkt der Erstellung gespeichert. Dies muss im Konstruktor gesondert mit angeben werden, ist dies nicht fall wird die Genauigkeit als die schlecht möglichste angenommen. Wenn Koordinaten von anderen Quellen importiert werden, kann dies alternativ zu der Genauigkeit angegeben werden. In diesem Fall wird dann die best möglichste Genauigkeit angenommen und abgespeichert.
|
|
|
|
|
|
|
|
Point Objekt können mit dem ==-Operator verglichen werden und es werden Funktionen bereitgestellt mit denen sich die Distanz und der Winkel zu einem anderen Point berechnen lassen. Dabei wird die Erdkrümmung vernachlässigt, weil diese in dem Entfernungsbereich den der Rover zurücklegen könnte keine relevanten Unterschiede machen würde und die Berechnung so Ressourcen schonender implementiert werden kann.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{NTRIPClient}
|
|
|
|
|
|
|
|
\label{NTRIPClient}
|
|
|
|
|
|
|
|
Ohne den NTRIPClient und die Daten die dieser bereitstellt wäre die ausreichend genaue Positionsbestimmung nicht möglich. Bei der Erstellung der Instanz wird das Objekt des GNSS-Moduls mit übergeben. Damit darüber die Daten für die Echtzeitkorrektur an das Modul übermittelt werden können. Damit das Modul die Daten verarbeiten kann werden zu beginn noch ein paar Einstellungen an dem GNSS-Modul über das Objekt vorgenommen.
|
|
|
|
|
|
|
|
Der NTRIPClient verbindet sich dann mit dem Caster und benutzt dazu ein HTTP-GET-Request. Sofern dieses vom Caster akzeptiert wurde, fängt dieser an die Korrektur, welche die Basissation pusht, an den NTRIPClient weiterzuleiten. Dieser wiederrum schickt die Daten weiter an das GNSS-Modul.
|
|
|
|
|
|
|
|
Dabei wird darauf geachtet ob die Verbindung zum Caster erhalten bleibt. Wenn diese abbricht kann entweder automatisch eine neue Verbindung zum Caster aufgebaut werden oder es wird auf einen externen Aufruf dafür gewartet.
|
|
|
|
|
|
|
|
Der aktuelle Status des Clients kann abgefragt werden und wird mit einem Status beantwortet der folgender Maßen aussieht:
|
|
|
|
|
|
|
|
\begin{minted}{c++}
|
|
|
|
|
|
|
|
enum NTRIPClientStates {
|
|
|
|
|
|
|
|
openConnection,
|
|
|
|
|
|
|
|
pushData,
|
|
|
|
|
|
|
|
closeConnection,
|
|
|
|
|
|
|
|
wait,
|
|
|
|
|
|
|
|
notAvailable
|
|
|
|
|
|
|
|
};
|
|
|
|
|
|
|
|
\end{minted}
|
|
|
|
|
|
|
|
Bei dem aktuell genutzten Caster ist es nicht notwendig die eigene aktuelle Position an diesen zu übermitteln. Wenn allerdings ein Caster von einem Anbieter verwendet wird, der einen großen Bereich abdeckt, muss die eigene Position übermittelt werden um die richtigen Daten zu erhalten. Dafür muss beim NTRIPClient lediglich die Variable für diese Funktion gesetzt werden.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\section{Bedienung}
|
|
|
|
|
|
|
|
Mit der Bedienoberfläche des Rovers können diverse Information über den Rover angezeigt werden, Einstellungen angepasst werden und die Hauptfunktionen genutzt werden.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{Benutzereingaben}
|
|
|
|
|
|
|
|
Die Benutzereingaben werden von der Fernbedienung über das ESPnow-Protokoll an den Rover gesendet. Dazu werden die einzelnen Tasten ausgelesen und in einem \mintinline{c++}|uint8_t| Integer abgespeichert. Dabei repräsentiert jedes einzelne Bit eine Taste. Die einzelnen Bits werden mit Bitoperationen gesetzt. Zusätzlich wird jeweils eine Achse des Joystick in einem weiteren \mintinline{c++}|uint8_t| Integer gespeichert. Als zusätzliche minimalistischste Überwachung Datentransmissionen wird bei jedem Sendevorgang ein letzter weitere \mintinline{c++}|uint8_t| Integer hochgezählt. Da die Eingaben alle 50 Millisekunden übertragen werden, läuft der letzte Wert ca alle 13 Sekunden über. Dies behindert die Aufgabe des Wertes nicht und wird deshalb vernachlässigt. Um die Daten strukturiert und wiederverwendbar zu übermitteln, werden diese in einem \mintinline{c++}|struct| verpackt.
|
|
|
|
|
|
|
|
\begin{minted}{c++}
|
|
|
|
|
|
|
|
struct ControlPadInputs {
|
|
|
|
|
|
|
|
uint8_t buttons;
|
|
|
|
|
|
|
|
uint8_t x;
|
|
|
|
|
|
|
|
uint8_t y;
|
|
|
|
|
|
|
|
uint8_t counter;
|
|
|
|
|
|
|
|
};
|
|
|
|
|
|
|
|
\end{minted}
|
|
|
|
|
|
|
|
Dieses \mintinline{c++}|struct| verbraucht nur 4 Byte Speicherplatz und lässt sich deshalb sehr effizient übermitteln. Auf dem Rover werden die Eingaben in einem Input-Objekt gespeichert. Dieses Input-Objekt wird vom Menü und anderen Komponenten verarbeitet, die Benutzereingaben erfordern.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Die Fernbedienung kann auch Daten Empfangen um diese auf dem verbauten Display anzuzeigen. Es gibt zwei Möglichkeiten. Bei der ersten müssen genau so viele Bytes empfangen werden wie in einer Zeile angezeigt werden können und ein zusätzliches Byte. Dabei gibt das erste Byte die Zeile an, auf welcher die Daten auf das Display geschrieben werden sollen und die restlichen sollen die Zeile füllen. Bei der zweiten Variante müssen genau so viele Bytes empfangen werden, wie das Display insgesamt Anzeigen kann. Diese werden dann der reihe nach auf das Display geschrieben.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Als zusätzliche Funktion verfügt die Fernbedienung über zwei LEDs die eine wird dazu genutzt um die Bereitschaft anzuzeigen und leuchtet in der Farbe grün. Ein zweite LED der Farbe rot leuchtet auf wenn keine Empfangsbestätigung vom Rover empfangen wird, um den Benutzer einen Signalabbruch zu signalisieren.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Ein häufiger Grund der zu einer fehlerhaften Kommunikation führt ist der ausgewählte Kanal auf dem die Daten gesendet werden. Das ESPnow-Protokoll nutzt die gleichen Frequenzen wie ein 2,4 GHz WiFi. Da der Rover neben der Verbindung zur Fernbedienung noch mit dem WLAN-Netzwerk verbunden sein muss um die Korrekturdaten zu erhalten und der im Rover verbaute ESP32 nur auf einem Kanal gleichzeitig arbeiten kann, müssen beide Protokolle den selben Kanal verwenden. Der Kanal wird in diesem Szenario dynamisch durch das vorhandene WLAN-Netzwerk vorgeben. Deshalb verfügt die Fernbedienung über ein kleines eigenes Menü. Dieses Menü lässt sich über eine Tastenkombination erreichen und kann unter anderem dazu genutzt werden den Kanal der Fernbedienung einzustellen.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{Menu}
|
|
|
|
|
|
|
|
\label{sec:Menu}
|
|
|
|
|
|
|
|
Das Menü ordnet und strukturiert alle für den Benutzer aufrufbaren Funktionen und stellt damit eine wichtige Hauptkomponente für die Interaktion mit dem Rover da. Es gibt die Klasse \mintinline{c++}|class Menu : public MenuControl|, jede dieser Instanzen kann mehrere Referenzen auf Instanzen der Klasse \mintinline{c++}|class MenuAction| halten. Diese Referenzen werden als einzelne Einträge im Menü dargestellt. Die Einträge im Menü können bei Aktivierung drei verschiedene Aktionen ausführen. Die erste wäre die Weiterleitung auf ein anderes beziehungsweise ein Untermenü. Die zweite Möglichkeit ruft eine übergebene Callback-Funktion auf. Und als letzte Möglichkeit kann eine Referenz auf eine Klasse übergeben werden, die von dem Interface \mintinline{c++}|class MenuActionWrapper| erbt. Das Interface verlangt eine, dass die Funktion \mintinline{c++}|void action()| implementiert wird. Diese wird dann aufgerufen. Um speziellere Funktionalitäten bereitstellen zu können, muss jede Klasse, die als Menü benutzt werden soll von dem Interface \mintinline{c++}|class MenuControl| erben. Dieses definiert die Grundfunktionalitäten, die jede Menüklasse beinhalten muss. Dazu gehören 6 Funktionen die die Eingabe annehmen.
|
|
|
|
|
|
|
|
\begin{minted}{c++}
|
|
|
|
|
|
|
|
virtual void down() {};
|
|
|
|
|
|
|
|
virtual void up() {};
|
|
|
|
|
|
|
|
virtual void right() {};
|
|
|
|
|
|
|
|
virtual void left() {};
|
|
|
|
|
|
|
|
virtual void yes() {};
|
|
|
|
|
|
|
|
virtual void no() {};
|
|
|
|
|
|
|
|
\end{minted}
|
|
|
|
|
|
|
|
Außerdem eine Funktion die die Ausgabe steuert und eine weitere optionale Funktion, mit welcher sich die Ausgabe nach gewissen Bedingungen automatisch aktualisiert. Folgende Funktionalitäten sind bereits durch das Interface implementiert, das Speichern der Ausgabegeräts und das Speichern des unter Umständen vorhandenen übergeordneten Menüs.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Mit diesen Mitteln lassen sich bereits Menüstrukturen implementieren. Die Endpunkt sind hingegen oft besondere Menüs. Zum einen wurde öfter auf das Interface \par\mintinline{c++}|class MenuInformationSites : public MenuControl| zurückgegriffen. Dieses dient dazu, verschiedene Informationen anzuzeigen, dafür basiert dieses Menü auf Seiten durch die gewechselt werden kann. Zum anderen fand die Klasse
|
|
|
|
|
|
|
|
\par\mintinline{c++}|class MenuIntInput : public MenuControl| Anwendung um dem Benutzer die Möglichkeit zu geben, Ganzzahlen einzugeben um Einstellungen tätigen zu können. Mit diesem Menü lassen sich mehrere Zahlen eingeben. Wenn Eingabe abgeschlossen wurde werden die Werte an ein zuvor übergebenes Objekt übergeben, welches vom Interface \mintinline{c++}|class MenuIntInputWrapper| geerbt haben muss.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Es gibt für jeden Fahrzeugmodus ein eigenes Menü, welches für den Modus spezifische Informationen anzeigt und Einstellungen bereithält. Hier sticht das Menü des TestModes ein bisschen heraus, weil dort auch unter anderem Einstellungen am PID-Regler verändert werden können. Im Hauptmenü findet sich ein Menü um Systeminformationen anzuzeigen und ein Menüeintrag mit dem sich ein Neustart auslösen lässt. Ein weiteres nennenswertes Menü ist das "GPS-Menü", in diesem werden viele Information von dem GNSS-Modul angezeigt. Unter anderem die Koordinaten und der Status der NTRIPClient Komponente. Letzteres lässt sich über dieser Menü auch aktivieren und deaktivieren.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Um die Routen zentral und Unabhängig von dem Rover zu speichern gibt es ein Menü in dem diese importiert und exportiert werden können. Dafür wird eine REST-API verwendet. Außerdem können die einzelnen Koordinaten der jeweils geladenen Route betrachtet werden.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\chapter{Bewertung}
|
|
|
|
|
|
|
|
Das Augenmerk dieses Kapitels wird darauf gerichtet sein, wie erfolgreich die Umsetzung des Projektes war. Dafür werden die zuvor aufgestellten Anforderungen in Kapitel \ref{cha:Anforderung} erneut betrachtet und dabei auf ihre Gegebenheit überprüft. Nachfolgend werden einige Test beschrieben, mit diesen wird überprüft, ob mehrere Anforderungen zugleich erfüllt sind und ob die benötigten Komponenten passend miteinander verbunden sind.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\section{Anforderungsüberprüfung}
|
|
|
|
|
|
|
|
\subsection{Motorsteuerung}
|
|
|
|
|
|
|
|
In dieser Betrachtung wird sowohl auf die relevante Hardware als auch auf die Software eingegangen.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Durch die Gegebenheiten der Hardware in diesem Fall der Verdrahtung, werden bereits einige der angesprochenen Risiken minimiert. Durch die eingebaute Sicherung von 16A sind zu gr0ße Ströme über längere Zeit nicht möglich, da der Motortreiber einen kurzfristigen Strom von bis zu $30A$ verträgt. \cite{Motortreiber} Von den Beschreibungen auf dem Akku ist abzulesen, dass dieser Ströme von $ 37 bis 50A$ bereitstellen kann. Damit kann dieser auch nicht durch die Motoren überlastet werden.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Auf der Softwareseite wurde die Komponente MotorControl entwickelt. (Kapitel \ref{sec:MotorControl}) Diese stellt die Einhaltung der geforderten Anfahrkurve sicher. Dazu sind in der Schnittstelle zu dieser Komponente nur Funktion zugänglich die Soll-Werte setzten. Alle Attribute und Methoden, die die Motoren direkt steuern sind dabei mit einer Ausnahme unzugänglich. Diese Ausnahme ist durch die Anforderung erforderlich, dass die Motoren ohne zeitliche Verzögerung abgeschaltet werden sollen können.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Die Leistungsbereiche in denen der Motor angesteuert wird sind einstellbar, allerdings nur im Quellcode. Daher wird diese Anforderung nur bedingt erfüllt.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{Geschwindigkeitssteuerung}
|
|
|
|
|
|
|
|
Zur Erfüllung dieser Anforderung sind die Komponenten MoveControl und Speedometer vonnöten. (siehe \ref{sec:MoveControl} und \ref{sec:Speedometer}) Mit diesen wurden je Seite eine Regelungsschleife umgesetzt unter Zuhilfenahme der PID-Bibliothek. Mit den in MoveControl errechneten Werten werden die Motoren dann angesteuert. Damit ist die Anforderung erfüllt, den Rover mit einer vorgegeben Geschwindigkeit bewegen zu können.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Allerdings wurde die Anforderung der Synchronisation der beiden Motoren nicht erfüllt, da die beiden Regelungsschleife unabhängig voneinander betrieben werden. Ein Versuch zum Verbinden der Regelungsschleifen schlug fehl, da die sich Anforderung als deutlich komplexer darstellte als angenommen. Ein Grund besteht darin, dass die Motoren selbst im unbelasteten Zustand mit gleicher Leistungszuführung deutlich unterschiedliche Drehzahlen erreichen. Daher ist ein Vergleich zwischen den beiden Motoren anhand der Leistungs-Outputs nicht durchführbar. Eine weitere Möglichkeit die gemessene Geschwindigkeit von der Speedometer Komponente zu verwenden, schlug ebenfalls fehl, da diese Komponente nicht schnell genug auf Änderungen reagiert und diese damit nicht agil genug für die Regelungsschleife ist. Ein weiter Grund besteht darin, dass in Kurvenfahrten unterschiedlich Zielgeschwindigkeiten angesetzt sind, in diesem Fall müssten die Motoren relativ zu einander synchronisiert werden, es wurde nicht geklärt ob sich diese Werte dann proportional zueinander verhalten müssten.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Beobachtungen haben ergeben, dass der Rover während der Nutzung durch das Fehlen dieser Verknüpfung nicht offensichtlich eingeschränkt wird.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{Energieversorgung}
|
|
|
|
|
|
|
|
Diese Anforderung muss durch die Hardware als auch durch die Software erfüllt werden. Der eingesetzte Akku ermöglicht den autonomen Betrieb des Rovers und kann außerdem einen ausreichend hohen Strom zur Verfügung stellen. Da dieser mit bis zu $50A$ angeben ist und das System aber mit $16A$ abgesichert ist, kann in jedem Szenario mit einer ausreichenden Stromversorgung gerechnet werden. Allerdings ist die Kapazität des Akkus in bestimmten Szenarios nicht ausreichend. Das liegt zum einen daran, dass bei einer vollständigen Ladung des Akkus, das Ladegerät lediglich knapp $70\%$ der Kapazität des Akku geladen hat. Zum anderen daran, dass nicht geklärt ist, welche Zeiträume mit einer Ladung überbrückt werden sollen können. Deshalb wird diese Anforderung als Teilweise erfüllt angesehen.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Mit der nächsten Anforderung soll ein Tiefentladen verhindert werden und dem Nutzer ein Einblick Ladezustand des Akkus gegeben werden. Dies wurde mit der Komponente Battery erreicht. (Kapitel ???) Die Komponente selbst stellt nur das Auslesen der Akkustand mithilfe des ADC und des Spannungsteilers bereit. Um zusätzlich noch die verlangte Abschaltung zu erreichen wird in \mintinline{c++}|void loop()| der main-Datei regelmäßig der Akkustand abgefragt, sollte dieser den Minimalwert für länger als einen kurzen Impuls unterschreiten, werden dir Motoren abgeschaltet und der ESP mit einer Endlosschleife eingefroren.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{Fahrsteuerung}
|
|
|
|
|
|
|
|
Die Anforderungen zur Steuerung des Rovers wurde durch die Komponenten ManualControl (Kapitel \ref{sec:ManualControl}) umgesetzt. Dabei wird durch die Achsen des Joysticks die Richtung angegeben und durch die Auslenkung die Geschwindigkeit.
|
|
|
|
|
|
|
|
Um die maximale Geschwindigkeit einstellen zu können muss das Menü mit aktiviert sein, in diesem lässt sich die maximale Geschwindigkeit dann temporären von default Wert ausgesehen erhöhen und verringern.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{Route eingeben}
|
|
|
|
|
|
|
|
Mit der Komponente CaptureRoute aus Kapitel \ref{sec:CaptureRoute} die als Betriebsmodi des Rovers fungiert wird das Interface geliefert um dem Nutzer das Speichern der einzelnen Punkte für die Route zu ermöglichen. Um einen Punkt zu speichern ist eine Aktion vom Benutzer notwendig. Dieser Modus basiert wie gefordert auf der Fahrsteuerung und erweitert diese lediglich.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Zur Sicherung der Daten wird auf die Komponente \ref{sec:Navigation} Navigation zurückgegriffen, diese nutzt wiederrum die Komponente Route um die Daten zu speichern. Führt aber selbstständig die Überprüfung der Daten auf ihre Verwendbarkeit durch. Bei mangelhaften Daten werden die Koordinaten wie gefordert nicht gespeichert
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Allerdings wird der Nutzer nur in einem Menüpunkt über den Erfolg oder Misserfolg der letzten Operation Informiert. Da das System nicht aktiv über einen Fehlschlag informiert, wird die Anforderung der Benutzerinformation nicht als erfüllt betrachtet, weil die passive Information in einem Menü die dauernde Aufmerksamkeit des Benutzers fordern um wahrgenommen zu werden.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Um den Wunsch einer externen Datenquelle nachzukommen wurde eine API entwickelt, welche ein zentrale externe Speicherung der Routen ermöglicht. Um diese zu Nutzen muss der richtige Menüpunkt gewählt werden und dort kann dann eine Route über eine ID gespeichert oder geladen werden.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{Navigation}
|
|
|
|
|
|
|
|
Da diese Anforderung eine Kernfunktionalität beschreibt, sind viele Komponenten für die Erfüllung nötig. Damit entsteht die Abhängigkeit, dass die Anforderungen zur Genauigkeit der Positionsbestimmung während des Betriebs erfüllt ist.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Darüber hinaus wird die Komponente \ref{sec:Navigation} Navigation als anweisende Einheit benötigt und der Modus \ref{sec:Autopilot} Autopilot als ausführende Einheit, wenn der Autopilot deaktiviert ist steht anstelle diesem der Benutzer unter Verwendung der normalen Fahrsteuerung.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Durch den wechsel in den Autopilotenmodus wird automatisch, sofern vorhanden, die Route gestartet. Die Anweisungen zum navigieren sind jederzeit über das Menü abrufbar und stehen damit dem Benutzer zur Verfügung.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Die eigentliche Funktion des Navigieren wird gesondert in dem Test Kapitel \ref{sec:TestNavigation} und \ref{sec:TestAutopilot} betrachtet.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Der Autopilot kann zu jeder Zeit abgeschaltet werden sofern die Fernbedienung in Reichweite zum Rover befindet. Dafür muss die Aktionstaste betätigt werden. Dieses Konzept erfüllt die Anforderung auf Grund der Einschränkung nicht. Da das Einsatzgebiet einen autonomen Betrieb vorsieht,ist es in diesem Szenario sehr unwahrscheinlicher, dass sich zu jeder Zeit eine Person mit der Fernbedienung in Empfangsnähe befindet.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Die Aktivierung des Autopiloten kann mit dem Aktionsbutton ausgeführt werden, unter der Bedingung dass sich der Rover in der Nähe des Startpunktes befindet und die Positionsbestimmung ausreichend genau ist.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Die Anforderungen aus diesem Bereich sind zum Teil abhängig von äußeren Umständen und werden deshalb nur Teilweise erfüllt.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{Genauigkeit der Positionsbestimmung}
|
|
|
|
|
|
|
|
Mithilfe der NTRIPClient Komponente aus Kapitel \ref{NTRIPClient} ist das verbaute GNSS Modul in der Lage eine Genauigkeiten von unter 5cm zu erreichen. Das würde die Anforderung bei weitem erfüllen. Es hat sich jedoch herausgestellt, dass die WiFi Verbindung eine Schwachstelle ist und hin und wieder Verbindungsabbrüche zustande kommen. Durch diese und die daraus resultierenden fehlenden Korrekturdaten, entstehen zu große Ungenauigkeiten. Wenn das Modul in Bewegung ist verschlechtert sich die Genauigkeit ebenfalls, aber in einem Maße in dem die Anforderung trotzdem erfüllt bleibt.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Mit der \ref{sec:Point} Point Komponente werden neben die Koordinaten auch die aktuelle Genauigkeit gespeichert. RouteCapture und Autopilot nutzen die aktuelle Genauigkeit um die zu überprüfen, ob die Operationen zum aktuellen Zeitpunkt valide sind. Damit sind Sicherheitsanforderungen ebenfalls erfüllt.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Der NTRIPClient kann sich bei verschiedenen Caster anmelden. Jedoch bricht die Verbindung zu Caster welche die aktuelle Position benötigen regelmäßig ab. Andere Verbindungsarten wie ??? Radio sind derzeit nicht möglich. Durch die Einschränkung bei des Auswahl des Caster und der Mangel an anderen Verbindungsmöglichkeiten wird diese Anforderung als nicht erfüllt betrachtet.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{Benutzerinterface}
|
|
|
|
|
|
|
|
Das benutzerinterface zeichnet sich besonders durch das entwickelte Menü aus, welches in Kapitel \ref{sec:Menu} beschrieben ist. Es wurde die angeforderte Struktur umgesetzt. In dieser lassen sich dann auch in den Unterschiedlichen Menüs Informationen über den Betriebszustand ablesen.
|
|
|
|
|
|
|
|
\par
|
|
|
|
|
|
|
|
Das Menü lässt sich intuitiv über die Fernbedienung des Projektes nutzen. Ist aber nicht explizit auf diese angewiesen. Es ist lediglich eine Eingabemöglichkeit erforderlich, mit welcher sich ein Steuerkreuz sowie eine Taste zum Bestätigen und Ablehnen abbilden lässt.
|
|
|
|
|
|
|
|
Damit sind alle Anforderungen die an das Benutzerinterface gestellt worden erfüllt.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\section{Tests}
|
|
|
|
|
|
|
|
\subsection{Steuerung}
|
|
|
|
|
|
|
|
\subsection{Navigation}
|
|
|
|
|
|
|
|
\label{sec:TestNavigation}
|
|
|
|
|
|
|
|
Punkte und Pfeile auf Boden aufzeichnen soll und ist Richtung
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{Autopilot}
|
|
|
|
|
|
|
|
Autokorrektur, Geradeausfahrt, Kurven, Geschwindigkiet.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\label{sec:TestAutopilot}
|
|
|
|
|
|
|
|
\chapter{Zusammenfassung}
|
|
|
|
|
|
|
|
\section{Fazit}
|
|
|
|
|
|
|
|
\section{Ausblick}
|
|
|
|
|
|
|
|
Es wäre durchaus sinnvoll den Rover mit weiteren Sensoren auszustatten, damit dieser auf gelegentlich auftretende Unregelmäßigkeiten der Route reagieren kann, zum Beispiel ausweichen eines Steins. Eine direkte Kollisionserkennung würde zu einer erheblichen Risikominimierung führen. Da so Schäden am Rover oder an der Umwelt des Rovers vermieden werden können.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Feste Station mit Radio transceiver und receiver am Rover damit kein WiFi mehr.
|
|
|
|
|
|
|
|
oder extra controller zum pushen und anderer Anschluss am modul
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Nicht erfüllte Anforderungen
|
|
|
|
|
|
|
|
Umbau auf Ros
|
|
|
|
|
|
|
|
Mehr Sensoren
|
|
|
|
|
|
|
|
Mehr Feedback z.B. Beeper Lampen
|
|
|
|
|
|
|
|
Mehr Display
|
|
|
|
|
|
|
|
- 7 segment auf Rover und Fernbedienung letzten Fehler anzeigen wie bios boot up
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Neu todo:
|
|
|
|
|
|
|
|
jetzt auch calc azi
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Keine Steuerung von der Basisstation, Projekt verbinden mit dem von Fabian. (autonomer Hintergrund)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\printbibliography[
|
|
|
|
|
|
|
|
heading=bibintoc,
|
|
|
|
|
|
|
|
title={Literaturverzeichnis}
|
|
|
|
|
|
|
|
]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\part{Anhang}
|
|
|
|
|
|
|
|
\renewcommand{\thechapter}{\Alph{chapter}}
|
|
|
|
|
|
|
|
% \setcounter{chapter}{0}
|
|
|
|
|
|
|
|
\chapter{Schaltplan Hauptplatine}
|
|
|
|
|
|
|
|
\begin{figure}
|
|
|
|
|
|
|
|
\vspace{-4cm}
|
|
|
|
|
|
|
|
\hspace{-2.2cm}
|
|
|
|
|
|
|
|
\label{fig:hauptplatine}
|
|
|
|
|
|
|
|
% \centering
|
|
|
|
|
|
|
|
% \includesvg[inkscapelatex=false, angle=-90, width=\linewidth]{includes/Hauptplatine}
|
|
|
|
|
|
|
|
\includesvg[inkscapelatex=false, angle=-90, width=26cm]{includes/Hauptplatine}
|
|
|
|
|
|
|
|
\caption{Schaltplan der Hauptplatine}
|
|
|
|
|
|
|
|
\end{figure}
|
|
|
|
|
|
|
|
\chapter{Test 2}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\chapter{Installation Bodenstation}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\part{Dokumentation}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\end{document}
|
|
|
|
|
