\chapter{Evaluation und Diskussion}

\section{Grundlagen}

\subsubsection{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 und
 \item BehaviorTree.CPP als Beschreibungssprache.
\end{itemize}

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

\subsubsection{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 im Projektverzeichnis befindliche \code{start.sh}-Shellskript.
Dieses Skript wird ohne Parameter ausgeführt.

Beim ersten Start der Umgebung wird automatisch eine neue Containervorlage erstellt.
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 gestarteter Virtualisierungsumgebung}
\label{console-docker-started}
\end{figure}

Die Verbindung in die ROS-Umgebung erfolgt über SSH in einer separaten Konsole.
Eine SSH-Verbindung wird mit dem Befehl \code{ssh ros@localhost -p 2222} aufgebaut.
In dieser 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}

\subsubsection{Erstellung der benötigten Modelle}
Für den simulierten Menschen und Roboter werden verschiedene Modelle benötigt.
Das Robotermodell wurde aus Herstellerdaten exportiert und in Blender nachbearbeitet.
Eine Definition des Roboters wurde für Gazebo und MoveIt erstellt, um die Zusammenhänge der einzelnen Armglieder und die physikalischen Eigenschaften der Gelenke festzulegen.

Für das Modell des Menschen wurde eine bereits in Gazebo enthaltene Animation als Grundlage verwendet.
Das in dieser enthaltene Modell wurde angepasst, um das Erstellen weiterer Animationen zu vereinfachen.
Mithilfe dieses modifizierten Modells wurden dann die benötigten Animationen erstellt.

\subsubsection{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 während der Laufzeit 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.


\subsubsection{Definition von Verhalten mit einer Beschreibungssprache}

Die Definition von verschiedenen Verhaltensweisen über eine Beschreibungssprache wurde durch die Erstellung neuer Nodes für einen Behavior Tree 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 vorher gestoppt.

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 unvollendeten Aktionen ist durch die implementierte Interruptable\-Sequence-Node möglich.

Die Entscheidung über die Ausführung einer von mehreren möglichen Aktionen wird mit der 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 dieser neu implementieren und den bereits in BehaviorTree.CPP verfügbaren Nodes kann alle in den Szenarien benötigten Verhaltensweisen darstellen.

\subsection{Erstellen der benötigten Pakete}

Alle benötigten Pakete müssen vor der ersten Ausführung der Simulation kompiliert werden.
Dies wird durch das Ausführen des \code{build.sh}-Skripts im Verzeichnis \code{\textasciitilde/workspace} des Containers ausgelöst.
Nach diesem Vorgang muss der Workspace neu geladen werden, damit die jetzt verfügbaren Pakete registriert werden.

Die kann sowohl durch einen erneuten Aufbau der SSH-Verbindung erfolgen, da bei Start der Session die entsprechende Datei geladen wird, oder manuell geschehen.
Für das manuelle Laden des Workspaces muss der Befehl \code{source /home/ros/workspace/install/setup.bash} in der Konsole ausgeführt werden.

Nach dem Laden des Workspaces ist die Umgebung für die Simulation einsatzbereit.

\section{Simulation der Szenarien}
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}

Alle beschriebenen Szenarien sind mit Ausnahme des Fließbandes aus dem Kooperationsszenario als Behavior Trees umgesetzt.
Diese werden nach dem Start einer Simulation ausgeführt und definieren das Verhalten von Roboter und Mensch.

\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 (Abbildung \ref{coex-move}).
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 an die Aufenthaltszone des Menschen angepasst.

Der Arbeitsvorgang des Menschen besteht aus dem Arbeiten an einer Werkbank und dem Verbringen von Material in das Regal (Abbildung \ref{coex-shelf}).
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 die aussortierten Objekte 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}

Für das Kollaborationsszenario durchschreitet der Mensch den Raum, was die Kontrolle mehrerer Systeme simuliert.
Der Roboter bewegt in diesem Szenario Objekte vom linken auf den rechten Tisch, wobei Fehler auftreten können.
Bei einem Fehler beendet der Mensch seinen Kontrollgang und hebt ein Objekt auf, bringt es zum Roboter zurück und legt es auf dem rechten Tisch ab (Abbildung \ref{colab-drop}).
Der Roboter bricht den fehlgeschlagenen Vorgang ab und setzt die Arbeit mit dem nächsten Objekt fort.

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

\section{Zusammenfassung}
Es wurden entsprechende Nodes für die Bewegung von Mensch und Roboter geschaffen.
Mit diesen Nodes wurden alle simulierten Szenarien in einer Beschreibungssprache abgebildet.
Die vollständige Kontrolle der Endeffektorposition des Roboters und der Bewegung des Menschen in der Simulation sind möglich.

Die dynamische Simulation von Objekten, die durch Roboter und Mensch beeinflusst werden können, wurde im Rahmen dieser Arbeit aus Komplexitätsgründen nicht umgesetzt.
Einen Überblick über die dafür notwendigen Erweiterungen wird in Sektion \ref{objectsim} skizziert.
\section{Lessons Learned}

Während der Entwicklung des Projekts wurden zahlreiche Erkenntnisse gesammelt, welche die Entwicklung weiterer Projekte mit dieser Plattform erleichtern können.

\begin{description}
 \item[Testen einzelner Komponenten]\hfill\\
  Alle ROS-Nachrichtentypen sind mit Kommandozeilenbefehlen versend- und empfangbar.
  Um einzelne Teilsysteme zu testen, können so deren Zustände gesetzt und überwacht werden.
 \item[Überprüfung auf Updates]\hfill\\
  Die regelmäßige Prüfung von verwendeten Bestandteilen auf Updates kann helfen, neue oder verbesserte Funktionen einzusetzen.
 \item[Verwendung eines Debuggers]\hfill\\
  Viele Nodes in ROS können über Kommandozeilenparameter im Debugmodus ausgeführt werden \cite{rosDebug}.
  Da Programme wie Gazebo aber über weitere Launch-Files eingebunden werden, ist dies hier nicht möglich.
  Eine Lösung ist in diesem Fall der separate Start der Gazebo-Umgebung in einem Debugger \cite{gazeboDebug}.
\end{description}
