MasterarbeitLaTeX/tex/5_Evaluation_und_Diskussion.tex

\chapter{Evaluation und Diskussion}

\section{Auswahl einer geeigneten Umgebung}
Die Auswahl einer geeigneten Umgebung für die gewünschte Simulation erfolgte in mehreren Auswahlschritten.
Hierfür wurden mehrere Komponenten einzeln verglichen und ausgewählt.
Folgende Komponenten wurden für die Umgebung ausgewählt:
\begin{itemize}
 \item ROS2 als Dienstumgebung
 \item Gazebo Ignition als Simulationssoftware
 \item BehaviorTree.CPP als Beschreibungssprache
\end{itemize}

Alle Komponenten können miteinander kommunizieren, was den Aufbau einer Simulationsumgebung erlaubt.

\section{Nutzung der Virtualisierungsumgebung}
Die auf Docker basierende Virtualisierungsumgebung stellt eine vollständige ROS2-Installation dar.
In dieser Umgebung sind alle für die Arbeit benötigten Pakete enthalten.
Der Start der Umgebung erfolgt über das mitgelieferte \code{start.sh}-Shellskript.
Dieses Skript wird ohne Parameter ausgeführt.

Falls die Umgebung noch nicht genutzt wurde, wird eine neue Containervorlage erstellt.
Dieser Prozess kann, je nach Internetverbindung des ausführenden Rechners, mehrere Minuten in Anspruch nehmen.
Der Start der Umgebung wird mit der Ausgabe \code{ros-ros-1  | Ready to connect.} abgeschlossen, die auch in Abbildung \ref{console-docker-started} sichtbar ist.
Während der Nutzung der Umgebung muss das Terminal weiter geöffnet bleiben.
Nach dem Senden eines Terminiersignals durch das Schließen des Terminals oder die Tastenkombination \code{Ctrl+C} wird die Containerumgebung beendet.

\begin{figure}
\includegraphics[width=\textwidth]{img/MA-Docker-Started}
\centering
\caption{Konsole mit ausgeführter Virtualisierungsumgebung}
\label{console-docker-started}
\end{figure}

Die Verbindung in die ROS-Umgebung erfolgt über SSH in einer separaten Konsole.
In der so aufgebauten Session kann die Hardwarebeschleunigung des Hostsystems automatisch genutzt werden.
Dies wurde in Abbildung \ref{console-docker-passthrough} durch die Ausführung von \code{glxgears}, einer OpenGL-Anwendung zum Testen der Grafikpipeline, demonstriert.

Das entworfene Containersystem ist mit der bereitgestellten Funktionalität eine Grundlage für die weitere Implementation.

\begin{figure}
\includegraphics[width=\textwidth]{img/MA-Docker-Passthrough}
\centering
\caption{Konsole in der virtuellen Umgebung mit Grafiktests}
\label{console-docker-passthrough}
\end{figure}

\section{Starten der Simulation eines Szenarios}
Das Starten der Simulation erfolgt über ein Skript innerhalb des \code{ign_world}-Pakets.
Dieses Skript wird durch den Befehl \code{ros2 launch ign_world gazebo_controller_launch.py} ausgeführt.
In diesem Skript werden alle für die Simulation benötigten ROS2-Nodes gestartet und konfiguriert.

Durch die Verwendung des optionalen Parameters \code{scene} kann das gewünschte Szenario ausgewählt werden.
Dieser muss in folgendem Format verwendet werden:
\code{ros2 launch ign_world gazebo_controller_launch.py scene:=[Coex|Coop|Colab]}
Als Standard wird die Option \code{Coex} genutzt, falls der \code{scene}-Parameter nicht spezifiziert wird.

Nach dem Start der Simulationsumgebung ist der Raum vollständig geladen und einsatzbereit (Abbildung \ref{sim-room}).
Der Roboter befindet sich nach dem Start in der Ausgangsposition, siehe Abbildung \ref{robot-still}.

\begin{figure}
\begin{minipage}{.45\textwidth}
\includegraphics[width=\textwidth]{img/MA-Sim-Room}
\centering
\caption{Raum in der Simulation}
\label{sim-room}
\end{minipage}
\hspace{.09\textwidth}
\begin{minipage}{.45\textwidth}
\includegraphics[width=\textwidth]{img/MA-Sim-Robot-Still}
\centering
\caption{Roboterarm in Ausagangslage}
\label{robot-still}
\end{minipage}
\end{figure}

\section{Erstellung der benötigten Modelle}

\section{Steuerung des Menschen}

Durch den Start der Simulation wird selbstständig das erstellte ActorPlugin geladen.
Der Start des für diese Arbeit implementierten ActorServers erfolgt zeitgleich, um die Anbindung an ROS zu gewährleisten.
Beide Anwendungen zusammen erlauben das Ausführen von Bewegungen und Animationen zur Laufzeit in der Simulation.

Alle für die Simulation des Menschen erstellten Animationen werden automatisch geladen, sobald diese durch das Plugin verwendet werden.
Dies kann durch die erstellten BehaviorTree-Nodes erfolgen, aber auch durch das Verwenden von Terminalbefehlen zu Testzwecken.


\section{Definition von Verhalten mit einer Beschreibungssprache}

Die Definition von verschiedenen Verhaltensweisen über eine Beschreibungssprache wurde durch die Erstellung neuer Nodes erreicht.
Für die Bewegung und Animation des Menschen sind die Nodes ActorMovement und ActorAnimation verfügbar.
Die Steuerung des Roboters erfolgt durch die RobotMove- und SetRobotVelocity-Node.
Beide Nodes zur Kontrolle des Roboters starten eine neue Bewegung mit den neuen Parametern.
Im Falle einer laufenden Bewegung wird diese gestoppt und mit den neuen Parametern gestartet.

Um Bewegungen in Zonen zu ermöglichen, kann die GenerateXYPose-Node zufällige Positionen in einer Zone generieren.
Die InAreaTest-Node erlaubt eine Auskunft über die Position von Objekten.
Eine Redefinition von bestehenden Parametern der generierten Pose ist über die OffsetPose-Node möglich.

Eine Wiederaufnahme von unvollständigen Aktionen ist durch die implementierte Interruptable\-Sequence-Node möglich.

Die Entscheidung über die Ausführung von einer aus mehreren Aktionen ist durch die WeightedRandom-Node realisiert.
Um Fehler simulieren zu können, ist der Abbruch von Aktionen nötig.
Dies wird durch die RandomFailure-Node erreicht.

Eine Kombination aus diesen neu implementieren und den bereits verfügbaren Nodes kann alle benötigten Verhalten darstellen.

\section{Umsetzung der Szenarien}

Alle beschriebenen Szenarien sind als Behavior Trees umgesetzt, welche nach dem Start einer Simulation ausgeführt werden.

\subsubsection{Koexistenzszenario}

Im Koexistenzszenario interagieren Roboter und Mensch nur im Ausnahmefall.
Der Roboter simuliert einen Entladevorgang, bei welchem Objekte vom linken Tisch auf den rechten Tisch bewegt werden.
Die für diesen Zweck implementierten Bewegungsnodes werden in späteren Szenarien weiter verwendet.
Um den Menschen nicht zu gefährden, wird die Verfahrgeschwindigkeit automatisch and die Aufenthaltszone des Menschen angepasst.

Der Arbeitsvorgang des Menschen besteht aus dem Arbeiten an einer Werkbank und dem Verbringen von Material in das Regal.
In diesem Szenario begibt sich der Mensch nur mit einer Wahrscheinlichkeit von 5\% nach jedem Arbeitsvorgang zum Roboter.

\begin{figure}
\begin{minipage}{.45\textwidth}
\includegraphics[width=\textwidth]{img/MA-Sim-Robot-Move}
\centering
\caption{Roboter in Bewegung}
\label{coex-move}
\end{minipage}
\hspace{.09\textwidth}
\begin{minipage}{.45\textwidth}
\includegraphics[width=\textwidth]{img/MA-Sim-Human-Shelf}
\centering
\caption{Mensch am Regal}
\label{coex-shelf}
\end{minipage}
\end{figure}

\subsubsection{Kooperationsszenario}

Eine Ausweitung der Interaktion erfolgt im Kooperationsszenario.
In diesem werden durch den Roboter Objekte entweder weitergereicht oder aussortiert.
Nach jedem aussortierten Objekt wird der Mensch gerufen.
Der Mensch holt den Ausschuss dann nach dem erledigen seiner aktuellen Aufgabe ab.
Diese Interaktion und das in diesem Szenario hinzugefügte Fließband sind in Abbildung \ref{coop-human} dargestellt.

\begin{figure}
\includegraphics[width=\textwidth]{img/MA-Sim-Human-Coop}
\centering
\caption{Mensch am Tisch des Roboters mit Förderband}
\label{coop-human}
\end{figure}

\subsubsection{Kollaborationsszenario}

\begin{figure}
\begin{minipage}{.45\textwidth}
\includegraphics[width=\textwidth]{img/MA-Sim-Human-Colab-Pickup}
\centering
\caption{Mensch bei Aufheben eines Objektes}
\label{colab-pickup}
\end{minipage}
\hspace{.09\textwidth}
\begin{minipage}{.45\textwidth}
\includegraphics[width=\textwidth]{img/MA-Sim-Human-Colab-Drop}
\centering
\caption{Mensch beim Ablegen eines Objektes}
\label{colab-drop}
\end{minipage}
\end{figure}

\section{Lessons Learned bei der Umsetzung}
-Viele kleine Unannehmlichkeiten, kombiniert ein großes Problemen

-Dokumentation für spätere Projekte
\subsection{Erstellung des Robotermodells}
-Keine direkten technischen Daten zum Roboter von Kuka
-Nur CAD-Dateien der Außenhülle

-Schätzung von Spezifikationen anhand Marketingmaterial
\subsection{Erweiterung des Robotermodells mit MoveIt}
-Fehler durch falsche Pfade des Setups

-Fehler durch fehlerhafte Config (Mal nachsehen, was das genau war)
\subsection{Gazebo}
%\subsubsection{Upgrade auf Ignition}
%Gazebo ist zu diesem Zeitpunkt in mehreren, teilweise gleichnamigen Versionen verfügbar, die sich jedoch grundlegend unterscheiden.
%Ein altes Projekt mit dem früheren Namen Gazebo, dass nun in Gazebo Classic umbenannt wurde,
%die Neuimplementation der Simulationssoftware mit dem Namen Gazebo Ignition und
%die nächste Version, die nur noch den Namen Gazebo tragen soll.
%Dies ist darauf zurückzuführen, dass Gazebo Classic und Ignition eine Zeit lang gleichzeitig existierten, jedoch unterschiedliche Funktionen und interne Schnittstellen besitzen.

%Das Upgrade von Gazebo Classic auf Gazebo Ignition gestaltete sich aus mehreren Gründen schwierig.
%Dies ist am leichtesten an der geänderten Nutzeroberfläche sichtbar, die in Ignition nun modular ausgeführt ist.
%Um dieses neue modulare System nutzen zu können, wurde das Dateiformat für die Simulationen angepasst.
%In diesem werden die benötigten Physikparameter, Nutzeroberflächen, Plugins und die Simulationswelt definiert.

%Um alte Simulationsdateien zu migieren, empfiehlt sich die Erstellung einer neuen, leeren Welt in Gazebo Ignition,
%sodass alle benötigten Physik, Nutzeroberflächen und Pluginreferenzen erstellt werden.
%Danach kann die Welt Stück für Stück in das neue Format übertragen werden, wobei nach jedem Eintrag ein Test zur Funktionsfähigkeit gemacht werden sollte, da sich bestimmte Parameterdeklarationen geändert haben.
%Die Arbeit in kleine Stücke aufzuteilen ist hierbei hilfreich, da Fehler während des Ladevorgangs im Log nicht weiter beschrieben werden.

%Auch das alte Plugin musste auf das neue System angepasst werden, was auch hier zu einer kompletten Neuimplementation führte, da die internen Systeme zu große Unterschiede aufwiesen.
%Darunter fallen eine grundlegende Strukturänderung der unterliegenden Engine, die auf ein Entity-Component-System umstellte, aber auch Veränderungen an den verwendeten Objekten innerhalb dieses Systems.
\subsubsection{Pluginarchitektur}
Die von Gazebo verwendete Plugininfrastruktur ist ideal, um schnell neue Funktionen in Gazebo zu entwickeln.
Jedoch existiert damit jedes Plugin im selben Prozess, was bei der Nutzung von Bibliotheken, die nicht für die mehrfache Nutzung im selben Prozess entsprechend ausgelegt wurden, zu Problemen führen kann.

Zur Kommunikation des ActorPlugins mit dem ROS-ActionServer wurde die benötigte Funktionalität vorerst im Plugin selbst implementiert.
Da diese Funktionalität zuerst entwickelt wurde, konnte sie zu diesem Zeitpunkt nur alleinstehend getestet werden.
Diese Tests verliefen vorerst erfolgreich, jedoch scheiterten sie bei der Integration des Robotermodells, dass über die \code{ros_control}-Integration ebenfalls \code{rclcpp} nutzt.

Um dieses Problem zu umgehen, sind mehrere Lösungsansätze denkbar.
\begin{description}
  \item[Separater Nachrichtendienst]
  Ein solcher losgelöster Dienst kann die Nachrichten mit einem anderen Programm auszutauschen, dass die Kommunikation nach außen übernimmt.
  \item[Nutzung der gleichen ROS-Instanz]
  Um dem Problem zu begegnen, könnte auch eine globale ROS-Instanz von Gazebo verwaltet werden, die dann von den Plugins genutzt werden kann.
  Dies könnte als ein Plugin realisiert werden, dass diese anderen Plugins zur Verfügung stellt, jedoch müssten die anderen Plugins zur Nutzung dieser Schnittstelle modifiziert werden.
  \item[Gazebo-ROS-Brücke]
  Die Gazebo-ROS-Brücke kann Nachrichten, die in beiden Formaten definiert wurden, ineinander umwandeln.
  Dies ermöglicht die Kommunikation über die Brücke als Mittelmann.
  Dabei müssten Anpassungen an der Architektur vorgenommen werden, da Gazebo kein Äquivalent zum ActionServer besitzt.
\end{description}
Die Entscheidung fiel auf einen separaten Nachrichtendienst, da dessen Implementation losgelöst von anderen Systemen funktioniert.
Natürlich ist die Einführung eines weiteren Nachrichtendienstes ein Bruch der Philosophie, jedoch die einzige Methode, die garantiert funktioniert, weswegen sie letztendlich implementiert wurde.

\subsubsection{Fehlende Animationsgrundlagen}
-Animationen werden als .col bereitgestellt

-Enthalten Textur, Mesh und Bones, jedoch nicht verbunden -> schlecht für Animation
\subsection{ROS2}
\subsubsection{Nachrichten und deren Echtzeitfähigkeit}
-TCP und UDP verfügbar, jedoch nicht sofort kompatibel
\subsection{MoveIt2}
\subsubsection{Fehlerhafte Generierung der Roboter}
-Einige Aspekte der Generierung nicht erforderlich oder falsch
\subsubsection{Controller}
-Controller benötigte Anpassungen und manuelle Tests
\section{Lessons Learned bei den Szenarien}
\subsection{Debugging}
-async tty Option

-gdb ist ein Muss

-``Aufhängen'' von trees