~~old and busted:https://yopad.eu/p/praktikum2020~~
new hotness: here and there soo aw such wow

Okay hier ist ein neues Dokument Das ~~30 Tage~~ für immer lang gültig ist, damit wir vlt ein paar Sachen schneller als mit $v_{git}$ machen können

emojis zum kopieren: ✔✔✔✔✔✔

## Namen von Quellen

%% Christopher Hahn, Sebastian Kind 2020

- schmitt_extendingGio = Bachelorarbeit Extending Giovanni Controller with Formation Control functionality},
- gio_2004 = Switching linear path following for bounded curvature car-like vehicles
- gio_1999 = Kinematic time-invariant control of a {2D} nonholonomic vehicle
- nuchti title = ABOUT THE CONTROL OF HIGH SPEED MOBILE INDOOR ROBOTS
- ros = https://www.ros.org/
- sick_datenblatt,

## Meta/soos/all

ANMERKUNG ZU Aufbau: "wiederverwendbaren Softwaremodulen auf Roboter[hinzufügen: n] erlaubt.""

und Fehlertolerantes klein schreiben ✔
und bei GMapping Menschlichen

>>> wollen wir alle Absätze hier under einer jeweil workintitle überschrift packen <<
>>> klingt gut ✔ ✔✔✔✔✔✔

### Abstract

\begin{abstract}
Die Autoren beschäftigen sich in dieser Arbeit mit der Implementierung
eines von Giovanni Indiveri und Canudas de Wit et al. entwickelten,
nichtlinearen Reglers für unbemannte Fahrzeuge. Zudem vergleichen sie
zwei Systeme, die dem Regler zur Bestimmung der Pose des Fahrzeugs
dienen. Die Adaptive Monte Carlo Localization (AMCL) liefert genauere
Messwerte als die Odometrie der Räder und ermöglicht somit eine
bessere Pfadverfolgung. Die Durchführung erfolgt im Rahmen des
Hardwarepraktikums 2020 an der Julius-Maximilians-Universität
Würzburg.
\end{abstract}

## Einleitung

\cite{gio_1999}
\cite{gio_2004}

Autonome Vehikel haben in den letzten Jahren sowohl für die Industrie
als auch für den öffentlichen Raum an Bedeutung gewonnen. Somit ist es
sinnvoll, verschiedene Pfadverfolgungsansätze zu untersuchen und zu
vergleichen. Im Folgenden führen die Autoren einen solchen Vergleich
zwischen Odometrie und der Adaptive Monte Carlo Localization (AMCL)
durch. Der Einsatz von AMCL erfordert zusätzlich eine Kartierung des
zu befahrenden Gebiets über GMapping. Für das Hardwarepraktikum
verwenden sie einen Roboter des Typs Volksbot und das Framework Robot
Operating System. Zudem stellen sie einen nichtlinearen Regler zur
Pfadverfolgung vor, dessen Verhalten die Qualität der
Lokalisierungsverfahren aufzeigt.

## Aufbau

Als verwendetes Vehikel dient ein vom Frauenhofer Institut
entwickelter Volksbot-Roboter. Er verfügt vorne über zwei unabhängig
voneinander ansteuerbare aktive Räder und je nach Modell ein oder zwei
Stützräder hinten. Eine inkrementelle Integration der
Geschwindigkeiten der Vorderräder ermöglicht die Lagebestimmung
mittels Odometrie. Zusätzlich ist ein Sick LMS100 Laserscanner
verbaut, der in einem horizontalen Winkel von 270° Abstände
misst.\cite{sick_datenblatt} Er ist über einen Ethernet-Hub mit einem
Laptop verbunden, der über einen USB-Hub auch mit den Rädern und dem
USB-Dongle eines zur manuellen Steuerung verwendeten kabellosen
Gamepads kommuniziert.


-- Hier fehlt ein Bild LaTeX bloat ausgelassen --
-- Anmerkung: können wir vielleicht aus deinem Video rauscutten wenn wir sonst keins haben --

Für den Softwarestack des fahrenden Vehikels wird auf ROS
(\textit{robot operating system}) \cite{ros} zurückgegriffen. ROS ist
eine etablierte Kommunikationsmiddleware für den Einsatz von Robotern,
die verschiedene Dienste abstrahiert und den Einsatz von
wiederverwendbaren Softwaremodulen auf Robotern
erlaubt. ROS-\textit{Packages} lassen sich über ein Serviceinterface
starten und bieten über verschieder ROS-APIs Dienste an. Somit lassen
sich über Treiber für Hardwarekomponenten (Human Interface Devices,
Sensoren, Aktuatoren) und Algorithmen (Datenprozessierung, Logging,
softwareimplementierte Regelsysteme) Problemlösungen kombinieren, die
für den Betrieb von Autonomen Systemen notwendig sind. ROS ist von
Beginn an als fehlertolerantes System konzipiert und kapselt alle
Dienste in unabhängige Prozesse auf Betriebssystemebene. ROS-Dienste
müssen folglich auf Interprocess Commication des Hostsystems
zurückgreifen. In bisherigen Releases ist ROS seitens der Hersteller
offiziell im Userland der Linuxdistribution Ubuntu
verfügbar. Workstation-Grade Computer, das Prozesscheduling des Linux
Kernels, die Reaktionszeit von Blockbasierte USB-Treibern und
TCP/IP-Stack setzten die zeitlichen Grenzen in denen ROS-basierte
Robotersysteme arbeiten können.

Auf dem Laptop sind Ubuntu 18.04 LTS und ROS Melodic Morenia
installiert. Dies entspricht zu diesem Zeitpunkt zwar nicht den
aktuellen Versionen, allerdings ist so die Kompatibilität mit den für
das Praktikum vorgegebenen ROS-Packages gewährleistet. Unter
den gegebenen Daten befinden sich auch Beispielpfade, die der Roboter
später abfahren soll.

\section{Odometrie}

## Odometrie

% science error you can't use sourceforge. kack seite
% [http://rossum.sourceforge.net/papers/DiffSteer/DiffSteer.html#d6]

Die Odometrie ist ein Ansatz für die Abschätzung der Pose des Roboters
ohne externe Informationsquellen. Der Roboter misst die Anzahl der
Radumdrehungen in kleinen Zeitabständen und kann so mithilfe des
Radumfangs eine Änderung der Pose berechnen und auf den letzten
bekannten Zustand aufaddieren.
Dies ist einfach zu implementieren und
hat den Vorteil, dass anders als bei AMCL die Umgebung nicht bekannt
sein muss (s. dazu 3.2 GMapping [link zum Kapitel]). Allerdings hat die Odometrie den
Nachteil, dass sich Fehler mit der Zeit aufsummieren. Wenn etwa der
Raddurchmesser fehlerhaft gemessen wurde oder die Räder beim Fahren
Schlupf haben, sind die kleinschrittigen Berechnungen der
Positionsänderung ebenfalls fehlerbehaftet, was für steigende
Ungenauigkeit der Position sorgt. Gemindert werden kann dieser Effekt,
indem man einen rutschfesten Untergrund wählt und langsam fährt, um
das Rutschen der Räder zu verringern.

## AMCL
[http://robots.stanford.edu/papers/fox.aaai99.pdf]

Die Adaptive Monte Carlo Localization (AMCL) ist die zweite
untersuchte Methode zur Abschätzung der Pose. Anders als bei der
Odometrie muss die Umgebung hier bekannt sein. Der Algorithmus
vergleicht die vorher durch GMapping aufgenommene Karte mit den Daten
des Laserscanners und berechnet daraus eine
Wahrscheinlichkeitsverteilung für die Pose des Roboters. Anfangs ist
diese Schätzung noch ungenau; wenn sich der Roboter jedoch bewegt und
die Anzahl der Messungen zunimmt, können zunehmend mögliche
Ausrichtungen ausgeschlossen werden und die Verteilung konvergiert auf
die echte Pose. Das ist ein offensichtlicher Vorteil von AMCL
gegenüber der Odometrie - anders als bei dieser steigt die Genauigkeit
der Schätzung mit der Zeit statt zu sinken. Dafür benötigt AMCL
bereits im Vorfeld Informationen zur Umgebung des Roboters; eine Karte
kann aber womöglich nicht immer angefertigt werden. Diese kann außerdem auch Fehler
enthalten. Der Einsatz von AMCL ist also komplizierter, da eine weitere
Abhängikeit besteht.

## GMapping
% [http://wiki.ros.org/gmapping] todo in bibtex eintragen

Bevor AMCL zur Positionsbestimmung eingesetzt werden kann, muss das zu
befahrende Gebiet - in diesem Fall ist es das Untergeschoss des
Informatikgebäudes der Universität Würzburg - kartiert werden. Dies
geschieht mithilfe des "gmapping"-Packages in ROS. Es handelt sich
dabei um einen Wrapper für OpenSlams Gmapping welches durch die
Kombination von Odometrie- und Laserscandaten einen Lösungsansatz für
das SLAM-Problem (Simultaneous Localization And Mapping; Deutsch:
Gleichzeitige Positionsbestimmung und Kartierung) bietet. Der
Algorithmus verwendet Abstandsmessdaten des Sick-Laserscanners und die
Positionsdaten der Odometrie, um während einer durch den Joystick
gesteuerten Fahrt eine zweidimensionale Karte der Umgebung zu
erstellen.

% [Abbildung Karte]
% Foto von Karte hier einfügen


\begin{figure}[htbp]
%\includegraphics[width=\textwidth,height=\textheight,keepaspectration=true]{images/keller_Lars.png}
\includegraphics[width=\textwidth]{images/keller_Lars.png}

\caption{Keller des Informatikgebäude. Kartiert mit
GMapping. Abgesehen von Klaren Wänden und Hindernissen, findet sich
auch viel Rauschen in der Darstellung: Türen hinterlassen unkartierte
Räume, Fenster erschwereren die Entfernungsmessung. Besonders
interessant sind die Fehlmessungen an den Heizkörpern am
Seiteneingang des Informatikgebäudes zwischen Zuse- und
Turinghörsal.
}
\label{keller_Lars}
\end{figure}

Abbildung \ref{keller_Lars} zeigt das kartierte Hanggeschoss des
Informatikgebäudes. Die Umrisse der Wände sind sofort erkennbar; das
ermöglicht es menschlichen Operatoren einfach die Daten zu überprüfen, die
dem Roboter zur Orientierung dienen. Schwarze Linien stellen Wände und
andere Hindernisse dar; der hellgraue Bereich ist frei befahrbar,
dunkelgraue Bereiche sind hingegen unkartiert. Während die Form des
Gebäudes klar definiert ist, erkennt man auf den ersten Blick
auch offensichtliche Fehler. Die vom Gebäude strahlenförmig
verlaufenden hellgrauen Linien sind auf Fensterscheiben oder andere
opake oder durchsichtige Objekte zurückzuführen, die Fehler in der
Lasermessung verursachen. Das Ergebnis lässt aber trotz dieser
kleineren Makel ohne Probleme für die Lokalisierung mittels AMCL
verwenden.

## Giovanni Controller
[referenz zum paper]

Für die Pfadverfolgung kommt eine Implementation des von Giovanni Indiveris entwickelten Reglers für statische Umgebungen zum Einsatz. Er beruht auf dem Steuergesetz von de Wit et al. und berücksichtigt die maximale Krümmung des abgefahrenen Pfades bei einer konstanten Geschwindigkeit. Die Modellierung erfolgt nach Abbildung [x].

--Bild von diesem dämlichen Modell mit Roboter und Pfad und Linien und Buchstaben x und y sind unsere Koordinaten--

Der Regler soll auf ein virtuelles Ziel konvergieren, welches sich auf dem Referenzpfad bewegt. Der Pfad ist durch s parametrisiert und hat eine Krümmung $\kappa (s)$ Auf dem Pfad befindet sich eine orthogonale Projektion $p$ des Roboters, der sich im Abstand l davon befindet. Er hat eine Translationsgeschwindigkeit u und eine Winkelgeschwindigkeit $\omega$ und ist im Winkel $\theta$ gegenüber der x-Achse ausgerichtet. $\theta_d$ ist die Ausrichtung des Pfades zur x-Achse. Die Differenz beträgt $\tilde{\theta} = \theta - \theta_d$. Nach dem Steuergesetz von de Wit ergibt sich für die Winkelgeschwindigkeit:

\begin{equation}
\omega = \frac{u \cdot \kappa (s) \cos \tilde{\theta} }{1 - l \cdot \kappa (s) } - h u l
\frac{\sin \tilde{\theta}}{\tilde{\theta}} - \gamma \tilde{\theta} : h, \gamma > 0 \tag{1}
\end{equation}

Dieses Regelgesetz garantiert bei einer Geschwindigkeit $u \neq 0$ die asymptotische Konvergenz von $\gamma$ und $l$ zu 0, die Position und Ausrichtung des Roboters entspricht dann also der des Pfades. Der rechte Teil des Terms ist für das Erreichen des Pfades, der linke für dessen Verfolgung zuständig.
Die Kurve wird auf lineare Teilstücke reduziert, in denen die Krümmung stets $\kappa (s) = 0$ beträgt. Daher vereinfacht sich obiger
Ausdruck zu:

\begin{equation}
\omega = -h u l \frac {\sin \tilde{\theta}}{\tilde{\theta}} - \gamma \cdot \tilde{\theta} : h, \gamma > 0 \tag{2}
\end{equation}

Transformiert man die Gleichung, kann die x-Achse als Bezugsachse verwendet werden:

\begin{equation}
\omega = -h u y \frac {\sin \theta}{\theta} - \gamma \cdot \theta : h, \gamma > 0 \tag{3}
\end{equation}

Die Verstärkungsfaktoren $h$ und $\gamma$ sollten dynamisch nach dem folgenden Zusammenhang gewählt werden:

\begin{equation}
\gamma = 2 \cdot \alpha u \sqrt{h} : \alpha > 1 \tag{4}
\end{equation}

Der Skalierungsfaktor $\alpha$ ist für dieses Praktikum auf $1,2$ festgelegt.
Die maximale Krümmung $\kappa_r$ des Roboterpfades ergibt sich aus dem Quotienten der Winkel- und Translationsgeschwindigkeit. Setzt man dort Gleichung $(3)$ und $(4)$ ein, folgt:

\begin{equation}
\kappa_r = \frac {\omega}{u} = -hy\frac {\sin \theta}{\theta} - 2\alpha\theta\sqrt{h} \tag{5}
\end{equation}

Parameter $h$ berechnet sich mit einer der folgenden Formeln:

\begin{equation}
h = \frac {\kappa_{max}^2}{\theta_0^2 (1+2\alpha)^2} \textrm{ für } y_0 = 0, \theta_0 \neq 0 \tag{6}
\end{equation}

\begin{equation}
h = \frac {1}{2}\left(-\frac{\theta_0^2}{y_0^2} + \sqrt{\frac{\theta_0^4}{y_0^4} + \frac{4\kappa_{max}^2}{y_0^2(1+2\alpha)^2}}\right) \textrm{ für } y_0 \neq 0, \forall \theta_0 \tag{7}
\end{equation}

Sind sowohl $y_0$ als auch $\theta_0$ nahe $0$, d.h. liegen beide Werte unter einem maximalen Mess-/Schätzungsfehler $\delta_{\theta}$ bzw. $\delta_y$, so sollte folgende Berechnung verwendet werden:

\begin{equation}
h = \frac {1}{2}\left(-\frac{\delta_{\theta}^2}{\delta_y^2} + \sqrt{\frac{\delta_{\theta}^4}{\delta_y^4} + \frac{4\kappa_{max}^2}{\delta_y^2(1+2\alpha)^2}}\right) \tag{8}
\end{equation}

Die so berechneten Faktoren $h$ und $\gamma$ fließen nun in die Berechnung der Winkelgeschwindigkeit $\omega$ nach $(3)$ ein.
Schließlich müssen noch die Geschwindigkeiten der einzelnen Räder ermittelt werden, um die gewünschte Winkel- und Translationsgeschwindigkeit zu erreichen:

\begin{equation}
v_{links} = u - \frac{1}{2} \cdot \omega b \tag{9}
\end{equation}

und

\begin{equation}
v_{rechts} = u + \frac{1}{2} \cdot \omega b, \tag{10}
\end{equation}

wobei $b$ die Achsenlänge des Fahrzeugs ist.

## Simulator

Ein Simulator erlaubt es das Verhalten des Reglers zu
überprüfen. Hierzu wurde in C++ ein ROS-Package erstellt, welcher eine
Liste an Koordinaten als Eingabe akzeptiert. Anschließend ermittelt
das Programm einen Pfad und übergibt ihn an den Regler. Dieser berechnet dann wie in [Referenz zum vorherigen Kapitel] die Radgschwindigkeiten. Statt diese an den Regler der Roboterräder weiterzugeben, ruft das Programm die Simulationsfunktion auf. Sie funktioniert analog zum Prinzip der Odometrie; Aus den Radgeschwindigkeiten berechnen sich Zustandsänderungen der Pose, die in jeder Iteration mit dem vorherigen Zustand verrechnet werden. Der Regler verwendet dann in der nächsten Iteration die neuen Zustandsdaten. Sobald die Simulation abgeschlossen ist, plottet das Programm die Ergebnisse zur Übersicht. Der simulierte Pfad kann dann mit einem Plot der Eingabekoordinaten verglichen werden.

[Abbildung Plot simuliertes Ergebnis über Inputpfad?]

## Durchführung

Hier zieht sich Sebbi dann was aus der Nase :) + plot, die man halt noch finden muss :D

## Zusammenfassung und Ausblick

Während die Odometrie zwar brauchbare Ergebnisse liefert, ist sie was die Genauigkeit angeht klar AMCL unterlegen. Unter günstigen Umständen, d.h. bei langsamen Geschwindigkeiten, einem ebenen und rutschfestem Boden, präzise eingestellten Raddurchmessern und kurzen Strecken (sodass sich die Fehler über einen geringeren Zeitraum fortpflanzen) ist sie aber als sinnvolle Alternative zu AMCL denkbar, da die Umgebung nicht kartiert werden muss. Das spart Zeit und Aufwand und beseitigt die Notwendigkeit eines Laserscanners oder ähnlicher Sensoren.
Die Pfadfindung mit AMCL ist hingegen genauer und weniger fehleranfällig. Zudem kann sie eigenständig die Startposition im Raum bestimmen und die Fahrt anpassen, wenn sie durch äußere Umstände vom Pfad abgebracht wird - etwa wenn das Gerät angehoben und versetzt wird. Die Odometrie hat als Datenquelle nur die Räder und kann solche Fehler nicht erkennen.
Der Giovanni Controller verfolgt zuverlässig vorgegebene Pfade, zeigt allerdings Schwächen auf, wenn diese scharfe Kurven enthalten. Das liegt daran, dass er nicht die Möglichkeit bietet, sich um die eigene Achse zu drehen, da die Geschwindigkeit des Roboters stets konstant bleiben soll. Soll ein Fahrzeug also Ecken oder enge Kurven fahren, liegt die Nutzung eines alternativen Reglers oder eines Fahrzeuges mit einer kürzeren Achsenlänge nahe.