MasterarbeitLaTeX/main.tex

\documentclass[paper=a4,
ngerman,
captions=tableabove,
fontsize=11pt,
numbers=noenddot,
parskip=half,
]{scrreprt}
\usepackage[ngerman]{babel}
\usepackage[T1]{fontenc}
\usepackage{lmodern}
\usepackage{minted}
\usepackage{csquotes}
\usepackage[includehead, includefoot, left=3.0cm, right=2.5cm, top=1.5cm, bottom=1.5cm]{geometry}
\usepackage{acro}
\usepackage[style=numeric,backend=biber]{biblatex}
\usepackage{pdfpages}
\usepackage{scrhack}
\usepackage{xcolor}
\usepackage{enumitem}
\usepackage{hyperref}
\usepackage{tabularray}
\usepackage{xurl}
\usepackage{soul}
\usepackage{xcolor}
\usepackage{inconsolata}
\usepackage{subcaption}

\usepackage[strings]{underscore}

\usepackage[letterspace=150]{microtype}
\usepackage[onehalfspacing]{setspace}
\usepackage[page]{totalcount}
\usepackage[automark,headsepline=.4pt,plainheadsepline]{scrlayer-scrpage}         % Erstellung von selbst definierten Kopfzeilen
\clearpairofpagestyles%\clearscrheadfoot veraltet
\renewcommand*{\chaptermarkformat}{
  \chaptername~\thechapter\autodot\quad-\quad
}

\definecolor{light-gray}{gray}{0.95}
%\newcommand{\code}[1]{\colorbox{light-gray}{\texttt{#1}}}
\newcommand{\code}[1]{
  \begingroup%
  \sethlcolor{light-gray}%
  \hl{\texttt{#1}}%
  \endgroup
}

\ihead*{\rightmark}
\ohead*{\thepage}
\setkomafont{pageheadfoot}{\normalfont}

\pagestyle{scrheadings}

\pdfminorversion=7

\addbibresource{main.bib}

% Title Page
\title{}
\subtitle{mechatronisches Forschungsprojekt}
\author{Bastian Maximilian Hofmann}


\DeclareAcronym{ros}{
  short=ROS,
  long=Robot Operating System,
}
\DeclareAcronym{fsm}{
  short=FSM,
  long=Finite-State-Machine,
}
\DeclareAcronym{mrk}{
  short=MRK,
  long=Mensch-Roboter-Kollaboration,
}

\begin{document}

\setcounter{page}{1}
\pagenumbering{Roman}

\begin{titlepage}

\includepdf[pages=-]{tex/Deckblatt.pdf}

\end{titlepage}

\tableofcontents
\listoffigures

\includepdf[pages=-]{tex/Aufgabenstellung.pdf}

\setcounter{page}{1}
\pagenumbering{arabic}

\input{tex/1_Einleitung.tex}
\input{tex/2_Konzept.tex}
\input{tex/3_Auswahl.tex}
\input{tex/4_Umsetzung.tex}

\chapter{Szenarienbasierte Evaluation}
\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
\chapter{Diskussion}
\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, welche sich jedoch grundlegend unterscheiden.
Ein altes Projekt mit dem früheren Namen Gazebo, welches nun in Gazebo Classic umbenannt wurde,
die Neuimplementation der Simulationssoftware mit dem Namen Gazebo Ignition und
die nächste Version, welche 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, welche 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, welche 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, welche 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, welches ü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, welches 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, welche dann von den Plugins genutzt werden kann.
  Dies könnte als ein Plugin realisiert werden, welches 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, welche 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
\chapter{Zusammenfassung und Ausblick}
\section{Ergebnisse}
\subsection{Graphische Repräsentation der Szenarien}
-Szenarien graphisch abgebildet
\subsection{Anpassung der Behavior Trees an Szenarien}
-Trees angepasst
\section{Diskussion}
-Viele Iterationen benötigt

-Funktionstüchtige Simulation der Szenarien

-Bewegung der Objekte schwerer als gedacht

-Synchronisationsmechanismus Gazebo <-> MoveIt benötigt
\section{Ausblick}
\subsection{Umsetzung in anderem Simulator}
-Einfachere ROS Anbindung
-Potentiell einfacher ausbaubar auf Basis einer erweiterbaren Gameengine
-Mangelhafte Dokumentation von Gazebo
\subsection{Simulation bewegter Objekte}
-Aufgrund von Komplexität des Prozesses nicht integriert
\subsection{Ergänzung von Umgebungserkennung}
-MoveIt hat Unterstützung

-Daten aus Gazebo extrahieren und in MoveIt einbinden

-Person in OctoMap\cite{octomap} erkennen
\subsection{Zusammenbringen von ActorPlugin und ActorServer}
-Mechanismus für Datenaustausch zwischen ROS und Gazebo überdenken/überarbeiten

-Geteilte ROS Instanz zwischen Plugins? Wie?

-Potentielle Integration von ROS als Messagedients in Gazebo

\subsection{Separieren der Subtrees in eigene Dateien}

\printbibliography
\newpage
\markboth{Anhang}{Anhang}
\begin{figure}[ht]
\includegraphics[width=14cm]{img/moveit_pipeline}
\caption{Visualisierung der MoveIt Pipeline \protect \cite{moveitpipeline}}
\label{moveitpipeline}
\end{figure}
\end{document}