More Changes.
This commit is contained in:
parent
48cbe29307
commit
9ebb18886f
@ -2,7 +2,7 @@
|
||||
kile_livePreviewEnabled=true
|
||||
kile_livePreviewStatusUserSpecified=true
|
||||
kile_livePreviewTool=LivePreview-PDFLaTeX
|
||||
lastDocument=tex/5_Evaluation_und_Diskussion.tex
|
||||
lastDocument=tex/4_Umsetzung.tex
|
||||
|
||||
[document-settings,item:Einleitung.tex]
|
||||
Bookmarks=
|
||||
@ -139,64 +139,64 @@ TextFolding={"checksum":"","ranges":[]}
|
||||
ViMarks=
|
||||
|
||||
[view-settings,view=0,item:main.bib]
|
||||
CursorColumn=0
|
||||
CursorLine=0
|
||||
CursorColumn=33
|
||||
CursorLine=321
|
||||
Dynamic Word Wrap=false
|
||||
JumpList=
|
||||
TextFolding={"checksum":"b10ad087170976892139d22580412bc441722b7c","ranges":[]}
|
||||
TextFolding={"checksum":"64bbdc6d25aa8e655ff2b9b9aaa47140545f4269","ranges":[]}
|
||||
ViMarks=
|
||||
|
||||
[view-settings,view=0,item:main.tex]
|
||||
CursorColumn=0
|
||||
CursorLine=97
|
||||
CursorLine=105
|
||||
Dynamic Word Wrap=false
|
||||
JumpList=
|
||||
TextFolding={"checksum":"a9f3802ff2422622f2ccbc846c82d7d7d46db982","ranges":[]}
|
||||
TextFolding={"checksum":"80ccd936ce5ae7dc5995816ffe293139ed94b427","ranges":[]}
|
||||
ViMarks=
|
||||
|
||||
[view-settings,view=0,item:tex/1_Einleitung.tex]
|
||||
CursorColumn=0
|
||||
CursorLine=19
|
||||
CursorLine=7
|
||||
Dynamic Word Wrap=false
|
||||
JumpList=
|
||||
TextFolding={"checksum":"578f69b0ffbc27d095768d7a3111120650ffd5d0","ranges":[]}
|
||||
TextFolding={"checksum":"752ca31e1c24d1d85d2d8fb12ebdefa2996283f2","ranges":[]}
|
||||
ViMarks=
|
||||
|
||||
[view-settings,view=0,item:tex/2_Konzept.tex]
|
||||
CursorColumn=67
|
||||
CursorLine=116
|
||||
CursorColumn=12
|
||||
CursorLine=19
|
||||
Dynamic Word Wrap=false
|
||||
JumpList=
|
||||
TextFolding={"checksum":"60485ed57cc9cd7aa26821b7c57cadfc76a24734","ranges":[]}
|
||||
TextFolding={"checksum":"6ef833b681fc8f01a09442bcb6e152ae53c9a838","ranges":[]}
|
||||
ViMarks=
|
||||
|
||||
[view-settings,view=0,item:tex/3_Auswahl.tex]
|
||||
CursorColumn=28
|
||||
CursorLine=132
|
||||
CursorColumn=15
|
||||
CursorLine=45
|
||||
Dynamic Word Wrap=false
|
||||
JumpList=
|
||||
TextFolding={"checksum":"6b7f9d13d5c6f43641e50a66c4529ff479e866b6","ranges":[]}
|
||||
TextFolding={"checksum":"7cc0088b0b9cf29bb8431a83dabf12502827f1cd","ranges":[]}
|
||||
ViMarks=
|
||||
|
||||
[view-settings,view=0,item:tex/4_Umsetzung.tex]
|
||||
CursorColumn=91
|
||||
CursorLine=853
|
||||
CursorColumn=29
|
||||
CursorLine=953
|
||||
Dynamic Word Wrap=false
|
||||
JumpList=
|
||||
TextFolding={"checksum":"5c4f9f82c6c2646c073a4757f197beed4b273c78","ranges":[]}
|
||||
TextFolding={"checksum":"109c6b373243657c2344cec26c14be91fef98dc1","ranges":[]}
|
||||
ViMarks=
|
||||
|
||||
[view-settings,view=0,item:tex/5_Evaluation_und_Diskussion.tex]
|
||||
CursorColumn=0
|
||||
CursorLine=51
|
||||
CursorColumn=45
|
||||
CursorLine=91
|
||||
Dynamic Word Wrap=false
|
||||
JumpList=
|
||||
TextFolding={"checksum":"ab50ad5132cf05a1290a02b2b48c793d41937fb9","ranges":[]}
|
||||
ViMarks=
|
||||
|
||||
[view-settings,view=0,item:tex/6_Ausblick.tex]
|
||||
CursorColumn=0
|
||||
CursorLine=39
|
||||
CursorColumn=82
|
||||
CursorLine=21
|
||||
Dynamic Word Wrap=false
|
||||
JumpList=
|
||||
TextFolding={"checksum":"85f5725ed69452476240fe61ecbb12cc35b38976","ranges":[]}
|
||||
|
||||
Binary file not shown.
Binary file not shown.
@ -6,14 +6,14 @@ Das Modell wird um die Maschine selbst erweitert, die Einfluss auf das System ni
|
||||
Die Veränderungen durch die Maschine werden analysiert, und erlauben Rückschlüsse auf die Funktion des Systems.
|
||||
Ein solches Modell kann für die Erkennung von Fehlverhalten und Problemen schon weit vor der eigentlichen Inbetriebnahme der Maschine genutzt werden.
|
||||
|
||||
Im wachsenden Feld der Mensch-Roboter-Kollaboration existieren bereits einige Lösungen, um auch die namensgebende Interaktion von Mensch und Roboter simulieren zu können.
|
||||
Eine häufige Einschränkung der Simulatoren ist dabei, dass der Bewegungsablauf in der Simulation bereits vor deren Ausführung fest definiert werden muss.
|
||||
Dies erlaubt lediglich die Reproduktion des genauen Bewegungsablaufes, aber
|
||||
nicht verschiedene Variationen im gesamten Prozess, die durch die Ereignisse in
|
||||
der Simulation ausgelöst werden.
|
||||
Um eine solche Funktionalität bereitstellen zu können, muss der Bewegungsablauf von sowohl Roboter und Mensch zur Laufzeit der Simulation gesteuert werden.
|
||||
Da in der Realität oftmals Menschen und Maschinen im gleichen Umfeld mit- oder auch zusammenarbeiten, ist es sinnvoll, die Menschen in die Simulation einzubeziehen.
|
||||
|
||||
Diese Steuerung soll durch eine eingängliche Beschreibungssprache ermöglicht werden, die einfach erweitert und auf neue Szenarien angepasst werden kann.
|
||||
Im wachsenden Feld der Mensch-Roboter-Kollaboration existieren bereits einige Lösungen, um auch die namensgebende Interaktion von Mensch und Roboter zu simulieren.
|
||||
Eine häufige Einschränkung der Simulatoren ist dabei, dass der Bewegungsablauf in der Simulation bereits vor deren Ausführung fest definiert werden muss.
|
||||
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.
|
||||
Um diese Funktionalität zu demonstrieren, sind 3 unterschiedliche Testszenarien in der Simulationsumgebung abzubilden.
|
||||
Diese sollen durch verschiedene Aufgaben unterschiedliche Interaktionsgrade zwischen Mensch und Roboter simulieren.
|
||||
|
||||
@ -23,47 +23,47 @@ Aktuelle wissenschaftliche Arbeiten befassen sich mit vielen unterschiedlichen T
|
||||
Die Planung von unterschiedlichen Reaktionen von Roboter auf den Menschen in verschiedenen Interaktionsszenarien stellt eine Grundlage für spätere
|
||||
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 Verletzungen durch den Roboter auszuschließen.
|
||||
Diese Einschränkungen können in der Interaktion verwendet werden, 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}
|
||||
Dafür werden die maximalen Beschleunigungen einzelner Körperteile ermittelt, um diese während der Interaktion überwachen zu können.
|
||||
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 Wege, 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}
|
||||
|
||||
Eine vollständige Umsetzung einer erweiterbaren Simulation mit Mensch und Roboter, gesteuert durch eine Beschreibungssprache konnte nicht gefunden werden.
|
||||
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 in vorherigen Szenarien genutzte Bestandteile in späteren, komplexeren Szenarien weiter genutzt werden können.
|
||||
Die drei zu modellierenden Szenarien sollten so gewählt werden, dass spätere komplexere Szenarien auf einfacheren Vorgängern aufsetzten und deren Funktionen weiter nutzen und ergänzen.
|
||||
Hierfür kommen bestimmte Aufgaben, wie zum Beispiel die Interaktion mit Objekten besonders in Frage.
|
||||
Diese besitzen viele ähnliche Bestandteile, die jedoch in mehrere Umständen nutzbar sind.
|
||||
Diese besitzen viele ähnliche Bestandteile, die in mehrere 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, die alle nur eine ähnliche Bewegungsabfolge des beteiligten Menschen sind.
|
||||
Dazu zählen zum Beispiel das Hineingreifen in einen Prozess, das Aufheben von Material oder das Begutachten eines Objekts, die jeweils nur eine ähnliche Bewegungsabfolge des beteiligten Menschen sind.
|
||||
|
||||
Das erste Szenario soll sich mit der Simulation einer bereits vollautomatisierten Fertigungsaufgabe befassen, in der ein Roboter im Arbeitsbereich eines Menschen Teile fertigt.
|
||||
Die zu erwartende Interaktion beschränkt sich hierbei auf die Anpassung der Fahrgeschwindigkeit bei Annäherung des Menschen, um Kollisionen zu vermeiden.
|
||||
Die zu erwartende Interaktion beschränkt sich hierbei auf die Anpassung der Fahrgeschwindigkeit des Roboters bei Annäherung des Menschen, um Kollisionen zu vermeiden.
|
||||
Der Mensch soll in diesem Szenario an einer anderen Aufgabe arbeiten.
|
||||
Während dieser Arbeit betritt der Mensch vereinzelt den Arbeitsbereich des Roboters, was eine entsprechende Reaktion hervorrufen soll.
|
||||
Während dieser Arbeit betritt der Mensch vereinzelt den Arbeitsbereich des Roboters, was die entsprechende Reaktion des Roboters hervorrufen soll.
|
||||
|
||||
Dieses Szenario ist ein Beispiel für eine Koexistenz zwischen Roboter und Mensch, wo beide an unterschiedlichen Aufgaben, jedoch im selben Raum, arbeiten.
|
||||
Dieses Szenario ist ein Beispiel für eine Koexistenz zwischen Roboter und Mensch, wo beide im selben Raum, jedoch an unterschiedlichen Aufgaben arbeiten.
|
||||
Außerdem werden grundlegende Aspekte der Simulation getestet, wie zum Beispiel das Bewegen von Mensch und Roboter und die sicherheitsrelevante Aktion der Geschwindigkeitsanpassung.
|
||||
|
||||
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 besonderen 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, dass weiter transportiert werden muss.
|
||||
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.
|
||||
|
||||
Die dritte simulierte Aufgabe stellt ein Kollaborationsszenario dar, in dem Mensch und Roboter an der selben Aufgabe arbeiten.
|
||||
Hierbei soll eine Palette entladen werden, wobei der Roboter nicht jedes Objekt ausreichend manipulieren kann.
|
||||
Dies resultiert in Problemen beim Aufheben, Transport und Ablegen der Objekte.
|
||||
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.
|
||||
Dieser soll, wenn seine Hilfe nicht benötigt wird, andere Roboter kontrollieren, was durch das Laufen im Raum abgebildet werden soll.
|
||||
Der Mensch soll, wenn seine Hilfe nicht benötigt wird, andere Roboter kontrollieren, was durch das Laufen im Raum abgebildet werden soll.
|
||||
\section{Contributions}
|
||||
Durch diese Arbeit soll in zukünftigen Projekten die Möglichkeit geschaffen werden, konzeptionelle Probleme bei der Erstellung neuer Aufgabenbereiche eines Roboters frühzeitig durch Simulation erkennbar zu machen.
|
||||
|
||||
Dazu ist eine schnelle Konfiguration von sowohl Roboter als auch Mensch auf unterschiedliche Szenarien nötig.
|
||||
Dazu ist eine schnelle Adaption von sowohl Roboter als auch Mensch auf unterschiedliche Szenarien nötig.
|
||||
Die Szenarien sollen dabei durch eine Beschreibungssprache definiert werden.
|
||||
Durch deren einfache Struktur soll komplexes Verhalten einfach und überschaubar definierbar sein, dass dann in der Simulation getestet werden kann.
|
||||
|
||||
@ -27,7 +27,7 @@ Die Bezeichnung als Cobot\cite{cobot} ist dabei ein Portemanteau aus Collaborati
|
||||
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.
|
||||
Dieses Modell sollte die physikalischen Eigenschaften des Roboters möglichst gut abbilden.
|
||||
Dieses Modell sollte die physikalischen Eigenschaften des Roboters möglichst genau abbilden.
|
||||
Anhand dieses Modells kann der Roboter dann in der Simulation dargestellt werden und mit anderen Objekten interagieren.
|
||||
|
||||
\section{Simulation des Menschen}
|
||||
@ -37,7 +37,7 @@ Für komplexere Verhaltensweisen können Animationen und andere Aktionen, wie zu
|
||||
|
||||
Um diese Animationen erstellen zu können, wird zuerst ein animierbares Modell des Menschen benötigt.
|
||||
Das zu erstellende Modell soll dabei um weitere Animationen erweiterbar sein.
|
||||
Unterschiedliche Animationen gehen dabei meist von verschidenen Ursprungszuständen aus.
|
||||
Unterschiedliche Animationen gehen dabei meist von verschiedenen Ursprungszuständen aus.
|
||||
Um zwischen diesen Ursprungszuständen wechseln zu können, werden weitere Animationen benötigt.
|
||||
|
||||
Die so erstellten Animationen müssen von außerhalb der Simulationsumgebung ausführbar gemacht werden.
|
||||
@ -57,28 +57,28 @@ Dies erschwert die schnelle Erfassung von Abfolgen und Zustandsübergängen bei
|
||||
Behavior Trees lösen dieses Problem, in dem sie sogenannte Nodes definieren, die in einer übersichtlichen Baumstruktur angeordnet werden.
|
||||
Die einzelnen Nodes verändern dabei das System und lösen den Wechsel zu neuen Nodes aus.
|
||||
|
||||
Ursprünglich wurde das Konzept von Rodney Brooks entwickelt, der diese für mobile Roboter einsetzen wollte. \cite{1087032}
|
||||
Das System setzte sich jedoch erst später in der Spieleindustrie, für die Beschreibung von menschlichem Verhalten durch. \cite{isla2005handling}
|
||||
Ursprünglich wurde das Konzept der Behavior Trees von Rodney Brooks entwickelt, der diese für mobile Roboter einsetzen wollte. \cite{1087032}
|
||||
Das System setzte sich später jedoch zuerst in der Spieleindustrie, für die Beschreibung von menschlichem Verhalten durch. \cite{isla2005handling}
|
||||
|
||||
Der Ablauf eines Behavior Trees startet vom sogenannten Root, der Wurzel des Baums.
|
||||
Von dort an werden Nodes, die je nach Node unterschiedliches Verhalten abbilden, miteinander verbunden.
|
||||
Die Nodes werden untereinander angeordnet, dass die Relation der Nodes zueinander beschreibt.
|
||||
Die Nodes werden untereinander angeordnet, was die Relation der Nodes zueinander beschreibt.
|
||||
Jede Node ist entweder direkt unter der Root-Node oder einer anderen Node angeordnet.
|
||||
Außerdem kann jede Node eine beliebige Anzahl an untergeordneten Nodes besitzen.
|
||||
Es gibt mehrere grundlegende Arten von Tree-Nodes, die in vier Kategorien unterschieden werden können.
|
||||
Es gibt mehrere grundlegende Arten von Tree-Nodes, die in vier Kategorien unterschieden werden.
|
||||
\begin{description}
|
||||
\item[Aktions-Nodes]
|
||||
beschreiben einzelne ausführbare Aktionen, die das System beeinflussen können.
|
||||
Jede Aktion liefert dabei einen Rückgabewert über ihren Erfolg, der durch die darüber liegende Node ausgewertet werden kann.
|
||||
\item[Dekorations-Nodes]
|
||||
können den Rückgabewert einer anderen Node modifizieren.
|
||||
Meist existiert die Negation des Rückgabewerts, aber auch das Forcieren eines bestimmten Rückgabewertes, für die unterliegende Node.
|
||||
Zumeist wird die Negation des Rückgabewerts verwendet, aber auch das Forcieren eines bestimmten Rückgabewertes ist möglich.
|
||||
\item[Sequenz-Nodes]
|
||||
beschreiben eine nacheinander ausgeführte Abfolge von darunter liegenden Nodes.
|
||||
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 zu Sequenz-Nodes, jedoch werden darunter liegenden Nodes nacheinander ausgeführt, bis eine Node Erfolg zurück gibt.
|
||||
verhalten sich ähnlich wie Sequenz-Nodes, jedoch werden darunter liegenden Nodes nacheinander ausgeführt, bis eine Node Erfolg zurück gibt.
|
||||
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}
|
||||
@ -91,39 +91,62 @@ Es gibt mehrere grundlegende Arten von Tree-Nodes, die in vier Kategorien unters
|
||||
\end{figure}
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
Diese drei Nodes werden in Leserichtung, in diesem Falle von links nach rechts, ausgeführt.
|
||||
Daraus resultierend wird als erstes die linke Node ausgeführt, diese ist jedoch eine Fallback-Node mit weiteren untergeordneten Nodes.
|
||||
Da der Rückgabewert der Fallback-Node von den in ihr befindlichen Nodes bestimmt wird, werden diese nacheinander ausgeführt.
|
||||
Hier gelten die oben genannten Regeln für Fallback-Nodes.
|
||||
In diesem Fall wird geprüft, ob die Tür bereits offen ist.
|
||||
Da dies nicht der Fall ist, wird die nächste Node ausgeführt, welche die Tür öffnen soll.
|
||||
Dieser Versuch gelingt, weshalb die Ausführung der Fallback-Node mit einem Erfolg beendet wird.
|
||||
|
||||
Dadurch wird die nächste Node in der Sequenz ausgeführt, die prüft, ob die Tür durchlaufen werden kann.
|
||||
Da dies nicht möglich ist, da die Tür zwar offen, aber durch dahinter liegende Gegenstände blockiert ist, wird ein Misserfolg gemeldet, der die Ausführung der Sequenz abbricht.
|
||||
Diese würde von neuem beginnen, da die Root-Node ihre untergeornete Node ohne Berücksichtigung des Rückgabewertes neu startet.
|
||||
Daraus resultierend wird als erstes 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.
|
||||
|
||||
Durch die Definition neuer Nodes und einer anderen Baumstruktur lassen sich so einfach neue Verhalten implementieren.
|
||||
Von diesem Punkt an beginnen die Rückgaben, die das weitere Verhalten beeinflussen.
|
||||
Folgender Kontrollfluss findet in diesem Beispiel statt:
|
||||
|
||||
\begin{enumerate}
|
||||
\item{
|
||||
In dieser Node wird geprüft, ob die Tür bereits offen ist.
|
||||
Da die Tür nicht offen ist, wird ein Misserfolg zurückgemeldet.
|
||||
}
|
||||
\item{
|
||||
Dieses Ergebnis löst die Ausführung der nächsten untergeordneten Node der Fallback-Node aus.
|
||||
Die so ausgewählte Node soll die Tür öffnen.
|
||||
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.
|
||||
Daher wird die Node "Tür eintreten" nicht mehr ausgeführt.
|
||||
}
|
||||
\item{
|
||||
Dadurch wird die nächste Node in der Sequenz ausgeführt, die prüft, ob die Tür durchlaufen werden kann.
|
||||
Da dies nicht möglich ist, da die Tür zwar offen, aber durch dahinter liegende Gegenstände blockiert ist, wird ein Misserfolg gemeldet.
|
||||
}
|
||||
\item{
|
||||
Der gemeldete Misserfolg der untergeordneten Node bricht die Ausführung der Sequenz mit einem negativen Rückgabewert ab.
|
||||
}
|
||||
\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.
|
||||
|
||||
Durch die Definition neuer Nodes und einer anderen Baumstruktur lassen sich neue Verhalten implementieren.
|
||||
Dies erlaubt die schnelle Anpassung des Verhaltens der gesteuerten Systeme.
|
||||
|
||||
In dieser Arbeit sollen deshalb BehaviorTrees für die Steuerung von Mensch und Roboter verwendet werden.
|
||||
Die hierfür erstellten Nodes sollen universell gestaltet werden, um alle Szenarien, die in dieser Arbeit betrachtet werden, abzudecken.
|
||||
|
||||
\section{Virtualisierungsumgebung als Platform}
|
||||
Um Fehler durch die unvollständige Einrichtung der Umgebung zu vermeiden, ist der Einsatz fest definierter Prozesse unerlässlich.
|
||||
\section{Virtualisierungsumgebung als Plattform}
|
||||
Um Fehler durch die unvollständige Einrichtung der Umgebung zu vermeiden, ist der Einsatz fest definierter Prozesse in einer stabilen Umgebung unerlässlich.
|
||||
Dies kann durch den Einsatz einer Virtualisierungsumgebung geschehen, in der das zu entwerfende System ausgeführt wird.
|
||||
|
||||
Dadurch können benötigte Programme, Pfade und Umgebungsvariablen in der Virtualisierungsumgebung hinterlegt werden, die diese bei der Ausführung auf einem anderen Grundsystem korrekt abbildet.
|
||||
Eine solche Struktur erhöht die Zuverlässigkeit der Umgebung, da alle Änderungen an der Umgebung auf alle ausführenden Systeme gespiegelt werden.
|
||||
Eine solche Struktur erhöht die Zuverlässigkeit der Umgebung, da die Änderungen an der Umgebung auf alle ausführenden Systeme gespiegelt werden.
|
||||
|
||||
Ein weiterer Vorteil ist die beschleunigte Entwicklung, da Änderungen nicht mehr an einzelne Zielsysteme angepasst werden müssen.
|
||||
Hinzu kommt die einfachere Inbetriebnahme eines bereits entwickelten Systems, da keine Anpassungen am Hostsystem vorgenommen werden müssen.
|
||||
|
||||
Natürlich existieren auch Nachteile der Virtualisierung, die mit den Vorteilen abgewogen werden müssen.
|
||||
Alle Virtualisierungssysteme benötigen zusätzliche Rechenleistung, die der virtualisierten Anwendung nicht mehr zur Verfügung steht.
|
||||
Außerdem muss bei grafischen Systemen bedacht werden, wie die darzustellenden Daten vom Hostsystem angezeigt werden können.
|
||||
Alle Virtualisierungssysteme benötigen zusätzliche Rechenleistung, die dann der virtualisierten Anwendung nicht mehr zur Verfügung steht.
|
||||
Außerdem muss bei grafischen Systemen die Darstellung der relevanten grafischen Daten auf dem Hostsystem berücksichtigt werden.
|
||||
|
||||
Die Auswahl einer für das Projekt geeigneten Virtualisierungsumgebung stellt einen wichtigen Schritt in der Entwicklung des Gesamtsystems dar.
|
||||
Die Auswahl einer für das Projekt geeigneten Virtualisierungsumgebung beeinflusst das Ergebnis dieser Arbeit zwar nicht direkt, hat aber großen Einfluss auf die Pflege des Gesamtsystems.
|
||||
Dies erlaubt zum Beispiel unabhängige, dedizierte Versionen der Softwarekomponenten und die Möglichkeit isolierter Upgrades dieser Komponenten.
|
||||
Eine solche Plattform sorgt somit für die Reproduzierbarkeit der Ergebnisse auf verschiedenen Systemen.
|
||||
|
||||
@ -1,6 +1,5 @@
|
||||
\chapter{Komponenten-/Softwareauswahl}
|
||||
Die Auswahl der verwendeten Softwarekomponenten ist ein wichtiger Schritt in der Entwicklung.
|
||||
Die Festlegung auf eine Komponente beeinflusst den späteren Entwicklungsprozess nachhaltig.
|
||||
Die Auswahl der verwendeten Softwarekomponenten beeinflusst den späteren Entwicklungsprozess nachhaltig.
|
||||
|
||||
Alle Komponenten sollen später in der entwickelten Softwareumgebung ihre jeweiligen Teilbereiche abdecken.
|
||||
Alle diese Teilbereiche können dann zu einer Simulation vebunden werden, die das gesamte Problemfeld abdeckt.
|
||||
@ -24,11 +23,10 @@ Wichtige Aspekte sind dabei die Geschwindigkeit der Anbindung und die Definition
|
||||
Nutzbare, bereits als Interprozesskommunikation integrierte Systeme sind zum Beispiel Pipes, die Daten zwischen Prozessen über Buffer austauschen.
|
||||
Auch die Nutzung von Message Queues oder Shared Memory ist für diesen Einsatzzweck möglich.
|
||||
Diese Systeme sind performant, jedoch schwerer zu verwalten.
|
||||
Ein Problem dieser Methoden ist die direkte Kommunikation mehrerer Komponenen.
|
||||
Diese Art der Kommunikation sieht keine Modifikation von Nachrichten zur Anpassung an andere Szenarien vor.
|
||||
Ein Problem dieser Methoden ist die direkte Kommunikation mehrerer Komponenten, da diese Art der Kommunikation keine Modifikation von Nachrichten zur Anpassung an andere Szenarien vorsieht.
|
||||
|
||||
Eine Alternative stellen Sockets dar, die Daten zwischen mehreren Programmen austauschen können.
|
||||
Dabei dient ein Programm als Server, dass Anfragen von anderen Programmen, auch Clients genannt, entgegen nimmt.
|
||||
Dabei dient ein Programm als Server, der Anfragen von anderen Programmen, auch Clients genannt, entgegen nimmt.
|
||||
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.
|
||||
@ -36,17 +34,17 @@ Dieser Nachteil besteht in der potentiellen Variabilität dieser Kommunikationsm
|
||||
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.
|
||||
|
||||
In diesem Bereich ist ROS\cite{doi:10.1126/scirobotics.abm6074} als Dienstumgebung für Roboter bekannt, da es sich um ein etabliertes und quelloffenes System handelt.
|
||||
Im Bereich der Robotik ist ROS\cite{doi:10.1126/scirobotics.abm6074} als Dienstumgebung für Roboter bekannt, da es sich um ein etabliertes und quelloffenes System handelt.
|
||||
Der oben genannte Nachteil einzelner Systeme wird in ROS durch mehrere standardisierte und erweiterbare Nachrichtendefinition gelöst, die von den Programmen in der Umgebung genutzt werden.
|
||||
Um diese Nachrichten senden und empfangen zu können, liefert ROS eine eigene Implementation des Protokolls für mehrere Programmiersprachen mit.
|
||||
Für zum Beispiel Python\cite{python}, C und C++\cite{cpp} existieren entsprechende Implementationen in den Paketen \code{rospy}, \code{rclc} und \code{rclcpp}.
|
||||
Für zum Beispiel Python\cite{python}, C und C++\cite{cpp} existieren entsprechende Implementationen in Form der Pakete \code{rospy}, \code{rclc} und \code{rclcpp}.
|
||||
|
||||
Die neuste Version ROS2 bietet dabei 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.
|
||||
|
||||
Generell existieren im Feld der Roboter-Dienstumgebungen keine freien Alternativen mit ähnlichem Funktionsumfang und gleicher Reichweite.
|
||||
Vor allem die unzähligen 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 für simulierte Umgebungen, aber auch für echte Roboter eingesetzt werden.
|
||||
Diese beiden Anwendungsfälle werden durch unterschiedliche Controller realisiert.
|
||||
@ -59,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}, später auch 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.
|
||||
|
||||
@ -75,7 +73,7 @@ Zu den Aufgaben von ROS zählen folgende Teilbereiche:
|
||||
|
||||
Darunter fallen Informationen über das Paket selbst, wie dessen Name, Beschreibung und Version.
|
||||
Außerdem sind Name und Mailadresse des Autors, sowie die gewählte Lizenz des Codes vermerkt.
|
||||
Um das Paket später korrekt ausführen zu können, sind benötigte Pakete für den Kompiliervorgang und die Ausführung des Pakets eingetragen.
|
||||
Um das Paket später korrekt ausführen zu können, werden benötigte Pakete für den Kompiliervorgang und die Ausführung in die package.xml-Datei eingetragen.
|
||||
|
||||
\item[Buildumgebung]\hfill \\
|
||||
ROS nutzt die eigene Buildumgebung \code{colcon} \cite{colcon}, um Pakete in den Workspaces reproduzierbar zu erstellen.
|
||||
@ -103,7 +101,7 @@ Zu den Aufgaben von ROS zählen folgende Teilbereiche:
|
||||
|
||||
\item[Abhängigkeitsverwaltung]\hfill \\
|
||||
ROS kann durch die in den Paketen deklarierten Abhängigkeiten prüfen, ob diese in der aktuellen Umgebung ausführbar sind.
|
||||
Die generierten Warnungen bei fehlenden Paketen vermeiden Abstürze und undefiniertes Verhalten in der Ausführung von Nodes, die diese benötigen.
|
||||
Die generierten Warnungen bei fehlenden Paketen helfen dem Anwender, Abstürze und undefiniertes Verhalten bei der Ausführung von Nodes zu vermeiden, die diese Pakete benötigen.
|
||||
|
||||
\item[Datenübertragung]\hfill \\
|
||||
Um Daten zwischen Nodes austauschen zu können, müssen die Nodes miteinander auf einem festgelegten Weg kommunizieren können.
|
||||
@ -137,12 +135,12 @@ Als Simulationsumgebung eignen sich verschiedenen Programme, die sich hinsichtli
|
||||
Hierfür kommen dedizierte Werkzeuge zur Robotersimulation, aber auch beispielsweise universell einsetzbare Gameengines in Frage.
|
||||
Ein Vergleich dieser Werkzeuge ist hierbei sinnvoll, da der gebotene Funktionsumfang der Softwares sich stark unterscheidet.
|
||||
Auch andere Aspekte, wie Lizenzen oder schwer bewertbare Aspekte wie Nutzerfreundlichkeit, sind hierbei zu betrachten.
|
||||
Eine Auswahl der als Simulationsumgebung in Frage kommenden Programme werden hier vorgestellt.
|
||||
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.
|
||||
Es unterstützt viele Sprachen (C/C++, Python, Java, Lua, Matlab oder Octave) zur Entwicklung von Erweiterungen des Simulators.
|
||||
Der Simulator selbst unterstützt Menschliche Aktoren, jedoch können diese nur Animationen abspielen oder zusammen mit Bewegungen abspielen.
|
||||
CoppeliaSim existiert in 3 Versionen, die sich im Funktionsumfang unterscheiden.
|
||||
Der Simulator selbst unterstützt menschliche Aktoren, jedoch können diese nur Animationen abspielen oder zusammen mit Bewegungen abspielen.
|
||||
CoppeliaSim existiert in 3 Versionen, die sich im 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, jedoch ohne integrierten Editor und direkte ROS-Unterstützung.
|
||||
@ -155,7 +153,7 @@ Unity\cite{unity} hingegen ist primär eine Grafikengine für Nutzung in Compute
|
||||
Es existieren mehrere Systeme zur Anbindung der Engine an ROS, vor allem das offizielle ``Robotics Simulation''-Paket und ZeroSim.
|
||||
Beide Systeme erlauben die Erweiterung der Gameengine um die Simulation von Robotern.
|
||||
Unity besitzt eine gute Dokumentation, die vor allem auf die Nutzung im Einsteigerbereich zurückzuführen ist.
|
||||
Auch die Optionen zur Menschensimulation sind gut, da diese häufig in Spielen verwendet werden.
|
||||
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 kostenlos ist.
|
||||
|
||||
Die Unreal Engine\cite{unreal} ist wie Unity eine Grafikengine aus dem Spielebereich.
|
||||
@ -172,16 +170,18 @@ Auch für diese Engine existiert eine ROS2-Anbindung, jedoch ist diese nicht off
|
||||
Alle vorgestellten Softwares besitzten ein integriertes Physiksystem, dass die Simulation von starren Körpern und Gelenken erlaubt.
|
||||
Diese Funktionen erlauben den Aufbau eines Roboterarms, der durch eine ROS-Brücke gesteuert wird.
|
||||
|
||||
Um den Entwicklungsvorgang zu beschleunigen, ist die Auswahl einer Umgebung mit bereits existierender ROS-Unterstützung sinnvoll.
|
||||
Um den Fokus dieser Arbeit auf die gestellte Aufgabe zu ermöglichen, ist die Auswahl einer Umgebung mit bereits existierender ROS-Unterstützung sinnvoll.
|
||||
Durch diese Einschränkung scheiden sowohl Unreal Engine aber auch Godot aus.
|
||||
Diese bieten zwar diese Funktionalität, jedoch wird diese nur durch Nutzer gewartet und ist demzufolge nicht offiziell unterstützt.
|
||||
Für einen späteren Einsatz ist eine offene Lizenz von Vorteil, da diese einen Einsatz in nahezu allen Umständen erlaubt.
|
||||
|
||||
Die Wahl der Simulationsumgebung fiel deshalb auf Gazebo Ignition, dass gleichzeitig bereits im ROS-Ökosystem etabliert ist.
|
||||
Die Wahl der hier zu verwendenden Simulationsumgebung fiel deshalb auf Gazebo Ignition, dass gleichzeitig bereits im ROS-Ökosystem etabliert ist.
|
||||
Dabei erlauben die offizielle ROS-Anbindung und offene Lizenz eine zuverlässige Verwendung in unterschiedlichsten Szenarien.
|
||||
\subsection{Welt- und Modellbeschreibung}
|
||||
Um die Simulationsumgebung zu beschreiben, nutzt Gazebo das .sdf-Dateiformat\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.
|
||||
|
||||
Um verschiedene Versionen des Formats zu unterstützen, enthält das einzige sdf-Element die gewünschte Versionsnummer.
|
||||
Eine solche Datei kann, wie bereits oben beschrieben, unterschiedliche Daten enthalten.
|
||||
@ -193,7 +193,7 @@ Zuerst enthält ein Welt-Element die Daten über die physikalischen Konstanten d
|
||||
Außerdem werden alle benötigten Teile der Nutzeroberfläche deklariert, die im ausgeführten Simulator verfügbar sein sollen.
|
||||
Letzendlich ist auch 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 das Laden von zum Beispiel 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.
|
||||
@ -216,7 +216,9 @@ Neben den Punklichtquellen existieren auch noch Spots, die außerdem noch nur ei
|
||||
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.
|
||||
Diese können durch in einem Skript definierte Trajectories ausgeführt werden, was eine einfache Simulation eines Menschen erlaubt.
|
||||
Eine solche Befehlsfolge kann jedoch nicht von außerhalb der Simulation zur Laufzeit angepasst werden, was weitere Entwicklungsarbeit erforderlich macht.
|
||||
|
||||
Eine solche Befehlsfolge kann jedoch nicht von außerhalb der Simulation zur Laufzeit angepasst werden.
|
||||
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.
|
||||
@ -239,7 +241,7 @@ Folgende Typen von Gelenken können in urdf-Dateien genutzt werden:
|
||||
\item[freie Gelenke]
|
||||
ermöglichen vollständige Bewegung in allen 6 Freiheitsgraden (Rotation und Translation). Sie stellen den normalen Zustand der Glieder zueinander dar.
|
||||
\item[planare Gelenke]
|
||||
erlauben Bewegungen senkrecht zur Achse des Gelenks. Sie werden zum Beispiel für Bodenkollisionen eingesetzt.
|
||||
erlauben Bewegungen senkrecht zur Achse des Gelenks. Sie werden zum Beispiel für Oberflächen eingesetzt, auf welchen Objekte gleiten sollen.
|
||||
\item[feste Gelenke]
|
||||
sperren alle 6 Freiheitsgrade und werden häufig zur Fixierung von Objekten in einer Szene genutzt.
|
||||
\item[kontinuierliche Gelenke]
|
||||
@ -252,10 +254,10 @@ Folgende Typen von Gelenken können in urdf-Dateien genutzt werden:
|
||||
\subsection{Menschensimulation}
|
||||
Gazebo besitzt bereits ein simples Animationssystem für bewegliche Aktoren, dass auch für Menschen nutzbar ist.
|
||||
Für diesen existiert bereits ein Modell mit mehreren Animationen, die allein abgespielt, oder an Bewegungen gekoppelt werden können.
|
||||
Dadurch ist eine Laufanimation realisierbar, die synchronisiert zu einer Bewegung abgespielt wird.
|
||||
Dadurch ist zum Beispiel eine Laufanimation realisierbar, die synchronisiert zu einer Bewegung abgespielt wird.
|
||||
|
||||
Dies setzt jedoch voraus, dass der gesamte Bewegungsablauf zum Simulationsstart bekannt ist.
|
||||
Der Grund dafür ist auf die Definition der Pfade zurück zu führen, die Aktionen wie Bewegungen und Animationen auslösen können.
|
||||
Der Grund dafür ist auf die Definition der Pfade zurückzuführen, die Aktionen wie Bewegungen und Animationen auslösen.
|
||||
Diese können nur als dem Actor untergeordnetes Element in der .sdf-Datei definiert werden, was Veränderungen zur Laufzeit ausschließt.
|
||||
Durch diesen Umstand ist der somit realisierbare Simulationsumfang nicht ausreichend, um die gewünschten Szenarien abzubilden.
|
||||
|
||||
@ -267,25 +269,25 @@ Ein solches System soll als Gazebo-Plugin einbindbar sein, um Modifikationen an
|
||||
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 Bewegungsplanung von Robotern.
|
||||
Deshalb existiert viel 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 das Nutzen dieser mit MoveIt zusammen erlaubt.
|
||||
Diese Eigenschaften machen das MoveIt als Bewegungsplanungsumgebung für dieses Projekt extrem attraktiv.
|
||||
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 meheren Komponmenten, die in ihrer Gesamtheit den Bereich der Bewegungsplanung abdecken.
|
||||
MoveIt besteht aus mehreren Komponmenten, 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 moglich.
|
||||
Die erste Inbetriebnahme ist über das mitgelieferte RViz-Plugin und die demo-Launch-Files möglich.
|
||||
Diese wurden mit dem mitgelieferten Setupassistenten für den Roboter generiert.
|
||||
Durch die Ausführung dieser Demo startet RViz, eine Test- und Visualisierungsumgebung für ROS.
|
||||
In dieser können Roboterbewegungen unter Zuhilfenahme von Markierungen in RViz geplant und ausgeführt werden.
|
||||
|
||||
Da sich eine solche Bewegungsplanung 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 MoveIt noch das moveit_commander Paket, dass den Zugriff auf MoveIt in Pyhon erlaubt, dass aber für MoveIt2 noch nicht portiert wurde. \cite{moveitpython}
|
||||
Für die Sprache Python existierte für die Vorgängerversion MoveIt noch das moveit_commander Paket, dass den Zugriff auf MoveIt in Pyhon erlaubt, dass 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 kann sowohl die Planung und Ausführung von Bewegungen ausgelöst werden, aber auch Exklusionszonen eingerichtet werden.
|
||||
Dabei können sowohl die Planung und Ausführung von Bewegungen ausgelöst aber auch Exklusionszonen eingerichtet werden.
|
||||
Außerdem können Objekte virtuell mit dem Roboter verbunden werden, wodurch sich diese in RViz mit dem Roboter bewegen.
|
||||
Natürlich können die Befehle auch direkt an die entsprechenden Topics gesendet werden um einzelne Bereiche des Systems zu testen, jedoch ist so kein einfacher Zugriff auf erweiterte Optionen möglich.
|
||||
Natürlich können die Befehle auch direkt an die entsprechenden Topics gesendet werden um einzelne Bereiche des Systems zu testen.
|
||||
|
||||
Um die durch den Setupassistenten generierten Informationen an MoveIt zu übergeben, wird intern ein RobotStatePublisher verwendet.
|
||||
Dieser läd alle Daten des Robotermodells und gibt sie an andere Programme weiter, die Roboterparameter zur Laufzeit anfordern, unter diesen auch MoveIt selbst.
|
||||
@ -296,11 +298,11 @@ Dabei können auch bestimmte Einschränkungen des Arbeitsraums, spezielle Trajek
|
||||
Diese Daten können durch eine OccupancyMap ergänzt werden, welche die Bereiche beschreibt, die sich um den Roboter befinden.
|
||||
Eine solche Erweiterung erlaubt die automatische Nutzung von Kollisionsvermeidung mit Objekten im Planungsbereich.
|
||||
|
||||
Die Planung der Bewegung wird durch einen der zahlreichen implementierten Solver erledigt, der durch die MoveGroup aufgerufen wird.
|
||||
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.
|
||||
Hiefür kann ein anderer \code{ros_control} Controller geladen werden, der entweder die simulierte oder echte Hardware ansteuert.
|
||||
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.
|
||||
|
||||
Im Falle von Gazebo wird \code{ign_ros_control} genutzt, dass die benötigten \code{ros_control} Controller in die Simulation einbindet.
|
||||
@ -309,11 +311,11 @@ Diese können dann wie normale Controller von \code{ros_control} genutzt werden.
|
||||
Dieser Ablauf ist auch im Anhang unter Abbildung \ref{moveitpipeline} im Anhang visualisiert.
|
||||
|
||||
\section{Programmiersprache}
|
||||
Als Programmiersprache kommen in ROS standartmäß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.
|
||||
Diese beiden Sprachen sind in der Softwareentwicklung beliebt, unterscheiden sich jedoch stark in Funktionsumfang und Entwicklungsprozess.
|
||||
|
||||
Python ist eine interpretierte Skriptsprache, die zu den hohen Programmiersprachen zählt.
|
||||
Sie wird in ROS zum Beispiel in .launch.py-Dateien eingesetzt, die den Start von Diensten in der Umgebung verwalten.
|
||||
Sie wird in ROS zum Beispiel in \code{.launch.py}-Dateien eingesetzt, die den Start von Diensten in der Umgebung verwalten.
|
||||
Die Sprache kann aber auch für die Programmierung von Nodes innerhalb des ROS-Systems verwendet werden.
|
||||
|
||||
C++ hingegen ist eine kompilierte, statisch typisierte, maschinennahe Programmiersprache.
|
||||
@ -321,13 +323,14 @@ In ROS wird C++ für Code verwendet, der entweder häufig oder in zeitkritischen
|
||||
Aus diesem Grund wird C++ in Nodes verwendet, die schnell auf große Datenmengen reagieren müssen.
|
||||
|
||||
Die Nutzung eines Kompilierers beschleunigt C++ deutlich im Vergleich zu Python, ist jedoch weniger geeignet für häufige Modifikation.
|
||||
Dies ist vor allem in häufig geänderten Programmen ein Nachteil, die nach einer Änderung wieder kompiliert werden müssen.
|
||||
Dies ist vor allem in häufig geänderten Programmen ein Nachteil, die nach einer Änderung erneut kompiliert werden müssen.
|
||||
Aus diesem Grund wird Python vor allem in .launch.py-Dateien verwendet, welche die Interaktion der anderen Programme in der Umgebung verwalten.
|
||||
|
||||
Um die gewünschten Funktionen für die Simulation umsetzen zu können, ist die Programmierung in C++ nötig.
|
||||
Da zum Beispiel Gazebo-Plugins auf C++ als Programmiersprache ausgelegt sind, was die Nutzung anderer Sprachen stark erschwert.
|
||||
Ein Grund dafür ist die hohe Geschwindigkeit, die bei einer hohen Anzahl an Simulationsschritten pro Sekunde benötigt wird.
|
||||
Außerdem kann MoveIt2 zur aktuellen Zeit nur mit C++ direkt gesteuert werden.
|
||||
Um die gewünschten Funktionen für die Simulation umsetzen zu können, ist die Programmierung in C++ nahezu unumgänglich.
|
||||
Zum Beispiel sind Gazebo-Plugins in C++ erstellt, was die Nutzung anderer Sprachen stark einschränkt.
|
||||
|
||||
Ein Grund für die Nutzung von C++ ist die hohe Geschwindigkeit, die bei einer hohen Anzahl von Simulationsschritten pro Sekunde benötigt wird.
|
||||
Außerdem kann MoveIt2 derzeit nur mit C++ direkt gesteuert werden.
|
||||
|
||||
Die Verwendung von C++ für die zu entwickelnden Nodes erscheint deshalb aus oben genannten Gründen naheliegend.
|
||||
In den Launch-Skripten wird jedoch Python verwendet werden, da hier die Vorteile einer Skriptsprache überwiegen.
|
||||
@ -336,14 +339,14 @@ In den Launch-Skripten wird jedoch Python verwendet werden, da hier die Vorteile
|
||||
Zur Verwaltung der Abläufe sollen BehaviorTrees 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 aber auch viele Beispiele und eine gute Dokumentation über die erweiterten Funktionen, die im folgenden vorgestellt werden.
|
||||
Es existieren auch viele Beispiele und eine gute Dokumentation über die erweiterten Funktionen der Bibliothek, die im folgenden vorgestellt werden.
|
||||
|
||||
\begin{description}
|
||||
\item[Asynchrone Nodes]
|
||||
sind in \code{BehaviorTree.CPP} leichter umsetzbar, da diese im Lebenszyklus der Nodes beim Konzept der Bibliothek mit bedacht wurden.
|
||||
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.
|
||||
\item[Reaktives Verhalten] ist ein neues Konzept, um die Handhabung von asnchronen Nodes zu vereinfachen.
|
||||
Diese Strukturelemente erlauben die parallele Ausführung von mehreren Zweigen, die aktuell ausführende Aktionen beeinflussen können.
|
||||
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.
|
||||
\item[Das .xml-Format der Behavior Trees] ermöglicht einen Austausch des Verhaltens, ohne die unterliegende Programme verändern zu müssen.
|
||||
Dies ist vor allem in kompilierten Sprachen wie C++ sinnvoll, da Änderungen im Verhaltensablauf keiner Neukompilierung bedürfen, was die Iterationszeit für Änderungen verbessert.
|
||||
@ -356,13 +359,13 @@ Es existieren aber auch viele Beispiele und eine gute Dokumentation über die er
|
||||
Dies erleichtert das häufig schwierige Debuggen von Zustandsmaschienen erheblich, da das Verhalten genau untersucht werden kann.
|
||||
\end{description}
|
||||
|
||||
BehaviorTrees werden in \code{BehaviorTree.CPP} als .xml-Dateien gespeichert.
|
||||
BehaviorTrees werden in \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.
|
||||
Durch veränderbare Parameter im später erstellten Tree können Nodes ohne Programmänderung verändert werden.
|
||||
Falls die Nodes mit Bedacht erstellt wurden, kann so auf viele spezialisierte Nodes verzichtet werden.
|
||||
Um dies zu ermöglichen kann deren Funktion durch mehrere andere Nodes in einem Subtree mit Parametern abgebildet werden.
|
||||
Um dies zu ermöglichen, kann deren Funktion durch mehrere andere Nodes in einem Subtree mit Parametern abgebildet werden.
|
||||
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.
|
||||
@ -373,21 +376,21 @@ Diese werden im Hintergrund als eine Referenz auf den eigentlichen Wert gespeich
|
||||
Eine solche Funktion erlaubt das weitere Zerlegen von Vorgängen innerhalb des BehaviorTrees.
|
||||
Solche kleineren Nodes sind durch ihren limitierten Umfang universeller einsetzbar, da sie nur kleinere Teilprobleme betrachten, die zu komplexeren Strukturen zusammengesetzt werden können.
|
||||
|
||||
Um die dadurch wachsenden Strukturen besser überblicken zu können, lassen sich Nodes als sogenannte SubTrees abspeichern.
|
||||
Um die dadurch wachsenden Strukturen besser überblicken zu können, lassen sich Nodes als sogenannte Subtrees abspeichern.
|
||||
Diese bilden dann in ihrer Gesamtheit eine neue Node, die im BehaviorTree eingesetzt werden kann.
|
||||
Um den Einsatz von Variablen innerhalb eines SubTrees zu ermöglichen, besitzt jeder SubTree ein separates Blackboard.
|
||||
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.
|
||||
|
||||
Natürlich sollte es auch möglich sein, Variablen an solche SubTrees zu übergeben.
|
||||
Diese können, wie auch bei normalen Nodes, als Parameter an den SubTree übergeben werden.
|
||||
Die Bibliothek \code{BehaviorTree.CPP} verbindet dann diese Werte und erlaubt die Datenübergabe zu und von dem SubTree.
|
||||
Natürlich sollte es auch möglich sein, Variablen an solche Subtrees zu übergeben.
|
||||
Diese können, wie auch bei normalen Nodes, als Parameter an den Subtree übergeben werden.
|
||||
Die Bibliothek \code{BehaviorTree.CPP} verbindet dann diese Werte und erlaubt die Datenübergabe zum und vom Subtree.
|
||||
|
||||
\subsection{Asynchrone Nodes}
|
||||
Da nicht jeder Prozess sofort vollständig durchgeführt werden kann, muss die Möglichkeit geschaffen werden, lang anhaltende Prozesse abzubilden.
|
||||
Dies geschieht in \code{BehaviorTree.CPP} durch asynchrone Nodes.
|
||||
|
||||
Eine asynchrone Node besitzt neben den Zuständen SUCCESS und FAILURE einer normalen Node auch noch die beiden neuen Zustände RUNNING und IDLE.
|
||||
Außerdem werden mehrere Funktionen definiert, die den Lebenszyklus der Node darstellen.
|
||||
Außerdem werden mehrere Funktionen definiert, die den Lebenszyklus der Node definieren.
|
||||
|
||||
Wird eine Node durch den Aufruf der \code{onStart}-Funktion gestartet, geht diese in einen der Zustände RUNNING, SUCCESS oder FAILURE über.
|
||||
|
||||
@ -405,12 +408,11 @@ Das in BehaviorTree.Cpp verwendete Dateiformat, um Behavior Trees zu erstellen,
|
||||
Jedes Dokument beginnt dabei mit einem Root-Element, dass alle BehaviorTrees und eine Referenz auf die ID des Hauptbaumes enthält.
|
||||
Diese wird benötigt, da auch Unterbäume im selben Dokument deklariert und genuzt werden können, diese aber sonst nicht vom Hauptbaum unterscheidbar sind.
|
||||
|
||||
Jeder Baum beginnt mit einem BehaviorTree-Element, dass als Attribut die ID des Baumes besitzen muss.
|
||||
Jeder Baum beginnt mit einem BehaviorTree-Element, das als Attribut die ID des Baumes besitzen muss.
|
||||
Als untergeornete Elemente des Baumes werden die Nodes entsprechend der gewünschten Baumstruktur angeordnet.
|
||||
|
||||
Zur besseren Visualisierung der XML-Struktur wurde hier die bereits aus dem Konzept bekannte Baumstruktur, hier noch einmal in Abbildung \ref{choice_tree_demo} zu sehen, umgewandelt.
|
||||
Die resultierende Datei ist in Abbildung \ref{choice_tree_xml} abgebildet.
|
||||
Dabei ist zu beachten, dass die Root-Node nicht in der Struktur existiert, da diese nur den Eintrittspunkt in die Struktur darstellt.
|
||||
Als Beispiel wird der bereits im Konzept verwendete Behavior Tree (hier nochmals in Abbildung \ref{choice_tree_xml} zu sehen) in die entsprechende XML-Repräsentation umgewandelt.
|
||||
Dabei ist zu beachten, dass die Root-Node in der Datei nicht existiert, da diese nur den Eintrittspunkt in die Struktur darstellt.
|
||||
Außerdem können selbst definierte Nodes sowohl direkt mit ihrem Namen, aber auch über den Namen Action mit ihrem Namen als ID-Parameter, referenziert werden.
|
||||
\begin{figure}[hpt]
|
||||
\includegraphics[width=\textwidth]{img/MA-tree-demo}
|
||||
@ -439,14 +441,28 @@ Außerdem können selbst definierte Nodes sowohl direkt mit ihrem Namen, aber au
|
||||
\label{choice_tree_xml}
|
||||
\end{figure}
|
||||
|
||||
\section{Docker-Compose als Virtualisierungsumgebung}
|
||||
Docker ist eine Virtualisierungsumgebung für Anwendungen, die eine komplette Umgebung für deren Ausführung bereitstellt.
|
||||
Dadurch wird die Inbetriebnahme von Anwendungen, die spezielle Umgebungen für ihre Ausführung benötigen auf beliebigen Systemen ermöglicht.
|
||||
\section{Virtualisierungsumgebung}
|
||||
|
||||
Dies wird durch den Einsatz von sogenannten Containern erreicht.
|
||||
Ein solcher Container wird über sogenannte Build-Files definiert.
|
||||
Ein Build-File enthält exakte Instruktionen, wie der Container aus anderen Containern, Dateien oder einer Kombination beider erstellt werden kann.
|
||||
Der so erstellte Container wird anhand dieser Definition durch den ausführenden Rechner erstellt.
|
||||
Die Auswahl der Virtualisierungsumgebung erfolgt zwischen einer virtuellen Maschine und einer Containerumgebung.
|
||||
|
||||
Bei einer virtuellen Maschine (VM) werden alle Komponenten der Maschine simuliert, was das Nutzen anderer Betriebssysteme ermöglicht.
|
||||
Dies beinhaltet auch die Abstraktion von Speichermedien und anderen Geräten.
|
||||
Eine virtualisierte Umgebung erzeugt kleine Performanceverluste durch diese Abstraktion.
|
||||
|
||||
Eine Containerumgebung nutzt den Kernel des Hostsystems mit, was die Virtualisierug 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.
|
||||
|
||||
Da bereits eine Linux-Maschine zur Entwicklung vorhanden ist, ist die Virtualisierung eines weiteren Linux-Kernels nur mit weiterem Performanceverlust verbunden.
|
||||
Außerdem soll in der Virtualisierungsumgebung Grafikbeschleunigung genutzt werden, wozu in einer VM eine Grafikkarte an das Zielsystem durchgereicht wird.
|
||||
In einer Containerumgebung kann die Grafikeinheit des Hostsystems mit genutzt werden, indem die Geräte in den Container hereingereicht werden.
|
||||
|
||||
Auf Grund dieser Punkte wurde eine Containerumgebung verwendet.
|
||||
Docker ist eine verbreitete 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.
|
||||
|
||||
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.
|
||||
Der so erstellte Container wird anhand dieser Definition durch den Host erstellt.
|
||||
Um diesen Prozess weiter zu beschleunigen, ist auch der Einsatz eines Buildservers möglich, der benötigte Container als Download bereitstellt.
|
||||
|
||||
Jeder Container enthält ein eigenes Dateisystem, das aus dem im Buildfile definierten Dateien und einem Overlay besteht.
|
||||
|
||||
@ -410,7 +410,7 @@ Dieser Schritt muss vor dem Kompiliervorgang der nutzenden Pakete geschehen.
|
||||
Dazu werden diese Nachrichtenpakete als Dependency der nutzenden Pakete angegeben, was eine automatische Anpassung der Kompilationsreihenfolge bewirkt.
|
||||
|
||||
Eine Action des \code{ros_action}-Pakets besteht immer aus 3 einzelnen Nachrichten, deren Inhalt frei definiert werden kann.
|
||||
\begin{enumerate}
|
||||
\begin{itemize}
|
||||
\item{Zum Start der Action wird die erste Nachricht vom Client an den Server gesendet.
|
||||
In dieser Startnachricht befinden sich alle Informationen, die zur Ausführung der Action benötigt werden.
|
||||
Nach dieser Nachricht kann der Server später entscheiden, ob die Aktion ausgeführt werden soll und sie gegebenenfalls abbrechen.}
|
||||
@ -418,11 +418,11 @@ Nach dieser Nachricht kann der Server später entscheiden, ob die Aktion ausgef
|
||||
Dabei ist es die Aufgabe des Programmierers, diese an signifikanten Punkten des Ablaufs zu senden.}
|
||||
\item{Am Ende der Action wird die Endnachricht an den Client gesendet, die weitere Rückgabewerte liefern kann.
|
||||
Die Endnachricht enthält standardmäßig eine Erfolgsangabe, weshalb diese nicht angegeben werden muss.}
|
||||
\end{enumerate}
|
||||
\end{itemize}
|
||||
|
||||
Ein ActionServer innerhalb eines Programmes definiert 3 Funktionen, welche die Handhabung einer Aktion definieren.
|
||||
|
||||
\begin{enumerate}
|
||||
\begin{itemize}
|
||||
\item{
|
||||
Die erste Funktion übergibt den Wert der Startnachricht, die mit einer Antwort quittiert werden muss.
|
||||
Hierbei sind die Antworten ACCEPT_AND_DEFER, ACCEPT_AND_EXECUTE und REJECT möglich.
|
||||
@ -439,7 +439,7 @@ Ein ActionServer innerhalb eines Programmes definiert 3 Funktionen, welche die H
|
||||
Um Feedback während der Ausführung der Aktion geben zu können, exisitiert die dritte Funktion.
|
||||
Diese erhält als Parameter ein Objekt, mit dem Feedback- und Endnachrichten an den Client gesendet werden können.
|
||||
}
|
||||
\end{enumerate}
|
||||
\end{itemize}
|
||||
Die gesamte Kommunikation einer Anfrage verläuft wie in Abbildung \ref{plugin_sequence} dargestellt.
|
||||
Zuerst wird durch den Client eine Zielvorgabe an den Server gesendet.
|
||||
Sollte der Server diese abweisen, wird die Kommunikation beendet.
|
||||
|
||||
@ -7,12 +7,12 @@ Die Auswahl einer geeigneten Umgebung für die gewünschte Simulation erfolgte i
|
||||
Hierfür wurden mehrere Komponenten einzeln verglichen und ausgewählt.
|
||||
Folgende Komponenten wurden für die Umgebung ausgewählt:
|
||||
\begin{itemize}
|
||||
\item ROS2 als Dienstumgebung
|
||||
\item Gazebo Ignition als Simulationssoftware
|
||||
\item BehaviorTree.CPP als Beschreibungssprache
|
||||
\item ROS2 als Dienstumgebung,
|
||||
\item Gazebo Ignition als Simulationssoftware und
|
||||
\item BehaviorTree.CPP als Beschreibungssprache.
|
||||
\end{itemize}
|
||||
|
||||
Alle Komponenten können miteinander kommunizieren, was den Aufbau einer Simulationsumgebung erlaubt.
|
||||
Alle Komponenten können prinzipiell miteinander kommunizieren, was den Aufbau einer Simulationsumgebung erlaubt.
|
||||
|
||||
\subsubsection{Nutzung der Virtualisierungsumgebung}
|
||||
Die auf Docker basierende Virtualisierungsumgebung stellt eine vollständige ROS2-Installation dar.
|
||||
@ -20,7 +20,7 @@ In dieser Umgebung sind alle für die Arbeit benötigten Pakete enthalten.
|
||||
Der Start der Umgebung erfolgt über das im Projektverzeichnis befindliche \code{start.sh}-Shellskript.
|
||||
Dieses Skript wird ohne Parameter ausgeführt.
|
||||
|
||||
Falls die Umgebung noch nicht genutzt wurde, wird eine neue Containervorlage erstellt.
|
||||
Beim ersten Start der Umgebung wird automatisch eine neue Containervorlage erstellt.
|
||||
Der Start der Umgebung wird mit der Ausgabe \code{ros-ros-1 | Ready to connect.} abgeschlossen, die auch in Abbildung \ref{console-docker-started} sichtbar ist.
|
||||
Während der Nutzung der Umgebung muss das Terminal weiter geöffnet bleiben.
|
||||
Nach dem Senden eines Terminiersignals durch das Schließen des Terminals oder die Tastenkombination \code{Ctrl+C} wird die Containerumgebung beendet.
|
||||
@ -28,12 +28,13 @@ Nach dem Senden eines Terminiersignals durch das Schließen des Terminals oder d
|
||||
\begin{figure}
|
||||
\includegraphics[width=\textwidth]{img/MA-Docker-Started}
|
||||
\centering
|
||||
\caption{Konsole mit ausgeführter Virtualisierungsumgebung}
|
||||
\caption{Konsole mit gestarteter Virtualisierungsumgebung}
|
||||
\label{console-docker-started}
|
||||
\end{figure}
|
||||
|
||||
Die Verbindung in die ROS-Umgebung erfolgt über SSH in einer separaten Konsole.
|
||||
In der so aufgebauten Session kann die Hardwarebeschleunigung des Hostsystems automatisch genutzt werden.
|
||||
Eine SSH-Verbindung wird mit dem Befehl \code{ssh ros@localhost -p 2222} aufgebaut.
|
||||
In dieser Session kann die Hardwarebeschleunigung des Hostsystems automatisch genutzt werden.
|
||||
Dies wurde in Abbildung \ref{console-docker-passthrough} durch die Ausführung von \code{glxgears}, einer OpenGL-Anwendung zum Testen der Grafikpipeline, demonstriert.
|
||||
|
||||
Das entworfene Containersystem ist mit der bereitgestellten Funktionalität eine Grundlage für die weitere Implementation.
|
||||
@ -50,12 +51,15 @@ 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.
|
||||
|
||||
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.
|
||||
|
||||
\subsubsection{Steuerung des Menschen}
|
||||
|
||||
Durch den Start der Simulation wird selbstständig das erstellte ActorPlugin geladen.
|
||||
Der Start des für diese Arbeit implementierten ActorServers erfolgt zeitgleich, um die Anbindung an ROS zu gewährleisten.
|
||||
Beide Anwendungen zusammen erlauben das Ausführen von Bewegungen und Animationen zur Laufzeit in der Simulation.
|
||||
Beide Anwendungen zusammen erlauben das Ausführen von Bewegungen und Animationen während der Laufzeit der Simulation.
|
||||
|
||||
Alle für die Simulation des Menschen erstellten Animationen werden automatisch geladen, sobald diese durch das Plugin verwendet werden.
|
||||
Dies kann durch die erstellten BehaviorTree-Nodes erfolgen, aber auch durch das Verwenden von Terminalbefehlen zu Testzwecken.
|
||||
@ -63,23 +67,23 @@ Dies kann durch die erstellten BehaviorTree-Nodes erfolgen, aber auch durch das
|
||||
|
||||
\subsubsection{Definition von Verhalten mit einer Beschreibungssprache}
|
||||
|
||||
Die Definition von verschiedenen Verhaltensweisen über eine Beschreibungssprache wurde durch die Erstellung neuer Nodes erreicht.
|
||||
Die Definition von verschiedenen Verhaltensweisen über eine Beschreibungssprache wurde durch die Erstellung neuer Nodes für einen Behavior Tree erreicht.
|
||||
Für die Bewegung und Animation des Menschen sind die Nodes ActorMovement und ActorAnimation verfügbar.
|
||||
Die Steuerung des Roboters erfolgt durch die RobotMove- und SetRobotVelocity-Node.
|
||||
Beide Nodes zur Kontrolle des Roboters starten eine neue Bewegung mit den neuen Parametern.
|
||||
Im Falle einer laufenden Bewegung wird diese gestoppt und mit den neuen Parametern gestartet.
|
||||
Im Falle einer laufenden Bewegung wird diese vorher gestoppt.
|
||||
|
||||
Um Bewegungen in Zonen zu ermöglichen, kann die GenerateXYPose-Node zufällige Positionen in einer Zone generieren.
|
||||
Die InAreaTest-Node erlaubt eine Auskunft über die Position von Objekten.
|
||||
Eine Redefinition von bestehenden Parametern der generierten Pose ist über die OffsetPose-Node möglich.
|
||||
|
||||
Eine Wiederaufnahme von unvollständigen Aktionen ist durch die implementierte Interruptable\-Sequence-Node möglich.
|
||||
Eine Wiederaufnahme von unvollendeten Aktionen ist durch die implementierte Interruptable\-Sequence-Node möglich.
|
||||
|
||||
Die Entscheidung über die Ausführung von einer aus mehreren Aktionen ist durch die WeightedRandom-Node realisiert.
|
||||
Die Entscheidung über die Ausführung einer von mehreren möglichen Aktionen wird mit der WeightedRandom-Node realisiert.
|
||||
Um Fehler simulieren zu können, ist der Abbruch von Aktionen nötig.
|
||||
Dies wird durch die RandomFailure-Node erreicht.
|
||||
|
||||
Eine Kombination aus diesen neu implementieren und den bereits verfügbaren Nodes kann alle benötigten Verhalten darstellen.
|
||||
Eine Kombination dieser neu implementieren und den bereits in BehaviorTree.CPP verfügbaren Nodes kann alle in den Szenarien benötigten Verhaltensweisen darstellen.
|
||||
|
||||
\section{Simulation der Szenarien}
|
||||
Das Starten der Simulation erfolgt über ein Skript innerhalb des \code{ign_world}-Pakets.
|
||||
@ -88,7 +92,7 @@ In diesem Skript werden alle für die Simulation benötigten ROS2-Nodes gestarte
|
||||
|
||||
Durch die Verwendung des optionalen Parameters \code{scene} kann das gewünschte Szenario ausgewählt werden.
|
||||
Dieser muss in folgendem Format verwendet werden:
|
||||
\code{ros2 launch ign_world gazebo_controller_launch.py scene:=[Coex|Coop|Colab]}
|
||||
\code{ros2 launch ign_world gazebo_controller_launch.py scene:=[Coex|Coop|Colab]}.
|
||||
Als Standard wird die Option \code{Coex} genutzt, falls der \code{scene}-Parameter nicht spezifiziert wird.
|
||||
|
||||
Nach dem Start der Simulationsumgebung ist der Raum vollständig geladen und einsatzbereit (Abbildung \ref{sim-room}).
|
||||
@ -144,7 +148,7 @@ In diesem Szenario begibt sich der Mensch nur mit einer Wahrscheinlichkeit von 5
|
||||
Eine Ausweitung der Interaktion erfolgt im Kooperationsszenario.
|
||||
In diesem werden durch den Roboter Objekte entweder weitergereicht oder aussortiert.
|
||||
Nach jedem aussortierten Objekt wird der Mensch gerufen.
|
||||
Der Mensch holt den Ausschuss dann nach dem erledigen seiner aktuellen Aufgabe ab.
|
||||
Der Mensch holt die aussortierten Objekte nach dem Erledigen seiner aktuellen Aufgabe ab.
|
||||
Diese Interaktion und das in diesem Szenario hinzugefügte Fließband sind in Abbildung \ref{coop-human} dargestellt.
|
||||
|
||||
\begin{figure}
|
||||
@ -158,8 +162,8 @@ Diese Interaktion und das in diesem Szenario hinzugefügte Fließband sind in Ab
|
||||
|
||||
Für das Kollaborationsszenario durchschreitet der Mensch den Raum, was die Kontrolle mehrerer Systeme simuliert.
|
||||
Der Roboter bewegt in diesem Szenario Objekte vom linken auf den rechten Tisch, wobei Fehler auftreten können.
|
||||
Bei einem Fehler beendet der Mensch seinen Kontrollgang und hebt ein Objekt auf, um es zum Roboter zurückzubringen (Abbildung \ref{colab-drop}).
|
||||
Der Roboter bricht den fehlgeschlagenen Vorgang ab, und beginnt diesen mit dem nächsten Objekt von neuem.
|
||||
Bei einem Fehler beendet der Mensch seinen Kontrollgang und hebt ein Objekt auf, bringt es zum Roboter zurück und legt es auf dem rechten Tisch ab (Abbildung \ref{colab-drop}).
|
||||
Der Roboter bricht den fehlgeschlagenen Vorgang ab und setzt die Arbeit mit dem nächsten Objekt fort.
|
||||
|
||||
\begin{figure}
|
||||
\begin{minipage}{.45\textwidth}
|
||||
@ -176,12 +180,12 @@ Der Roboter bricht den fehlgeschlagenen Vorgang ab, und beginnt diesen mit dem n
|
||||
\end{figure}
|
||||
|
||||
\section{Zusammenfassung}
|
||||
Alle simulierten Szenarien sind in einer Beschreibungssprache abgebildet.
|
||||
Es wurden entsprechende Austauschmechanismen für die Beschreibungsprache geschaffen, welche auch neue Szenarien darstellen können.
|
||||
Es wurden entsprechende Nodes für die Bewegung von Mensch und Roboter geschaffen.
|
||||
Mit diesen Nodes wurden alle simulierten Szenarien in einer Beschreibungssprache abgebildet.
|
||||
Die vollständige Kontrolle der Endeffektorposition des Roboters und der Bewegung des Menschen in der Simulation sind möglich.
|
||||
|
||||
Eine dynamische Simulation von Objekten, welche durch Roboter und Mensch beeinflusst werden können, konnte nicht umgesetzt werden.
|
||||
|
||||
Die dynamische Simulation von Objekten, die durch Roboter und Mensch beeinflusst werden können, wurde im Rahmen dieser Arbeit aus Komplexitätsgründen nicht umgesetzt.
|
||||
Einen Überblick über die dafür notwendigen Erweiterungen wird in Sektion \ref{objectsim} skizziert.
|
||||
\section{Lessons Learned}
|
||||
|
||||
Während der Entwicklung des Projekts wurden zahlreiche Erkenntnisse gesammelt, welche die Entwicklung weiterer Projekte mit dieser Plattform erleichtern können.
|
||||
|
||||
@ -4,7 +4,7 @@ Die Umsetzung des gleichen Problems in einem anderen Simulator bietet die Mögli
|
||||
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 ein Fokus auf Erweiterbarkeit gelegt werden.
|
||||
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.
|
||||
@ -13,7 +13,7 @@ Außerdem ist die hohe Verfügbarkeit von Tutorials und Dokumentation für diese
|
||||
Mitgelieferte Werkzeuge bekannter Engines wie Unity, Unreal Engine und Godot beinhalten ausgereifte Physik- und Animationssysteme.
|
||||
Diese können für Roboterbewegungen und Menschensimulation verwendet werden.
|
||||
|
||||
\section{Simulation bewegter Objekte}
|
||||
\section{Simulation bewegter Objekte}\label{objectsim}
|
||||
Die Simulation bewegter Objekte benötigt ein neues Gazebo-Plugin, welches mit den bereits entwickelten Komponenten der aktuellen Umgebung interagiert.
|
||||
Um ein Objekt mit dem Roboter oder Menschen zu bewegen, muss dieses auf eine von zwei Arten bewegt werden.
|
||||
|
||||
@ -26,8 +26,13 @@ Da der Mensch nicht aus einzelnen Physikobjekten besteht, ist die Anbringung als
|
||||
Stattdessen muss die aktuelle Position des Armes anhand der Animationsdaten verfolgt werden, um die Position des Objektes diesen anzupassen.
|
||||
|
||||
Die unterschiedliche Anbindung von Roboter und Mensch erfordert mehrere Implementationen, welche Zustandsdaten über das Objekt austauschen müssen.
|
||||
Um die Objekte mit
|
||||
\section{Ergänzung von Umgebungserkennung}
|
||||
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.
|
||||
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.
|
||||
\section{Erweiterung um Umgebungserkennung}
|
||||
Eine Ergänzung von simulierten Tiefenkameras zur Umgebungserkennung stellt eine weitere mögliche Ausbaustufe des Projekts dar.
|
||||
Mit den Kameras kann eine Tiefenkarte erstellt werden, um die Verfahrgeschwindigkeit des Roboters zu kontrollieren.
|
||||
MoveIt implementiert für diesen Verwendungszweck bereits sogenannte Octomaps.
|
||||
@ -37,12 +42,13 @@ Der Einsatz dieser OctoMaps zum Ausweichen von Hindernissen ist bereits in der B
|
||||
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}
|
||||
|
||||
-Mechanismus für Datenaustausch zwischen ROS und Gazebo überdenken/überarbeiten
|
||||
|
||||
-Geteilte ROS Instanz zwischen Plugins? Wie?
|
||||
|
||||
-Potentielle Integration von ROS als Messagedients in Gazebo
|
||||
Die aktuelle, separate Implementation von ActorServer und ActorPlugin kann durch eine Vereinigung der Implementation verbessert werden.
|
||||
Folgende Versuche wurden bereits durchgeführt, führten aber zu keinem Erfolg:
|
||||
\begin{itemize}
|
||||
\item{Die Ausführung in einem separaten Thread,}
|
||||
\item{eine Trennung vom Hauptprogramm mittels Fork und}
|
||||
\item{das Weglassen der Initialisierung von rclcpp, da diese später durch ign_ros2_control durchgeführt wird.}
|
||||
\end{itemize}
|
||||
|
||||
\section{Migration auf die neuste ROS-Version}
|
||||
Die neuste ROS-Version bietet keine expliziten Vorteile der Umgebung selbst, jedoch sind in dieser mehr Pakete verfügbar.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user