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{pdfpages}
\usepackage{scrhack}
\usepackage{xcolor}
\usepackage{enumitem}
\usepackage{hyperref}
\usepackage{tabularray}

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

\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=-]{Deckblatt.pdf}

\end{titlepage}

\tableofcontents

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

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


\chapter{Einleitung}
\section{Motivation}
Das Feld der Mensch-Roboter-Kollaboration entwickelt sich mit zunehmender Geschwindigkeit fort.
Viele Unternehmen bieten neue Lösungen für die unterschiedlichsten Einsatzszenarien der Endanwender.

Dabei ist eine Prüfung des Anwendungsfalls sinnvoll, um etwaige Probleme der Interaktion früh erkennen und beheben zu können.
Diese Prüfung kann durch eine Simulation, in welcher der konkrete Anwendungsfall abgebildet wird, vereinfacht werden.

Außerdem bietet eine Simulation die Möglichkeit, die Aufgabe des Roboters, ohne dessen Anschaffung, evaluieren zu können.
Das so gefertigte Modell des Anwendungsfalls könnte später auch als Grundlage für einen digitalen Zwilling dienen.
Dieser kann später zur Wartung und Fehlerdiagnose des Systems dienen.

-MRK häufiger ein Thema
-Anwendungsfälle sollen evaluiert werden
-Erprobung von Szenarien ohne Roboter

->Simulation eine kompletten Szenarios mit Roboter und Mensch
\section{Stand der Wissenschaft}
Aktuelle Arbeiten:

-Planung von Interaktionen

-Parametervergrleiche von maschinellen und menschlichen Bewegungen

-Vermeidung von Kollisionen und Strategie

-Steuerung von Robotern mit Behavior Trees

-> Keine allgemeine Simulation einen gesamten Szenarios mit Mensch.

\url{https://www.sciencedirect.com/science/article/pii/S2351978918311442}
\url{https://www.researchgate.net/publication/319888916_Interactive_Simulation_of_Human-robot_Collaboration_Using_a_Force_Feedback_Device}
\url{https://elib.dlr.de/120687/1/human_motion_projection.pdf}
\url{https://www.researchgate.net/publication/220065749_Human-Robot_Collaboration_a_Survey}

\section{Welche Szenarien}
Die drei Szenarien sollten so gewählt werden, dass vorher genutzte Bestandteile in späteren, komplexeren Szenarien weiter genutzt werden können.
Hierfür kommen bestimmte Aufgaben, wie zum Beispiel die Manipulation von Objekten, besonders in Frage, da diese viele ähnliche Bestandteile haben, jedoch mehrere Szenarien denkbar sind.

Das erste abgebildete Szenario soll sich mit der Simulation einer bereits vollautomatisierten Fertigungsaufgabe handeln, in welcher ein Roboter im Arbeitsbereich eines Menschen Teile fertigt.
Die zu erwartende Interaktion beschränkt sich hierbei auf die Anpassung der Fahrgeschwindigkeit bei Annäherung des Menschen.

Bei dem zweiten Szenario soll der Roboter Teile sortieren und auf ein Fließband legen, falls diese weiter genutzt werden können.
Der Mensch muss nun nur noch den Ausschuss beseitigen, welcher vom Roboter in eine besondere Zone gelegt wird.

Die dritte simulierte Aufgabe stellt ein Colaborationsszenario dar, in welchem Mensch und Roboter an der selben Aufgabe arbeiten.
Hierbei soll eine Palette entladen werden, wobei der Roboter nicht jedes Objekt ausreichend manipulieren kann.
In diesen Fällen muss nun ein Mensch aushelfen, wodurch er mit dem Roboter in Interaktion tritt.
\section{Welcher Nutzen / Contributions}
- Erkennen von konzeptionellen Problemen vor Ersteinsatz

- Definition von Interaktion mit einfacheren Strukturen als State-Machines
\chapter{Konzept}
Die zu entwickelnde Simulation soll die bisher meißt separaten Zweige der Roboter- und Menschensimulation verbinden.
Um die beiden Akteuren in der simulierten Umgebung zu steuern, werden Befehle von außerhalb der Simulation eingesetzt.
Diese Befehle werden dabei von externer Software unter der Verwendung von Behavior Trees und Feedback aus der Simulation generiert.

Die zu erarbeitende Softwareumgebung soll einfach erweiterbar sein, um weitere Modifikationen und die Umsetzung anderer Projekte zuzulassen.
Hierzu zählt die Austauschbarkeit und Erweiterbarkeit von Komponenten wie der simulierten Welt, dem Roboter oder dem simulierten Mensch.
Um diese Möglichkeiten zu schaffen, sind die Systeme modular aufgebaut.

-Mensch und Roboter in Simulation
-Austauschbare Welt
-Beliebig erweiterbar
\section{Simulation des Roboters}
Der simulierte Roboter soll für viele unterschiedliche Szenarien nutzbar sein, was spezialisierte Robotertypen ausschließt.
Außerdem ist die enge Interaktion mit Menschen interessant, was einen für Mensch-Roboter-Kollaboration ausgelegten Roboter spricht.
Für diese beschriebenen Kriterien eignet sich der KUKA LBR iisy, welcher als Cobot vermarktet wird.
Cobot ist dabei ein Portemanteau aus Collaborative und Robot, was die besondere Eignung für MRK-Szenarien noch einmal unterstreicht.
Er besitzt auch einen modifizierbaren Endeffektor, um unterschiedlichste Aufgaben erfüllen zu können.

Um den Kuka iisy in der Simulation verwenden zu können, muss ein Modell des Roboterarms erstellt werden.
Anhand dieses Modells kann der Roboter dann in der Simulation dargestellt werden und mit anderen Objekten interagieren.

-Beruhend auf echtem Roboter (Kuka iisy)
-Kollision
\section{Simulation des Menschen}
Der Mensch soll in der Simulation typische Aufgaben erledigen und häufiges Verhalten abbilden können.
Hierzu werden Animationen verwendet, welche die aktuelle Tätigkeit darstellen.
Für komplexere Verhaltensweisen können Animationen und andere Aktionen, wie zum Beispiel eine Bewegung und Rotation kombiniert werden, um zum Beispiel die Aktion ``laufen'' auszuführen.

Auch hier wird ein Modell der Person für die Simulation benötigt.
Außerdem werden mehrere Animationen und Übergänge zwischen diesen benötigt, um bestimmte Bewegungen darstellen zu können.
Hinzu kommt noch eine Komponente, welche diese Animationen und andere Parameter von außen entgegennehmen kann, um sie in der Simulation ausführen zu können.
Um die spätere Steuerung des Menschen von außerhalb zu erleichtern, müssen diese Aktionen im Fortschritt überwacht und abgebrochen werden können.

-Dynamische Ausführung von Befehlen
-Erkennbare Bewegungsabläufe
\section{Behavior Trees}
-Steuerung von Mensch und Roboter
-Vermeidung der Nachteile von großen State-Machines
\chapter{Komponenten-/Softwareauswahl}
\section{Dienstumgebung (ROS2)}
\subsection{Auswahl}
\subsection{Beschreibung}
ROS2\cite{doi:10.1126/scirobotics.abm6074}, später auch einfach nur ROS genannt, beschreibt sich selbst als ``a meta operating system for robots''\cite{ros-git}.
Hierbei ist ``operating system'' nicht in seiner herkömmlichen Bedeutung eines vollständigen Betriebssystems zu verstehen.
Es handelt sich um eine gemeinsame Basis für Programme und Daten, welche durch ROS bereitgestellt wird.
Einzelne Bestandteile sind dabei in Pakete gegliedert.
Ein Paket kann dabei beliebig viele Daten und Programme beinhalten.
Programme, welche mit anderen Programmen in der Umgebung interagieren, werden in ROS ``Nodes'' genannt.

Zu den Aufgaben von ROS gehören dabei:
\begin{description}
 \item[Buildumgebung]\hfill \\
  ROS benutzt colcon \cite{colcon}, um Pakete in den Workspaces reproduzierbar zu erstellen.
  Hierfür werden CMake und einige Erweiterungen, wie z.B. ament\_cmake eingesetzt.

 \item[Workspaceverwaltung]\hfill \\
  Pakete können in verschiedenen Verzeichnissen installiert werden und müssen für andere Pakete auffindbar sein.
  ROS nutzt hierfür von colcon generierte Skripte, welche beim Erstellen eines Pakets mit angelegt werden.
  Das Ausführen eines solchen Skripts fügt alle Pakete im Workspace der aktuellen Konsolenumgebung hinzu.

 \item[Abhängigkeitsverwaltung]\hfill \\
  ROS kann durch die in den Paketen deklarierten Abhängigkeiten prüfen, ob diese in der aktuellen Umgebung verfügbar sind.
  Dies vermeidet Abstürze und undefiniertes Verhalten in der Ausführung von Nodes.

 \item[Datenübertragung]\hfill \\
  Nodes müssen miteinander auf einem festgelegten Weg kommunizieren können, um beliebige Verbindungen dieser zu unterstützen.
  Dieser wird durch ROS in Form mehrerer Bibliotheken für unterschiedliche Sprachen bereitgestellt.

 \item[Parameterübergabe]\hfill \\
  Nodes benötigen häufig problemspezifische Konfiguration, um in vorher nicht bedachten Szenarien eingesetzt werden zu können.
  ROS stellt diese durch deklarierfähige und integrierte Argumente bereit.

 \item[Startverwaltung]\hfill \\
  In sogenannten ``launch''-Files können verschiedene Nodes und andere ``launch''-Files zu komplexen Startvorgängen zusammengefasst werden.
\end{description}


\section{Simulationsumgebung (Gazebo)}
\subsection{Auswahl}
Als Simulationsumgebung können verschiedene Programme genutzt werden, welche sich in ihrem Funktionsumfang stak unterscheiden.
Hierfür kommen dedizierte Werkzeuge zur Robotersimulation, aber auch zum Beispiel universell einsetzbare Gameengines in Frage.
Diese Werkzeuge müssen hierfür auf ihre Tauglichkeit für die gesetzte Aufgabe geprüft werden.
Auch andere Aspekte sind hierbei zu betrachten, wie Lizenzen oder schwer bewertbare Aspekte wie Nutzerfreundlichkeit.
Für die Auswahl kommen verschiedene Prgramme in Frage, welche im folgenden weiter beleuchtet werden.

CoppeliaSim:
Gute Robotersimulation
Keine Simulation von Menschen
Library ist Open Source, jedoch nicht kostenfrei kommerziell einsetzbar.

Gazebo:
Gute Robotersimulation
Einfache Simulation von Menschen integriert, jedoch nicht für Aufgabe ausreichend.
Open Source, keine Beschränkungen

Unity:
Offizielles Roboterframework und 3rd-Party Lösung verfügbar.
Gute Dokumentation
Gute Werkzeuge für Menschensimulation.
Robotersimulation möglich, jedoch mit anderem Aufbau.
Lizenzen einfach gestaltet, jedoch nicht offen.

Unreal:
3rd Party Lösung verfügbar
Gute Dokumentation
Gute Werkzeuge für Menschensimulation.
Lizenz komplex, nicht offen.

Godot:
3rd Party Lösung verfügbar
Dokumentation stark im Wandel
Gute Werkzeuge für Menschensimulation.
Lizenz offen
Keine explizite Robotersimulation, wäre nachzurüsten

\section{Robotersimulation}
-URDF-Dateiformat

-Einteilung in Kollisions- und Anzeigemesh
\section{Menschensimulation}
-Nur vorprogrammierte Bewegungen möglich

-Nur einige vorgefertigte Animationen verfügbar

\section{Roboterumgebung (MoveIt2)}
-populärste Umgebung für Bewegungsplanung in ROS2

-Integration mit ros\_control

-Integration von ros\_control in gazebo ignition möglich
\chapter{Umsetzung}
\section{Grundlegender Systemaufbau}
-BehaviorTree -> ActorPluginServer -> ActorPluginServer

-BehaviorTree -> MoveIt -> ros\_control -> Gazebo
\section{Mensch}
\subsection{Übersicht (Diagramme)}
\subsection{Modellierung}
Rerigging des Actor-Modells
Animation in eigenem Rig
Konflikte durch 'verschiedene' Rigs in Animationen
Erstellung eines neuen Rigify-Rigs
Erneutes Erstellen von Animationen
Disconnect Bones in Rig
Flatten Hierarchy
\subsection{Programmierung}
\subsubsection{Message Queue}
-2 rclcpp Instanzen kollidieren

-Anderes Protokoll nötig

-Möglichst einfach, von anderen Sprachen verwendbar und schnell

-Websocket zu langsam

-Shared memory schwer zu synchronisieren

-Message Queue guter Mix aus beiden
\subsubsection{ROS-Server}
-Transformieren von ROS2 action server in Message Queue

-Eigene state machine
\subsubsection{Gazebo Plugin}
-Relativ einfache Implementation

-Reagiert nur auf Nachrichten, kein Konzept der gesamten Abfolge
\section{Roboter}
\subsection{Übersicht (Diagramme)}
\subsection{Modellierung}
Erstellung der Robotermodelle aus Herstellerdaten

Kollision und Visualisierung
\subsection{Details}
\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

\end{document}