spellcheck.
This commit is contained in:
parent
d00a3f18be
commit
8a6b7455f9
@ -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
2264
Fehler.html
Normal file
File diff suppressed because one or more lines are too long
61
dict.txt
Normal file
61
dict.txt
Normal 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}
|
||||
@ -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.
|
||||
|
||||
@ -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.
|
||||
@ -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.
|
||||
|
||||
@ -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,7 +30,7 @@ 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.
|
||||
|
||||
@ -44,7 +44,7 @@ Ein neues Nachrichtenformat mit Quality of Service kann beispielsweise Nachricht
|
||||
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.
|
||||
@ -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.
|
||||
@ -190,8 +190,8 @@ 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}.
|
||||
|
||||
@ -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.
|
||||
@ -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.
|
||||
@ -273,7 +273,7 @@ Deshalb existiert eine umfangreiche Dokumentation für die zahlreichen Komponent
|
||||
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.
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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}
|
||||
@ -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,20 +384,19 @@ 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.
|
||||
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.
|
||||
@ -406,18 +405,18 @@ Der Einsatz einer lang anhaltenden Request umgeht dieses Problem, jedoch müssen
|
||||
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.
|
||||
@ -428,9 +427,9 @@ Die Angaben zu den Durchsätzen der verschiedenen Datenübertragungsmechanismen
|
||||
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.
|
||||
@ -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.
|
||||
@ -631,7 +630,7 @@ Hierzu wird ein Mutex verwendet, der die Auswertung neuer Nachrichten verhindert
|
||||
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 ActionServer abgespielt werden, wird neben dem Animationsnamen noch die Animationsgeschwindigkeit als Parameter benötigt.
|
||||
@ -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]
|
||||
@ -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}
|
||||
@ -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.
|
||||
@ -952,6 +951,7 @@ 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}
|
||||
@ -975,7 +975,7 @@ 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}
|
||||
@ -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,6 +1014,7 @@ 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}
|
||||
|
||||
@ -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}
|
||||
|
||||
@ -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.
|
||||
@ -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,7 +62,7 @@ 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.
|
||||
|
||||
@ -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.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user