220 lines
10 KiB
TeX
220 lines
10 KiB
TeX
\chapter{Evaluation und Diskussion}
|
|
|
|
\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, welches ohne Parameter ausgeführt wird.
|
|
|
|
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}[h]
|
|
\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 deiser Funktionalität für den Einsatz geeignet.
|
|
|
|
\begin{figure}[h]
|
|
\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 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{Steuerung des Menschen}
|
|
|
|
\section{Umsetzung der Szenarien}
|
|
\subsection{Koexistenzszenario}
|
|
|
|
\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}
|
|
|
|
\subsection{Kooperationsszenario}
|
|
|
|
\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}
|
|
|
|
\subsection{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{Simulation des Menschen}
|
|
-Animationen und Bewegungen funktionieren
|
|
|
|
-Kollisionen möglich, aber mit Animationen schwer zu synchronisieren
|
|
\section{Bewegung des Roboters}
|
|
-Roboter kann sich bewegen
|
|
|
|
-Kollisionen verfügbar
|
|
|
|
-Interaktion technisch möglich, nicht implementiert. (Kooperation MoveIt/Gazebo nötig)
|
|
\section{BehaviorTrees}
|
|
\subsection{Nodes}
|
|
-Nodes für implementierte Funktionen verfügbar
|
|
|
|
-Einige andere, technisch relevante Nodes auch implementiert
|
|
\subsection{Kombinieren von Nodes zu einer Request}
|
|
-MoveIt Planung benötigt mehrere Parameter, sollen aber in einzelnen Nodes gesetzt werden
|
|
|
|
-Kombination nötig, Beschreibung hier
|
|
\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, Nuteroberflä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
|
|
\subsubsection{Änderung der Compilertoolchain}
|
|
-Änderung des Buildsystems von rosbuild auf catkin
|
|
|
|
-Benötigte Änderungen in CMakeFile und package
|
|
\subsection{MoveIt2}
|
|
\subsubsection{Upgrade auf MoveIt2}
|
|
-Unterschiede in der Deklaration des Roboters selbst
|
|
|
|
-Änderungen der Deklaration der ros\_control Anbindung
|
|
|
|
-Vorerst kein Setup, manuelle Migration erforderlich
|
|
|
|
->Lesson learned: Projekte häufig auf Updates prüfen
|
|
\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
|