204 lines
11 KiB
TeX
204 lines
11 KiB
TeX
\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 physikalische 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.
|
|
Mit Hilfe 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.
|
|
|
|
\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 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}
|