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

Alle Komponenten können 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.

Falls die Umgebung noch nicht genutzt wurde, wird 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 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}

\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 physikalische Eigenschaften der Gelenke festzulegen.


\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 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.


\subsubsection{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{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 Außnahme 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 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 (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 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}

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, um es zum Roboter zurückzubringen (Abbildung \ref{colab-drop}).
Der Roboter bricht den fehlgeschlagenen Vorgang ab, und beginnt diesen mit dem nächsten Objekt von neuem.

\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}
Alle simulierten Szenarien sind in einer Beschreibungssprache abgebildet.
Es wurden entsprechende Austauschmechanismen für die Beschreibungsprache geschaffen, welche auch neue Szenarien darstellen können.
Die vollständige Kontrolle der Endeffektorposition des Roboters und der Bewegung des Menschen in der Simulation sind möglich.

Eine dynamische Simulation von Objekten, welche durch Roboter und Mensch beeinflusst werden können, konnte nicht umgesetzt werden.

\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}