yenon/MasterarbeitLaTeX
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

spellcheck.

Browse Source
This commit is contained in:
yenon 2023-07-03 03:52:47 +02:00
parent d00a3f18be
commit 8a6b7455f9
9 changed files with 2493 additions and 167 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

44
.kile/mechforsch.kilepr.gui
View File

@ -2,7 +2,7 @@
kile_livePreviewEnabled=true
kile_livePreviewStatusUserSpecified=true
kile_livePreviewTool=LivePreview-PDFLaTeX
lastDocument=main.tex
lastDocument=tex/3_Auswahl.tex
[document-settings,item:Einleitung.tex]
Bookmarks=
@ -139,67 +139,67 @@ TextFolding={"checksum":"","ranges":[]}
ViMarks=
[view-settings,view=0,item:main.bib]
CursorColumn=18
CursorColumn=51
CursorLine=326
Dynamic Word Wrap=false
JumpList=
TextFolding={"checksum":"4baf2bb15fceb5c9f2aabf1cf70c4c7dba5ec9f5","ranges":[]}
TextFolding={"checksum":"8795c48226fb036f16e6bbcfbf55b812c6d43eaa","ranges":[]}
ViMarks=
[view-settings,view=0,item:main.tex]
CursorColumn=0
CursorLine=96
CursorLine=105
Dynamic Word Wrap=false
JumpList=
TextFolding={"checksum":"80ccd936ce5ae7dc5995816ffe293139ed94b427","ranges":[]}
ViMarks=
[view-settings,view=0,item:tex/1_Einleitung.tex]
CursorColumn=68
CursorLine=43
CursorColumn=196
CursorLine=35
Dynamic Word Wrap=false
JumpList=
TextFolding={"checksum":"75bcf6c0e7387bff6aee008e1995bfd43ba5a46b","ranges":[]}
TextFolding={"checksum":"99e42b912b320890bab1219df1e7d056e5124a2d","ranges":[]}
ViMarks=
[view-settings,view=0,item:tex/2_Konzept.tex]
CursorColumn=39
CursorLine=116
CursorColumn=26
CursorLine=25
Dynamic Word Wrap=false
JumpList=
TextFolding={"checksum":"03b463289e4adf34859cce5e79432be3ca9c3f53","ranges":[]}
TextFolding={"checksum":"111913c063e94bf8f1bf4f786b47b20be2773064","ranges":[]}
ViMarks=
[view-settings,view=0,item:tex/3_Auswahl.tex]
CursorColumn=0
CursorLine=446
CursorColumn=17
CursorLine=361
Dynamic Word Wrap=false
JumpList=
TextFolding={"checksum":"0163bec2d59ee0fdc7502865f6859d4fffa2ee1b","ranges":[]}
TextFolding={"checksum":"7aa9002df025f03505dbfc278b329c1fb13f4e2a","ranges":[]}
ViMarks=
[view-settings,view=0,item:tex/4_Umsetzung.tex]
CursorColumn=14
CursorLine=915
CursorColumn=102
CursorLine=1001
Dynamic Word Wrap=false
JumpList=
TextFolding={"checksum":"f6689d8b4009907e1b500952fcd8c46a3c8d88d0","ranges":[]}
TextFolding={"checksum":"dbda4a467836d9dfaee2833e58221fe122996b5e","ranges":[]}
ViMarks=
[view-settings,view=0,item:tex/5_Evaluation_und_Diskussion.tex]
CursorColumn=82
CursorLine=135
CursorColumn=18
CursorLine=168
Dynamic Word Wrap=false
JumpList=
TextFolding={"checksum":"f0868d9f15eec0ec90ab265f5c740a42a7b52d9b","ranges":[]}
TextFolding={"checksum":"847cd8cf59a779530aa24d2840e2423d2f10200b","ranges":[]}
ViMarks=
[view-settings,view=0,item:tex/6_Ausblick.tex]
CursorColumn=28
CursorLine=66
CursorColumn=59
CursorLine=71
Dynamic Word Wrap=false
JumpList=
TextFolding={"checksum":"08c80e4a421859760de9f6abca5d28d188b891d5","ranges":[]}
TextFolding={"checksum":"e964476a9eab203b42b321940c7b6784639e0caf","ranges":[]}
ViMarks=
[view-settings,view=0,item:tex/Einleitung.tex]

2264
Fehler.html Normal file
View File

File diff suppressed because one or more lines are too long

61
dict.txt Normal file
View File

@ -0,0 +1,61 @@
ActorPlugin
ROS
MessageQueue
ActorServer
Koexistenzszenario
Kooperationsszenario
Kollaborationsszenario
State
Actor
Actors
Behavior
Tree
Gazebo
MoveIt
REST-API
ActorPlugins
ROS-Topic
ROS-Topics
rclcpp
Feedbackmechanismus
rclcpp
ros
control
Kompiliervorgang
Feedbacknachrichten
Movement
Idle
actor
action
server
Movement
Interface
Node
Success
SUCCESS
Failure
Nodes
Pose
ActorAnimation
ActorMovement
animation_name
animation_speed
animation_distance
target
FAILURE
velocity
WeightedRandom
WeightedRandom-Node
ReactiveSequence
Sequence
Verfahrgeschwindigkeit
Octomap
Octomaps
ign
Trees
Kuka
kuka
iisy
IDLE
MOVEMENT
state}

16
tex/1_Einleitung.tex
View File

@ -13,7 +13,7 @@ Eine häufige Einschränkung der Simulatoren ist dabei, dass der Bewegungsablauf
Dies erlaubt lediglich die Reproduktion des geplanten Bewegungsablaufes, aber nicht dessen Variation im Prozess, ausgelöst durch Ereignisse in der Simulation.
Um eine solche Funktionalität bereitzustellen, müssen die Bewegungsabläufe sowohl von Roboter als auch Mensch zur Laufzeit der Simulation gesteuert werden können.
Diese Steuerung soll durch eine eingängliche Beschreibungssprache erfolgen, die einfach erweitert und auf neue Szenarien angepasst werden kann.
Diese Steuerung soll durch eine eingängige Beschreibungssprache erfolgen, die einfach erweitert und auf neue Szenarien angepasst werden kann.
Um die Funktionalität zu demonstrieren, sind 3 unterschiedliche Testszenarien in der Simulationsumgebung abzubilden.
Diese sollen durch verschiedene Aufgaben unterschiedliche Interaktionsgrade zwischen Mensch und Roboter simulieren.
@ -21,25 +21,25 @@ Diese sollen durch verschiedene Aufgaben unterschiedliche Interaktionsgrade zwis
Aktuelle wissenschaftliche Arbeiten befassen sich mit vielen unterschiedlichen Teilaspekten der Simulation eines Mensch-Roboter-Kollaborationsszenarios.
Die Planung von unterschiedlichen Reaktionen von Roboter auf den Menschen in verschiedenen Interaktionsszenarien stellt eine Grundlage für spätere
Projekte dar.\cite{DOMBROWSKI2018134}
Projekte dar \cite{DOMBROWSKI2018134}.
Hierbei wird die erwünschte Interaktion betrachtet und aus den gewonnenen Daten werden Einschränkungen generiert.
Diese Einschränkungen können in der Interaktion verwendet werden, um zum Beispiel Verletzungen des Menschen durch den Roboter auszuschließen.
Ein anderer Weg der Kollisionsvermeidung ist die Planung der maximal zurücklegbaren Distanz eines Menschen aus seiner aktuellen Position.\cite{ffdrobotsim}
Ein anderer Weg der Kollisionsvermeidung ist die Planung der maximal zurücklegbaren Distanz eines Menschen aus seiner aktuellen Position \cite{ffdrobotsim}.
Dafür werden die maximalen Beschleunigungen einzelner Körperteile ermittelt, um diese während der Interaktion zu überwachen.
Sollte ein Mensch den Roboter erreichen können, muss dieser in der dafür benötigten Zeit stoppen können.
Dies sorgt für eine Geschwindigkeitsanpassung im Nahfeld, da hier schnellere Bewegungen möglich sind.
Es existieren auch zahlreiche Ansätze, die Bewegungs- und Interaktionsplanung eines Roboters mit Beschreibungssprachen abzudecken.\cite{btintro}
Es existieren auch zahlreiche Ansätze, die Bewegungs- und Interaktionsplanung eines Roboters mit Beschreibungssprachen abzudecken \cite{btintro}.
Dabei kommt es auf die Umsetzung in der Beschreibungssprache, aber auch auf Anforderungen an das System an, um zum Beispiel das Abbrechen von Aktionen zu ermöglichen.
In Computerspielen werden Beschreibungssprachen schon seit langer Zeit eingesetzt, um verschiedene Systeme, wie zum Beispiel die Steuerung von Nichtspielercharakteren, zu beschreiben.\cite{halo2}
In Computerspielen werden Beschreibungssprachen schon seit langer Zeit eingesetzt, um verschiedene Systeme, wie zum Beispiel die Steuerung von Nichtspielercharakteren, zu beschreiben \cite{halo2}.
Eine vollständige Umsetzung einer erweiterbaren Simulation mit Mensch und Roboter, gesteuert durch eine Beschreibungssprache, konnte bei der Recherche zu dieser Arbeit jedoch nicht gefunden werden.
\section{Auswahl der Szenarien}
Die drei zu modellierenden Szenarien sollten so gewählt werden, dass spätere komplexere Szenarien auf einfacheren Vorgängern aufsetzen und deren Funktionen weiter nutzen und ergänzen.
Hierfür kommen bestimmte Aufgaben, wie zum Beispiel die Interaktion mit Objekten besonders in Frage.
Hierfür kommen bestimmte Aufgaben, wie zum Beispiel die Interaktion mit Objekten besonders infrage.
Diese besitzen viele ähnliche Bestandteile, die in mehreren Umständen nutzbar sind.
Das erlaubt den Einsatz von wenigen Animationen in vielen Szenarien.
Dazu zählen zum Beispiel das Hineingreifen in einen Prozess, das Aufheben von Material oder das Begutachten eines Objekts, welche jeweils nur eine ähnliche Bewegungsabfolge des beteiligten Menschen sind.
@ -54,9 +54,9 @@ Außerdem werden grundlegende Aspekte der Simulation getestet, wie zum Beispiel
Im zweiten Szenario prüft und sortiert der Roboter Teile und legt die fehlerfreien Exemplare auf einem Fließband zur Weiterverarbeitung ab.
Die Mängelexemplare werden hingegen in einer dafür vorgesehenen Zone abgelegt, von wo sie vom Menschen abtransportiert werden.
Auch hier soll der Mensch solange eigenständig arbeiten, bis der Roboter ein aussortiertes Teil ablegt, das transportiert werden muss.
Auch hier soll der Mensch so lange eigenständig arbeiten, bis der Roboter ein aussortiertes Teil ablegt, das transportiert werden muss.
Die dritte simulierte Aufgabe stellt ein Kollaborationsszenario dar, in dem Mensch und Roboter an der selben Aufgabe arbeiten.
Die dritte simulierte Aufgabe stellt ein Kollaborationsszenario dar, in dem Mensch und Roboter an derselben Aufgabe arbeiten.
Hierbei soll der Roboter eine Palette entladen, wobei er nicht jedes Objekt ausreichend manipulieren kann.
Dies wird durch zufällige Fehler beim Aufheben, Transport und Ablegen der Objekte abgebildet.
In diesen Fällen muss ein Mensch aushelfen, wodurch er mit dem Roboter in Interaktion tritt.

14
tex/2_Konzept.tex
View File

@ -23,7 +23,7 @@ Um diese Möglichkeiten zu schaffen, sind die Systeme modular aufzubauen.
Der simulierte Roboter soll für viele unterschiedliche Szenarien nutzbar sein, was spezialisierte Robotertypen ausschließt.
Außerdem ist die enge Interaktion mit Menschen gewünscht, was für einen auf Mensch-Roboter-Kollaboration ausgelegten Roboter spricht.
Für diese beschriebenen Kriterien eignet sich der KUKA LBR iisy, der als Cobot vermarktet wird.
Die Bezeichnung als Cobot\cite{cobot} ist dabei ein Portemanteau aus Collaborative und Robot, was die besondere Eignung für Mensch-Roboter-Kollaboration noch einmal unterstreicht.
Die Bezeichnung als Cobot \cite{cobot} ist dabei ein Kofferwort aus Collaborative und Robot, was die besondere Eignung für Mensch-Roboter-Kollaboration noch einmal unterstreicht.
Der Roboter besitzt 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.
@ -49,7 +49,7 @@ Außerdem kann durch andere Komponenten in der Simulation der Abbruch einer Akti
Die Weitergabe eines Abbruchbefehls soll demzufolge auch über die geplante Komponente realisiert werden können.
\section{Behavior Trees als Beschreibungssprache}
Bislang wird das Verhalten von Akteuren in Simationsumgebungen, darunter Roboter und Menschen, häufig in Form von State-Machines ausgedrückt.
Bislang wird das Verhalten von Akteuren in Simulationsumgebungen, darunter Roboter und Menschen, häufig in Form von State-Machines ausgedrückt.
Diese besitzen jedoch einen großen Nachteil, der vor allem bei komplexeren Abläufen hervortreten kann.
Dabei handelt es sich um die Übersichtlichkeit, die bei einer wachsenden State-Machine leicht verloren geht.
Dies erschwert die schnelle Erfassung von Abfolgen und Zustandsübergängen bei Änderungen am Code, was zu Fehlern im späteren Betrieb führen kann.
@ -78,7 +78,7 @@ Es gibt mehrere grundlegende Arten von Tree-Nodes, die in vier Kategorien unters
Sollte eine Node einen Fehler zurückgeben, wird die Ausführung der Sequenz abgebrochen, was wiederum zur Rückgabe eines Fehlers durch die Sequenz selbst führt.
Beim erfolgreichen Durchlauf gibt die Sequenz einen Erfolg zurück.
\item[Fallback-Nodes]
verhalten sich ähnlich wie Sequenz-Nodes, jedoch werden die darunter liegenden Nodes nacheinander ausgeführt, bis eine Node Erfolg zurück gibt.
verhalten sich ähnlich wie Sequenz-Nodes, jedoch werden die darunter liegenden Nodes nacheinander ausgeführt, bis eine Node Erfolg zurückgibt.
In diesem Fall wird die Ausführung der Fallback-Node mit einem Erfolg abgebrochen.
Ein Fehler wird hier zurückgegeben, wenn alle Nodes ohne eine Erfolgsmeldung durchlaufen wurden.
\end{description}
@ -93,10 +93,10 @@ Es gibt mehrere grundlegende Arten von Tree-Nodes, die in vier Kategorien unters
Das in Abbildung \ref{concept_tree_demo} visualisierte Beispiel zeigt die Abfolge, um eine Tür zu öffnen und zu durchschreiten.
Die Ausführung des Baumes beginnt an der Root-Node, wobei die Zahlen über den Nodes die Reihenfolge der Rückgabewerte angeben.
Von dort aus wird als erstes die Sequenz-Node ausgeführt, die drei untergeordnete Nodes besitzt.
Von dort aus wird als Erstes die Sequenz-Node ausgeführt, die drei untergeordnete Nodes besitzt.
Diese drei Nodes werden in Leserichtung, in diesem Falle von links nach rechts, ausgeführt.
Daraus resultierend wird als erstes die linke Fallback-Node, die ihrerseits untergeordnete Nodes besitzt, ausgeführt.
Daraus resultierend wird zuerst die linke Fallback-Node, die ihrerseits untergeordnete Nodes besitzt, ausgeführt.
Da der Rückgabewert der Fallback-Node von den unter ihr befindlichen Nodes bestimmt wird, werden diese nacheinander ausgeführt.
Von diesem Punkt an beginnen die Rückgaben, die das weitere Verhalten beeinflussen.
@ -113,7 +113,7 @@ Folgender Kontrollfluss findet in diesem Beispiel statt:
Der Versuch gelingt und der Erfolg wird an die Fallback-Node übergeben.
}
\item{
Da die untergeornete Node eine erfolgreiche Ausführung meldet, wird die Ausführung der Fallback-Node mit einem erfolgreichen Rückgabewert beendet.
Da die untergeordnete Node eine erfolgreiche Ausführung meldet, wird die Ausführung der Fallback-Node mit einem erfolgreichen Rückgabewert beendet.
Aus diesem Grund wird die Node ``Tür eintreten'' nicht mehr ausgeführt.
}
\item{
@ -125,7 +125,7 @@ Folgender Kontrollfluss findet in diesem Beispiel statt:
}
\end{enumerate}
Dieser Ablauf würde nun von neuem beginnen, da die Root-Node ihre untergeornete Node ohne Berücksichtigung des Rückgabewertes neu startet.
Dieser Ablauf würde nun von neuem beginnen, da die Root-Node ihre untergeordnete Node ohne Berücksichtigung des Rückgabewertes neu startet.
Durch die Definition neuer Nodes und einer anderen Baumstruktur lassen sich neue Verhalten implementieren.
Dies erlaubt die schnelle Anpassung des Verhaltens der gesteuerten Systeme.

92
tex/3_Auswahl.tex
View File

@ -5,7 +5,7 @@ Alle Komponenten sollen später in der entwickelten Softwareumgebung ihre jeweil
Alle diese Teilbereiche können dann zu einer Simulation verbunden werden, die das gesamte Problemfeld abdeckt.
Wie bereits in Abbildung \ref{concept_overview} dargestellt, ist für die Erfüllung der Aufgaben eine Dienst- und eine Simulationsumgebung erforderlich.
Dieses Kapitel beschreibt die Auswahl der Umgebungen und der in diesen laufenden Prozesse.
Dieses Kapitel beschreibt die Auswahl der Umgebungen und alle in den Umgebungen laufenden Prozesse.
\section{Dienstumgebung}
Die Dienstumgebung bestimmt maßgeblich, wie Software im Entwicklungsprozess geschrieben wird.
Durch sie werden häufig benötigte Funktionen bereitgestellt, die Programme innerhalb der Umgebung nutzen können.
@ -15,8 +15,8 @@ Diese wird genutzt, um eine gemeinsame Basis für ein erweiterbares System zu sc
Außerdem sind Werkzeuge zur Parameterübergabe an Teilsysteme sinnvoll, um die Einstellungen an einer Stelle gesammelt anpassen zu können.
\subsection{Auswahl}
Es existieren mehrere Systeme, die als Dienstumgebung für Roboter in Frage kommen, wenn man lediglich die Nachrichtenübergabe zwischen Programmen betrachtet.
Jede Dienstumgebung, die Nachrichten zwischen Prozessen austauschen kann, ist potentiell als ein Roboterframework einsetzbar.
Es existieren mehrere Systeme, die als Dienstumgebung für Roboter infrage kommen, wenn man lediglich die Nachrichtenübergabe zwischen Programmen betrachtet.
Jede Dienstumgebung, die Nachrichten zwischen Prozessen austauschen kann, ist potenziell als ein Roboterframework einsetzbar.
Wichtige Aspekte sind dabei die Geschwindigkeit der Anbindung und die Definition der Nachrichten, die über das System ausgetauscht werden.
@ -30,21 +30,21 @@ Dabei dient ein Programm als Server, der Anfragen von anderen Programmen, auch C
Die Kommunikation zwischen Client und Server ist bidirektional möglich, was kompliziertere Protokolle ermöglicht.
Alle diese Lösungen besitzen einen gemeinsamen Nachteil in deren Nachrichtendefinition.
Dieser Nachteil besteht in der potentiellen Variabilität dieser Kommunikationsmechanismen.
Dieser Nachteil besteht in der potenziellen Variabilität dieser Kommunikationsmechanismen.
Bei einem ausreichend großen Projekt treten so unweigerlich Unterschiede in der Handhabung von Nachrichten auf, die es zu berücksichtigen gilt.
Durch solche Unterschiede kann es zu Inkompatibilitäten zwischen Programmen kommen, was sich auf die universelle Nutzbarkeit der Programme negativ auswirkt.
Im Bereich der Robotik ist ROS\cite{doi:10.1126/scirobotics.abm6074}, bei dem es sich um ein quelloffenes System handelt, als Dienstumgebung etabliert.
Im Bereich der Robotik ist ROS \cite{doi:10.1126/scirobotics.abm6074}, bei dem es sich um ein quelloffenes System handelt, als Dienstumgebung etabliert.
Der oben genannte Nachteil einzelner Systeme wird in ROS durch mehrere standardisierte und erweiterbare Nachrichtendefinitionen gelöst, die von den Programmen in der Umgebung genutzt werden.
Um diese Nachrichten senden und empfangen zu können, liefert ROS bereits eine eigene Implementation des Protokolls für mehrere Programmiersprachen mit.
Zum Beispiel existieren für Python\cite{python}, C und C++\cite{cpp} entsprechende Implementationen in Form der Pakete \code{rospy}, \code{rclc} und \code{rclcpp}.
Zum Beispiel existieren für Python \cite{python}, C und C++ \cite{cpp} entsprechende Implementationen in Form der Pakete \code{rospy}, \code{rclc} und \code{rclcpp}.
Die neuste Version ROS2 bietet mehrere Verbesserungen im Vergleich zu früheren Version ROS1 \cite{changesRosII}.
Ein neues Nachrichtenformat mit Quality of Service kann beispielsweise Nachrichten zwischenspeichern und über sowohl TCP, als auch UDP kommunizieren.
Außerdem werden neben CMake\cite{cmake} auch andere Buildsysteme unterstützt, was die Verwendung von Python erlaubt.
Außerdem werden neben CMake \cite{cmake} auch andere Buildsysteme unterstützt, was die Verwendung von Python erlaubt.
Generell existieren im Feld der Roboter-Dienstumgebungen keine freien Alternativen mit ähnlichem Funktionsumfang und gleicher Reichweite.
Vor allem die Vielzahl von ROS-Bibliotheken, die von Nutzern des Systems über die Jahre erstellt wurden, machen das System so populär.\cite{rospackages}
Vor allem die Vielzahl von ROS-Bibliotheken, die von Nutzern des Systems über die Jahre erstellt wurden, machen das System so populär \cite{rospackages}.
ROS kann sowohl für simulierte Umgebungen als auch für echte Roboter eingesetzt werden.
Diese beiden Anwendungsfälle werden durch unterschiedliche Controller realisiert.
@ -57,7 +57,7 @@ Bei dem Einsatz echter Hardware werden die Zielpositionen durch den Controller a
%-LCM
%-ZeroMQ
\subsection{Beschreibung}
ROS2\cite{doi:10.1126/scirobotics.abm6074}, im weiteren Verlauf nur ROS genannt, beschreibt sich selbst als ``a meta operating system for robots''\cite{ros-git}.
ROS2 \cite{doi:10.1126/scirobotics.abm6074}, im weiteren Verlauf 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, die durch ROS bereitgestellt wird.
@ -78,7 +78,7 @@ Zu den Aufgaben von ROS zählen folgende Teilbereiche:
\item[Buildumgebung]\hfill \\
ROS nutzt die eigene Buildumgebung \code{colcon} \cite{colcon}, um Pakete in den Workspaces reproduzierbar zu erstellen.
Zu deren Konfiguration wird eine \code{CMakeLists.txt}-Datei erstellt, die den Buildprozess beschreibt.
In dieser sind die Buildinstruktionen für den Kompiler enhalten, mit welchen die im Paket befindlichen Programme kompiliert werden.
In dieser sind die Buildinstruktionen für den Compiler enthalten, mit welchen die im Paket befindlichen Programme kompiliert werden.
Der Aufruf des \code{ament_cmake}-Makros in dieser ergänzt den Kompiliervorgang um weitere Parameter aus der \code{package.xml}-Datei.
Nach diesen Vorbereitungsschritten kann CMake das Paket kompilieren.
@ -88,7 +88,7 @@ Zu den Aufgaben von ROS zählen folgende Teilbereiche:
Diese sind dann später im erstellten Workspace für die Nutzung durch andere Programme verfügbar.
\item[Workspaceverwaltung]\hfill \\
Gruppen von Paketen werden zur einfacheren Handhabung in sogenannen “Workspaces” zusammengefasst.
Gruppen von Paketen werden zur einfacheren Handhabung in sogenannten ``Workspaces'' zusammengefasst.
Diese vereinfachen das Auffinden der enthaltenen Pakete durch Skripte, die diese im System registrieren.
Die Erstellung der Skripte erfolgt anhand der bereits beschriebenen \code{CMakeLists.txt}-Datei.
Das Programm \code{colcon} analysiert diese und generiert die Skripte.
@ -137,32 +137,32 @@ Ein Vergleich dieser Werkzeuge ist hierbei sinnvoll, da sich der gebotene Funkti
Auch andere Aspekte, wie Lizenzen oder die schwer bewertbare Nutzerfreundlichkeit, sind hierbei zu betrachten.
Eine Auswahl der als Simulationsumgebung in Frage kommenden Programme wird hier vorgestellt.
CoppeliaSim\cite{coppelia}, früher auch V-REP genannt, ist eine Robotersimulationsumgebung mit integriertem Editor und ROS-Unterstützung.
CoppeliaSim \cite{coppelia}, 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, diese können aber nur Animationen allein oder in Kombination mit einer Bewegung abspielen.
CoppeliaSim existiert in 3 Versionen, die sich hinsichtlich Funktionsumfang und Lizenz unterscheiden.
Jedoch besitzt nur die professionelle Version Zugriff auf alle Funktionen und Verwendungsszenarien.
Gazebo Ignition\cite{gazebo} ist wie CoppeliaSim eine Robotersimulationsumgebung, besitzt aber keinen integrierten Editor und direkte ROS-Unterstützung.
Gazebo Ignition \cite{gazebo} ist wie CoppeliaSim eine Robotersimulationsumgebung, besitzt aber keinen integrierten Editor und direkte ROS-Unterstützung.
Gazebo setzt wie CoppeliaSim auf Erweiterungen, um zusätzliche Funktionen einbinden zu können.
So existiert zum Beispiel auch eine ROS-Brücke, die 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\cite{unity} hingegen ist primär eine Grafikengine für die Nutzung in Computerspielen.
Unity \cite{unity} hingegen ist primär eine Grafikengine für die 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 umfangreich, da diese häufig in Spielen verwendet werden.
Ein großer Nachteil hingegen ist die Lizenz, die nur für Einzelpersonen kostenfrei ist.
Die Unreal Engine\cite{unreal} ist wie Unity eine Grafikengine aus dem Spielebereich.
Die Unreal Engine \cite{unreal} 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 die Erstellung eines Plugins zur ROS-Anbindung der Unreal Engine ermöglichte, die von Nutzern gewartet wird.
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\cite{godot} dar.
Eine weitere Möglichkeit zur Simulation stellt die Grafikengine Godot \cite{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 Standardaufgabe 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.
@ -178,7 +178,7 @@ Für einen späteren Einsatz ist eine offene Lizenz von Vorteil, da diese einen
Die Wahl der hier zu verwendenden Simulationsumgebung fiel deshalb auf Gazebo Ignition, welche gleichzeitig bereits im ROS-Ökosystem etabliert ist.
Dabei erlauben die offizielle ROS-Anbindung und die offene Lizenz eine zuverlässige Verwendung in unterschiedlichsten Szenarien.
\subsection{Welt- und Modellbeschreibung}
Gazebo nutzt das .sdf-Dateiformat, um die Simulationsumbebung zu beschreiben\cite{sdf-format}.
Gazebo nutzt das .sdf-Dateiformat, um die Simulationsumbebung zu beschreiben \cite{sdf-format}.
Dieses Format basiert auf XML und wird zur Definition gesamter Welten, aber auch einzelner Objekte innerhalb dieser Welten benutzt.
Eine Welt ist in Gazebo eine Umgebung aus mehreren Objekten, welche simuliert werden sollen.
Die Welt beschreibt außerdem die simulierte Physikumgebung und deren Konstanten, wie zum Beispiel die Gravitation.
@ -190,10 +190,10 @@ Andernfalls können in der Datei eine oder mehrere Welten definiert werden.
Eine Welt definiert in Gazebo den kompletten Aufbau des Simulators.
Zuerst enthält ein Welt-Element die Daten über die physikalischen Konstanten der Simulationsumgebung.
Außerdem werden alle benötigten Teile der Nutzeroberfläche deklariert, die im ausgeführten Simulator verfügbar sein sollen.
Letzendlich ist die Definition mehrerer Modelle, Aktoren und Lichter in der Welt möglich.
Zudem werden alle benötigten Teile der Nutzeroberfläche deklariert, die im ausgeführten Simulator verfügbar sein sollen.
Letztendlich ist die Definition mehrerer Modelle, Aktoren und Lichter in der Welt möglich.
Diese können auch aus anderen URIs stammen, die in der Welt deklariert wurden.
Dies erlaubt zum Beispiel das Laden von vorher definierten Objekten oder Objekten aus der offiziellen Bibliothek\cite{gazebo-app}.
Dies erlaubt zum Beispiel das Laden von vorher definierten Objekten oder Objekten aus der offiziellen Bibliothek \cite{gazebo-app}.
Ein Modell enthält einen Roboter oder ein anderes physikalisches Objekt in der Simulation.
Die Deklaration eines weiteren Untermodells ist möglich, um komplexere Strukturen abbilden zu können.
@ -203,7 +203,7 @@ Jedes Modell wird über eine Translation und Rotation im Simulationsraum veranke
Dies geschieht immer relativ zum Referenzsystem des überliegenden Modells.
Außerdem können im Modell Einstellungen für dessen Physiksimulation vorgenommen werden.
Ein Modell enhält meist mindestens ein Link-Element, dass zur Darstellung von dessen Geometrie verwendet wird.
Ein Modell enthält meist mindestens ein Link-Element, dass zur Darstellung von dessen Geometrie verwendet wird.
Mehrere Link-Elemente können dabei mit der Welt oder anderen Link-Elementen über Joint-Elemente verbunden werden.
Diese Joint-Elemente können jedoch nicht von außerhalb gesteuert werden, was das Dateiformat ungeeignet für Roboterdefinitionen macht.
@ -211,7 +211,7 @@ Lichter besitzen einen Lichttyp, der die Ausbreitung des Lichtes im Raum bestimm
Die erste Art ist direktionales Licht, dass parallel zur gewünschten Achse auftrifft.
Solche Lichter werden vor allem zur grundlegenden Raumausleuchtung genutzt.
Weiterhin sind Punktlichtquellen verfügbar, deren Licht von einer Position im Raum ausgeht.
Neben den Punklichtquellen existieren auch noch Spots, die außerdem nur einen gewissen Winkel ausleuchten.
Neben den Punklichtquellen existieren auch noch Spots, die nur einen gewissen Winkel ausleuchten.
Die Actor-Komponente wird für animierte Modelle in der Simulation eingesetzt.
Sie besteht aus einem Namen für das Modell, einer Skin, welche das Aussehen des Modells definiert und mehreren Animationen.
@ -222,7 +222,7 @@ Diese Funktionalität wurde im Rahmen der Arbeit hinzugefügt.
\subsection{Robotersimulation}
Für die Robotersimulation wird ein Modell des Roboters benötigt, in dem dieser für die Simulationsumgebung beschrieben wird.
Gazebo und ROS nutzen hierfür .urdf-Dateien\cite{urdf-format}, die auf XML basieren.
Gazebo und ROS nutzen hierfür .urdf-Dateien \cite{urdf-format}, die auf XML basieren.
In diesen werden die einzelnen Glieder des Roboterarms und die verbindenden Gelenke beschrieben.
Jedes Glied des Modells besitzt eine Masse, einen Masseschwerpunkt und eine Trägheitsmatrix für die Physiksimulation in Gazebo.
@ -249,7 +249,7 @@ Folgende Typen von Gelenken können in urdf-Dateien genutzt werden:
\item[drehbare Gelenke]
verhalten sich wie kontinuierliche Gelenke, haben jedoch minimale und maximale Auslenkungen. Sie sind die häufigste Art von Gelenken in Roboterarmen.
\item[prismatische Gelenke]
ermöglichen die lineare Bewegung entlang der Achse des Gelenks. Sie werden zur Umsetzung von Linearaktuatore in der Simulation verwendet.
ermöglichen die lineare Bewegung entlang der Achse des Gelenks. Sie werden zur Umsetzung von Linearaktuatoren in der Simulation verwendet.
\end{description}
\subsection{Menschensimulation}
Gazebo besitzt bereits ein simples Animationssystem für bewegliche Aktoren, dass auch für Menschen nutzbar ist.
@ -268,12 +268,12 @@ Dafür soll ein ROS Action-Server verwendet werden, der die Befehle entgegennimm
Ein solches System soll als Gazebo-Plugin einbindbar sein, um Modifikationen an der Simulationsumgebung selbst auszuschließen, die konstant weiter entwickelt wird.
Dies vereinfacht die Wartung, da bei Updates der Simulationsumgebung nicht die Menschensimulation an den neuen Code angepasst werden muss.
\section{Roboterumgebung}
MoveIt2\cite{moveit-docs} ist das meist genutzte ROS2 Paket für die Bewegungsplanung von Robotern.
MoveIt2 \cite{moveit-docs} ist das meist genutzte ROS2 Paket für die Bewegungsplanung von Robotern.
Deshalb existiert eine umfangreiche Dokumentation für die zahlreichen Komponenten, was die Entwicklung neuer Komponenten erleichtert.
Außerdem sind zahlreiche direkte Integrationen mit anderen ROS-Paketen verfügbar, was die Nutzung dieser zusammen mit MoveIt erlaubt.
Aufgrund dieser Eigenschaften ist MoveIt eine vorteilhafte Bewegungsplanungsumgebung für dieses Projekt.
MoveIt besteht aus mehreren Komponmenten, die in ihrer Gesamtheit den Bereich der Bewegungsplanung abdecken.
MoveIt besteht aus mehreren Komponenten, die in ihrer Gesamtheit den Bereich der Bewegungsplanung abdecken.
Der Nutzer kann mit MoveIt auf verschiedenen Wegen Steuerbefehle für den Roboter absenden, die durch die Software umgesetzt werden.
Die erste Inbetriebnahme ist über das mitgelieferte RViz-Plugin und die demo-Launch-Files möglich.
@ -282,7 +282,7 @@ Durch die Ausführung dieser Demo startet RViz, eine Test- und Visualisierungsum
In der Demo können Roboterbewegungen unter Zuhilfenahme von Markierungen in RViz geplant und ausgeführt werden.
Da sich eine Bewegungsplanung in einer Nutzeroberfläche nur beschränkt zur Automatisierung durch Software eignet, müssen die der Demo zugrundeliegenden Schnittstellen genutzt werden.
Für die Sprache Python existierte für die Vorgängerversion von MoveIt das moveit_commander Paket, welches den Zugriff auf MoveIt in Pyhon erlaubt, aber für MoveIt2 noch nicht portiert wurde\cite{moveitpython}.
Für die Sprache Python existierte für die Vorgängerversion von MoveIt das moveit_commander Paket, welches den Zugriff auf MoveIt in Python erlaubt, aber für MoveIt2 noch nicht portiert wurde \cite{moveitpython}.
Die direkte Nutzung der C++-API ist aktuell die einzige offizielle Möglichkeit, mit MoveIt2 direkt zu interagieren.
Dabei können sowohl die Planung und die Ausführung von Bewegungen ausgelöst aber auch Exklusionszonen eingerichtet werden.
@ -301,7 +301,7 @@ Eine solche Erweiterung erlaubt die automatische Nutzung von Kollisionsvermeidun
Die Planung der Bewegung wird durch einen der in MoveIt implementierten Solver realisiert, der durch die MoveGroup aufgerufen wird.
Um die generierte Bewegung umzusetzen, werden die gewünschten Gelenkpositionen als Abfolge an die \code{ros_control} Controller des Roboters weitergegeben.
Diese Abstaktion erlaubt die Nutzung von sowohl simulierten, aber auch echten Robotern.
Diese Abstraktion erlaubt die Nutzung von sowohl simulierten, aber auch echten Robotern.
Dazu werden für echte und simulierte Roboter unterschiedliche ros_control Controller verwendet.
Der Erfolg der gesamten Pipeline kann dabei durch einen Feedbackmechanismus überwacht werden.
@ -311,7 +311,7 @@ Diese können dann wie normale Controller von \code{ros_control} genutzt werden.
Der Ablauf der Bewegungsplanungspipeline von MoveIt ist im Anhang unter Abbildung \ref{moveitpipeline} visualisiert.
\section{Programmiersprache}
Als Programmiersprache kommen in ROS standardmäßig Python\cite{python} und C++\cite{cpp} zum Einsatz.
Als Programmiersprache kommen in ROS standardmäßig Python \cite{python} und C++ \cite{cpp} zum Einsatz.
Beide Sprachen sind in der Softwareentwicklung beliebt, unterscheiden sich jedoch stark im Funktionsumfang und im Entwicklungsprozess.
Python ist eine interpretierte Skriptsprache, die zu den hohen Programmiersprachen zählt.
@ -336,7 +336,7 @@ Die Verwendung von C++ für die zu entwickelnden Nodes erscheint deshalb aus obe
In den Launch-Skripten wird jedoch Python verwendet werden, da hier die Vorteile einer Skriptsprache überwiegen.
\section{Behavior Trees}
Zur Verwaltung der Abläufe sollen BehaviorTrees genutzt werden, die durch die Bibliothek \code{BehaviorTree.CPP} bereitgestellt werden.
Zur Verwaltung der Abläufe sollen Behavior Trees genutzt werden, die durch die Bibliothek \code{BehaviorTree.CPP} bereitgestellt werden.
Diese Bibliothek wurde in C++ geschrieben, und ist somit in ROS und dem geplanten Konzept integrierbar.
Es existieren viele Beispiele und eine gute Dokumentation über die erweiterten Funktionen der Bibliothek, die im Folgenden vorgestellt werden.
@ -344,7 +344,7 @@ Es existieren viele Beispiele und eine gute Dokumentation über die erweiterten
\begin{description}
\item[Asynchrone Nodes]
sind in \code{BehaviorTree.CPP} leichter umsetzbar, da diese in Form verschiedener Zustände der Nodes beim Konzept der Bibliothek mit bedacht wurden.
Dies resultiert in Nodes, die ohne spezielle Logik langanhaltende Aktionen ausführen können, ohne die Ausführung des BehaviorTrees zu behindern.
Dies resultiert in Nodes, die ohne spezielle Logik langanhaltende Aktionen ausführen können, ohne die Ausführung des Behavior Trees zu behindern.
\item[Reaktives Verhalten] ist ein neues Konzept, um die Handhabung von asynchronen Nodes zu vereinfachen.
Diese Strukturelemente erlauben die parallele Ausführung von mehreren Zweigen, die die aktuell ausgeführte Aktion beeinflussen können.
Darunter fällt die Modifizierung von Parametern der Aktionen, aber auch der vollständige Abbruch einer Aktion durch äußere Einflüsse.
@ -359,7 +359,7 @@ Es existieren viele Beispiele und eine gute Dokumentation über die erweiterten
Dies erleichtert das häufig schwierige Debuggen von Zustandsmaschinen erheblich, da das Verhalten genau untersucht werden kann.
\end{description}
BehaviorTrees werden bei Verwendung von \code{BehaviorTree.CPP} in Form von .xml-Dateien gespeichert.
Behavior Trees werden bei Verwendung von \code{BehaviorTree.CPP} in Form von .xml-Dateien gespeichert.
Diese Dateien enthalten die Anordnung der Nodes selbst, aber auch weitere Konfigurationsmöglichkeiten in Form von Ein- und Ausgabeports.
Ports können verwendet werden, um Nodes generischer zu gestalten.
@ -369,15 +369,15 @@ Um dies zu ermöglichen, kann deren Funktion durch mehrere andere Nodes in einem
Diese in den Ports übertragenen Daten können sowohl aus einem String ausgelesen, aber auch aus dem sogenannten Blackboard entnommen werden.
Um die Übersetzung aus einem String zu ermöglichen, muss eine entsprechende Funktion implementiert werden, die einen String in den gewünschten Zieltyp übersetzt.
Viele primitive Datentypen, wie Ganzzahlen und Gleitkommazahlen, werden von BehaviorTree.Cpp bereits durch native Funktionen unterstützt.
Viele primitive Datentypen, wie Ganzzahlen und Gleitkommazahlen, werden von Behavior Tree.Cpp bereits durch native Funktionen unterstützt.
Das Blackboard ist ein System, dass die Nutzung von Variablen als Parameter für Ports 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.
Eine solche Funktion erlaubt das weitere Zerlegen von Vorgängen innerhalb des Behavior Trees.
Solche kleineren Nodes sind durch ihren limitierten Umfang universeller einsetzbar, da sie nur kleinere Teilprobleme betrachten, die zu komplexeren Strukturen zusammengesetzt werden können.
Um die dadurch wachsenden Strukturen besser überblicken zu können, lassen sich Gruppen von Nodes als sogenannte Subtrees abspeichern.
Diese bilden in ihrer Gesamtheit eine neue Node, die im BehaviorTree eingesetzt werden kann.
Diese bilden in ihrer Gesamtheit eine neue Node, die im Behavior Tree eingesetzt werden kann.
Um den Einsatz von Variablen innerhalb eines Subtrees zu ermöglichen, besitzt jeder Subtree ein separates Blackboard.
Dadurch kann auch ein Eingriff durch äußere Einflüsse verhindert werden.
@ -395,7 +395,7 @@ Außerdem werden mehrere Funktionen definiert, die den Lebenszyklus der Node def
Wird eine Node durch den Aufruf der \code{onStart}-Funktion gestartet, geht diese in einen der Zustände RUNNING, SUCCESS oder FAILURE über.
Der Zustand RUNNING steht dabei für eine Node, die sich noch in der Ausführung befindet.
So lange dieser Zustand anhält, wird die Node nicht noch ein weiteres Mal gestartet, sondern nur der Zustand in der neuen \code{onRunning}-Funktion abgefragt.
Solange dieser Zustand anhält, wird die Node nicht noch ein weiteres Mal gestartet, sondern nur der Zustand in der neuen \code{onRunning}-Funktion abgefragt.
Der IDLE-Zustand ist ein besonderer Zustand, der nur durch eine vollständige Ausführung erreichbar ist.
Er wird von der Node angenommen, nachdem deren Ausführung durch SUCCESS oder FAILURE beendet wurde.
@ -403,11 +403,11 @@ Er wird von der Node angenommen, nachdem deren Ausführung durch SUCCESS oder FA
Im Falle eines Abbruchs, der durch andere Nodes im Baum ausgelöst werden könnte, muss die Ausführung der Node vorzeitig beendet werden können.
Dies geschieht mit der neuen \code{onHalted}-Funktion, welche ausgeführt wird, wenn die Ausführung der Node abgebrochen werden soll.
\subsection{Dateiformat}
Das in BehaviorTree.Cpp verwendete Dateiformat, um Behavior Trees zu erstellen, basiert auf XML.
Jedes Dokument beginnt dabei mit einem Root-Element, dass alle BehaviorTrees und eine Referenz auf die ID des Hauptbaumes enthält.
Das in Behavior Tree.Cpp verwendete Dateiformat, um Behavior Trees zu erstellen, basiert auf XML.
Jedes Dokument beginnt dabei mit einem Root-Element, dass alle Behavior Trees und eine Referenz auf die ID des Hauptbaumes enthält.
Diese wird benötigt, da auch Unterbäume im selben Dokument deklariert und genutzt werden können, die aber sonst nicht vom Hauptbaum unterscheidbar sind.
Jeder Baum beginnt mit einem BehaviorTree-Element, das als Attribut die ID des Baumes besitzen muss.
Jeder Baum beginnt mit einem Behavior Tree-Element, das als Attribut die ID des Baumes besitzen muss.
Als untergeordnete Elemente des Baumes werden die Nodes entsprechend der gewünschten Baumstruktur angeordnet.
Als Beispiel wird der bereits im Konzept verwendete Behavior Tree (siehe Abbildung \ref{choice_tree_xml}) in die entsprechende XML-Repräsentation umgewandelt.
@ -416,14 +416,14 @@ Außerdem können selbst definierte Nodes sowohl direkt mit ihrem Namen, aber au
\begin{figure}[hpt]
\includegraphics[width=\textwidth]{img/MA-tree-demo}
\centering
\caption{Beispiel eines BehaviorTrees}
\caption{Beispiel eines Behavior Trees}
\label{choice_tree_demo}
\end{figure}
\begin{figure}[hpt]
\begin{minted}[breaklines,frame=single,linenos]{xml}
<?xml version="1.0"?>
<root main_tree_to_execute="demoTree">
<BehaviorTree ID="actorTree">
<Behavior Tree ID="actorTree">
<Sequence>
<Fallback>
<Action ID="IsDoorOpen"/>
@ -433,10 +433,10 @@ Außerdem können selbst definierte Nodes sowohl direkt mit ihrem Namen, aber au
<CanWalkThrough/>
<WalkThrough/>
</Sequence>
</BehaviorTree>
</Behavior Tree>
</root>
\end{minted}
\caption{Beispiel eines BehaviorTrees als .xml}
\caption{Beispiel eines Behavior Trees als .xml}
\label{choice_tree_xml}
\end{figure}
@ -448,7 +448,7 @@ Bei einer virtuellen Maschine (VM) werden alle Komponenten der Maschine simulier
Dies beinhaltet auch die Abstraktion von Speichermedien und anderen Geräten.
Eine virtualisierte Umgebung erzeugt kleine Performanceverluste durch die Abstraktion.
Eine Containerumgebung nutzt den Kernel des Hostsystems mit, was die Virtualisierug auf die Ebenen über dem Betriebssystem beschränkt.
Eine Containerumgebung nutzt den Kernel des Hostsystems mit, was die Virtualisierung auf die Ebenen über dem Betriebssystem beschränkt.
Die auszuführende Umgebung muss also mit dem Systemkernel lauffähig sein, um in einem Container ausgeführt werden zu können.
Die Performanceverluste dieser Umgebung sind kleiner als die einer virtuellen Maschine, da grundlegende Teile des Systems nicht mehrfach ausgeführt werden müssen.
@ -457,7 +457,7 @@ Außerdem soll in der Virtualisierungsumgebung Grafikbeschleunigung genutzt werd
In einer Containerumgebung kann die Grafikeinheit des Hostsystems mit genutzt werden, indem das durch das Hostsystem bereits abstrahierte Gerät in den Container hereingereicht werden.
Diese Punkte sprechen für die Nutzung einer Containerumgebung.
Docker ist eine etablierte Umgebung für die Ausführung von Containern, die auf Grund der extensiven Dokumentation und Verfügbarkeit auf allen gängigen Linux-Systemen ausgewählt wurde.
Docker ist eine etablierte Umgebung für die Ausführung von Containern, die aufgrund der extensiven Dokumentation und Verfügbarkeit auf allen gängigen Linux-Systemen ausgewählt wurde.
Ein Container wird in Docker über sogenannte Build-Files definiert.
Das Build-File enthält exakte Instruktionen, wie der Container aus anderen Containern, Dateien oder einer Kombination beider erstellt werden kann.
@ -475,6 +475,6 @@ Docker-Compose stellt eine Erweiterung von Docker dar.
Diese Erweiterung verwaltet die Inbetriebnahme der Container über ein spezielles Dateiformat.
Eine solche Funktion erlaubt das wiederholte Einrichten von Containern mit gleichen Parametern.
In dieser Datei werden weitere Optionen angegeben, die in die Umgebung des laufenden Containers eingreifen.
Dazu gehört zum Beispiel das automatisierte Übergeben von Umgebungsvariablen, Einrichten von Netzwekumgebungen und Erstellen von Volumes und ``bind mounts''.
Dazu gehört zum Beispiel das automatisierte Übergeben von Umgebungsvariablen, Einrichten von Netzwerkumgebungen und Erstellen von Volumes und ``bind mounts''.
Diese Automatisierung erleichtert die initiale Einrichtung eines Containers auf einem neuen System, da alle benötigten Aspekte leicht angepasst werden können.

135
tex/4_Umsetzung.tex
View File

@ -63,7 +63,7 @@ popd || exit
\end{figure}
Dieses Skript nutzt \code{colcon}, um alle Pakete in \code{~/workspace}-Verzeichnis zu erstellen.
Dabei wird auch eine \code{compile_commands.json}-Datei im build-Unterordner erstellt, die von Entwicklungsumgebungen zur Syntaxvervollständigung genutzt werden.
Dabei wird auch eine \code{compile_commands.json}-Datei im \code{build}-Unterordner erstellt, die von Entwicklungsumgebungen zur Syntaxvervollständigung genutzt werden.
Um eine Nutzung in allen Entwicklungsumgebungen zu erlauben, wurde diese zusätzlich in das Hauptverzeichnis des Workspaces gelinkt.
Dies ist notwendig, da einige Entwicklungsumgebungen nur dort nach dieser Datei suchen.
@ -72,7 +72,7 @@ Um trotzdem alle wichtigen Informationen zu erhalten, kommt der Event-Handler \c
Durch diesen werden die Ausgaben gruppiert, und erst nach einen vollständigen Kompiliervorgang eines Pakets nacheinander ausgegeben.
Dies ermöglicht es, aufgetretene Fehler einfacher auf ein bestimmtes Paket zurückführen zu können, ohne das gesamte Log zu durchsuchen.
Hierbei ist es hilfreich, dass die verbleibenden Kompiliervorgänge abgebrochen werden, falls der Kompiliervorgang eines Pakets fehlschlägt.
Dadurch befindet sich der Fehlers immer im letzten Paket der Ausgabe, da alle anderen Prozesse abgebrochen und nicht ausgegeben werden.
Dadurch befindet sich der Fehler immer im letzten Paket der Ausgabe, da alle anderen Prozesse abgebrochen und nicht ausgegeben werden.
\section{Entwicklungsumgebung}
@ -86,12 +86,12 @@ Die Entwicklungsumgebung kann eine interne Repräsentation des geschriebenen Cod
Diese Repräsentation kann genutzt werden, um die implementierten Funktionen der Entwicklungsumgebung bereitzustellen.
Um dies zu erreichen, muss für jede unterstützte Sprache Code geschrieben werden, der in die Entwicklungsumgebung integriert wird.
Als Alternative existiert das Language Server Protocol, kurz LSP\cite{lsp}, dass eine Schnittstelle in Form eines JSON-RPC Protokolls zur Verfügung stellt, um Infomationen über den Code an die Entwicklungsumgebung zu übergeben.
Als Alternative existiert das ``Language Server Protocol'', kurz LSP \cite{lsp}, dass eine Schnittstelle in Form eines JSON-RPC Protokolls zur Verfügung stellt, um Informationen über den Code an die Entwicklungsumgebung zu übergeben.
Dies erlaubt einer Entwicklungsumgebung, nur noch den benötigten Server der Sprache zu starten, um Informationen über den Code in einem standardisierten Protokoll zu erhalten.
Der große Vorteil des LSP ist, dass eine Entwicklungsumgebung alle Funktionen der Programmiersprache vollständig unterstützt, solange das Protokoll vollständig implementiert wurde und ein entsprechender Server für die Sprache existiert.
Bestimmte Funktionen, die beim Design des LSP nicht bedacht wurden, können einfacher in einer interner Implementation umgesetzt werden.
Bestimmte Funktionen, die beim Design des LSP nicht bedacht wurden, können einfacher in einer internen Implementation umgesetzt werden.
Deswegen besitzen Entwicklungsumgebungen mit interner Coderepräsentation häufig mehr Funktionen, spezialisieren sich jedoch auf bestimmte Sprachen.
In diesem Projekt wurden mehrere Entwicklungsumgebungen mit den jeweils unterschiedlichen Verfahren eingesetzt.
@ -103,8 +103,8 @@ Dazu wird beim Start einer Verbindung zu einem entfernten System dieser Server a
Die anfängliche Entwicklung wurde mit PyCharm und CLion durchgeführt, da diese durch ihre interne Codeanalyse die ROS-Umgebung ohne Konfiguration nutzen konnten.
Jedoch sind diese Umgebungen sehr ressourcenintensiv, was die gleichzeitige Ausführung erheblich verlangsamt.
Daher wurde später eine Entwicklungsumgebung mit LSP-Unterstützung, in diesem Fall Lapce, verwendet.
Der dafür notwenige LSP-Server wird durch eine Veränderung des Buildscripts automatisch im Container installiert.
Daher wurde später eine Entwicklungsumgebung mit LSP-Unterstützung, in diesem Fall Lapce (siehe Abbildung \ref{lapce}), verwendet.
Der dafür notwendige LSP-Server wird durch eine Veränderung des Buildscripts automatisch im Container installiert.
Unter Verwendung dieser neuen Server kann Lapce die Codevervollständigung und Codeanalyse wie PyCharm und CLion durchführen.
Gleichzeitig wird der Ressourcenverbrauch gesenkt, da nur ein einziger Editor benötigt wird.
@ -116,14 +116,14 @@ Gleichzeitig wird der Ressourcenverbrauch gesenkt, da nur ein einziger Editor be
\end{figure}
\newpage
\section{Verwendete Datentypen}\label{datatypes}
In diesem Projekt werden viele unterschiedliche Datentypen sowohl für den Datenaustauch zwischen Nodes, als auch in der internen Implementation der Nodes verwendet.
In diesem Projekt werden viele unterschiedliche Datentypen sowohl für den Datenaustausch zwischen Nodes, als auch in der internen Implementation der Nodes verwendet.
Diese Datentypen sind größtenteils aus der Programmiersprache C++ bekannt, jedoch werden auch weitere Typen aus eigenem Code oder eingebundenen Bibliotheken verwendet.
Um die Verständlichkeit der Dokumentation zu erleichtern, sind die in der Implementation verwendeten Datentypen hier zusammengefasst und beschrieben.
\begin{description}
\item[Pose]
ist einer der häufigsten Datentypen im Umgang mit Gazebo.
Der Pose-Datentyp enthält die Information über die Lage und Rotation eines Objekts im Raum.
Die Daten werden als relative Werte im Bezug auf das übergeornete Objekt gespeichert.
Die Daten werden als relative Werte in Bezug auf das übergeordnete Objekt gespeichert.
Objekte wie der Mensch liegen in der Hierarchie der Simulation direkt unter der Welt, deren Pose sich direkt im Nullpunkt und ohne Rotation befindet.
Durch diesen Umstand sind die Koordinaten des Menschen absolut, da sie nicht durch die Welt verschoben und rotiert werden.
\item[Area]
@ -156,7 +156,7 @@ Zuerst wird ein Stellplatz für den Roboter benötigt.
Dieser sollte an einer Ecke des Raumes positioniert werden, was zu höheren Verfahrgeschwindigkeiten führt.
Das ist durch die dynamische Verfahrgeschwindigkeit bedingt, die bei geringerer Distanz zum Menschen abnimmt.
Des weiteren werden eine Arbeits- und Lagerstätte für den Menschen benötigt, die in den Szenarien genutzt werden sollen.
Des Weiteren werden eine Arbeits- und Lagerstätte für den Menschen benötigt, die in den Szenarien genutzt werden sollen.
Im Koexistenzszenario soll der Mensch nur an diesen Stellen seine Arbeit verrichten, sich jedoch seltener dem Roboter nähern, um dessen Fortschritt zu begutachten.
Die Lagerstätte soll im Kooperationsszenario neben der Arbeit des Menschen auch für die fehlerhaften Teile verwendet werden.
Diese Teile werden durch den Roboter aussortiert und durch den Menschen in das Lager verbracht.
@ -215,9 +215,9 @@ An diesem Punkt könnte die Animation des Modells mit dem importierten Skelett b
Diese fehlenden Knochen werden für einige der gewünschten Animationen benötigt und müssten hinzugefügt werden.
Da das importierte Skelett noch andere Fehler aufwies, wurde es verworfen.
Um ein neues, passendes Skelett zu erstellen, wurde mit dem ``Rigify''\cite{rigify}-Plugin ein standartisiertes Menschenskelett generiert.
Um ein neues, passendes Skelett zu erstellen, wurde mit dem ``Rigify'' \cite{rigify}-Plugin ein standardisiertes Menschenskelett generiert.
Dieses neue Skelett kann an das bereits vorhandene Modell angepasst werden.
Um eine bessere Übersicht zu ermöglichen, sollten zuerst alle nicht benötigten Skeletteile, wie zum Beispiel für Gesichtsanimationen, entfernt werden.
Um eine bessere Übersicht zu ermöglichen, sollten zuerst alle nicht benötigten Skelettteile, wie zum Beispiel für Gesichtsanimationen, entfernt werden.
Danach müssen die Knochen durch Verschiebung und Skalierung an die richtigen Positionen im Modell gebracht werden.
Dabei muss auf die Ausrichtung der Knochen zueinander geachtet werden.
@ -227,7 +227,7 @@ Der Grund dafür ist das Kreuzprodukt, dass im oben genannten Fall ein Nullvekto
Deshalb muss bei der Platzierung darauf geachtet werden, dass der Startpunkt A des ersten und der Endpunkt C des zweiten Knochens auf einer Gerade liegen.
Der Verbindungspunkt B der beiden Knochen wird vorerst auf dieser Gerade platziert.
Dieser muss senkrecht zu dieser Gerade und der gewünschten Biegeachse verschoben werden, wie in Abbildung \ref{bend} gezeigt.
Dieser muss senkrecht zu dieser Gerade und der gewünschten Beugeachse verschoben werden, wie in Abbildung \ref{bend} gezeigt.
\begin{figure}
\begin{minipage}{.45\textwidth}
@ -254,7 +254,7 @@ Dieser muss senkrecht zu dieser Gerade und der gewünschten Biegeachse verschobe
Das neu erstellte Skelett ist in Abbildung \ref{person-bones} visualisiert.
Um eine bessere Verformung bei der Bewegung von Knochen zu erreichen, wird das so genannte ``weight painting'' eingesetzt.
Um eine bessere Verformung bei der Bewegung von Knochen zu erreichen, wird das sogenannte ``weight painting'' eingesetzt.
Hierfür werden für jeden Knochen entweder automatisch oder manuell Teile des Meshes mit Gewichten versehen.
Je höher die Wichtung, desto stärker ist die Verformung an dieser Stelle, wenn der Knochen bewegt oder skaliert wird.
Die so erstellten Knochen werden auch als deformierende Knochen bezeichnet, da deren Bewegung das Modell beeinflusst.
@ -318,7 +318,7 @@ Für die neuen Animationen werden die erstellten Steuerknochen verwendet, welche
Die Verwendung des hier erstellten, verbesserten und animierten Rigs ist in vielen Grafikengines, darunter auch Gazebo, noch nicht möglich.
Es bedarf einer zusätzlichen Anpassung des Skeletts, bei der die neu erstellte Knochenstruktur aufgelöst wird, da Gazebo keine Constraints unterstützt.
Um aus einem existierenden, vollständig verbundenen Skelett ein Skelett ohne verbundene Knochen zu extrahieren, exisitiert ein weiteres Plugin mit dem Namen ``Game_Rig_Tools''\cite{gamerig}.
Um aus einem existierenden, vollständig verbundenen Skelett ein Skelett ohne verbundene Knochen zu extrahieren, existiert ein weiteres Plugin mit dem Namen ``Game_Rig_Tools'' \cite{gamerig}.
Dieses separiert die neuen Steuerknochen wieder vom ursprünglichen Modell, damit in diesem nur noch die deformierenden Knochen enthalten sind.
Alle erstellten Animationen der Steuerknochen müssen in direkte Bewegungen der deformierenden Knochen des Modells umgewandelt werden.
@ -349,7 +349,7 @@ Wird diese Modifikation nicht vorgenommen, sind die Modelle um 90 Grad verdreht.
Zuletzt muss im mit 5 markierten Animations-Reiter noch eine weitere Einstellung vorgenommen werden.
Die mit 6 markierte Einstellung bewirkt, dass alle Bewegungen der exportierten Knochen mit gespeichert werden, auch wenn diese sich nicht bewegen.
Da sich einige Knochen in der Animation in einer konstanten Pose befinden, exportiert Blender diese nicht.
Dies führt zu Fehlern, falls die Knochen von der Standartposition abweichen.
Dies führt zu Fehlern, falls die Knochen von der Standardposition abweichen.
Ein solcher Fehler äußert sich in Gazebo durch verdrehte Knochen während der Animation.
\begin{figure}
@ -384,53 +384,52 @@ Diese Kollisionen führt zu einem Crash, wenn beide Plugins in der Simulation ge
Der Crash geschieht, da beide Plugins rclcpp, eine Bibliothek zur Kommunikation mit ROS-Topics, verwenden.
In dieser Bibliothek wird eine globale Instanz angelegt, die 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.
Da jedoch von beiden Plugins auf diesen Zustand zugegriffen wird, kommt es zu Problemen, da kein Synchronisationsmechanismus existiert.
Die dadurch entstehenden gleichzeitigen Zugriffe auf dieselben Ressourcen führen zur Terminierung des Programms.
Nachdem die Fehlerursache ermittelt war, stellte sich heraus, daß der Konflikt allein durch Modifikation des ActorPlugins nicht aufzulösen ist.
Nachdem die Fehlerursache ermittelt war, stellte sich heraus, das der Konflikt allein durch Modifikation des ActorPlugins nicht aufzulösen ist.
Eine Anpassung beider Plugins auf die gemeinsame Nutzung der Bibliothek ist möglich, erfordert aber potentiell weitreichende Neuimplementationen, die zeitlich im Rahmen dieser Arbeit nicht umsetzbar waren.
Eine Anpassung beider Plugins auf die gemeinsame Nutzung der Bibliothek ist möglich, erfordert aber potenziell weitreichende Neuimplementationen, die zeitlich im Rahmen dieser Arbeit nicht umsetzbar waren.
Die Nutzung eines separaten Nachrichtendienstes, der keinen globalen Kontext benötigt, ist die sicherste und schnellste Lösung des Problems.
Eine solche Implementation erfordert jedoch zusätzliche Logik, um die beiden Dienste ineinander übersetzen zu können.
Die Auswahl eines Dienstes wurde dabei aus einer Reihe an unterschiedlichen Möglichkeiten getroffen.
Webdienste, wie zum Beispiel REST-API's und Websockets werden von vielen Sprachen nativ untersützt, was diese universell einsetzbar macht.
Webdienste, wie zum Beispiel REST-API's und Websockets werden von vielen Sprachen nativ unterstützt, was diese universell einsetzbar macht.
Eine REST-API hat den Vorteil, dass sie durch fast jede Programmiersprache genutzt werden kann, die Hyper Text Transfer Protocol, auch HTTP genannt, unterstützt.
da diese zur Kommunikation genutzt werden
Eine REST-API hat den Vorteil, dass sie durch fast jede Programmiersprache genutzt werden kann, die das ``Hyper Text Transfer Protocol'', auch HTTP genannt, unterstützt.
Das HTTP besitzt jedoch keinen einheitlichen Feedbackmechanismus.
Dieser müsste entweder durch kontinuierliche Abfragen des aktuellen Status, auch ``polling'' genannt, oder eine lang anhaltende Request realisiert werden.
Eine Verwendung von kontinuierlichen Abfragen ist zwar mit fast jeder Programmiersprache möglich, jedoch ist die Reaktionszeit des Systems an die Antwortzeit des Servers gebunden.
Der Einsatz einer lang anhaltenden Request umgeht dieses Problem, jedoch müssen der eingesetzte Webserver und der Client diese Funktion unterstützen.
Das neuere Websocket-Protokoll\cite{websocket} bieten die Möglichkeit, bidirektional Daten zu übertragen.
Das neuere Websocket-Protokoll \cite{websocket} bieten die Möglichkeit, bidirektional Daten zu übertragen.
Dadurch können Aktionsanfragen und Feedback auf dem gleichen Kanal übertragen werden, was das Protokoll übersichtlicher macht.
Beide Technologien basieren auf einem Webserver, der auf einem bestimmten Port des Systems ausgeführt werden muss, was Kollisionen mit anderen Services ermöglicht.
Die Portnummer kann zwar geändert werden, ist jedoch nicht einfach mit einer Komponente assoziierbar, was sie zu einer ``Magischen Zahl'' macht.
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 Technologien durch TCP oder UDP und HTTP relativ großen Protokolloverhead, der 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.\cite{shmem}
Eine andere Möglichkeit ist die Nutzung von ``shared memory'', einem geteilten Speicherbereich zwischen beiden Programmen \cite{shmem}.
Dieser kann zur bidirektionalen Kommunikation genutzt werden, da beide Programme auf den gleichen Speicherbereich zugreifen können.
Alle Zugriffe auf den Bereich sind extrem schnell, da sie den Arbeitsspeicher des Systems nie verlassen, was diese Technik ideal zur Datenübertragung zwischen Prozessen macht.
Durch das Erlauben gleichzeitiger Zugriffe kann es vorkommen, dass beide Programme gleichzeitig versuchen, Änderungen am Speicher vorzunehmen.
Diese gleichzeitige Modifikation, auch ``race condition'' genannt, kann zu Fehlern führen, wenn die Zugriffe auf den Bereich nicht kontrolliert werden.
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.
Hier wird im Betriebssystem ein Speicherbereich mit bestimmter Größe für den Datenaustausch reserviert.
Dieser Bereich besitzt ein Identifikationsmerkmal, dass es Anwendungen erlaubt, Zugriff auf diesen zu erlangen.
Ein Programm kann in diesem Bereich Daten ablegen, die durch andere Programme gelesen und geschrieben werden können.
Die Koordinierung der Zugriffe erfolgt dabei durch das Betriebssystem, was gleichzeitige Zugriffe, wie bei shared memory, ausschließt.
Durch diesen Umstand kommt es zu einer Reduktion des Nachrichtendurchsatzes.
Die Angaben zu den Durchsätzen der verschiedenen Datenübertragungsmechanismen wurden mit \code{ipc-bench}\cite{ipcBench} auf dem Entwicklungssystem ermittelt.
Die Angaben zu den Durchsätzen der verschiedenen Datenübertragungsmechanismen wurden mit \code{ipc-bench} \cite{ipcBench} auf dem Entwicklungssystem ermittelt.
Als Nachrichtendienst wurde die MessageQueue ausgewählt, da die integrierten Funktionen die Entwicklung erleichtern und die Geschwindigkeit ausreichend für das Einsatzszenario ist.
Jedoch existieren unter Linux 2 unabhängige Implementationen von MessageQueues mit unterschiedlichen Funktionen.
Die erste Implementation ist die System V MessageQueue\cite{mqSystemV}, und verwendet zur Identifikation einfache Ganzzahlen.
Die erste Implementation ist die System V MessageQueue \cite{mqSystemV} und verwendet zur Identifikation einfache Ganzzahlen.
Die neuere Implementation der MessageQueue ist die POSIX-MessageQueue.\cite{mqPosix}
Die neuere Implementation der MessageQueue ist die POSIX-MessageQueue \cite{mqPosix}.
Sie bietet einige weitere Funktionen, wie zum Beispiel asynchrone Benachrichtigungen bei neuen Nachrichten, Quality of Service und nutzt bis zu 256 Zeichen lange Zeichenketten 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 entwickelt wurde.
@ -467,7 +466,7 @@ Ein ActionServer innerhalb eines Programmes definiert 3 Funktionen, welche die H
Auch diese Anfrage kann entweder mit ACCEPT akzeptiert werden, oder mit REJECT zurückgewiesen werden.
}
\item{
Um Feedback während der Ausführung der Aktion geben zu können, exisitiert die dritte Funktion.
Um Feedback während der Ausführung der Aktion geben zu können, existiert die dritte Funktion.
Diese erhält als Parameter ein Objekt, mit dem Feedback- und Endnachrichten an den Client gesendet werden können.
}
\end{itemize}
@ -484,7 +483,7 @@ Der Server wartet den Zustandswechsel des Plugins ab und bestätigt dem Client d
Ab diesem Zeitpunkt ist eine Terminierung der Anfrage durch den Client möglich.
Dies geschieht durch eine Abbruchanfrage, welche sofort bearbeitet wird.
Für den Abbruch wird der Status des Plugins über die MessageQueue auf IDLE gesetzt, was alle laufenden Aktionen sofort beendet.
Der Zustandswechsel des Plugins wird abgewartet, um bei erreichen des IDLE-Zustands die Abbruchanfrage zu bestätigen.
Der Zustandswechsel des Plugins wird abgewartet, um bei Erreichen des IDLE-Zustands die Abbruchanfrage zu bestätigen.
Solange die Aktion läuft, werden periodisch Feedbacknachrichten über die MessageQueue an den Server gesendet.
Der Server bringt diese in ein neues Format und leitet sie an den Client weiter.
@ -504,11 +503,11 @@ Der Code des Plugins ist dabei im Paket \code{ign_actor_plugin} organisiert, das
Das Plugin wird durch den Startvorgang und später von den empfangenen Nachrichten in folgende Zustände versetzt werden:
\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.
wird ausschließlich zu Simulationsbeginn verwendet, um alle benötigten Referenzen aus der Simulationsumgebung im Plugin zu hinterlegen, sodass diese in den anderen Zuständen genutzt werden können.
\item[Idle]
definiert den Zustand, der nach erfolgreicher Ausführung eines Befehls angenommen wird.
\item[Movement]
bedeutet die Ausführung einer Bewegung in potentiell mehreren Schritten.
bedeutet die Ausführung einer Bewegung in potenziell mehreren Schritten.
\item[Animation]
entspricht der Ausführung einer Animation an der aktuellen Position des Actors.
Diese kann durch einen Skalierungsfaktor beschleunigt oder verlangsamt werden.
@ -518,7 +517,7 @@ In diesen Zuständen muss das ActorPlugin die Simulationsumgebung beeinflussen,
Dies erfordert den Zugriff auf simulationsinterne Daten, die durch das Plugin gelesen und verändert werden sollen.
Der Zugriff auf diese Daten wird durch ein EntityComponentManager-Objekt ermöglicht.
Durch den EntityComponentManager kann auf das so genannte ``Entity Component System'' zugegriffen werden, in dem alle Simulationsobjekte organisiert sind.
Durch den EntityComponentManager kann auf das sogenannte ``Entity Component System'' zugegriffen werden, in dem alle Simulationsobjekte organisiert sind.
Ein Entity Component System besteht aus einer oder mehr Entities, die Objekte innerhalb der Simulation abbilden.
Objekte können beliebig viele Components besitzen, bei denen es sich um zusätzliche Eigenschaften und Erweiterungen der Funktionen des betroffenen Objekts handelt.
Die wichtigsten Komponenten für die Funktion des Plugins sind dabei:
@ -537,8 +536,8 @@ Die wichtigsten Komponenten für die Funktion des Plugins sind dabei:
\end{description}
Durch das Verändern dieser Komponenten kann die gewünschte Funktionalität des Plugins erreicht werden.
Diese Veränderungen müssen zu jedem Simulationschritt erneut vorgenommen werden, um einen flüssigen Ablauf zu gewährleisten.
Um dies zu erreichen, können im Plugin bestimmte Interfaces mit entsprechenden Funktionen implementiert werden.\cite{ignPlugin}
Diese Veränderungen müssen zu jedem Simulationsschritt erneut vorgenommen werden, um einen flüssigen Ablauf zu gewährleisten.
Um dies zu erreichen, können im Plugin bestimmte Interfaces mit entsprechenden Funktionen implementiert werden \cite{ignPlugin}.
Diese Funktionen werden später in der Simulation aufgerufen.
Folgende Funktionen werden von Gazebo unterstützt:
\begin{description}
@ -560,20 +559,20 @@ Jede dieser Funktionen ist in einem Interface mit dem Präfix \code{ISystem} def
Für Gazebo muss das Plugin noch registriert werden, was mit dem \code{IGNITION_ADD_PLUGIN}-Makro geschieht.
Mit diesen Vorbereitungsschritten wird das Plugin von Gazebo verwendbar gemacht.
Das ActorPlugin benötigt für seine Funktion das übergeornete Simulationsobjekt, dass durch das Plugin beeinflusst werden soll.
Das ActorPlugin benötigt für seine Funktion das übergeordnete Simulationsobjekt, dass durch das Plugin beeinflusst werden soll.
Dies erfordert die Implementation des \code{ISystemConfigure}-Interfaces für das ActorPlugin.
Außerdem soll die simulierte Person bewegt werden. Da dieser Vorgang während der Simulationszeit ablaufen soll, muss hierfür das \code{ISystemUpdate}-Interface genutzt werden.
Als erstes wird durch das Laden des Plugins die Configure-Funktion aufgerufen.
Als Erstes wird durch das Laden des Plugins die Configure-Funktion aufgerufen.
Da das Plugin erst durch Gazebo geladen werden muss, kann davon ausgegangen werden, dass alle benötigten Message Queues bereits durch den ActorServer erstellt wurden.
Trotz dieses Umstandes wartet das Plugin auf deren Erstellung, um bei Konfigurationsfehlern auffälliges Verhalten zu zeigen.
Im Log wird diese Aktion vermerkt, um das Debugging zu erleichtern.
Nach dem erfolgreichen Aufbau der Verbindung wird ein Thread gestartet, der die eingehenden Nachrichten verarbeitet.
Dabei wird zuerst ein Sperre gesetzt, um parallele Zugriffe durch die Update-Funktion zu verhindern.
Dabei wird zuerst eine Sperre gesetzt, um parallele Zugriffe durch die Update-Funktion zu verhindern.
Alle in der Anfrage gespeicherten Daten werden übernommen und der gewünschte State gesetzt.
Nach dem Entfernen der Sperre wird im nächsten Simulationschritt die gewünschte Aktion durchgeführt.
Nach dem Entfernen der Sperre wird im nächsten Simulationsschritt die gewünschte Aktion durchgeführt.
Das Setzen aller obrigen Zustände ist dabei möglich, jedoch werden nur Idle, Animation und Movement genutzt.
Das Setzen aller obigen Zustände ist dabei möglich, jedoch werden nur Idle, Animation und Movement genutzt.
Der Idle-Zustand kann zum Beenden eines anderen Zustands eingesetzt werden, falls dieser abgebrochen werden soll.
Die Zustände Animation und Movement werden gesendet, falls neue Ziele gesetzt werden sollen.
Da beide Zustände Animationen verwenden, wird bei deren erster Ausführung in der Update-Funktion die gewünschte Animation gesetzt.
@ -627,14 +626,14 @@ Wird bereits eine andere Aktion ausgeführt, kommt es zur Ablehnung der aktuelle
Im anderen Fall wird die Anfrage akzeptiert und in das MessageQueue-Format übersetzt und an das ActorPlugin gesandt.
Um das Starten mehrerer gleichzeitiger Aktionen zu unterbinden, muss der Empfang einer neuen Anfrage bestätigt werden, bevor weitere Befehle über den ROS-ActionServer entgegen genommen werden können.
Hierzu wird ein Mutex verwendet, der die Auswertung neuer Nachrichten verhindert, so lange der aktuelle Befehl noch nicht durch das Plugin bestätigt wurde.
Hierzu wird ein Mutex verwendet, der die Auswertung neuer Nachrichten verhindert, solange der aktuelle Befehl noch nicht durch das Plugin bestätigt wurde.
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.
Zuerst werden Animationsname und -distanz 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 neben dem Animationsnamen noch die Animationsgeschwindigkeit als Parameter benötigt.
Soll eine Animation über den ActionServer abgespielt werden, wird neben dem Animationsnamen noch die Animationsgeschwindigkeit als Parameter benötigt.
Die Feedbacknachricht enthält den Fortschritt der Animation als Gleitkommazahl von null bis eins.
\section{Roboter}
Der Roboter besteht aus mehreren interagierenden Systemen, die in ihrer Gesamtheit das vollständige Robotermodell in der Simulation verwendbar machen.
@ -648,7 +647,7 @@ Um diese Vielfalt an Daten standardisiert für andere Nodes in ROS weitergeben z
Für den Kuka LBR iisy ist kein Simulationsmodell für Gazebo und ROS verfügbar.
Daher wurde das für die Simulation benötigte Modell aus einer .stl Datei des Herstellers generiert.
Diese Datei enthält eine geometrische Beschreibung des Roboters, zu sehen in Abbildung \ref{robot_raw}, welche nicht direkt im Simulator nutzbar ist.
Aus dieser Datei wurden mit FreeCAD\cite{freecad} alle Glieder des Roboters als separate Collada-Dateien exportiert.
Aus dieser Datei wurden mit FreeCAD \cite{freecad} alle Glieder des Roboters als separate Collada-Dateien exportiert.
Dabei muss darauf geachtet werden, dass die exportierten Daten eine ausreichende Meshgröße haben.
Diese kann vor dem Export in FreeCAD eingestellt werden.
Durch diese Einstellung bleiben feine Strukturen erhalten, die später in Blender wieder reduziert werden können.
@ -680,7 +679,7 @@ Diese Daten können später zur Simulation der Motoren genutzt werden, die den A
Die Gelenkpositionen sind dabei relative Angaben, die sich auf das Glied beziehen, an dem ein weiteres Glied über das Gelenk verbunden werden soll.
Alle kontrollierbaren Gelenke benötigen auch eine Gelenkachse, die 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.
Alle hier erstellten Dateien wurden im Paket \code{iisy_config} zusammengefasst, um diese einfacher wieder auffinden zu können.
\begin{figure}
\begin{minipage}{.49\textwidth}
\includegraphics[width=\textwidth]{img/MA-Roboter-Visuell}
@ -728,7 +727,7 @@ Das Gazebo-Plugin lädt dabei die verwendeten Controller und versorgt diese mit
Alle Behavior Trees wurden im Paket \code{btree} organisiert, das die Bäume im XML-Format und die Implementation der Nodes und umliegenden Infrastruktur in C++ enthält.
Für die Umsetzung des Szenarios wurden neue Nodes für den BehaviorTree erstellt.
Für die Umsetzung des Szenarios wurden neue Nodes für den Behavior Tree erstellt.
Diese lassen sich nach Nutzung in verschiedene Gruppen einordnen.
\subsubsection{Allgemein nutzbare Nodes}
@ -745,7 +744,7 @@ Diese lassen sich nach Nutzung in verschiedene Gruppen einordnen.
Hierfür wird überprüft, ob die X und Y-Werte der Pose in einem der Dreiecke liegen, welche die Area definieren.
Der Rückgabewert ist das Ergebnis dieser Überprüfung, wobei SUCCESS bedeutet, dass sich die Pose in der Area befindet.
\item[OffsetPose]
wird genuzt, um eine Pose im Raum zu bewegen und/oder deren Orientierung zu verändern.
wird genutzt, um eine Pose im Raum zu bewegen und/oder deren Orientierung zu verändern.
Falls der \code{offset} Parameter gesetzt ist, wird dieser mit dem \code{input} Parameter summiert.
Außerdem wird die Orientierung der Pose auf den \code{orientation} Parameter gesetzt, falls dieser vorhanden ist, was den ursprünglichen Wert überschreibt.
\item[InterruptableSequence]
@ -757,8 +756,8 @@ Diese lassen sich nach Nutzung in verschiedene Gruppen einordnen.
ist eine Steuerungsnode, die mehrere untergeordnete Nodes besitzt.
Dabei werden diese nicht, wie bei anderen Steuerungsnodes üblich, sequentiell ausgeführt.
Anhand einer vorgegebenen Wichtung im \code{weights} Parameter wird eine der untergeordneten Nodes zufällig ausgewählt.
Diese Node wird als einzige Node ausgeführt, bis diese den SUCCESS-Status zurück gibt.
Nach dem dieser Status erreicht wurde, wird bei dem nächsten Durchlauf eine neue Node ausgewählt.
Diese Node wird als einzige Node ausgeführt, bis diese den SUCCESS-Status zurückgibt.
Nachdem dieser Status erreicht wurde, wird bei dem nächsten Durchlauf eine neue Node ausgewählt.
Der Rückgabewert ist der Rückgabewert der ausgewählten untergeordneten Node.
\item[IsCalled]
fragt den aktuellen Called-Status des Actors ab, der in einigen Szenarien vom Roboter verwendet wird, um den simulierten Menschen zu rufen.
@ -775,16 +774,16 @@ Diese lassen sich nach Nutzung in verschiedene Gruppen einordnen.
\begin{description}
\item[ActorAnimation]
wird verwendet, um dem simulierten Menschen eine auszuführende Animation zu senden.
Die Node benötigt zur Ausführung einen Animationsname, der im \code{animation_name} Parameter angegeben wird.
Die Node benötigt zur Ausführung einen Animationsnamen, der im \code{animation_name} Parameter angegeben wird.
Ein optionaler \code{animation_speed} Parameter gibt die Ausführungsgeschwindigkeit vor.
Der Rückgabewert ist SUCCESS, wenn die komplette Ausführung gelang, oder FAILURE, falls diese abgebrochen oder abgelehnt wurde.
\item[ActorMovement]
funktioniert wie eine ActorAnimation, sendet jedoch eine Bewegungsanfrage.
Auch für diese wird ein Animationsname benötigt, der im \code{animation_name} Parameter definiert wird.
Jedoch wird für die Synchronisation zur Bewegung ein Disztanzwert benötigt, der in einem Animationsdurchlauf zurückgelegt wird.
Jedoch wird für die Synchronisation zur Bewegung ein Distanzwert benötigt, der in einem Animationsdurchlauf zurückgelegt wird.
Dieser wird im \code{animation_distance} Parameter übergeben.
Eine Zielpose wird im \code{target} Parameter gesetzt.
Eine Besonderheit dieses Paramerters ist die Verwendung des Null-Quaternions als Richtungsangabe, was die Endrotation auf die Laufrichtung setzt.
Eine Besonderheit dieses Parameters ist die Verwendung des Null-Quaternions als Richtungsangabe, was die Endrotation auf die Laufrichtung setzt.
\end{description}
\subsubsection{Roboterspezifische Nodes}
@ -818,7 +817,7 @@ Der vollständige resultierende Baum ist in Abbildung \ref{subtree_work} visuali
\begin{figure}
\includegraphics[width=\textwidth]{img/MA-subtree-work}
\centering
\caption{BehaviorTree für das Arbeiten an der Werkbank}
\caption{Behavior Tree für das Arbeiten an der Werkbank}
\label{subtree_work}
\end{figure}
@ -846,7 +845,7 @@ Der resultierende Ablauf wurde als Baum in Abbildung \ref{subtree_deposit} visua
\begin{figure}
\includegraphics[width=\textwidth]{img/MA-subtree-deposit}
\centering
\caption{BehaviorTree für das Ablegen von Objekten im Schrank}
\caption{Behavior Tree für das Ablegen von Objekten im Schrank}
\label{subtree_deposit}
\end{figure}
@ -870,7 +869,7 @@ Dies wird durch eine über dem Test angeordnete Inverter-Node erreicht.
Nach diesem Schritt kann die Geschwindigkeitsanpassung vorgenommen werden, falls diese nötig ist.
Dies wird durch eine If-Then-Else Node erreicht.
Als Bedingung wird ein Test auf den Aufenthalt des Menschen in der Warnzone verwendet.
Wenn der Mensch sich in dieser befindet, wird die Geschwingigkeit auf 10\% gesetzt.
Wenn der Mensch sich in dieser befindet, wird die Geschwindigkeit auf 10\% gesetzt.
Sonst wird die Geschwindigkeit wieder auf 100\% erhöht.
Nach dieser Sequenz kann der spezifische Teil für die gewünschte Applikation hinzugefügt werden.
@ -879,7 +878,7 @@ In Abbildung \ref{tree_base_robot} wurde dies durch eine Wolke repräsentiert.
\begin{figure}
\includegraphics[width=\textwidth]{img/MA-tree-base-robot}
\centering
\caption{Grundlegender BehaviorTree des Roboters}
\caption{Grundlegender Behavior Tree des Roboters}
\label{tree_base_robot}
\end{figure}
@ -898,7 +897,7 @@ Der vollständige Baum ist in Abbildung \ref{tree_robot_coex} zu sehen.
\begin{figure}
\includegraphics[width=\textwidth]{img/MA-tree-robot-coex}
\centering
\caption{Erweiterter BehaviorTree des Roboters bei Koexistenz }
\caption{Erweiterter Behavior Tree des Roboters bei Koexistenz }
\label{tree_robot_coex}
\end{figure}
@ -916,7 +915,7 @@ Eine Visualisierung des modifizierten Baums wird in Abbildung \ref{tree_robot_co
\begin{figure}
\includegraphics[width=\textwidth]{img/MA-tree-robot-coop}
\centering
\caption{Erweiterter BehaviorTree des Roboters bei Kooperation}
\caption{Erweiterter Behavior Tree des Roboters bei Kooperation}
\label{tree_robot_coop}
\end{figure}
@ -935,7 +934,7 @@ Der Aufbau des Baumes wird in Abbildung \ref{tree_base_colab} dargestellt.
\begin{figure}
\includegraphics[width=\textwidth]{img/MA-tree-robot-colab}
\centering
\caption{Erweiterter BehaviorTree des Roboters bei Kollaboration}
\caption{Erweiterter Behavior Tree des Roboters bei Kollaboration}
\label{tree_base_colab}
\end{figure}
@ -952,11 +951,12 @@ Der normale Arbeitsvorgang ist ein linearer Ablauf und wird von einer Sequence-N
In dieser werden nacheinander die beiden Subtrees ``WorkOnBench'' und ``DepositToShelf'' ausgeführt.
Das Bewegen in die Sicherheitszone wird auch durch eine Sequence-Node erreicht.
Diese enthält eine GenerateXYPose-Node, um ein Ziel in der Sicherheitszone auszuwählen und eine ActorMovement-Node, um die Bewegung auszulösen.
Der Baum für diese Interaktion wird in Abbildung \ref{tree_actor_coex} dargestellt.
\begin{figure}
\includegraphics[width=\textwidth]{img/MA-tree-actor-coex}
\centering
\caption{BehaviorTree des Menschen bei Koexistenz }
\caption{Behavior Tree des Menschen bei Koexistenz }
\label{tree_actor_coex}
\end{figure}
@ -975,12 +975,12 @@ Dies erfolgt durch eine ActorMovement-Node, welche den Mensch zum rechten Tisch
Nach dieser werden zwei ActorAnimation-Nodes ausgeführt, welche die Animationen ``standing_extend_arm'' und ``standing_retract_arm'' durchführen.
Dies simuliert den Griff auf den Tisch, um das Objekt aufzuheben.
Um das Objekt im Schrank zu verstauen, wird der bereits definierte Subtree ``DepositToShelf'' genutzt.
Der Behavior Tree für die Kooperation des Menschen ist in Abbildung \ref{tree_actor_coop} dargestellt.
\begin{figure}
\includegraphics[width=\textwidth]{img/MA-tree-actor-coop}
\centering
\caption{BehaviorTree des Menschen bei Kooperation }
\caption{Behavior Tree des Menschen bei Kooperation }
\label{tree_actor_coop}
\end{figure}
@ -991,15 +991,15 @@ Falls der Mensch nicht vom Roboter gerufen wird, soll dieser im Raum herumwander
Für die Festlegung einer Baumstruktur ist es wichtig, ob der Mensch sofort, oder erst nach dem Vollenden seiner Arbeit dem Roboter zu Hilfe kommt.
In diesem Fall soll er seine Arbeit unterbrechen, um auch diese Möglichkeit zu demonstrieren.
Ein solches Verhalten lässt sich mit Hilfe einer Fallback- mit untergeordneter ReactiveSequence-Node modellieren.
Ein solches Verhalten lässt sich mithilfe einer Fallback- mit untergeordneter ReactiveSequence-Node modellieren.
In der ReactiveSequence wird zuerst überprüft, ob der Mensch gerufen wurde.
Da dieser Zustand die ReactiveSequence abbrechen soll, wird die verantwortliche AmICalled-Node mit einer Inverter-Node versehen.
In der ReactiveSequence kann eine weitere Sequence nach der Inverter-Node angeornet werden.
In der ReactiveSequence kann eine weitere Sequence nach der Inverter-Node angeordnet werden.
Diese Sequence-Node enthält den Teil des Baumes, der ausgeführt werden soll, solange der Mensch nicht gerufen wird.
In diesem Fall wird mit einer WeightedRandom-Node eine von drei GenerateXYPose-Nodes ausgewählt.
Diese geben jeweils Ziele in der sicheren Zone, Warnzone und Sicherheitszone zurück.
Nach der WeightedRandom-Node wird eine ActorMovement-Node genutzt, welche den Mensch zu dem ausgewählen Ziel bewegt.
Nach der WeightedRandom-Node wird eine ActorMovement-Node genutzt, welche den Mensch zu dem ausgewählten Ziel bewegt.
Neben der ReactiveSequence unter der Fallback-Node wird eine weitere Sequence angeordnet.
Hier wird die gewünschte Aktionsfolge bei Ruf durch den Roboter definiert.
@ -1014,10 +1014,11 @@ Auch hier wird zum Ablegen eine weitere Animationsfolge aus zwei ActorAnimation-
Dabei wird zuerst ``standing_extend_arm'' abgespielt, gefolgt von ``standing_retract_arm''.
Als letzte Aktion wird der Ruf nach dem Menschen durch eine SetCalledTo-Node auf false zurückgesetzt.
Dieser Behavior Tree ist in Abbildung \ref{tree_actor_colab} dargestellt.
\begin{figure}
\includegraphics[width=\textwidth]{img/MA-tree-actor-colab}
\centering
\caption{BehaviorTree des Menschen bei Kollaboration }
\caption{Behavior Tree des Menschen bei Kollaboration }
\label{tree_actor_colab}
\end{figure}

14
tex/5_Evaluation_und_Diskussion.tex
View File

@ -49,11 +49,11 @@ Das entworfene Containersystem ist mit der bereitgestellten Funktionalität eine
\subsubsection{Erstellung der benötigten Modelle}
Für den simulierten Menschen und Roboter werden verschiedene Modelle benötigt.
Das Robotermodell wurde aus Herstellerdaten exportiert und in Blender nachbearbeitet.
Eine Definition des Roboters wurde für Gazebo und MoveIt erstellt, um die Zusammenhänge der einzelnen Armglieder und die physikalische Eigenschaften der Gelenke festzulegen.
Eine Definition des Roboters wurde für Gazebo und MoveIt erstellt, um die Zusammenhänge der einzelnen Armglieder und die physikalischen Eigenschaften der Gelenke festzulegen.
Für das Modell des Menschen wurde eine bereits in Gazebo enthaltene Animation als Grundlage verwendet.
Das in dieser enthaltene Modell wurde angepasst, um das Erstellen weiterer Animationen zu vereinfachen.
Mit Hilfe dieses modifizierten Modells wurden dann die benötigten Animationen erstellt.
Mithilfe dieses modifizierten Modells wurden dann die benötigten Animationen erstellt.
\subsubsection{Steuerung des Menschen}
@ -87,8 +87,8 @@ Eine Kombination dieser neu implementieren und den bereits in BehaviorTree.CPP v
\subsection{Erstellen der benötigten Pakete}
Alle benötigten Pakete müssen vor der ersten Ausführung der Simulation kompilliert werden.
Dies wird durch das Ausführen des \code{build.sh}-Skripts im Verzeichnis \code{\textasciitilde/workspace} des Container ausgelöst.
Alle benötigten Pakete müssen vor der ersten Ausführung der Simulation kompiliert werden.
Dies wird durch das Ausführen des \code{build.sh}-Skripts im Verzeichnis \code{\textasciitilde/workspace} des Containers ausgelöst.
Nach diesem Vorgang muss der Workspace neu geladen werden, damit die jetzt verfügbaren Pakete registriert werden.
Die kann sowohl durch einen erneuten Aufbau der SSH-Verbindung erfolgen, da bei Start der Session die entsprechende Datei geladen wird, oder manuell geschehen.
@ -125,7 +125,7 @@ Der Roboter befindet sich nach dem Start in der Ausgangsposition, siehe Abbildun
\end{minipage}
\end{figure}
Alle beschriebenen Szenarien sind mit Außnahme des Fließbandes aus dem Kooperationsszenario als Behavior Trees umgesetzt.
Alle beschriebenen Szenarien sind mit Ausnahme des Fließbandes aus dem Kooperationsszenario als Behavior Trees umgesetzt.
Diese werden nach dem Start einer Simulation ausgeführt und definieren das Verhalten von Roboter und Mensch.
\subsubsection{Koexistenzszenario}
@ -208,7 +208,7 @@ Während der Entwicklung des Projekts wurden zahlreiche Erkenntnisse gesammelt,
\item[Überprüfung auf Updates]\hfill\\
Die regelmäßige Prüfung von verwendeten Bestandteilen auf Updates kann helfen, neue oder verbesserte Funktionen einzusetzen.
\item[Verwendung eines Debuggers]\hfill\\
Viele Nodes in ROS können über Kommandozeilenparameter im Debugmodus ausgeführt werden.\cite{rosDebug}
Viele Nodes in ROS können über Kommandozeilenparameter im Debugmodus ausgeführt werden \cite{rosDebug}.
Da Programme wie Gazebo aber über weitere Launch-Files eingebunden werden, ist dies hier nicht möglich.
Eine Lösung ist in diesem Fall der separate Start der Gazebo-Umgebung in einem Debugger.\cite{gazeboDebug}
Eine Lösung ist in diesem Fall der separate Start der Gazebo-Umgebung in einem Debugger \cite{gazeboDebug}.
\end{description}

20
tex/6_Ausblick.tex
View File

@ -1,13 +1,13 @@
\chapter{Ausblick}
\section{Umsetzung in anderem Simulator}
Die Umsetzung des gleichen Problems in einem anderen Simulator bietet die Möglichkeit, weitere Simulationsplatformen zu testen und miteinander zu vergleichen.
Die Umsetzung des gleichen Problems in einem anderen Simulator bietet die Möglichkeit, weitere Simulationsplattformen zu testen und miteinander zu vergleichen.
Hierbei ist vor allem die Anbindung an ROS interessant, welche mit Gazebo mit nur einem Plugin gleichzeitig funktioniert.
Eine verbesserte Anbindung an ROS würde die schnellere Entwicklung von Komponenten und Szenarien erlauben.
Da diese für viele andere Simulatoren erst geschaffen werden muss, kann von Anfang an der Fokus auf Erweiterbarkeit gelegt werden.
Je nach gewählter Umgebung ist es potentiell nötig, bestimmte Basisfunktionen neu zu implementieren, falls diese noch nicht unterstützt werden.
Moderne Gameengines sind für diesen Einsatzzweck geeignet, da diese viele Bestandteile einer Simulationsplatform bereits enthalten.
Je nach gewählter Umgebung ist es potenziell nötig, bestimmte Basisfunktionen neu zu implementieren, falls diese noch nicht unterstützt werden.
Moderne Gameengines sind für diesen Einsatzzweck geeignet, da diese viele Bestandteile einer Simulationsplattform bereits enthalten.
Außerdem ist die hohe Verfügbarkeit von Tutorials und Dokumentation für diese weitläufig eingesetzten Engines vorteilhaft.
Mitgelieferte Werkzeuge bekannter Engines wie Unity, Unreal Engine und Godot beinhalten ausgereifte Physik- und Animationssysteme.
@ -19,7 +19,7 @@ Um ein Objekt mit dem Roboter oder Menschen zu bewegen, muss dieses auf eine von
Die Bewegung von Objekten mit dem Roboter ist möglich, da dieser mit der gegenwärtigen Implementation aus mehreren Physikobjekten besteht.
Das zu bewegende Objekt kann somit dem Objekt des Endeffektors als Unterobjekt hinzugefügt werden.
Der daraus resultierende Übergang in lokale Koordinaten kann potentielle Umrechnung anhand der Transformationen vorhergehender Armteile erfordern.
Der daraus resultierende Übergang in lokale Koordinaten kann potenzielle Umrechnung anhand der Transformationen vorhergehender Armteile erfordern.
Eine Bewegung mit dem Menschen erfordert vor allem bei Animationen einen anderen Mechanismus.
Da der Mensch nicht aus einzelnen Physikobjekten besteht, ist die Anbringung als Unterobjekt nicht möglich.
@ -28,7 +28,7 @@ Stattdessen muss die aktuelle Position des Armes anhand der Animationsdaten verf
Die unterschiedliche Anbindung von Roboter und Mensch erfordert mehrere Implementationen, welche Zustandsdaten über das Objekt austauschen müssen.
Um die Objekte zu steuern, muss eine weitere ROS-Anbindung in einem entsprechenden Gazebo-Plugin erfolgen.
Dieses Plugin unterliegt den selben Limitierungen, die auch schon im ActorPlugin beachtet werden mussten.
Dieses Plugin unterliegt denselben Limitierungen, die auch schon im ActorPlugin beachtet werden mussten.
Eine weitere Nachrichtenübergabe als Zwischenschritt vor dem eigentlichen ROS-Server ist so unausweichlich.
Dieser Kommunikationsmechanismus muss das Erstellen, Entfernen und Bewegen von Objekten zwischen Roboter, Umgebung und Mensch unterstützen.
@ -38,7 +38,7 @@ Mit den Kameras kann eine Tiefenkarte erstellt werden, um die Verfahrgeschwindig
MoveIt implementiert für diesen Verwendungszweck bereits sogenannte Octomaps.
Diese Octomaps repräsentieren die Belegung eines Raums durch Objekte mit gleichseitigen Würfeln.
Der Einsatz dieser OctoMaps zum Ausweichen von Hindernissen ist bereits in der Bewegungsplanung implementiert.
Der Einsatz dieser Octomaps zum Ausweichen von Hindernissen ist bereits in der Bewegungsplanung implementiert.
Für die Reduktion der Verfahrgeschwindigkeit muss der erwartete Raum mit dem aktuellen Raum verglichen werden.
Daraus kann die Distanz zu einem unerwarteten Objekt berechnet werden, um die Verfahrgeschwindigkeit dementsprechend anzupassen.
\section{Zusammenführung von ActorPlugin und ActorServer}
@ -54,7 +54,7 @@ Folgende Versuche wurden bereits durchgeführt, führten aber zu keinem Erfolg:
Die neuste ROS-Version bietet keine expliziten Vorteile der Umgebung selbst, jedoch sind in dieser mehr Pakete verfügbar.
In der für das Projekt genutzten Umgebung befinden sich mehrere Pakete, die so auf eine neuere Version gebracht werden könnten.
Jedoch ist der Aufwand einer Migration nur schwer abschätzbar.
Dies führte zu der Entscheidung, diesen Prozesses in dieser Arbeit nicht durchzuführen.
Dies führte zu der Entscheidung, diesen Prozess in dieser Arbeit nicht durchzuführen.
Ein Vorteil dieser Maßnahme ist die Möglichkeit, das Paket \code{gz_ros2_control} aus einer offiziellen Paketquelle zu beziehen.
Dieses Paket stellt das Gazebo-Plugin für den Roboter bereit und muss so nicht manuell auf dem neusten Stand gehalten werden.
@ -62,14 +62,14 @@ Dieses Paket stellt das Gazebo-Plugin für den Roboter bereit und muss so nicht
\section{Verbesserung der Behavior Trees}
Eine weitere mögliche Verbesserung ist der Ausbau der Implementation der Behavior Trees.
Ein Update auf die neuste Version, die während der Entwicklung diese Projektes erschienen ist, würde die verbesserte Nutzung von asynchronen Nodes erlauben.
Ein Update auf die neuste Version, die während der Entwicklung dieses Projektes erschienen ist, würde die verbesserte Nutzung von asynchronen Nodes erlauben.
Die Integration von Pre- und Post-Conditions erlaubt die Ausführung von Events vor und nach dem Ausführen einer Node.
Weitere universelle Node-Parameter vereinfachen den Aufbau von Bäumen durch die Vereinfachung von Schleifen und Bedingungen.
Ein Nachteil der Migration wäre jedoch das Wegfallen einiger Funktionen des Editors, welcher in dieser Version unter einer neuen Lizenz vertrieben wird.
Die Analyse von Logdateien nach der Ausführung und die Überwachung von Bäumen zur Laufzeit sind ohne kostenpflichtige Lizenz nicht mehr möglich.
Eine weitere Alternative ist die Nutzung von MoveIt Studio\cite{moveItStudio}, welches ebenfalls mit Behavior Trees arbeitet.
Eine weitere Alternative ist die Nutzung von MoveIt Studio \cite{moveItStudio}, welches ebenfalls mit Behavior Trees arbeitet.
Die direkte Integration mit MoveIt vereinfacht die Anbindung an den Roboter, da wichtige Funktionen bereits implementiert sind.
Jedoch ist die Unterstützung für eigene Befehle nur schlecht dokumentiert.
Diese werden aber für die Steuerung des Menschen benötigt, was dieses Alternative nur für die Robotersteuerung attraktiv macht.
@ -77,5 +77,5 @@ Diese werden aber für die Steuerung des Menschen benötigt, was dieses Alternat
Die Anpassung der aktuellen Implementation für größere Projekte ist eine weitere Option.
Um die Übersichtlichkeit des Projekts zu erhöhen, werden häufig separate Module verwendet.
Diese können einzelne Funktionen bereitstellen, die separat von anderen Modulen agieren.
Alle Module müssen aktuell im Buildfile deklariert und mit in das Programm kompilliert werden.
Alle Module müssen aktuell im Buildfile deklariert und mit in das Programm kompiliert werden.
Bei einer großen Anzahl an Modulen erschwert dieser Umstand die Übersicht über benötigte Module für spezifische Trees.