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{csquotes}
\usepackage[includehead, includefoot, left=3.0cm, right=2.5cm, top=1.5cm, bottom=1.5cm]{geometry}
\usepackage{acro}
\usepackage{listings}
\usepackage[style=numeric,backend=biber]{biblatex}
%\usepackage[style=numeric,backend=libbib]{biblatex}
\usepackage{pdfpages}
\usepackage{scrhack}
\usepackage{xcolor}
\usepackage{enumitem}
\usepackage{hyperref}
\usepackage{tabularray}
\usepackage{xurl}
\usepackage{xcolor}
\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}}}

\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

\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{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 sahlreiche kleinere Änderungen
\subsubsection{Pluginarchitektur}
-Plugins werden im selben Kontext geladen, verwendung von Librarys mit globalem Kontext schwer
\subsubsection{Doppelte Messagedienste}
-Duplizierung von Messagediensten in ROS und Gazebo

-Potentielle Lösung in einer Präsentation angekündigt (mal sehen, ob ich die wiederfinde)
\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 erkennen

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