Changes from 14.04
This commit is contained in:
parent
16449809b0
commit
c5e91e77c2
@ -2,7 +2,16 @@
|
||||
kile_livePreviewEnabled=true
|
||||
kile_livePreviewStatusUserSpecified=true
|
||||
kile_livePreviewTool=LivePreview-PDFLaTeX
|
||||
lastDocument=main.tex
|
||||
lastDocument=tex/4_Umsetzung.tex
|
||||
|
||||
[document-settings,item:Einleitung.tex]
|
||||
Bookmarks=
|
||||
Encoding=UTF-8
|
||||
Highlighting=LaTeX
|
||||
Highlighting Set By User=false
|
||||
Indentation Mode=normal
|
||||
Mode=LaTeX
|
||||
Mode Set By User=false
|
||||
|
||||
[document-settings,item:main.bib]
|
||||
Bookmarks=
|
||||
@ -22,8 +31,53 @@ Indentation Mode=normal
|
||||
Mode=LaTeX
|
||||
Mode Set By User=true
|
||||
|
||||
[document-settings,item:tex/1_Einleitung.tex]
|
||||
Bookmarks=
|
||||
Encoding=UTF-8
|
||||
Highlighting=LaTeX
|
||||
Highlighting Set By User=false
|
||||
Indentation Mode=normal
|
||||
Mode=LaTeX
|
||||
Mode Set By User=false
|
||||
|
||||
[document-settings,item:tex/2_Konzept.tex]
|
||||
Bookmarks=
|
||||
Encoding=UTF-8
|
||||
Highlighting=LaTeX
|
||||
Highlighting Set By User=false
|
||||
Indentation Mode=normal
|
||||
Mode=LaTeX
|
||||
Mode Set By User=false
|
||||
|
||||
[document-settings,item:tex/3_Auswahl.tex]
|
||||
Bookmarks=
|
||||
Encoding=UTF-8
|
||||
Highlighting=LaTeX
|
||||
Highlighting Set By User=false
|
||||
Indentation Mode=normal
|
||||
Mode=LaTeX
|
||||
Mode Set By User=false
|
||||
|
||||
[document-settings,item:tex/4_Umsetzung.tex]
|
||||
Bookmarks=
|
||||
Encoding=UTF-8
|
||||
Highlighting=LaTeX
|
||||
Highlighting Set By User=false
|
||||
Indentation Mode=normal
|
||||
Mode=LaTeX
|
||||
Mode Set By User=false
|
||||
|
||||
[document-settings,item:tex/Einleitung.tex]
|
||||
Bookmarks=
|
||||
Encoding=UTF-8
|
||||
Highlighting=LaTeX
|
||||
Highlighting Set By User=false
|
||||
Indentation Mode=normal
|
||||
Mode=LaTeX
|
||||
Mode Set By User=false
|
||||
|
||||
[item:main.bib]
|
||||
open=true
|
||||
open=false
|
||||
order=1
|
||||
|
||||
[item:main.tex]
|
||||
@ -34,6 +88,30 @@ order=0
|
||||
open=false
|
||||
order=-1
|
||||
|
||||
[item:tex/1_Einleitung.tex]
|
||||
open=true
|
||||
order=1
|
||||
|
||||
[item:tex/2_Konzept.tex]
|
||||
open=true
|
||||
order=2
|
||||
|
||||
[item:tex/3_Auswahl.tex]
|
||||
open=true
|
||||
order=3
|
||||
|
||||
[item:tex/4_Umsetzung.tex]
|
||||
open=true
|
||||
order=4
|
||||
|
||||
[view-settings,view=0,item:Einleitung.tex]
|
||||
CursorColumn=0
|
||||
CursorLine=0
|
||||
Dynamic Word Wrap=false
|
||||
JumpList=
|
||||
TextFolding={"checksum":"","ranges":[]}
|
||||
ViMarks=
|
||||
|
||||
[view-settings,view=0,item:main.bib]
|
||||
CursorColumn=14
|
||||
CursorLine=109
|
||||
@ -44,8 +122,48 @@ ViMarks=
|
||||
|
||||
[view-settings,view=0,item:main.tex]
|
||||
CursorColumn=0
|
||||
CursorLine=455
|
||||
CursorLine=111
|
||||
Dynamic Word Wrap=false
|
||||
JumpList=
|
||||
TextFolding={"checksum":"1d8262bd4fab97ca3ac166d2d70ba8518a0c146f","ranges":[]}
|
||||
TextFolding={"checksum":"86fedba94f6f431aca10df7e7ffc4fd7dd3eac24","ranges":[]}
|
||||
ViMarks=
|
||||
|
||||
[view-settings,view=0,item:tex/1_Einleitung.tex]
|
||||
CursorColumn=42
|
||||
CursorLine=26
|
||||
Dynamic Word Wrap=false
|
||||
JumpList=
|
||||
TextFolding={"checksum":"7f68313ac5accbbfe63bf0c2f33b5f2b97851ec3","ranges":[]}
|
||||
ViMarks=
|
||||
|
||||
[view-settings,view=0,item:tex/2_Konzept.tex]
|
||||
CursorColumn=0
|
||||
CursorLine=0
|
||||
Dynamic Word Wrap=false
|
||||
JumpList=
|
||||
TextFolding={"checksum":"daf7cac8e4765460806a7139b3eb9171fb011da3","ranges":[]}
|
||||
ViMarks=
|
||||
|
||||
[view-settings,view=0,item:tex/3_Auswahl.tex]
|
||||
CursorColumn=0
|
||||
CursorLine=164
|
||||
Dynamic Word Wrap=false
|
||||
JumpList=
|
||||
TextFolding={"checksum":"04558a693eba7702df7000723ab69b6eb36166ba","ranges":[]}
|
||||
ViMarks=
|
||||
|
||||
[view-settings,view=0,item:tex/4_Umsetzung.tex]
|
||||
CursorColumn=0
|
||||
CursorLine=216
|
||||
Dynamic Word Wrap=false
|
||||
JumpList=
|
||||
TextFolding={"checksum":"93fb61d8448ada79778cce2b5e34a55776abbb30","ranges":[]}
|
||||
ViMarks=
|
||||
|
||||
[view-settings,view=0,item:tex/Einleitung.tex]
|
||||
CursorColumn=0
|
||||
CursorLine=0
|
||||
Dynamic Word Wrap=false
|
||||
JumpList=
|
||||
TextFolding={"checksum":"","ranges":[]}
|
||||
ViMarks=
|
||||
|
||||
|
Before Width: | Height: | Size: 99 KiB After Width: | Height: | Size: 99 KiB |
401
main.tex
401
main.tex
@ -9,7 +9,7 @@ parskip=half,
|
||||
\usepackage[T1]{fontenc}
|
||||
\usepackage{lmodern}
|
||||
\usepackage{csquotes}
|
||||
\usepackage[includehead,includefoot, left=3.0cm, right=2.5cm, top=1.5cm, bottom=1.5cm]{geometry}
|
||||
\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}
|
||||
@ -21,6 +21,7 @@ parskip=half,
|
||||
\usepackage{hyperref}
|
||||
\usepackage{tabularray}
|
||||
\usepackage{xurl}
|
||||
\usepackage{xcolor}
|
||||
\usepackage[strings]{underscore}
|
||||
|
||||
\usepackage[letterspace=150]{microtype}
|
||||
@ -32,6 +33,9 @@ parskip=half,
|
||||
\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}
|
||||
@ -69,403 +73,22 @@ parskip=half,
|
||||
|
||||
\begin{titlepage}
|
||||
|
||||
\includepdf[pages=-]{Deckblatt.pdf}
|
||||
\includepdf[pages=-]{tex/Deckblatt.pdf}
|
||||
|
||||
\end{titlepage}
|
||||
|
||||
\tableofcontents
|
||||
|
||||
\includepdf[pages=-]{Aufgabenstellung.pdf}
|
||||
\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{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
|
||||
|
||||
-Parametervergleiche 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.
|
||||
|
||||
\begin{figure}[]
|
||||
\includegraphics[]{Konzept_Overview}
|
||||
\centering
|
||||
\caption{Visualisierung des Konzepts}
|
||||
\label{concept_overview}
|
||||
\end{figure}
|
||||
|
||||
\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.
|
||||
Dieses Modell sollte die physikalischen Eigenschaften des Roboters möglichst gut wiederspiegeln.
|
||||
Anhand dieses Modells kann der Roboter dann in der Simulation dargestellt werden und mit anderen Objekten interagieren.
|
||||
|
||||
\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.
|
||||
|
||||
\section{Behavior Trees}
|
||||
Häufig wird Verhalten in State-Machines ausgedrückt, welche jedoch einige Nachteile besitzen.
|
||||
State-Machines werden ab einer gewissen Größe schnell unübersichtlich.
|
||||
Dies erschwert die schnelle Erfassung von Abfolgen und Zustandsübergängen bei Änderungen am Code, welche jedoch essentiell für den Betrieb einer Maschine sind.
|
||||
Um diese Probleme zu adressieren, entstand das Konzept der Behavior Trees.
|
||||
|
||||
Ein Behavior Tree ist eine Struktur, um Verhalten als ein Baum zu beschreiben.
|
||||
Der Ablauf startet vom sogenannten Root, der Wurzel des Baums.
|
||||
Von dort an werden sogenannte Nodes, welche je nach Node unterschiedliches Verhalten abbilden, miteinander verbunden.
|
||||
Die Nodes werden untereinander angeordnet, welches die Relation der Nodes zueinander beschreibt.
|
||||
Jede Node hat dabei entweder die Root-Node oder eine andere Node über ihr im Baum und eine beliebige Anzahl an Nodes unter sich.
|
||||
Hierbei gibt es mehrere grundlegende Arten von Tree-Nodes.
|
||||
\begin{description}
|
||||
\item[Aktions-Nodes]
|
||||
beschreiben einzelne ausführbare Aktionen. Mit Hilfe von Parametern kann ihr Verhalten von anderen Nodes beeinflusst werden.
|
||||
\item[Dekorations-Nodes]
|
||||
können den Rückgabewert einer anderen Node modifizieren. Häufig existieren hier Negation, garantierter Erfolg und garantierter Fehler.
|
||||
\item[Sequenz-Nodes]
|
||||
beschreiben eine nacheinander ausgeführte Abfolge von anderen Nodes, welche mit spezifischen Randbedingungen weiter fortschreitet.
|
||||
\item[Fallback-Nodes]
|
||||
werden verwendet, um Verhalten zu definieren, welches nur bei Fehlern in vorherigen Nodes ausgeführt wird.
|
||||
\end{description}
|
||||
|
||||
In dieser Arbeit sollen BehaviorTrees für die Steuerung von Mensch und Roboter verwendet werden.
|
||||
Die hierfür erstellten Nodes sollen universell gestaltet werden, um alle Szenarien, welche in dieser Arbeit bearbeitet werden, abzudecken.
|
||||
|
||||
\chapter{Komponenten-/Softwareauswahl}
|
||||
\section{Dienstumgebung (ROS2)}
|
||||
\subsection{Auswahl}
|
||||
Durch eine Dienstumgebung werden häufig benötigte Funktionen bereitgestellt, welche in Programmen genutzt werden können.
|
||||
Dabei ist es irrelevant, ob diese für simulierte, aber auch echte Hardware, genutzt werden.
|
||||
Bei einer Dienstumgebung für Roboter gehören zu den grundlegendn Aspekten die Nachrichtenübergabe zwischen einzelen interagierenden Programmen, um eine gemeinsame Basis für ein einfach erweiterbares System zu schaffen.
|
||||
|
||||
In diesem Bereich sticht ROS als Dienstumgebung für Roboter hervor, da es sich um ein etabliertes, quelloffenes und häufig verwendetes System handelt.
|
||||
Es bietet die oben genannten Aspekte und einige weitere Verbesserungen, welche später näher beleuchtet werden.
|
||||
Die neuste Version ROS2 bietet dabei einige Verbesserungen im Vergleich zu früheren Version ROS1.
|
||||
Ein neues Nachrichtenformat mit Quality of Service kann zum Beispiel Nachrichten vorhalten und über sowohl TCP als auch UDP kommunizieren.
|
||||
Außerdem werden nun neben CMake auch andere Buildsysteme unterstützt, unter anderem auch Python.
|
||||
|
||||
Generell existieren im Feld der Roboter-Dienstumgebungen keine Alternativen mit ähnlichem Funktionsumfang und gleicher Reichweite, jedoch sind andere Systeme mit anderen Nachrichtenformaten denkbar.
|
||||
Vor allem die unzähligen ROS-Bibliotheken, welche von Nutzern des Systems über die Jahre erstellt wurden, machen das System so populär.\cite{rospackages}
|
||||
|
||||
-Alternative Ökosysteme mit gleichem Umfang wie ROS existieren nicht.
|
||||
-ROS2
|
||||
-Andere (nur) Messagingsysteme
|
||||
-LCM
|
||||
-ZeroMQ
|
||||
\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 dabei um eine gemeinsame Grundlage für Programme und Daten, welche durch ROS bereitgestellt wird.
|
||||
|
||||
Einzelne Bestandteile in der Umgebung sind dabei in Pakete gegliedert.
|
||||
Ein Paket kann beliebig viele Daten und Programme beinhalten, welche in zwei Dateien beschrieben werden.
|
||||
In CMakeLists.txt befinden sich Buildinstruktionen für den Compiler, falls sich Programme im Paket befinden.
|
||||
Außerdem können bestimmte Pfade aus dem Paket exportiert werden, sodass diese später im Workspace verfügbar sind.
|
||||
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 und eines Workspaces mit angelegt werden.
|
||||
Das Skript des Pakets fügt nur dieses Paket der Umgebung hinzu, das Skript des Workspaces führt alle Skripte der enthaltenen Pakete aus, um diese der Umgebung hinzuzufügen.
|
||||
|
||||
\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, früher auch V-REP genannt, ist eine Robotersimulationsumgebung mit integriertem Editor und ROS-Unterstützung.
|
||||
Es unterstützt viele Sprachen (C/C++, Python, Java, Lua, Matlab oder Octave) zur Entwicklung von Erweiterungen des Simulators.
|
||||
Der Simulator selbst unterstützt Menschliche Aktoren, jedoch können diese nur Animationen abspielen oder zusammen mit Bewegungen abspielen.
|
||||
CoppeliaSim existiert in 3 Versionen, welche sich im Funktionsumfang unterscheiden, jedoch hat nur die professionelle Version Zugriff auf alle Funktionen und Verwendungsszenarien.
|
||||
|
||||
Gazebo Ignition ist wie CoppeliaSim eine Robotersimulationsumgebung, jedoch ohne integrierten Editor und direkte ROS-Unterstützung.
|
||||
Gazebo setzt wie CoppeliaSim auf Erweiterungen, welche die gewünschten Funktionen einbinden können.
|
||||
Zum Beispiel existiert auch eine ROS-Brücke, welche die Anbindung an ROS ermöglicht.
|
||||
Auch hier unterstützt der Simulator nur Animationen für menschliche Aktoren.
|
||||
Das Projekt ist Open Source, unter der Apache Lizenz (Version 2.0), was die Verwendung in jeglichen Szenarien erleichtert.
|
||||
|
||||
Unity hingegen ist primär eine Grafikengine für Nutzung in Computerspielen.
|
||||
Es existieren mehrere Systeme zur Anbindung der Engine an ROS, vor allem das offizielle ``Robotics Simulation''-Paket und ZeroSim.
|
||||
Beide Systeme erlauben die Erweiterung der Gameengine um die Simulation von Robotern.
|
||||
Unity besitzt eine gute Dokumentation, die vor allem auf die Nutzung im Einsteigerbereich zurückzuführen ist.
|
||||
Auch die Optionen zur Menschensimulation sind gut, da diese häufig in Spielen verwendet werden.
|
||||
Ein großer Nachteil hingegen ist die Lizenz, welche nur für Einzelpersonen kostenlos ist.
|
||||
|
||||
Die Unreal Engine ist wie Unity eine Grafikengine aus dem Spielebereich.
|
||||
Auch hier ist die Menschensimulation aufgrund oben genannter Gründe gut möglich.
|
||||
Jedoch existiert für Unreal Engine keine offizielle Lösung zur Anbindung an ROS2.
|
||||
Die Programmierung der Engine erfolgt in C++, was einer Drittlösung erlaubte, eine ROS-Anbindung für Unreal Engine zu erstellen.
|
||||
Die Lizenz der Unreal Engine erlaubt die kostenfreie Nutzung bis zu einem gewissen Umsatz mit der erstellten Software.
|
||||
|
||||
Eine weitere Möglichkeit zur Simulation stellt die Grafikengine Godot dar.
|
||||
Im Vergleich zu Unity und Unreal Engine ist Godot quelloffene Software unter der MIT-Lizenz.
|
||||
Auch hier stellt die Simulation von menschlichen Aktoren eine Standartaufgabe dar, jedoch befinden sich Teile des dafür verwendeten Systems derzeit in Überarbeitung.
|
||||
Auch für diese Engine existiert eine ROS2-Anbindung, jedoch ist diese nicht offiziell.
|
||||
|
||||
Jede der drei Gameengines besitzt ein integriertes Physiksystem, welches die Simulation von starren Körpern und Gelenken erlaubt.
|
||||
Aus diesen Funktionen könnte ein Roboterarm aufgebaut werden, welcher dann durch eine der ROS-Brücken der Engines gesteuert werden kann.
|
||||
|
||||
Die Wahl der Simulationsumgebung fiel auf Gazebo Ignition, da dieser Simulator bereits im ROS-Framework etabliert ist.
|
||||
Dabei erlauben die offizielle ROS-Anbindung und offene Lizenz eine zuverlässige Verwendung in unterschidlichsten Szenarien.
|
||||
|
||||
\subsection{Robotersimulation}
|
||||
Für die Robotersimulation wird ein Modell des Roboters benötigt, in welchem dieser für die Siimulationsumgebung beschrieben wird.
|
||||
Gazebo nutzt hierfür .srdf-Dateien, welche auf xml basieren.
|
||||
In diesen werden die einzelnen Glieder des Arms und die verbindenden Gelenke beschrieben.
|
||||
|
||||
Jedes Glied des Modells besitzt eine Masse, einen Masseschwerpunkt und eine Trägheitsmatrix für die Physiksimulation in Gazebo.
|
||||
Außerdem werden Modelle für die visuelle Repräsentation in Gazebo und die Kollisionserkennung in der Physiksimulation hinterlegt.
|
||||
Für beide existieren einfache Modelle wie Zylinder, Boxen und Kugeln.
|
||||
Da diese Formen nicht jeden Anwendungsfall abdecken und in der visuellen Repräsentation nicht ausreichen, können auch eigene Modelle hinterlegt werden.
|
||||
|
||||
Gelenke werden separat von den Gliedern definiert und verbinden jeweils zwei Glieder miteinander.
|
||||
Durch das Aneinanderreihen von mehreren Gliedern und Gelenken kann so jeder Roboteraufbau beschrieben werden.
|
||||
Jedes Gelenk besitzt eine Position und Rotation im Raum, um dessen Effekte je nach Typ des Gelenks berechnen zu können.
|
||||
Aspekte wie Reibung und Dämpfung können auch für die Physiksimulation angegeben werden.
|
||||
Folgende Typen von Gelenken können in urdf genutzt werden:
|
||||
\begin{description}
|
||||
\item[freie Gelenke]
|
||||
ermöglichen vollständige Bewegung in allen 6 Freiheitsgraden. Sie stellen den normalen Zustand der Gelenke zueinander dar.
|
||||
\item[planare Gelenke]
|
||||
erlauben Bewegungen senkrecht zur Achse des Gelenks. Sie werden für zum Beispiel Bodenkollisionen eingesetzt.
|
||||
\item[feste Gelenke]
|
||||
sperren alle 6 Freiheitsgrade und werden häufig zur Plazierung von Objekten in einer Szene genutzt.
|
||||
\item[kontinuierliche Gelenke]
|
||||
erlauben die beliebige Rotation um die Achse des Gelenks. Sie sind nur selten in rotierenden Gelenken mit Schleifkontakten zu finden.
|
||||
\item[drehbare Gelenke]
|
||||
verhalten sich wie kontinuerliche Verbindungen, haben jedoch minimale und maximale Auslenkungen. Sie sind die häufigste Art von Gelenken in Roboterarmen.
|
||||
\item[prismatische Gelenke]
|
||||
ermöglichen die Bewegung entlang der Achse des Gelenks. Denkbare Anwendungsfälle sind simulierte lineare Aktuatoren.
|
||||
\end{description}
|
||||
\subsection{Menschensimulation}
|
||||
Gazebo besitzt bereits ein einfaches Animationssystem für bewegliche Aktoren, welches auch für Menschen nutzbar ist.
|
||||
Es existiert bereits ein Modell eines Menschen mit mehreren Animationen, welche allein abgespielt, oder an Bewegungen gekoppelt werden können.
|
||||
Dadurch ist eine Laufanimation realisierbar, welche synchronisiert zur Bewegung abgespielt wird.
|
||||
|
||||
Jedoch ist dies nur unter der Bedingung möglich, dass der gesamte Bewegungsablauf zum Simulationsstart bekannt ist.
|
||||
Dies ist auf die Definition der Pfade, welche die Bewegung auslösen, zurückzuführen.
|
||||
Diese können nur in der .sdf-Datei des Aktoren definiert werden, was Veränderungen zur Laufzeit ausschließt.
|
||||
Durch diesen Umstand ist der mögliche Simulationsumfang nicht ausreichend.
|
||||
|
||||
Um diesen Umstand zu beheben, ist die Entwicklung eines eigenen Systems zum Bewegen und Animieren des Menschen unausweichlich.
|
||||
Dieses System muss, wie im Konzept beschrieben, Steuerbefehle von außen empfangen, umsetzen und Feedback liefern können.
|
||||
|
||||
\section{Roboterumgebung (MoveIt2)}
|
||||
MoveIt2 ist das empfohlene ROS2 Paket für Bewegungsplanung von Robotern.
|
||||
Das System besteht aus meheren Komponmenten, welche in ihrer Gesamtheit den Bereich der Bewegungsplanung abdecken.
|
||||
Der Nutzer kann mit MoveIt auf mehreren Wegen Steuerbefehle für den Roboter absenden.
|
||||
|
||||
Die einfachste Art der Inbetriebnahme ist über das mitgelieferte RViz-Plugin und die demo-Launch-Files, welche durch den Setupassistenten für den Roboter generiert werden.
|
||||
Dort können Bewegungen durch das Bewegen von Markierungen oder in der Simulation geplant und ausgeführt werden.
|
||||
|
||||
Da sich ein solches System nur beschränkt zur Automatisierung durch Software eignet, existieren auch noch andere Schnitstellen.
|
||||
Für die Sprache Python existierte früher noch das moveit_commander Paket, welches den Zugriff auf MoveIt in Pyhon erlaubt, welches aber aktuell noch nicht portiert wurde. \cite{moveitpython}
|
||||
Die direkte Nutzung der C++-API ist aktuell die einzige offizielle Möglichkeit, mit MoveIt auf einer abstrakteren Ebene zu interagieren.
|
||||
Natürlich können die Befehle auch direkt an die entsprechenden Topics gesendet werden, was jedoch Erfahrung mit den verwendeten Datenstrukturen benötigt.
|
||||
|
||||
Durch diese Schnittstelle erhält die sogenannte MoveGroup ihre Informationen über die gewünschte Bewegung.
|
||||
Diese Daten können durch eine OccupancyMap ergänzt werden, welche die Bereiche beschreibt, welche sich um den Roboter befinden.
|
||||
Eine solche Erweiterung erlaubt die Nutzung von Kollisionsvermeidung mit Objekten im Planungsbereich.
|
||||
|
||||
Die Planung der Bewegung wird durch einen der zahlreichen implementierten Solver erledigt, welcher durch die MoveGroup aufgerufen wird.
|
||||
Um die generierte Bewegung umzusetzen, werden die gewünschten Gelenkpositionen als Abfolge an ros_control weitergegeben.
|
||||
Dabei können sowohl echte Hardwaretreiber, aber auch simulierte Roboter genutzt werden.
|
||||
Der Erfolg der gesamten Pipeline kann dabei durch einen Feedbackmechanismus überwacht werden.
|
||||
|
||||
Im Falle von Gazebo wird ign_ros_control genutzt, welches die benötigten ros_control Controller in die Simulation einbindet.
|
||||
Diese können dann wie normale Controller von ros_control genutzt werden.
|
||||
|
||||
Dieser Ablauf ist auch im Anhang unter Abbildung \ref{moveitpipeline} visualisiert.
|
||||
|
||||
\chapter{Umsetzung}
|
||||
|
||||
\section{Grundlegender Systemaufbau}
|
||||
Der grundlegende Systemaufbau musste stark modifiziert werden, wie in Abbildung \ref{umsetzung_overview} zu sehen, um die gesetzten Aufgaben erfüllen zu können.
|
||||
Dabei fallen vor allem die überarbeitete Kommunikation mit dem simulierten Menschen und die komplexere Steuerung des Roboterarms auf.
|
||||
|
||||
Die komplexere Steuerung des Roboters ist auf die Struktur von MoveIt zurückzuführen, welches in viele einzelne Teilmodule aufgeteilt ist.
|
||||
Diese müssen durch ihren modularen Aufbau, welcher für die Vielseitigkeit verantwortlich ist, einzeln konfiguriert werden, um miteinander in Interaktion treten zu können.
|
||||
|
||||
Außerdem musste die Kommunikation des Modells des Menschen überarbeitet werden, da die ROS-Kommunikation in Gazebo nur mit Einschränkungen möglich ist.
|
||||
|
||||
\begin{figure}[]
|
||||
\includegraphics[width=\textwidth]{Umsetzung_Overview}
|
||||
\centering
|
||||
\caption{Visualisierung des überarbeiteten Konzepts}
|
||||
\label{umsetzung_overview}
|
||||
\end{figure}
|
||||
|
||||
-BehaviorTree -> ActorPluginServer -> ActorPluginServer
|
||||
|
||||
-BehaviorTree -> MoveIt -> ros\_control -> Gazebo
|
||||
\section{Mensch}
|
||||
\subsection{Übersicht (Diagramme)}
|
||||
Das angepasste Verfahren zur Menschensteuerung in der Simulation verwendet mehrere Kommunikationswege.
|
||||
Als erstes wird eine Bewegungs- oder Animationsanfrage an den ROS-Action-Server im ActorServer gesendet.
|
||||
Wenn die Simulation aktuell keinen Befehl ausführt, wird diese Anfrage akzeptiert, ansonsten wird sie abgebrochen.
|
||||
Daraufhin werden die Daten der Anfrage über eine Posix-Message-Queue vom ActorServer an das ActorPlugin in Gazebo gesendet.
|
||||
|
||||
Dieses verwendet die Daten, um eine interne State-Machine in den entsprechenden Zustand zu setzen, welcher zur Ausführung des Befehls benötigt wird.
|
||||
|
||||
Um Feedback an den Client des ROS-Action-Servers übertragen zu können, werden bei der Ausführung von Befehlen oder Zustandswechseln des ActorPlugins Feedbackdaten über eine separate MessageQueue zurück an den ActorServer übertragen.
|
||||
Diese werden durch den ActorServer aufbereitet, da nicht alle Daten für die jeweilige laufende Aktion relevant sind und an den ROS-Action-Client gesendet.
|
||||
|
||||
Um diese Befehle in der Simulation auch visuell umsetzen zu können, werden weitere Animationen für das Modell des Menschen benötigt, welche im Kontext der zur erfüllenden Aufgabe relevant sind.
|
||||
Dafür muss dan Modell in einen animierbaren Zustand gebracht werden, in welchem dann weitere Animationen erstellt und in die Simulation eingebunden werden können.
|
||||
\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}
|
||||
Bei der Implementierung des ActorPlugins stellte sich heraus, dass die nun im ActorServer ausgelagerten Befehle mit den Befehlen im ros_control-Plugin kollidieren.
|
||||
Dies geschieht, da beide Plugins rclcpp, eine Bibliothek zur Kommunikation mit ROS, verwenden.
|
||||
|
||||
In dieser Bibliothek wird eine globale Instanz angelegt, welche den Zustand des Kommunikationsprotokolls abbildet.
|
||||
Da jedoch von beiden Plugins auf diesen Zustand zugegriffen wird, kommt es zur Problemen, da kein Synchronisationsmechanismus existiert.
|
||||
Die dadurch entstehenden gleichzeitigen Zugriffe auf die selben Ressourcen führen zur Terminierung des Programms.
|
||||
|
||||
Eine Anpassung beider Plugins auf die gemeinsame Nutzung einer Ressource ist möglich, erfordert jedoch weitere Anpassungen, welche zeitlich nur schwer planbar sind.
|
||||
Die Nutzung eines separaten Dienstes, welcher keinen globalen Kontext benötigt, ist die sicherste Lösung des Problems.
|
||||
Durch einen solchen Dienst werden auch in Zukunft keine Plugins gestört, auch wenn sie selbigen Dienst zur Kommunikation verwenden.
|
||||
|
||||
Die Auswahl eines Dienstes wurde dabei aus einer Reihe an unterschielichen Möglichkeiten getroffen.
|
||||
Eine REST-API hat den Vorteil, dass sie durch fast jede Programmiersprache genutzt werden kann, die Sockets unterstützt, hat jedoch keinen einheitlichen Feedbackmechanismus.
|
||||
Die neueren Websockets bieten die Möglichkeit, bidirektional Daten zu übertragen und erlauben somit Feedback an das aufrufende Programm.
|
||||
Beide Technologien basieren jedoch auf einem Webserver, welcher auf einem bestimmten Port des Systems ausgeführt werden muss, was Kollisionen mit anderen Serveices ermöglicht.
|
||||
Die Portnummer kann zwar geändert werden, ist jedoch nicht einfach mit einer Komponente assoziierbar, was sie zu einer ``Magischen Zahl'' macht.
|
||||
Dies sorgt für schlechte Lesbarkeit in einem wichtigen Teil des Kontrollflusses.
|
||||
Außerdem besitzen beide Terchnologien durch TCP oder UDP und HTTP relativ großen Protokolloverhead, welcher bei den hohen Updateraten der Gazebo-Simulation zu Problemen führen könnte.
|
||||
|
||||
Eine andere Möglichkeit ist die Nutzung von ``shared memory'', einem geteilten Speicherbereich zwischen beiden Programmen.
|
||||
Dieser kann zur bidirektionalen Kommunikation genutzt werden, da beide Programme auf den Speicher zugreifen können.
|
||||
Alle Zugriffe auf den Bereich sind extrem schnell, was diese Technik ideal zur schnellen Datenübertragung zwischen Prozessen macht.
|
||||
Durch das erlauben gleichzeitiger Zugriffe kann es hierbei vorkommen, dass die selbe Adresse gleichzeitig von einem Programm gelesen und von einem anderen geschrieben wird.
|
||||
Die dabei gelesenen Daten können Schäden aufweisen, weswegen Zugriffe auf den Speicherbereich koordiniert werden müssen.
|
||||
|
||||
Die letzte betrachtete Methode ist die Verwendung einer Message Queue.
|
||||
Hier wird im Betriebssystem ein Speicherbereich mit bestimmter Größe für den Datenaustauch reserviert.
|
||||
Dieser Bereich besitzt ein Identifikationsmerkmal, mit welchem Anwendungen Zugriff auf diesen erlangen können.
|
||||
Ein Programm kann in diesem Bereich Nachrichten ablegen, welche durch das andere Programm gelesen werden können.
|
||||
Die Koordinierung der Zugriffe erfolgt dabei durch das Betriebssystem, was gleichzeitige Zugriffe, wie bei shared memory, aussschließt.
|
||||
Hierdurch kommt es zu einem Anstieg an Latenzzeit, jedoch ist dieser ausreichend gering.
|
||||
|
||||
Die Wahl des Dienstes fiel auf eine MessageQueue, jedoch existieren unter Linux 2 unabhängige Implementationen.
|
||||
Die erste Implementation ist die System V MessageQueue, und verwendet zur Identifikation einfache Integer.
|
||||
Eine Spezialität dieser alten Implementation ist das Sortieren der Nachrichten nach Nachrichtentyp in der gleichen Warteschlange.
|
||||
Die neuere Implementation der POSIX MessageQueue bietet einige weitere Funktionen, wie zum Beispiel aynchrone Benachrichtigungen bei neuen Nachrichten, Quality of Service und nutzt bis zu 256 Zeichen lange Strings zur Identifikation.
|
||||
|
||||
Die ausgewählte Implementation ist die neuere POSIX-Implementation einer Message Queue, da diese basierend auf den Erfahrungen mit der System V Implementation verbessert wurde.
|
||||
\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
|
||||
@ -585,7 +208,7 @@ Darunter fallen eine grundlegende Strukturänderung der unterliegenden Engine, w
|
||||
\printbibliography
|
||||
\markboth{Anhang}{Anhang}
|
||||
\begin{figure}[h]
|
||||
\includegraphics[width=14cm]{moveit_pipeline}
|
||||
\includegraphics[width=14cm]{img/moveit_pipeline}
|
||||
\caption{Visualisierung der MoveIt Pipeline\cite{moveitpipeline}}
|
||||
\label{moveitpipeline}
|
||||
\end{figure}
|
||||
|
||||
@ -35,3 +35,27 @@ archive=true
|
||||
encoding=
|
||||
highlight=
|
||||
mode=
|
||||
|
||||
[item:tex/1_Einleitung.tex]
|
||||
archive=true
|
||||
encoding=UTF-8
|
||||
highlight=LaTeX
|
||||
mode=LaTeX
|
||||
|
||||
[item:tex/2_Konzept.tex]
|
||||
archive=true
|
||||
encoding=UTF-8
|
||||
highlight=LaTeX
|
||||
mode=LaTeX
|
||||
|
||||
[item:tex/3_Auswahl.tex]
|
||||
archive=true
|
||||
encoding=UTF-8
|
||||
highlight=LaTeX
|
||||
mode=LaTeX
|
||||
|
||||
[item:tex/4_Umsetzung.tex]
|
||||
archive=true
|
||||
encoding=UTF-8
|
||||
highlight=LaTeX
|
||||
mode=LaTeX
|
||||
|
||||
52
tex/1_Einleitung.tex
Normal file
52
tex/1_Einleitung.tex
Normal file
@ -0,0 +1,52 @@
|
||||
\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
|
||||
|
||||
-Parametervergleiche 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 Kollaborationsszenario 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
|
||||
62
tex/2_Konzept.tex
Normal file
62
tex/2_Konzept.tex
Normal file
@ -0,0 +1,62 @@
|
||||
\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.
|
||||
|
||||
\begin{figure}[]
|
||||
\includegraphics[]{img/Konzept_Overview}
|
||||
\centering
|
||||
\caption{Visualisierung des Konzepts}
|
||||
\label{concept_overview}
|
||||
\end{figure}
|
||||
|
||||
\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.
|
||||
Dieses Modell sollte die physikalischen Eigenschaften des Roboters möglichst gut wiederspiegeln.
|
||||
Anhand dieses Modells kann der Roboter dann in der Simulation dargestellt werden und mit anderen Objekten interagieren.
|
||||
|
||||
\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.
|
||||
|
||||
\section{Behavior Trees}
|
||||
Häufig wird Verhalten in State-Machines ausgedrückt, welche jedoch einige Nachteile besitzen.
|
||||
State-Machines werden ab einer gewissen Größe schnell unübersichtlich.
|
||||
Dies erschwert die schnelle Erfassung von Abfolgen und Zustandsübergängen bei Änderungen am Code, welche jedoch essentiell für den Betrieb einer Maschine sind.
|
||||
Um diese Probleme zu adressieren, entstand das Konzept der Behavior Trees.
|
||||
|
||||
Ein Behavior Tree ist eine Struktur, um Verhalten als ein Baum zu beschreiben.
|
||||
Der Ablauf startet vom sogenannten Root, der Wurzel des Baums.
|
||||
Von dort an werden sogenannte Nodes, welche je nach Node unterschiedliches Verhalten abbilden, miteinander verbunden.
|
||||
Die Nodes werden untereinander angeordnet, welches die Relation der Nodes zueinander beschreibt.
|
||||
Jede Node hat dabei entweder die Root-Node oder eine andere Node über ihr im Baum und eine beliebige Anzahl an Nodes unter sich.
|
||||
Hierbei gibt es mehrere grundlegende Arten von Tree-Nodes.
|
||||
\begin{description}
|
||||
\item[Aktions-Nodes]
|
||||
beschreiben einzelne ausführbare Aktionen. Mit Hilfe von Parametern kann ihr Verhalten von anderen Nodes beeinflusst werden.
|
||||
\item[Dekorations-Nodes]
|
||||
können den Rückgabewert einer anderen Node modifizieren. Häufig existieren hier Negation, garantierter Erfolg und garantierter Fehler.
|
||||
\item[Sequenz-Nodes]
|
||||
beschreiben eine nacheinander ausgeführte Abfolge von anderen Nodes, welche mit spezifischen Randbedingungen weiter fortschreitet.
|
||||
\item[Fallback-Nodes]
|
||||
werden verwendet, um Verhalten zu definieren, welches nur bei Fehlern in vorherigen Nodes ausgeführt wird.
|
||||
\end{description}
|
||||
|
||||
In dieser Arbeit sollen BehaviorTrees für die Steuerung von Mensch und Roboter verwendet werden.
|
||||
Die hierfür erstellten Nodes sollen universell gestaltet werden, um alle Szenarien, welche in dieser Arbeit bearbeitet werden, abzudecken.
|
||||
171
tex/3_Auswahl.tex
Normal file
171
tex/3_Auswahl.tex
Normal file
@ -0,0 +1,171 @@
|
||||
\chapter{Komponenten-/Softwareauswahl}
|
||||
\section{Dienstumgebung (ROS2)}
|
||||
\subsection{Auswahl}
|
||||
Durch eine Dienstumgebung werden häufig benötigte Funktionen bereitgestellt, welche in Programmen genutzt werden können.
|
||||
Dabei ist es irrelevant, ob diese für simulierte, aber auch echte Hardware, genutzt werden.
|
||||
Bei einer Dienstumgebung für Roboter gehören zu den grundlegendn Aspekten die Nachrichtenübergabe zwischen einzelen interagierenden Programmen, um eine gemeinsame Basis für ein einfach erweiterbares System zu schaffen.
|
||||
|
||||
In diesem Bereich sticht ROS als Dienstumgebung für Roboter hervor, da es sich um ein etabliertes, quelloffenes und häufig verwendetes System handelt.
|
||||
Es bietet die oben genannten Aspekte und einige weitere Verbesserungen, welche später näher beleuchtet werden.
|
||||
Die neuste Version ROS2 bietet dabei einige Verbesserungen im Vergleich zu früheren Version ROS1.
|
||||
Ein neues Nachrichtenformat mit Quality of Service kann zum Beispiel Nachrichten vorhalten und über sowohl TCP als auch UDP kommunizieren.
|
||||
Außerdem werden nun neben CMake auch andere Buildsysteme unterstützt, unter anderem auch Python.
|
||||
|
||||
Generell existieren im Feld der Roboter-Dienstumgebungen keine Alternativen mit ähnlichem Funktionsumfang und gleicher Reichweite, jedoch sind andere Systeme mit anderen Nachrichtenformaten denkbar.
|
||||
Vor allem die unzähligen ROS-Bibliotheken, welche von Nutzern des Systems über die Jahre erstellt wurden, machen das System so populär.\cite{rospackages}
|
||||
|
||||
-Alternative Ökosysteme mit gleichem Umfang wie ROS existieren nicht.
|
||||
-ROS2
|
||||
-Andere (nur) Messagingsysteme
|
||||
-LCM
|
||||
-ZeroMQ
|
||||
\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 dabei um eine gemeinsame Grundlage für Programme und Daten, welche durch ROS bereitgestellt wird.
|
||||
|
||||
Einzelne Bestandteile in der Umgebung sind dabei in Pakete gegliedert.
|
||||
Ein Paket kann beliebig viele Daten und Programme beinhalten, welche in zwei Dateien beschrieben werden.
|
||||
In CMakeLists.txt befinden sich Buildinstruktionen für den Compiler, falls sich Programme im Paket befinden.
|
||||
Außerdem können bestimmte Pfade aus dem Paket exportiert werden, sodass diese später im Workspace verfügbar sind.
|
||||
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 und eines Workspaces mit angelegt werden.
|
||||
Das Skript des Pakets fügt nur dieses Paket der Umgebung hinzu, das Skript des Workspaces führt alle Skripte der enthaltenen Pakete aus, um diese der Umgebung hinzuzufügen.
|
||||
|
||||
\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, früher auch V-REP genannt, ist eine Robotersimulationsumgebung mit integriertem Editor und ROS-Unterstützung.
|
||||
Es unterstützt viele Sprachen (C/C++, Python, Java, Lua, Matlab oder Octave) zur Entwicklung von Erweiterungen des Simulators.
|
||||
Der Simulator selbst unterstützt Menschliche Aktoren, jedoch können diese nur Animationen abspielen oder zusammen mit Bewegungen abspielen.
|
||||
CoppeliaSim existiert in 3 Versionen, welche sich im Funktionsumfang unterscheiden, jedoch hat nur die professionelle Version Zugriff auf alle Funktionen und Verwendungsszenarien.
|
||||
|
||||
Gazebo Ignition ist wie CoppeliaSim eine Robotersimulationsumgebung, jedoch ohne integrierten Editor und direkte ROS-Unterstützung.
|
||||
Gazebo setzt wie CoppeliaSim auf Erweiterungen, welche die gewünschten Funktionen einbinden können.
|
||||
Zum Beispiel existiert auch eine ROS-Brücke, welche die Anbindung an ROS ermöglicht.
|
||||
Auch hier unterstützt der Simulator nur Animationen für menschliche Aktoren.
|
||||
Das Projekt ist Open Source, unter der Apache Lizenz (Version 2.0), was die Verwendung in jeglichen Szenarien erleichtert.
|
||||
|
||||
Unity hingegen ist primär eine Grafikengine für Nutzung in Computerspielen.
|
||||
Es existieren mehrere Systeme zur Anbindung der Engine an ROS, vor allem das offizielle ``Robotics Simulation''-Paket und ZeroSim.
|
||||
Beide Systeme erlauben die Erweiterung der Gameengine um die Simulation von Robotern.
|
||||
Unity besitzt eine gute Dokumentation, die vor allem auf die Nutzung im Einsteigerbereich zurückzuführen ist.
|
||||
Auch die Optionen zur Menschensimulation sind gut, da diese häufig in Spielen verwendet werden.
|
||||
Ein großer Nachteil hingegen ist die Lizenz, welche nur für Einzelpersonen kostenlos ist.
|
||||
|
||||
Die Unreal Engine ist wie Unity eine Grafikengine aus dem Spielebereich.
|
||||
Auch hier ist die Menschensimulation aufgrund oben genannter Gründe gut möglich.
|
||||
Jedoch existiert für Unreal Engine keine offizielle Lösung zur Anbindung an ROS2.
|
||||
Die Programmierung der Engine erfolgt in C++, was einer Drittlösung erlaubte, eine ROS-Anbindung für Unreal Engine zu erstellen.
|
||||
Die Lizenz der Unreal Engine erlaubt die kostenfreie Nutzung bis zu einem gewissen Umsatz mit der erstellten Software.
|
||||
|
||||
Eine weitere Möglichkeit zur Simulation stellt die Grafikengine Godot dar.
|
||||
Im Vergleich zu Unity und Unreal Engine ist Godot quelloffene Software unter der MIT-Lizenz.
|
||||
Auch hier stellt die Simulation von menschlichen Aktoren eine Standartaufgabe dar, jedoch befinden sich Teile des dafür verwendeten Systems derzeit in Überarbeitung.
|
||||
Auch für diese Engine existiert eine ROS2-Anbindung, jedoch ist diese nicht offiziell.
|
||||
|
||||
Jede der drei Gameengines besitzt ein integriertes Physiksystem, welches die Simulation von starren Körpern und Gelenken erlaubt.
|
||||
Aus diesen Funktionen könnte ein Roboterarm aufgebaut werden, welcher dann durch eine der ROS-Brücken der Engines gesteuert werden kann.
|
||||
|
||||
Die Wahl der Simulationsumgebung fiel auf Gazebo Ignition, da dieser Simulator bereits im ROS-Framework etabliert ist.
|
||||
Dabei erlauben die offizielle ROS-Anbindung und offene Lizenz eine zuverlässige Verwendung in unterschidlichsten Szenarien.
|
||||
|
||||
\subsection{Robotersimulation}
|
||||
Für die Robotersimulation wird ein Modell des Roboters benötigt, in welchem dieser für die Siimulationsumgebung beschrieben wird.
|
||||
Gazebo nutzt hierfür .srdf-Dateien, welche auf xml basieren.
|
||||
In diesen werden die einzelnen Glieder des Arms und die verbindenden Gelenke beschrieben.
|
||||
|
||||
Jedes Glied des Modells besitzt eine Masse, einen Masseschwerpunkt und eine Trägheitsmatrix für die Physiksimulation in Gazebo.
|
||||
Außerdem werden Modelle für die visuelle Repräsentation in Gazebo und die Kollisionserkennung in der Physiksimulation hinterlegt.
|
||||
Für beide existieren einfache Modelle wie Zylinder, Boxen und Kugeln.
|
||||
Da diese Formen nicht jeden Anwendungsfall abdecken und in der visuellen Repräsentation nicht ausreichen, können auch eigene Modelle hinterlegt werden.
|
||||
|
||||
Gelenke werden separat von den Gliedern definiert und verbinden jeweils zwei Glieder miteinander.
|
||||
Durch das Aneinanderreihen von mehreren Gliedern und Gelenken kann so jeder Roboteraufbau beschrieben werden.
|
||||
Jedes Gelenk besitzt eine Position und Rotation im Raum, um dessen Effekte je nach Typ des Gelenks berechnen zu können.
|
||||
Aspekte wie Reibung und Dämpfung können auch für die Physiksimulation angegeben werden.
|
||||
Folgende Typen von Gelenken können in urdf genutzt werden:
|
||||
\begin{description}
|
||||
\item[freie Gelenke]
|
||||
ermöglichen vollständige Bewegung in allen 6 Freiheitsgraden. Sie stellen den normalen Zustand der Gelenke zueinander dar.
|
||||
\item[planare Gelenke]
|
||||
erlauben Bewegungen senkrecht zur Achse des Gelenks. Sie werden für zum Beispiel Bodenkollisionen eingesetzt.
|
||||
\item[feste Gelenke]
|
||||
sperren alle 6 Freiheitsgrade und werden häufig zur Plazierung von Objekten in einer Szene genutzt.
|
||||
\item[kontinuierliche Gelenke]
|
||||
erlauben die beliebige Rotation um die Achse des Gelenks. Sie sind nur selten in rotierenden Gelenken mit Schleifkontakten zu finden.
|
||||
\item[drehbare Gelenke]
|
||||
verhalten sich wie kontinuerliche Verbindungen, haben jedoch minimale und maximale Auslenkungen. Sie sind die häufigste Art von Gelenken in Roboterarmen.
|
||||
\item[prismatische Gelenke]
|
||||
ermöglichen die Bewegung entlang der Achse des Gelenks. Denkbare Anwendungsfälle sind simulierte lineare Aktuatoren.
|
||||
\end{description}
|
||||
\subsection{Menschensimulation}
|
||||
Gazebo besitzt bereits ein einfaches Animationssystem für bewegliche Aktoren, welches auch für Menschen nutzbar ist.
|
||||
Es existiert bereits ein Modell eines Menschen mit mehreren Animationen, welche allein abgespielt, oder an Bewegungen gekoppelt werden können.
|
||||
Dadurch ist eine Laufanimation realisierbar, welche synchronisiert zur Bewegung abgespielt wird.
|
||||
|
||||
Jedoch ist dies nur unter der Bedingung möglich, dass der gesamte Bewegungsablauf zum Simulationsstart bekannt ist.
|
||||
Dies ist auf die Definition der Pfade, welche die Bewegung auslösen, zurückzuführen.
|
||||
Diese können nur in der .sdf-Datei des Aktoren definiert werden, was Veränderungen zur Laufzeit ausschließt.
|
||||
Durch diesen Umstand ist der mögliche Simulationsumfang nicht ausreichend.
|
||||
|
||||
Um diesen Umstand zu beheben, ist die Entwicklung eines eigenen Systems zum Bewegen und Animieren des Menschen unausweichlich.
|
||||
Dieses System muss, wie im Konzept beschrieben, Steuerbefehle von außen empfangen, umsetzen und Feedback liefern können.
|
||||
|
||||
\section{Roboterumgebung (MoveIt2)}
|
||||
MoveIt2 ist das empfohlene ROS2 Paket für Bewegungsplanung von Robotern.
|
||||
Das System besteht aus meheren Komponmenten, welche in ihrer Gesamtheit den Bereich der Bewegungsplanung abdecken.
|
||||
Der Nutzer kann mit MoveIt auf mehreren Wegen Steuerbefehle für den Roboter absenden.
|
||||
|
||||
Die einfachste Art der Inbetriebnahme ist über das mitgelieferte RViz-Plugin und die demo-Launch-Files, welche durch den Setupassistenten für den Roboter generiert werden.
|
||||
Dort können Bewegungen durch das Bewegen von Markierungen oder in der Simulation geplant und ausgeführt werden.
|
||||
|
||||
Da sich ein solches System nur beschränkt zur Automatisierung durch Software eignet, existieren auch noch andere Schnitstellen.
|
||||
Für die Sprache Python existierte früher noch das moveit_commander Paket, welches den Zugriff auf MoveIt in Pyhon erlaubt, welches aber aktuell noch nicht portiert wurde. \cite{moveitpython}
|
||||
Die direkte Nutzung der C++-API ist aktuell die einzige offizielle Möglichkeit, mit MoveIt auf einer abstrakteren Ebene zu interagieren.
|
||||
Natürlich können die Befehle auch direkt an die entsprechenden Topics gesendet werden, was jedoch Erfahrung mit den verwendeten Datenstrukturen benötigt.
|
||||
|
||||
Durch diese Schnittstelle erhält die sogenannte MoveGroup ihre Informationen über die gewünschte Bewegung.
|
||||
Diese Daten können durch eine OccupancyMap ergänzt werden, welche die Bereiche beschreibt, welche sich um den Roboter befinden.
|
||||
Eine solche Erweiterung erlaubt die Nutzung von Kollisionsvermeidung mit Objekten im Planungsbereich.
|
||||
|
||||
Die Planung der Bewegung wird durch einen der zahlreichen implementierten Solver erledigt, welcher durch die MoveGroup aufgerufen wird.
|
||||
Um die generierte Bewegung umzusetzen, werden die gewünschten Gelenkpositionen als Abfolge an ros_control weitergegeben.
|
||||
Dabei können sowohl echte Hardwaretreiber, aber auch simulierte Roboter genutzt werden.
|
||||
Der Erfolg der gesamten Pipeline kann dabei durch einen Feedbackmechanismus überwacht werden.
|
||||
|
||||
Im Falle von Gazebo wird ign_ros_control genutzt, welches die benötigten ros_control Controller in die Simulation einbindet.
|
||||
Diese können dann wie normale Controller von ros_control genutzt werden.
|
||||
|
||||
Dieser Ablauf ist auch im Anhang unter Abbildung \ref{moveitpipeline} visualisiert.
|
||||
225
tex/4_Umsetzung.tex
Normal file
225
tex/4_Umsetzung.tex
Normal file
@ -0,0 +1,225 @@
|
||||
\chapter{Umsetzung}
|
||||
|
||||
\section{Grundlegender Systemaufbau}
|
||||
Der grundlegende Systemaufbau musste stark modifiziert werden, wie in Abbildung \ref{umsetzung_overview} zu sehen, um die gesetzten Aufgaben erfüllen zu können.
|
||||
Dabei fallen vor allem die überarbeitete Kommunikation mit dem simulierten Menschen und die komplexere Steuerung des Roboterarms auf.
|
||||
|
||||
Die komplexere Steuerung des Roboters ist auf die Struktur von MoveIt zurückzuführen, welches in viele einzelne Teilmodule aufgeteilt ist.
|
||||
Diese müssen durch ihren modularen Aufbau, welcher für die Vielseitigkeit verantwortlich ist, einzeln konfiguriert werden, um miteinander in Interaktion treten zu können.
|
||||
|
||||
Außerdem musste die Kommunikation des Modells des Menschen überarbeitet werden, da die ROS-Kommunikation in Gazebo nur mit Einschränkungen möglich ist.
|
||||
|
||||
\begin{figure}[]
|
||||
\includegraphics[width=\textwidth]{img/Umsetzung_Overview}
|
||||
\centering
|
||||
\caption{Visualisierung des überarbeiteten Konzepts}
|
||||
\label{umsetzung_overview}
|
||||
\end{figure}
|
||||
\section{Mensch}
|
||||
\subsection{Übersicht}
|
||||
Das angepasste Verfahren zur Menschensteuerung in der Simulation verwendet mehrere Kommunikationswege.
|
||||
Als erstes wird eine Bewegungs- oder Animationsanfrage an den ROS-Action-Server im ActorServer gesendet.
|
||||
Wenn die Simulation aktuell keinen Befehl ausführt, wird diese Anfrage akzeptiert, ansonsten wird sie abgebrochen.
|
||||
Daraufhin werden die Daten der Anfrage über eine Posix-Message-Queue vom ActorServer an das ActorPlugin in Gazebo gesendet.
|
||||
|
||||
Dieses verwendet die Daten, um eine interne State-Machine in den entsprechenden Zustand zu setzen, welcher zur Ausführung des Befehls benötigt wird.
|
||||
|
||||
Um Feedback an den Client des ROS-Action-Servers übertragen zu können, werden bei der Ausführung von Befehlen oder Zustandswechseln des ActorPlugins Feedbackdaten über eine separate MessageQueue zurück an den ActorServer übertragen.
|
||||
Diese werden durch den ActorServer aufbereitet, da nicht alle Daten für die jeweilige laufende Aktion relevant sind und an den ROS-Action-Client gesendet.
|
||||
|
||||
Um diese Befehle in der Simulation auch visuell umsetzen zu können, werden weitere Animationen für das Modell des Menschen benötigt, welche im Kontext der zur erfüllenden Aufgabe relevant sind.
|
||||
Dafür muss dan Modell in einen animierbaren Zustand gebracht werden, in welchem dann weitere Animationen erstellt und in die Simulation eingebunden werden können.
|
||||
\subsection{Modellierung}
|
||||
Um neue Animationen für den Menschen in der Simulation erstellen zu können, muss ein Modell für diesen erstellt werden.
|
||||
Dafür wurde eine der inkludierten Animationen in Blender geöffnet und das visuelle Modell kopiert.
|
||||
|
||||
Dieses Modell war auf Grund von vielen inneren Falten nur schlecht für Animationen geeignet, weshalb das Modell an diesen Stellen vereinfacht wurde.
|
||||
Eine solches Vorgehen beugt Anomalien bei der Animation durch unterschiedliche Verschiebung der Strukturen vor, welche vom inneren des Modells hervortreten können.
|
||||
|
||||
Nun musste das visuelle Modell mit neuen Animationsknochen versehen werden, da die in der Animation vorhandenen Knochen nicht verbunden sind.
|
||||
Diese Knochen bilden ein Skelett, welches zur Animation bewegt werden kann.
|
||||
|
||||
In Blender können sogenannte Constraints verwendet werden, um die Gelenke in Gruppen zusammenzufassen und genauer zu spezifizieren.
|
||||
Dazu wurde das Plugin ``Rigify'' verwendet, welches ein komplettes Skelett generiert und konfiguriert.
|
||||
|
||||
Dieses generierte Skelett kann nun an das Modell angepasst werden.
|
||||
Um eine bessere Übersicht zu ermöglichen, sollten als erstes alle nicht benötigten Skeletteile, wie zum Beispiel für Gesichtsanimationen, entfernt werden.
|
||||
Danach werden alle Knochen dem visuellen Modell angepasst.
|
||||
Dabei muss auf die Ausrichtung der Knochen zueinander geachtet werden.
|
||||
Das Kreuzprodukt der Vektoren beider Knochensegmente ist die Richtung der Beugeachse, welche sich im Verbindungspunkt beider Knochen befindet.
|
||||
Ist diese nicht richtig ausgerichtet, wenn zum Beispiel beide Knochen auf einer Gerade liegen, verbiegen sich Gelenke bei der Verwendung von inverser Kinematik zur Positionsvorgabe falsch.
|
||||
|
||||
Das hier erstellte, verbesserte Rigify-Skelett kann nun einfacher animiert werden.
|
||||
Dies liegt vor allem an neuen Markierungen in Blender, welche durch mehrere Constraints viele andere Knochen beeinflussen.
|
||||
Beispielswise können Fuß- und Handmarkierungen gesetzt werden, welche die Rotation des Fußes oder der Hand, aber auch gleichzeitig die inverse Kinematik des gesamten Beins oder Arms automatisieren.
|
||||
Selbiges gilt für neue Markierungen, welche zum Beispiel Hüft- und Kopfbewegungen vereinfachen.
|
||||
|
||||
Das Exportieren eines solchen Rigs ist jedoch schwierig, da viele Grafikengines keine verschachtelten Skelette verstehen.
|
||||
Dies ist auch der Grund, warum die Skelette beim initialen Import mitgelieferter Animationen nicht verbunden waren.
|
||||
|
||||
Um aus einem existierenden, vollständig verbundenen Skelett einzelne Knochen zu extrahieren exisitiert ein weiteres Plugin mit dem Namen ``GameRig''.
|
||||
Dieses separiert die Knochen wieder, um die Animationen für Grafikengines exportieren zu können.
|
||||
|
||||
Nach dieser Veränderung kann die Animation als Collada-Animation exportiert werden.
|
||||
Dabei muss darauf geachtet werden, dass die vorwärts gerichtete Achse auf die richtige Achse gestellt ist.
|
||||
Außerdem ist es später einfacher, wenn nur eine Animation in jeder Datei vorhanden ist.
|
||||
Dies ist dem Fakt geschuldet, dass diese anderen Animationen zwar verfügbar sind, jedoch aber nur durch einen Index unterscheidbar sind, der von der Reihenfolge der exportierten Animationen abhängig ist.
|
||||
|
||||
\subsection{Programmierung}
|
||||
\subsubsection{Message Queue}
|
||||
Bei der Implementierung des ActorPlugins stellte sich heraus, dass die nun im ActorServer ausgelagerten Befehle mit den Befehlen im ros_control-Plugin kollidieren.
|
||||
Dies geschieht, da beide Plugins rclcpp, eine Bibliothek zur Kommunikation mit ROS, verwenden.
|
||||
|
||||
In dieser Bibliothek wird eine globale Instanz angelegt, welche den Zustand des Kommunikationsprotokolls abbildet.
|
||||
Da jedoch von beiden Plugins auf diesen Zustand zugegriffen wird, kommt es zur Problemen, da kein Synchronisationsmechanismus existiert.
|
||||
Die dadurch entstehenden gleichzeitigen Zugriffe auf die selben Ressourcen führen zur Terminierung des Programms.
|
||||
|
||||
Eine Anpassung beider Plugins auf die gemeinsame Nutzung einer Ressource ist möglich, erfordert jedoch weitere Anpassungen, welche zeitlich nur schwer planbar sind.
|
||||
Die Nutzung eines separaten Dienstes, welcher keinen globalen Kontext benötigt, ist die sicherste Lösung des Problems.
|
||||
Durch einen solchen Dienst werden auch in Zukunft keine Plugins gestört, auch wenn sie selbigen Dienst zur Kommunikation verwenden.
|
||||
|
||||
Die Auswahl eines Dienstes wurde dabei aus einer Reihe an unterschielichen Möglichkeiten getroffen.
|
||||
Eine REST-API hat den Vorteil, dass sie durch fast jede Programmiersprache genutzt werden kann, die Sockets unterstützt, hat jedoch keinen einheitlichen Feedbackmechanismus.
|
||||
Die neueren Websockets bieten die Möglichkeit, bidirektional Daten zu übertragen und erlauben somit Feedback an das aufrufende Programm.
|
||||
Beide Technologien basieren jedoch auf einem Webserver, welcher auf einem bestimmten Port des Systems ausgeführt werden muss, was Kollisionen mit anderen Serveices ermöglicht.
|
||||
Die Portnummer kann zwar geändert werden, ist jedoch nicht einfach mit einer Komponente assoziierbar, was sie zu einer ``Magischen Zahl'' macht.
|
||||
Dies sorgt für schlechte Lesbarkeit in einem wichtigen Teil des Kontrollflusses.
|
||||
Außerdem besitzen beide Terchnologien durch TCP oder UDP und HTTP relativ großen Protokolloverhead, welcher bei den hohen Updateraten der Gazebo-Simulation zu Problemen führen könnte.
|
||||
|
||||
Eine andere Möglichkeit ist die Nutzung von ``shared memory'', einem geteilten Speicherbereich zwischen beiden Programmen.
|
||||
Dieser kann zur bidirektionalen Kommunikation genutzt werden, da beide Programme auf den Speicher zugreifen können.
|
||||
Alle Zugriffe auf den Bereich sind extrem schnell, was diese Technik ideal zur schnellen Datenübertragung zwischen Prozessen macht.
|
||||
Durch das erlauben gleichzeitiger Zugriffe kann es hierbei vorkommen, dass die selbe Adresse gleichzeitig von einem Programm gelesen und von einem anderen geschrieben wird.
|
||||
Die dabei gelesenen Daten können Schäden aufweisen, weswegen Zugriffe auf den Speicherbereich koordiniert werden müssen.
|
||||
|
||||
Die letzte betrachtete Methode ist die Verwendung einer Message Queue.
|
||||
Hier wird im Betriebssystem ein Speicherbereich mit bestimmter Größe für den Datenaustauch reserviert.
|
||||
Dieser Bereich besitzt ein Identifikationsmerkmal, mit welchem Anwendungen Zugriff auf diesen erlangen können.
|
||||
Ein Programm kann in diesem Bereich Nachrichten ablegen, welche durch das andere Programm gelesen werden können.
|
||||
Die Koordinierung der Zugriffe erfolgt dabei durch das Betriebssystem, was gleichzeitige Zugriffe, wie bei shared memory, aussschließt.
|
||||
Hierdurch kommt es zu einem Anstieg an Latenzzeit, jedoch ist dieser ausreichend gering.
|
||||
|
||||
Die Wahl des Dienstes fiel auf eine MessageQueue, jedoch existieren unter Linux 2 unabhängige Implementationen.
|
||||
Die erste Implementation ist die System V MessageQueue, und verwendet zur Identifikation einfache Integer.
|
||||
Eine Spezialität dieser alten Implementation ist das Sortieren der Nachrichten nach Nachrichtentyp in der gleichen Warteschlange.
|
||||
Die neuere Implementation der POSIX MessageQueue bietet einige weitere Funktionen, wie zum Beispiel aynchrone Benachrichtigungen bei neuen Nachrichten, Quality of Service und nutzt bis zu 256 Zeichen lange Strings zur Identifikation.
|
||||
|
||||
Die ausgewählte Implementation ist die neuere POSIX-Implementation einer Message Queue, da diese basierend auf den Erfahrungen mit der System V Implementation verbessert wurde.
|
||||
\subsubsection{Nachrichten}
|
||||
Die versendeten Nachrichten für den ActionServer, als auch für die Message Queue sind in den Paketen \code{ros_actor_action_server_msgs} und \code{ros_actor_message_queue_msgs} abgelegt.
|
||||
Die beiden ActionServer definieren jeweils 3 Nachrichten, welche eine Startnachricht, das Feedback während der Laufzeit und eine Endnachricht beschreiben.
|
||||
|
||||
In der Startnachricht werden alle Daten, welche der Server für die Bearbeitung einer Anfrage benötigt, übergeben.
|
||||
Dies geschieht, damit der Auftrag schon beim Start abgebrochen werden kann, sollte dieser nicht erfüllbar sein.
|
||||
|
||||
Die Feedbacknachrichten werden vom Server an den Client zurück gesendet, solange das Programm ausgeführt wird.
|
||||
Dabei ist es Aufgabe des Programms, diese in beliebigen Abständen an den Client zu senden.
|
||||
|
||||
Die Endnachricht kann Rückgabewerte für die ausgeführte Aufgabe enthalten, falls diese benötigt werden.
|
||||
Sie werden in diesem Projekt nicht genutzt, da das Beenden eines Auftrags immer mit einer einfachen Erfolgs- oder Misserfolgsmeldung quittiert wird.
|
||||
\subsubsection{ActorServer}
|
||||
Der ActorServer ist die Brücke zwischen ROS und dem ActorPlugin.
|
||||
Es werden zwei ActionServer angeboten, welche jeweils Bewegungen oder Animationen des simulierten Menschen auslösen können.
|
||||
Beide ActionServer prüfen zuerst, ob bereits eine andere Aktion ausgeführt wird.
|
||||
Sollte dies der Fall sein, wird die Anfrage abgelehnt.
|
||||
Im anderen Fall wird die Aufgabe akzeptiert und in das MessageQueue-Format übersetzt und an das ActorPlugin gesandt.
|
||||
Hier kommt es zu einer forcierten Warteschleife, welche die Bestätigung der Aktion vom ActorPlugin in der Feedback-Queue wartet, um das Starten mehrerer gleichzeitiger Aktionen zu unterbinden.
|
||||
Parallel werden alle eingehenden Feedback-Nachrichten der Message Queue des ActorPlugins in Feedback für die aktuell laufende Action umgewandelt.
|
||||
|
||||
Im Falle des Bewegungs-ActionServers werden mehrere Parameter benötigt.
|
||||
Zuerst werden Animationsname und -diztanz benötigt, um die richtige Animation auszuwählen und die Bewegung mit der Animation zu synchronisieren.
|
||||
Als Feedbacknachricht erhält der Client die aktuelle Pose des Actors im Simulationsraum.
|
||||
|
||||
Soll eine Animation über den Action Server abgespielt werden, wird auch hier ein Animationsname, jedoch auch eine Animationsgeschwindigkeit benötigt.
|
||||
Die Feedbacknachricht enthält den Fortschritt der Animation als Gleitkommazahl.
|
||||
\subsubsection{Gazebo Plugin}
|
||||
Das ActorPlugin nutzt die Daten aus der Message Queue für Befehle, um diese in der Simulation umzusetzen.
|
||||
Es werden dabei mehrere Zustände unterschieden.
|
||||
\begin{description}
|
||||
\item[Setup]
|
||||
wird ausschließlich zu Simulationsbeginn verwendet, um alle benötigten Referenzen aus der Simualtionumgebung im Plugin zu hinerlegen, so dass diese in den anderen Zuständen genutzt werden können.
|
||||
\item[Movement]
|
||||
bedeutet die Ausführung einer Bewegung in potentiell mehreren Schritten.
|
||||
Zuerst wird die Distanz zum Zielpunkt geprüft.
|
||||
Ist diese ausreichend gering, wird nur eine Bewegung in die gewünschte Endausrichtung durchgeführt.
|
||||
Ist diese größer, dreht sich der Actor in Richtung des Ziels und bewegt sich anschließend dorthin.
|
||||
Falls die gewünschte Endrotation nicht einem Null-Quaternion entspricht, wird anschließend noch eine Rotation in die Zielrichtung durchgeführt.
|
||||
\item[Animation]
|
||||
entspricht der Ausführung einer Animation an der aktuellen Position des Actors.
|
||||
Diese kann durch einen Skalierungsfaktor beschleunigt oder verlangsamt werden.
|
||||
\item[Idle]
|
||||
ist der Zustand, welcher nach erfolgreicher Ausführung eines Befehls angenommen wird.
|
||||
\end{description}
|
||||
|
||||
Das ActorPlugin besitzt kein Konzept des ActionServers und verlässt sich auf den ActorServer, welcher die Feedbacknachrichten in das richtige Format bringt.
|
||||
Feedback wird in den Zuständen Movement und Animation in jedem Simulationsschritt gesendet.
|
||||
Um auch Zustandsübergänge erkennen zu können, werden auch diese als Feedback an den ActorServer gesendet.
|
||||
\section{Roboter}
|
||||
\subsection{Übersicht}
|
||||
\subsection{Modellierung}
|
||||
Für den Kuka LBR iisy existiert kein Simulationsmodell für Gazebo und ROS, weswegen dieses Modell aus Herstellerdaten generiert wurden.
|
||||
Die Maße und Form des Roboters wurden aus einer .stl-Datei des Arms generiert.
|
||||
|
||||
Diese Datei wurde dazu in die unterschidlichen Glieder aufgeteilt, welche danach in Blender weiter bearbeitet wurden.
|
||||
Hiebei wurde die hohe Auflösung der Modelle reduziert, was sich in kleineren Dateien und Startzeiten der Simulation, aber auch in der Renderzeit der Simulation, auswirkt.
|
||||
Außerdem wuden die Glieder so ausgerichtet, dass der Verbindungspunkt zum vorherigen Glied im Nullpunkt des Koordinatensystems befindet.
|
||||
|
||||
Um die Simulation weiter zu beschleunigen, wurden die Kollisionsboxen des Arms noch weiter vereinfacht, was die Kollisionsüberprüfung dramatisch beschleunigt.
|
||||
Dabei werden stark simplifizierte Formen verwendet, welche das hochqualitative visuelle Modell mit einfachen Formen umfassen.
|
||||
|
||||
Diese Herangehensweise ist nötig, da Kollisionserkennung auf der CPU durchgeführt wird, welche durch komplexe Formen stark verlangsamt wird.
|
||||
|
||||
Um aus den generierten Gliedermodellen ein komplettes Robotermodell erstellen zu können, wurde eine .urdf-Datei erstellt.
|
||||
In dieser werden die verwendeten Gelenktypen zwischen den einzelnen Gliedern, aber auch deren Masse, maximale Geschwindigkeit, maximale Motorkraft, Reibung und Dämpfung hinterlegt.
|
||||
Diese Daten können später zur Simulation der Motoren genutzt werden, welche den Arm bewegen.
|
||||
|
||||
Die Gelenkpositionen sind dabei relative Angaben, welche sich auf das Glied beziehen, an welchem ein weiteres Glied über das Gelenk verbunden werden soll.
|
||||
Alle kontrollierbaren Gelenke benötigen auch eine Gelenkachse, welche je nach Gelenktyp die mögliche Beweglichkeit bestimmt.
|
||||
|
||||
Alle hier erstellten Dateien wurden im Paket \code{iisy_config} zusammengefasst, um diese einfacher wiederauffinden zu können.
|
||||
\subsection{MoveIt 2 Konfiguration}
|
||||
Das somit erstellte Paket kann nun mit dem neu implementierten MoveIt Configurator um die benötigten Kontrollstrukturen erweitert werden.
|
||||
\subsection{Details}
|
||||
Das so erstellte Modell kann nun zur Laufzeit in Gazebo geladen werden.
|
||||
Dafür wird das Paket \code{ros_gz_sim} verwendet, welches das \code{create} Programm beinhaltet.
|
||||
Mit diesem Werkzeuk kann ein Modell unter einem bestimmten Namen anhand einer Datei oder eines übergebenen Strings in Gazebo importiert werden.
|
||||
Das Modell kann dabei über Argumente im Raum verschoben und rotiert werden, falls diese Funktionalität benötigt wird.
|
||||
|
||||
Im Modell sind auch die verwendeten Gazebo-Plugins deklariert, welche für die Integration mit dem \code{ros_control} verantwortlich sind.
|
||||
|
||||
\section{Behavior Trees}
|
||||
Alle Behavior Trees wurden im Paket \code{btree_trees} organisert, welche durch das Paket \code{btree_nodes} gelesen werden.
|
||||
BehaviorTrees werden in \code{behaviortree_cpp_v3} als .xml-Dateien gespeichert.
|
||||
Diese Dateien enthalten die Anordnung der Nodes selbst, aber auch weitere Konfigurationsmöglichkeiten in Form von Ein- und Ausgabeschnittstellen.
|
||||
|
||||
Solche Schnittstellen können verwendet werden, um Nodes generischer gestalten zu können.
|
||||
So kann auf feste Parameter in den Nodes selber verzichtet werden, was das erstellen mehrerer Nodes für ähnliche Funktionalitäten verhindert.
|
||||
Diese Daten können sowohl aus einem String ausgelesen werden, falls die ensprechende Funktion, welche diese in den Zieltyp übersetzt, implementiert wurde.
|
||||
Aber sie können auch aus dem sogenannten Blackboard entnommen werden.
|
||||
|
||||
Das Blackboard ist ein System, welches die Nutzung von Variablen als Parameter für Ein- und Ausgänge erlaubt.
|
||||
Diese werden im Hintergrund als eine Referenz auf den eigentlichen Wert gespeichert.
|
||||
Eine solche Funktion erlaubt das weitere Zerlegen von Vorgängen innerhalb des BehaviorTrees.
|
||||
Solche kleineren Nodes sind durch ihren limitierten Umfang universeller einsetzbar, da sie nur kleinere Teilprobleme betrachten, welche zu komplexeren Strukturen zusammengesetzt werden können.
|
||||
|
||||
Um die dadurch wachsenden Strukturen besser überblicken zu können, lassen sich Nodes als sogenannte SubTrees abspeichern.
|
||||
Diese bilden dann in ihrer Gesamtheit eine neue Node, welche im BehaviorTree eingesetzt werden kann.
|
||||
Um den Einsatz von Variablen innerhalb eines SubTrees zu ermöglichen, besitzt jeder SubTree ein separates Blackboard.
|
||||
Dadurch kann ein Eingriff in äußere Funktionalität verhindert werden.
|
||||
|
||||
Natürlich sollte es auch möglich sein, Variablen an solche SubTrees zu übergeben.
|
||||
Diese können, wie auch bei normalen Nodes, einfach als Parameter an den SubTree übergeben werden.
|
||||
Die Bibliothek \code{behaviortree_cpp_v3} verbindet dann diese Werte und erlaubt die Datenübergabe zu und von dem SubTree.
|
||||
|
||||
\subsection{Asynchrone Nodes}
|
||||
Da nicht jeder Prozess in einem einzigen Durchlauf des BehaviorTrees abgebildet werden kann, muss die Möglichkeit geschaffen werden, lang anhaltende Prozesse abzubilden.
|
||||
Dies geschieht in in \code{behaviortree_cpp_v3} durch asynchrone Nodes.
|
||||
|
||||
Eine asynchrone Node besitzt neben den Zuständen SUCCESS und FAILURE auch noch die beiden anderen Zustände RUNNING und IDLE.
|
||||
|
||||
Der Zustand RUNNING steht dabei für eine Node, welche sich noch in der Ausführung befindet.
|
||||
So lang dieser Zustand anhält, wird die Node nicht noch ein weiteres Mal gestartet, sondern nur der Zustand abgefragt.
|
||||
|
||||
Der IDLE-Zustand ist ein besonderer Zustand, welcher nur durch eine vollständige Ausführung erreichbar ist.
|
||||
Er wird von der Node angenommen, nachdem ein RUNNING Zustand durch entweder SUCCESS oder FAILURE beendet wurde und darf sonst nicht verwendet werden.
|
||||
|
||||
BIN
tex/Aufgabenstellung.pdf
Normal file
BIN
tex/Aufgabenstellung.pdf
Normal file
Binary file not shown.
BIN
tex/Deckblatt.pdf
Normal file
BIN
tex/Deckblatt.pdf
Normal file
Binary file not shown.
Loading…
x
Reference in New Issue
Block a user