Results of TeXtidote analysis
Here is the result of analyzing your file(s) with TeXtidote. Hover the mouse over highlighted portions of the document to read a tooltip that gives you some writing advice.
tex/4_Umsetzung.tex
Found 376 warning(s)
1
\chapter{Umsetzung}
2
3
Bei der Umsetzung des geplanten Systemaufbaus waren Anpassungen nötig, die den geplanten Systemaufbau, sowie dessen Komplexität, negativ beeinflussen.
4
5
Die Kommunikation zwischen dem Actormodell und dem Behavior Tree musste in mehrere Komponenten aufgeteilt werden, um Konflikte innerhalb der Simulationssoftware zu vermeiden.
6
7
Zudem ist die Bewegungsplanung mit MoveIt2 deutlich komplexer als vorerst angenommen.
8
Diese Komplexität entsteht aus der Interaktion mehrerer Komponenten, die das Gesamtsystem zur Ausführung benötigt.
9
Alle Einzelsysteme mussten hierfür konfiguriert werden, um die Kommunikation dieser zu ermöglichen.
10
11
Mit den genannten Änderungen ergibt sich die in Abbildung \ref{umsetzung_overview} gezeigte Übersicht des Systems.
12
13
\begin{figure}
14
\includegraphics[width=\textwidth]{img/MA-Umsetzung-Übersicht}
15
\centering
16
\caption{Visualisierung des überarbeiteten Konzepts}
17
\label{umsetzung_overview}
18
\end{figure}
19
20
\section{Docker-Compose}
21
Um Docker für die Verwaltung einer ROS-Installation verwenden zu können, müssen einige Anpassungen vorgenommen werden.
22
Da viele Anwendungen, unter anderem auch die Simulationsumgebung, eine Desktopumgebung benötigen, musste der Zugriff auf eine solche Umgebung berücksichtigt werden.
23
24
Diese Probleme können nicht durch Docker allein gelöst werden, da die Virtualisierungsumgebung eine Trennung der Systeme vorsieht.
25
Die Isolation des Containers von der Benutzeroberfläche des Systems kann durch eine Kombination aus zwei Komponenten aufgehoben werden.
26
27
Um diese Modifikationen trotzdem reproduzierbar zu machen, wurde ein Shellscript geschrieben, dass zum Starten des Containers verwendet wird.
28
29
Dieses Skript erstellt zuerst die benötigten Verzeichnisse für den Container, falls diese noch nicht existieren.
30
Danach werden die SSH-Keys des Hosts in den Container kopiert, um eine SSH-Verbindung zu ermöglichen.
31
Dieser Umweg über SSH ist nötig, da die benötigten Umgebungsvariablen für ROS sonst nicht in allen Fällen gesetzt werden können.
32
33
Außerdem werden die benötigten Zugriffe auf den lokalen X-Server durch den Container mittels Hostname erlaubt.
34
Diese Änderung gestattet es dem Container, Fenster auf dem Desktop anzuzeigen, solange die benötigten SysFS-Dateien hereingereicht werden.
35
Dies geschieht durch Einträge in der compose.yml-Datei, die diese als ``bind mount'' in den Container hereinreicht.
36
37
Um Zugriff auf die Grafikbeschleunigung des Systems zu erhalten, muss deren Repräsentation im SysFS unter \code{/dev/dri} hineingereicht werden.
38
Der Zugriff auf die Desktopumgebung, der im vorherigen Schritt entsperrt wurde, wird durch das mounten von \code{/tmp/.X11-unix} erreicht.
39
Dabei handelt es sich um den Unix-Socket des X11 Displayservers.
40
41
Zum Starten des Containers wird das Script \code{start.sh} im Verzeichnis der Containerinstallation ausgeführt.
42
Das Script führt die obengenannten Schritte aus und startet den Container.
43
Eine Verbindung zum Container ist möglich, nachdem die Meldung \code{ros_1 | Ready to connect.} in der Konsole erscheint.
44
45
Dafür wird ein SSH-Client eingesetzt, der eine Verbindung zu der lokalen Netzadresse des Systems mit dem Benutzer \code{ros} aufbaut.
46
Der Port des SSH-Servers wird dabei durch die Deklaration im docker-compose.yaml an das Hostsystem durchgereicht.
47
Hierbei ist zu beachten, dass der SSH-Server im Container vom Host aus über Port 2222 erreichbar ist.
48
49
Nach der Verbindung wird automatisch die ROS2-Umgebung eingerichtet.
50
Diese kann ohne weitere Befehle nach dem Verbindungsaufbau genutzt werden.
51
Um die erstellten Pakete zu kompilieren, wurde das Skript \code{build.sh} (Abbildung \ref{buildscript}) im \code{workspace}-Verzeichnis erstellt.
52
53
54
\begin{figure}
55
\begin{minted}[breaklines,frame=single]{bash}
56
#!/bin/bash
57
pushd "$(dirname "$0")" || exit
58
colcon build --event-handlers console_cohesion+ --cmake-args -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -G Ninja
59
popd || exit
60
\end{minted}
61
\caption{build.sh Shellskript}
62
\label{buildscript}
63
\end{figure}
64
65
Dieses Skript nutzt \code{colcon}, um alle Pakete in \code{~/workspace}-Verzeichnis zu erstellen.
66
Dabei wird auch eine \code{compile_commands.json}-Datei im \code{build}-Unterordner erstellt, die von Entwicklungsumgebungen zur Syntaxvervollständigung genutzt werden.
67
Um eine Nutzung in allen Entwicklungsumgebungen zu erlauben, wurde diese zusätzlich in das Hauptverzeichnis des Workspaces gelinkt.
68
Dies ist notwendig, da einige Entwicklungsumgebungen nur dort nach dieser Datei suchen.
69
70
Da der Kompiliervorgang parallel abläuft, erscheinen Informationen zu allen Paketen gleichzeitig, was die Zuordnung von Fehlern erschwert.
71
Um trotzdem alle wichtigen Informationen zu erhalten, kommt der Event-Handler \code{console_cohesion} zum Einsatz, der die Ausgaben neu formatiert.
72
Durch diesen werden die Ausgaben gruppiert, und erst nach einen vollständigen Kompiliervorgang eines Pakets nacheinander ausgegeben.
73
Dies ermöglicht es, aufgetretene Fehler einfacher auf ein bestimmtes Paket zurückführen zu können, ohne das gesamte Log zu durchsuchen.
74
Hierbei ist es hilfreich, dass die verbleibenden Kompiliervorgänge abgebrochen werden, falls der Kompiliervorgang eines Pakets fehlschlägt.
75
Dadurch befindet sich der Fehler immer im letzten Paket der Ausgabe, da alle anderen Prozesse abgebrochen und nicht ausgegeben werden.
76
77
\section{Entwicklungsumgebung}
78
79
Ein Texteditor ist für das Schreiben von ROS-Packages ausreichend und bietet bei der Arbeit mit Containern sogar einen großen Vorteil.
80
Das Editieren von Dateien ist mit einem Texteditor auch von außerhalb des Containers möglich.
81
Jedoch besitzt ein Texteditor nur wenige Funktionen einer vollständigen Entwicklungsumgebung, die den Prozess der Softwareentwicklung beschleunigen.
82
Um diese Funktionen bieten zu können, analysieren Entwicklungsumgebungen den geschriebenen Code.
83
Dies geschieht meist auf eine von zwei unterschiedlichen Weisen.
84
85
Die Entwicklungsumgebung kann eine interne Repräsentation des geschriebenen Codes generieren.
86
Diese Repräsentation kann genutzt werden, um die implementierten Funktionen der Entwicklungsumgebung bereitzustellen.
87
Um dies zu erreichen, muss für jede unterstützte Sprache Code geschrieben werden, der in die Entwicklungsumgebung integriert wird.
88
89
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.
90
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.
91
92
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.
93
94
Bestimmte Funktionen, die beim Design des LSP nicht bedacht wurden, können einfacher in einer internen Implementation umgesetzt werden.
95
Deswegen besitzen Entwicklungsumgebungen mit interner Coderepräsentation häufig mehr Funktionen, spezialisieren sich jedoch auf bestimmte Sprachen.
96
97
In diesem Projekt wurden mehrere Entwicklungsumgebungen mit den jeweils unterschiedlichen Verfahren eingesetzt.
98
Um diese mit dem Docker-Container verwenden zu können, müssen diese Umgebungen die Entwicklung auf entfernten Systemen unterstützten, da der Container vom ausführenden System getrennt ist.
99
100
Um dies zu ermöglichen, wird ein Teil der Entwicklungsumgebung im Container ausgeführt, um mit dem inneren Kontext der Maschine arbeiten zu können.
101
Dazu wird beim Start einer Verbindung zu einem entfernten System dieser Server auf das Zielsystem übertragen und gestartet.
102
103
Die anfängliche Entwicklung wurde mit PyCharm und CLion durchgeführt, da diese durch ihre interne Codeanalyse die ROS-Umgebung ohne Konfiguration nutzen konnten.
104
Jedoch sind diese Umgebungen sehr ressourcenintensiv, was die gleichzeitige Ausführung erheblich verlangsamt.
105
106
Daher wurde später eine Entwicklungsumgebung mit LSP-Unterstützung, in diesem Fall Lapce (siehe Abbildung \ref{lapce}), verwendet.
107
Der dafür notwendige LSP-Server wird durch eine Veränderung des Buildscripts automatisch im Container installiert.
108
Unter Verwendung dieser neuen Server kann Lapce die Codevervollständigung und Codeanalyse wie PyCharm und CLion durchführen.
109
Gleichzeitig wird der Ressourcenverbrauch gesenkt, da nur ein einziger Editor benötigt wird.
110
111
\begin{figure}[ht]
112
\includegraphics[width=\textwidth]{img/MA-Umsetzung-Lapce}
113
\centering
114
\caption{Entwicklungsumgebung Lapce}
115
\label{lapce}
116
\end{figure}
117
\newpage
118
\section{Verwendete Datentypen}\label{datatypes}
119
In diesem Projekt werden viele unterschiedliche Datentypen sowohl für den Datenaustausch zwischen Nodes, als auch in der internen Implementation der Nodes verwendet.
120
Diese Datentypen sind größtenteils aus der Programmiersprache C++ bekannt, jedoch werden auch weitere Typen aus eigenem Code oder eingebundenen Bibliotheken verwendet.
121
Um die Verständlichkeit der Dokumentation zu erleichtern, sind die in der Implementation verwendeten Datentypen hier zusammengefasst und beschrieben.
122
\begin{description}
123
\item[Pose]
124
ist einer der häufigsten Datentypen im Umgang mit Gazebo.
125
Der Pose-Datentyp enthält die Information über die Lage und Rotation eines Objekts im Raum.
126
Die Daten werden als relative Werte in Bezug auf das übergeordnete Objekt gespeichert.
127
Objekte wie der Mensch liegen in der Hierarchie der Simulation direkt unter der Welt, deren Pose sich direkt im Nullpunkt und ohne Rotation befindet.
128
Durch diesen Umstand sind die Koordinaten des Menschen absolut, da sie nicht durch die Welt verschoben und rotiert werden.
129
\item[Area]
130
ist eine Datenstruktur mit einem Vektor an Positionen, die eine Zone im zweidimensionalen Raum definieren.
131
Jede Position ist eine einfache Datenstruktur aus 2 Gleitkommazahlen, die den X- und Y-Koordinaten der Position entsprechen.
132
Der Verwendungszweck dieser Struktur ist die einfache Definition von Zonen, die für Positionsgenerierungen und Positionsabfragen genutzt werden können.
133
\item[ActorPluginState]
134
definiert 4 Zustände, die das ActorPlugin annehmen kann. Diese 4 Werte sind SETUP, IDLE, MOVEMENT und ANIMATION.
135
\item[FeedbackMessage]
136
beschreibt die erste der beiden MessageQueue-Nachrichten, die vom ActorPlugin an den ActorServer gesendet wird.
137
In dieser Struktur befindet sich der aktuelle Plugin-Zustand als \code{state} Parameter vom Typ ActorPluginState
138
und außerdem ein \code{progress} Parameter in Form einer Gleitkommazahl, die den Fortschritt der aktuellen Aktion angibt.
139
Um bei Bewegungen die aktuelle Position des Menschen zu erhalten, ist zusätzlich die aktuelle Pose des Modells im Parameter \code{current} enthalten.
140
\item[ActionMessage]
141
ist die zweite Nachricht, die über die zweite MessageQueue vom ActorServer an das ActorPlugin gesendet wird.
142
Wie in der FeedbackMessage ist ein \code{state} Parameter vom selben Typ enthalten, jedoch dient dieser hier als Vorgabe für den nächsten State.
143
Ein \code{animationName} Parameter wird als char-Array mit einer maximalen Länge von 255 Zeichen übergeben.
144
Dieser bestimmt später die Animation, die je nach ActorPluginState während einer Bewegung oder Animation ausgeführt wird.
145
Der \code{animationSpeed} Parameter beschreibt entweder die Abspielgeschwindigkeit der Animation, oder die zurückgelegte Distanz pro Animationsdurchlauf.
146
Außerdem wird im Falle einer Bewegung der Parameter \code{target} vom Typ Pose verwendet, um die Endposition und Rotation des Actors zu bestimmen.
147
\end{description}
148
\section{Simulationswelt}
149
Die Definition aller Simulationselemente erfolgt im Paket \code{ign_world}.
150
In diesem Paket sind sowohl die Geometrien der Welt, aber auch die benötigten Dateien zum Starten der Simulation enthalten.
151
152
Diese Dateien enthalten zum Beispiel die Definition des virtuellen Raumes, in dem die Simulation der Mensch-Roboter-Interaktion abläuft.
153
Für diesen Raum wurde ein Raumplan erstellt, der alle benötigten Bereiche für die Szenarien besitzt (Abbildung \ref{room-plan}).
154
155
Zuerst wird ein Stellplatz für den Roboter benötigt.
156
Dieser sollte an einer Ecke des Raumes positioniert werden, was zu höheren Verfahrgeschwindigkeiten führt.
157
Das ist durch die dynamische Verfahrgeschwindigkeit bedingt, die bei geringerer Distanz zum Menschen abnimmt.
158
159
Des Weiteren werden eine Arbeits- und Lagerstätte für den Menschen benötigt, die in den Szenarien genutzt werden sollen.
160
Im Koexistenzszenario soll der Mensch nur an diesen Stellen seine Arbeit verrichten, sich jedoch seltener dem Roboter nähern, um dessen Fortschritt zu begutachten.
161
Die Lagerstätte soll im Kooperationsszenario neben der Arbeit des Menschen auch für die fehlerhaften Teile verwendet werden.
162
Diese Teile werden durch den Roboter aussortiert und durch den Menschen in das Lager verbracht.
163
Eine Nutzung der Arbeits- und Lagerstätte im Kollaborationsszenario ist nicht geplant, da der Mensch den Roboter überwachen und dessen Fehler korrigieren soll.
164
165
Der so geplante Raum wurde in Blender modelliert und als Datei im .stl-Format exportiert, um sie in die Welt einbinden zu können.
166
Das Resultat des Exports ist in Abbildung \ref{room-finished} dargestellt.
167
Für das Kooperationsszenario wurde ein Förderband erstellt, das nur in diesem Szenario dem Raum hinzugefügt wird.
168
169
Der so erstellte Raum wird in einer .sdf-Datei als Modell referenziert, um diesen später in die Simulation einbinden zu können.
170
Das Förderband erhält ein eigenes Modell in einer weiteren Datei, die zur Laufzeit in die Simulation geladen wird.
171
Für beide wird, wie später auch für den Roboter selbst, das Paket \code{ros_gz_sim} verwendet.
172
Dieses veranlasst mit dem \code{create}-Programm das Erstellen der übergebenen Datenstruktur in Gazebo.
173
174
\begin{figure}
175
\begin{minipage}{.45\textwidth}
176
\includegraphics[width=\textwidth]{img/MA-Umsetzung-Welt-Plan.drawio}
177
\centering
178
\caption{Geplanter Raum}
179
\label{room-plan}
180
\end{minipage}
181
\hspace{.09\textwidth}
182
\begin{minipage}{.45\textwidth}
183
\includegraphics[width=\textwidth]{img/MA-Umsetzung-Welt-Blender}
184
\centering
185
\caption{Umsetzung in Blender}
186
\label{room-finished}
187
\end{minipage}
188
\end{figure}
189
190
\section{Mensch}
191
192
Der Mensch soll in der Simulation verschiedene Aufgaben ausführen, die durch Behavior Trees definiert sind.
193
Um diese Aufgaben visuell darzustellen, werden verschiedene Animationen für ein Modell des Menschen benötigt.
194
Ein Modell eines Menschen ist bereits in Gazebo integriert, welches als sogenannter ``Actor'' durch vorher definierte Pfade bewegt werden kann.
195
Die für das Modell existierenden Animationen müssen um die gewünschten Animationen erweitert werden.
196
197
Um diese Animationen eines Modells in Bewegungen und Verhalten umzuwandeln, muss das Verhalten während der Simulation gesteuert werden.
198
Dies erfolgt über das ActorPlugin, welches in Gazebo ausgeführt wird.
199
Mit diesem Plugin kann der Mensch in der Simulation gesteuert werden.
200
Da eine Anbindung an ROS in Gazebo nicht möglich ist, kommuniziert das ActorPlugin mit dem ActorServer über MessageQueues.
201
Dieser ActorServer übersetzt Nachrichten und Anfragen zwischen ROS und der MessageQueue des ActorPlugins.
202
203
\subsection{Modellierung}
204
Um neue Animationen für den Menschen in der Simulation erstellen zu können, muss ein Modell für diesen erstellt werden.
205
Dafür wurde eine der bereits modellierten Laufanimationen von Gazebo in Blender geöffnet und bearbeitet.
206
207
Eine Kopie des Menschenmodells aus der Laufanimation dient als Grundlage für das neue Modell.
208
Dieses Modell ist durch die interne Geometrie, zum Beispiel zwischen Körper und Pullover der Person, nur schlecht für Animationen geeignet.
209
Die interne Geometrie bildet ``Falten'' im Modell, die während der Animation hervortreten können, was zu unerwarteten Artefakten führen kann.
210
Solche Artefakte entstehen durch unterschiedliche Verschiebung der Strukturen, die aus dem inneren des ursprünglichen Modells hervortreten, wenn es bewegt wird.
211
Beim kopierten Modell kam es häufig zum Hervortreten der Haut unter dem Rollkragen und der Hose.
212
Diese Artefakte wurden durch die Vereinfachung des Modells an den entsprechenden Stellen behoben.
213
214
An diesem Punkt könnte die Animation des Modells mit dem importierten Skelett beginnen, jedoch fehlen diesem viele Knochen, wie zum Beispiel für Finger und Zehen, aber auch Rotationsknochen für Arme und Beine.
215
Diese fehlenden Knochen werden für einige der gewünschten Animationen benötigt und müssten hinzugefügt werden.
216
Da das importierte Skelett noch andere Fehler aufwies, wurde es verworfen.
217
218
Um ein neues, passendes Skelett zu erstellen, wurde mit dem ``Rigify'' \cite{rigify}-Plugin ein standardisiertes Menschenskelett generiert.
219
Dieses neue Skelett kann an das bereits vorhandene Modell angepasst werden.
220
Um eine bessere Übersicht zu ermöglichen, sollten zuerst alle nicht benötigten Skelettteile, wie zum Beispiel für Gesichtsanimationen, entfernt werden.
221
Danach müssen die Knochen durch Verschiebung und Skalierung an die richtigen Positionen im Modell gebracht werden.
222
223
Dabei muss auf die Ausrichtung der Knochen zueinander geachtet werden.
224
Das Kreuzprodukt der Vektoren beider Knochensegmente bestimmt die Richtung der Beugeachse, die sich im Verbindungspunkt beider Knochen befindet.
225
Ist diese nicht richtig ausgerichtet, zum Beispiel wenn beide Knochen auf einer Gerade liegen, bewegen sich Gelenke bei der Verwendung von inverser Kinematik zur Positionsvorgabe falsch.
226
Der Grund dafür ist das Kreuzprodukt, dass im oben genannten Fall ein Nullvektor ist, wodurch keine Beugeachse bestimmt werden kann.
227
228
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.
229
Der Verbindungspunkt B der beiden Knochen wird vorerst auf dieser Gerade platziert.
230
Dieser muss senkrecht zu dieser Gerade und der gewünschten Beugeachse verschoben werden, wie in Abbildung \ref{bend} gezeigt.
231
232
\begin{figure}
233
\begin{minipage}{.45\textwidth}
234
\includegraphics[width=\textwidth]{img/MA-Umsetzung-Person-Bones}
235
\centering
236
\caption{Knochen des Modells}
237
\label{person-bones}
238
\end{minipage}
239
\hspace{.09\textwidth}
240
\begin{minipage}{.45\textwidth}
241
\includegraphics[width=\textwidth]{img/MA-Umsetzung-Person-Armature}
242
\centering
243
\caption{Armaturen des Modells}
244
\label{person-armature}
245
\end{minipage}
246
\end{figure}
247
248
\begin{figure}
249
\includegraphics[width=.5\textwidth]{img/MA-bend-axis}
250
\centering
251
\caption{Visualisierung der generierten Beugeachse}
252
\label{bend}
253
\end{figure}
254
255
Das neu erstellte Skelett ist in Abbildung \ref{person-bones} visualisiert.
256
257
Um eine bessere Verformung bei der Bewegung von Knochen zu erreichen, wird das sogenannte ``weight painting'' eingesetzt.
258
Hierfür werden für jeden Knochen entweder automatisch oder manuell Teile des Meshes mit Gewichten versehen.
259
Je höher die Wichtung, desto stärker ist die Verformung an dieser Stelle, wenn der Knochen bewegt oder skaliert wird.
260
Die so erstellten Knochen werden auch als deformierende Knochen bezeichnet, da deren Bewegung das Modell beeinflusst.
261
262
Da das Animieren aller Knochen einzeln sehr zeitaufwändig ist, werden diese in Gruppen zusammengefasst.
263
Hierfür werden in Blender sogenannte Constraints eingesetzt, die Knochen automatisch durch eingestellte Bedingungen positionieren können.
264
265
Durch das Verwenden von Rigify und einem standardisierten Skelett ist die automatische Generierung der Constraints möglich.
266
Hierfür können die in dem Skelett enthaltenen Informationen vom Plugin genutzt werden, um alle häufig genutzten Constraints automatisch zu generieren.
267
In diesem Schritt werden auch neue Knochen eingefügt, die das Skelett durch Constraints beeinflussen.
268
Das neue Animationsmodell, visualisiert in Abbildung \ref{person-armature}, kann jetzt für Animationen genutzt werden.
269
270
Hierfür stehen mehrere Knochengruppen zur Verfügung, die typische Animationsmethoden abdecken.
271
272
In der Farbe Rot sind im Modell (siehe Abbildung \ref{person-armature}) Knochen markiert, die für inverse Kinematik genutzt werden, in diesem Fall Arme und Beine.
273
Die Knochen geben die gewünschte Ausrichtung und die Zielposition des untersten Knochens vor.
274
Aus diesen Angaben wird die wirkliche Position der Knochen berechnet, die durch die Constraints automatisch auf die entsprechenden Knochen übertragen wird.
275
276
Orange gefärbte Knochen werden für generelle Einstellungen von Fingern, Handfläche und Zehen genutzt.
277
Die Handfläche kann so gekrümmt werden, wodurch sich alle Finger mit der Krümmung mitbewegen.
278
Ein Abknicken aller Zehen kann durch die Rotation des Hilfsknochens an den Zehen erreicht werden.
279
Die Finger können auch einzeln rotiert und eingeknickt werden.
280
Hierbei wird der Grad des Einknickens nicht durch eine Rotation des Knochens ausgedrückt, da diese bereits durch die Rotation des Fingers selbst benutzt wird.
281
Anstatt der Rotation wird die Skalierung des Knochens eingesetzt, wobei ein kleinerer Knochen eine stärkere Knickung aller Fingerglieder bewirkt.
282
283
Die gelben Knochen beeinflussen die generelle Pose des Modells.
284
Der Quader in der Hüfte gibt die gewünschte Höhe des Modells vor, die auch für die inverse Kinematik benutzt wird.
285
Die anderen Knochen beeinflussen die Rotation des Beckens, der Wirbelsäule, der Schultern und des Kopfes.
286
287
Das hier erstellte, verbesserte Rigify-Skelett kann durch den Einsatz der neuen Constraints einfacher animiert werden.
288
289
\subsection{Erstellen von Animationen}
290
291
Animationen werden in Blender über sogenannte Keyframes erstellt.
292
Ein Keyframe stellt dabei einen spezifischen Zeitpunkt in der Animation dar.
293
Jedem Keyframe kann eine beliebige Anzahl von Knochenpositionen zugeordnet werden.
294
295
Eine Animation entsteht, sobald mehrere Keyframes auf der Zeitachse existieren.
296
Alle zugeordneten Positionen werden zwischen beiden Keyframes durch auswählbare Kurven interpoliert.
297
In Abbildung \ref{actorinterpolate} wird dieser Prozess am Beispiel der ``low_to_standing''-Animation dargestellt.
298
299
Für die neuen Animationen werden die erstellten Steuerknochen verwendet, welche die später in Gazebo sichtbaren Knochen über Constraints beeinflussen.
300
301
\begin{figure}
302
\centering
303
\begin{minipage}{.25\textwidth}
304
\includegraphics[width=\textwidth]{img/MA-Animation-Human-Start}
305
\end{minipage}
306
\begin{minipage}{.25\textwidth}
307
\includegraphics[width=\textwidth]{img/MA-Animation-Human-Interpolated}
308
\end{minipage}
309
\begin{minipage}{.25\textwidth}
310
\includegraphics[width=\textwidth]{img/MA-Animation-Human-End}
311
\end{minipage}
312
\caption{Erste und letzte Keyframes einer Animation mit interpoliertem Zwischenbild}
313
\label{actorinterpolate}
314
\end{figure}
315
316
\subsection{Export der Modellanimationen}
317
318
Die Verwendung des hier erstellten, verbesserten und animierten Rigs ist in vielen Grafikengines, darunter auch Gazebo, noch nicht möglich.
319
Es bedarf einer zusätzlichen Anpassung des Skeletts, bei der die neu erstellte Knochenstruktur aufgelöst wird, da Gazebo keine Constraints unterstützt.
320
321
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}.
322
Dieses separiert die neuen Steuerknochen wieder vom ursprünglichen Modell, damit in diesem nur noch die deformierenden Knochen enthalten sind.
323
324
Alle erstellten Animationen der Steuerknochen müssen in direkte Bewegungen der deformierenden Knochen des Modells umgewandelt werden.
325
Um dies zu erreichen wird der in Abbildung \ref{export-prepare} visualisierte Arbeitsablauf verwendet.
326
327
Im ersten Schritt wird das zu exportierende Skelett ausgewählt, um diesem später die neue Animation zuweisen zu können.
328
Dann muss im zweiten Schritt die gewünschte Animation der Liste der bekannten Animationen hinzugefügt werden.
329
330
Danach muss die durch die Constraints abgebildete Animation auf das ausgewählte Skelett übertragen werden, was mit dem ``Bake Action Bakery''-Knopf ausgelöst wird.
331
Dabei wird die Position aller deformierenden Knochen zu jedem Zeitpunkt der Animation bestimmt, und in einer neuen Animation mit modifiziertem Namen abgespeichert.
332
333
Diese neu erstellte Animation kann im vierten Schritt dem ausgewählten Skelett zugewiesen werden.
334
Nach dieser Veränderung kann die Animation im Collada-Format exportiert werden.
335
Dazu muss das visuelle Modell der Selektion hinzugefügt werden, da Gazebo dieses für jede Animation benötigt.
336
337
Jetzt kann der Export über die in Blender integrierte Exportoption ausgelöst werden.
338
Hierfür müssen die in Abbildung \ref{export-settings} gezeigten Exporteinstellungen verwendet werden, damit Gazebo die exportierte Animation nutzen kann.
339
Alle in der Blender-Version 3.5 nicht standardmäßigen Einstellungen wurden dabei durch Punkte hervorgehoben.
340
341
Zuerst müssen im Reiter ``Main'' die globalen Exporteinstellungen angepasst werden.
342
Der markierte Punkt 2. bewirkt, dass nur die vorher ausgewählten Modellteile exportiert werden.
343
Dies verkleinert das Modell, da alle Steuerknochen von Gazebo nicht verwendet werden können, was die Ladezeit der Simulation verbessert.
344
345
Die Punkte 3. und 4. bewirken, dass das exportierte Modell die in Gazebo verwendete Vorwärtsachse erhält.
346
In Blender ist Y als Vorwärtsachse üblich, jedoch verwendet Gazebo die X-Achse für diesen Zweck.
347
Wird diese Modifikation nicht vorgenommen, sind die Modelle um 90 Grad verdreht.
348
349
Zuletzt muss im mit 5 markierten Animations-Reiter noch eine weitere Einstellung vorgenommen werden.
350
Die mit 6 markierte Einstellung bewirkt, dass alle Bewegungen der exportierten Knochen mit gespeichert werden, auch wenn diese sich nicht bewegen.
351
Da sich einige Knochen in der Animation in einer konstanten Pose befinden, exportiert Blender diese nicht.
352
Dies führt zu Fehlern, falls die Knochen von der Standardposition abweichen.
353
Ein solcher Fehler äußert sich in Gazebo durch verdrehte Knochen während der Animation.
354
355
\begin{figure}
356
\begin{subfigure}[b]{\textwidth}
357
\includegraphics[width=.5\textwidth]{img/MA-Umsetzung-Animation-Prepare}
358
\hfill
359
\includegraphics[width=.5\textwidth]{img/MA-Umsetzung-Animation-Prepare2}
360
\end{subfigure}
361
\caption{Vorbereitung zum Export mit Game_Rig_Tools}
362
\label{export-prepare}
363
\end{figure}
364
365
\begin{figure}
366
\begin{subfigure}[b]{\textwidth}
367
\includegraphics[height=.50\linewidth]{img/MA-Umsetzung-Animation-Save}
368
\hfill
369
\includegraphics[height=.50\linewidth]{img/MA-Umsetzung-Animation-Save2}
370
\end{subfigure}
371
\caption{Benötigte Exporteinstellungen in Blender}
372
\label{export-settings}
373
\end{figure}
374
375
\subsection{Programmierung}
376
377
Die von Gazebo verwendete Plugininfrastruktur ist ideal, um schnell neue Funktionen in Gazebo zu entwickeln.
378
Um dies zu ermöglichen werden beim Start der Simulation zusätzliche Programme in diese eingebunden.
379
380
\subsubsection{Message Queue}
381
382
Nach der ersten Implementation des ActorPlugins kam es zu Kollisionen mit \code{ros_control}, die beide \code{rclcpp} zur Kommunikation benutzen.
383
Diese Kollisionen führt zu einem Crash, wenn beide Plugins in der Simulation geladen werden.
384
Der Crash geschieht, da beide Plugins rclcpp, eine Bibliothek zur Kommunikation mit ROS-Topics, verwenden.
385
386
In dieser Bibliothek wird eine globale Instanz angelegt, die den Zustand des Kommunikationsprotokolls abbildet.
387
Da jedoch von beiden Plugins auf diesen Zustand zugegriffen wird, kommt es zu Problemen, da kein Synchronisationsmechanismus existiert.
388
Die dadurch entstehenden gleichzeitigen Zugriffe auf dieselben Ressourcen führen zur Terminierung des Programms.
389
390
Nachdem die Fehlerursache ermittelt war, stellte sich heraus, das der Konflikt allein durch Modifikation des ActorPlugins nicht aufzulösen ist.
391
392
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.
393
Die Nutzung eines separaten Nachrichtendienstes, der keinen globalen Kontext benötigt, ist die sicherste und schnellste Lösung des Problems.
394
Eine solche Implementation erfordert jedoch zusätzliche Logik, um die beiden Dienste ineinander übersetzen zu können.
395
396
Die Auswahl eines Dienstes wurde dabei aus einer Reihe an unterschiedlichen Möglichkeiten getroffen.
397
Webdienste, wie zum Beispiel REST-API's und Websockets werden von vielen Sprachen nativ unterstützt, was diese universell einsetzbar macht.
398
399
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.
400
Das HTTP besitzt jedoch keinen einheitlichen Feedbackmechanismus.
401
Dieser müsste entweder durch kontinuierliche Abfragen des aktuellen Status, auch ``polling'' genannt, oder eine lang anhaltende Request realisiert werden.
402
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.
403
Der Einsatz einer lang anhaltenden Request umgeht dieses Problem, jedoch müssen der eingesetzte Webserver und der Client diese Funktion unterstützen.
404
405
Das neuere Websocket-Protokoll \cite{websocket} bieten die Möglichkeit, bidirektional Daten zu übertragen.
406
Dadurch können Aktionsanfragen und Feedback auf dem gleichen Kanal übertragen werden, was das Protokoll übersichtlicher macht.
407
Beide Technologien basieren auf einem Webserver, der auf einem bestimmten Port des Systems ausgeführt werden muss, was Kollisionen mit anderen Services ermöglicht.
408
Die Portnummer kann zwar geändert werden, ist jedoch nicht einfach mit einer Komponente assoziierbar, was sie zu einer ``magischen Zahl'' macht.
409
Dies sorgt für schlechte Lesbarkeit in einem wichtigen Teil des Kontrollflusses.
410
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.
411
412
Eine andere Möglichkeit ist die Nutzung von ``shared memory'', einem geteilten Speicherbereich zwischen beiden Programmen \cite{shmem}.
413
Dieser kann zur bidirektionalen Kommunikation genutzt werden, da beide Programme auf den gleichen Speicherbereich zugreifen können.
414
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.
415
Durch das Erlauben gleichzeitiger Zugriffe kann es vorkommen, dass beide Programme gleichzeitig versuchen, Änderungen am Speicher vorzunehmen.
416
Diese gleichzeitige Modifikation, auch ``race condition'' genannt, kann zu Fehlern führen, wenn die Zugriffe auf den Bereich nicht kontrolliert werden.
417
418
Die letzte betrachtete Methode ist die Verwendung einer Message Queue.
419
Hier wird im Betriebssystem ein Speicherbereich mit bestimmter Größe für den Datenaustausch reserviert.
420
Dieser Bereich besitzt ein Identifikationsmerkmal, dass es Anwendungen erlaubt, Zugriff auf diesen zu erlangen.
421
Ein Programm kann in diesem Bereich Daten ablegen, die durch andere Programme gelesen und geschrieben werden können.
422
Die Koordinierung der Zugriffe erfolgt dabei durch das Betriebssystem, was gleichzeitige Zugriffe, wie bei shared memory, ausschließt.
423
Durch diesen Umstand kommt es zu einer Reduktion des Nachrichtendurchsatzes.
424
425
Die Angaben zu den Durchsätzen der verschiedenen Datenübertragungsmechanismen wurden mit \code{ipc-bench} \cite{ipcBench} auf dem Entwicklungssystem ermittelt.
426
427
Als Nachrichtendienst wurde die MessageQueue ausgewählt, da die integrierten Funktionen die Entwicklung erleichtern und die Geschwindigkeit ausreichend für das Einsatzszenario ist.
428
Jedoch existieren unter Linux 2 unabhängige Implementationen von MessageQueues mit unterschiedlichen Funktionen.
429
430
Die erste Implementation ist die System V MessageQueue \cite{mqSystemV} und verwendet zur Identifikation einfache Ganzzahlen.
431
432
Die neuere Implementation der MessageQueue ist die POSIX-MessageQueue \cite{mqPosix}.
433
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.
434
435
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.
436
\subsubsection{ROS-Nachrichten}
437
Die verwendeten Nachrichten für den ActionServer, als auch für die Message Queue sind in den entsprechenden Paketen \code{ros_actor_action_server_msgs} und \code{ros_actor_message_queue_msgs} organisiert.
438
Sie sind absichtlich nicht in den nutzenden Paketen untergebracht, da sie durch ein externes Programm in den benötigten Code umgewandelt werden.
439
Dieser Schritt muss vor dem Kompiliervorgang der nutzenden Pakete geschehen.
440
Dazu werden diese Nachrichtenpakete als Dependency der nutzenden Pakete angegeben, was eine automatische Anpassung der Kompilationsreihenfolge bewirkt.
441
442
Eine Action des \code{ros_action}-Pakets besteht immer aus 3 einzelnen Nachrichten, deren Inhalt frei definiert werden kann.
443
\begin{itemize}
444
\item{Zum Start der Action wird die erste Nachricht vom Client an den Server gesendet.
445
In dieser Startnachricht befinden sich alle Informationen, die zur Ausführung der Action benötigt werden.
446
Nach dieser Nachricht kann der Server später entscheiden, ob die Aktion ausgeführt werden soll und sie gegebenenfalls abbrechen.}
447
\item{Nach dem Beginn der Action werden vom Server eine oder mehrere Feedbacknachrichten an den Client gesendet, die den Fortschritt der Action beschreiben.
448
Dabei ist es die Aufgabe des Programmierers, diese an signifikanten Punkten des Ablaufs zu senden.}
449
\item{Am Ende der Action wird die Endnachricht an den Client gesendet, die weitere Rückgabewerte liefern kann.
450
Die Endnachricht enthält standardmäßig eine Erfolgsangabe, weshalb diese nicht angegeben werden muss.}
451
\end{itemize}
452
453
Ein ActionServer innerhalb eines Programmes definiert 3 Funktionen, welche die Handhabung einer Aktion definieren.
454
455
\begin{itemize}
456
\item{
457
Die erste Funktion übergibt den Wert der Startnachricht, die mit einer Antwort quittiert werden muss.
458
Hierbei sind die Antworten ACCEPT_AND_DEFER, ACCEPT_AND_EXECUTE und REJECT möglich.
459
460
Die erste mögliche Antwort ACCEPT_AND_EXECUTE signalisiert die sofortige Ausführung des gewünschten Befehls.
461
Als Alternative existiert die Antwort ACCEPT_AND_DEFER, die für eine verspätete Ausführung der gewünschten Aktion steht.
462
Die REJECT-Antwort weist die Ausführung der Aktion vorzeitig ab.
463
}
464
\item{
465
Die zweite Funktion übergibt Abbruchanfragen an den Server, falls die Aktion durch den Client abgebrochen werden soll.
466
Auch diese Anfrage kann entweder mit ACCEPT akzeptiert werden, oder mit REJECT zurückgewiesen werden.
467
}
468
\item{
469
Um Feedback während der Ausführung der Aktion geben zu können, existiert die dritte Funktion.
470
Diese erhält als Parameter ein Objekt, mit dem Feedback- und Endnachrichten an den Client gesendet werden können.
471
}
472
\end{itemize}
473
474
Die gesamte Kommunikation einer Anfrage verläuft wie in Abbildung \ref{plugin_sequence} dargestellt.
475
Zuerst wird durch den Client eine Zielvorgabe an den Server gesendet.
476
Sollte der Server diese abweisen, wird die Kommunikation beendet.
477
Dies geschieht, falls bereits eine Aktion ausgeführt wird.
478
479
Falls keine Aktion ausgeführt wird, beginnt die Kommunikation mit dem ActorPlugin.
480
Das Plugin erhält die Zielinformationen und seinen neuen Status aus der Zielvorgabe des Clients über die MessageQueue.
481
Der Server wartet den Zustandswechsel des Plugins ab und bestätigt dem Client die Ausführung der Zielanfrage.
482
483
Ab diesem Zeitpunkt ist eine Terminierung der Anfrage durch den Client möglich.
484
Dies geschieht durch eine Abbruchanfrage, welche sofort bearbeitet wird.
485
Für den Abbruch wird der Status des Plugins über die MessageQueue auf IDLE gesetzt, was alle laufenden Aktionen sofort beendet.
486
Der Zustandswechsel des Plugins wird abgewartet, um bei Erreichen des IDLE-Zustands die Abbruchanfrage zu bestätigen.
487
488
Solange die Aktion läuft, werden periodisch Feedbacknachrichten über die MessageQueue an den Server gesendet.
489
Der Server bringt diese in ein neues Format und leitet sie an den Client weiter.
490
491
Wenn das Ziel erreicht wird, wechselt das Plugin eigenständig in den IDLE-Zustand, was vom Server durch eine Feedbacknachricht erkannt wird.
492
Dieser Zustandswechsel löst die Meldung einer vollständigen Ausführung des gewünschten Befehls an den Client aus.
493
\begin{figure}
494
\includegraphics[width=\textwidth]{uml/out/plugin_connectivity.eps}
495
\caption{Kommunikation des ActorPlugins}
496
\label{plugin_sequence}
497
\end{figure}
498
499
\subsubsection{ActorPlugin}
500
Das ActorPlugin steuert den Menschen in der Simulationsumgebung anhand von empfangenen Nachrichten aus der eingehenden Message Queue.
501
Der Code des Plugins ist dabei im Paket \code{ign_actor_plugin} organisiert, dass im Gazebo-Modell der Welt referenziert werden muss, um das Plugin zu laden.
502
503
Das Plugin wird durch den Startvorgang und später von den empfangenen Nachrichten in folgende Zustände versetzt werden:
504
\begin{description}
505
\item[Setup]
506
wird ausschließlich zu Simulationsbeginn verwendet, um alle benötigten Referenzen aus der Simulationsumgebung im Plugin zu hinerlegen, so dass diese in den anderen Zuständen genutzt werden können.
507
\item[Idle]
508
definiert den Zustand, der nach erfolgreicher Ausführung eines Befehls angenommen wird.
509
\item[Movement]
510
bedeutet die Ausführung einer Bewegung in potenziell mehreren Schritten.
511
\item[Animation]
512
entspricht der Ausführung einer Animation an der aktuellen Position des Actors.
513
Diese kann durch einen Skalierungsfaktor beschleunigt oder verlangsamt werden.
514
\end{description}
515
516
In diesen Zuständen muss das ActorPlugin die Simulationsumgebung beeinflussen, in der die simulierte Person bewegt und animiert wird.
517
Dies erfordert den Zugriff auf simulationsinterne Daten, die durch das Plugin gelesen und verändert werden sollen.
518
Der Zugriff auf diese Daten wird durch ein EntityComponentManager-Objekt ermöglicht.
519
520
Durch den EntityComponentManager kann auf das sogenannte ``Entity Component System'' zugegriffen werden, in dem alle Simulationsobjekte organisiert sind.
521
Ein Entity Component System besteht aus einer oder mehr Entities, die Objekte innerhalb der Simulation abbilden.
522
Objekte können beliebig viele Components besitzen, bei denen es sich um zusätzliche Eigenschaften und Erweiterungen der Funktionen des betroffenen Objekts handelt.
523
Die wichtigsten Komponenten für die Funktion des Plugins sind dabei:
524
525
\begin{description}
526
\item[components::Actor]
527
Dieses Objekt beschreibt die simulierte Person mit allen weiteren Daten, wie zum Beispiel deren Animationen.
528
\item[components::AnimationName]
529
In dieser Komponente wird der aktuell verwendete Animationsname abgelegt, der von Gazebo zur Auswahl der aktuell laufenden Animation verwendet wird.
530
\item[components::AnimationTime]
531
enthält den aktuellen Zeitpunkt innerhalb der Animation, um die richtigen Positionsdaten aus dieser auswählen zu können. Dabei wird zwischen einzelnen Positionen linear interpoliert, falls der Zeitpunkt zwischen diesen liegt.
532
\item[components::Pose]
533
entspricht der bereits beschriebenen Pose aus Abschnitt \ref{datatypes}, jedoch verwendet Gazebo dafür diesen eigenen Datentyp.
534
\item[components::TrajectoryPose]
535
beschreibt eine Pose während einer Bewegung. Ist diese nicht gesetzt, werden keine Animationen abgespielt.
536
\end{description}
537
538
Durch das Verändern dieser Komponenten kann die gewünschte Funktionalität des Plugins erreicht werden.
539
Diese Veränderungen müssen zu jedem Simulationsschritt erneut vorgenommen werden, um einen flüssigen Ablauf zu gewährleisten.
540
Um dies zu erreichen, können im Plugin bestimmte Interfaces mit entsprechenden Funktionen implementiert werden \cite{ignPlugin}.
541
Diese Funktionen werden später in der Simulation aufgerufen.
542
Folgende Funktionen werden von Gazebo unterstützt:
543
\begin{description}
544
\item[Configure] wird aufgerufen, sobald das Plugin geladen wird.
545
Alle benötigten Informationen über dessen Umgebung werden als Parameter übergeben.
546
Als ersten Parameter wird die Entity übergeben, an welcher das Plugin als Component hinzugefügt wurde.
547
Außerdem wird eine Referenz auf die Konfiguration des Plugins in der geladenen Welt übergeben.
548
Für den Zugriff auf die Simulationsumgebung werden zuletzt noch eine aktuelle Instanz des EntityComponentManagers und EventManagers von Gazebo übergeben.
549
\item[PreUpdate] wird verwendet, um den nächsten Update-Schritt vorzubereiten.
550
Diese Funktion erlaubt die Modifikation von Entities und Components und wird vor der eigentlichen Physiksimulation aufgerufen.
551
\item[Update] wird genutzt, um die in der Simulation abgelaufene Zeit zu simulieren.
552
Auch hier ist die Modifikation von Entities und Components möglich.
553
In dieser Funktion wird beispielsweise die Physiksimulation der Objekte durchgeführt.
554
\item[PostUpdate] bietet die Möglichkeit, die Ergebnisse der Simulation vor dem nächsten Simulationsschritt auszulesen.
555
Dies wird zum Beispiel für die simulierten Sensoren in Gazebo genutzt, die hier ihren Status prüfen.
556
In dieser Funktion kann nur lesend auf Entities und Components zugegriffen werden.
557
\end{description}
558
Jede dieser Funktionen ist in einem Interface mit dem Präfix \code{ISystem} definiert, die vom Plugin genutzt werden können.
559
Für Gazebo muss das Plugin noch registriert werden, was mit dem \code{IGNITION_ADD_PLUGIN}-Makro geschieht.
560
Mit diesen Vorbereitungsschritten wird das Plugin von Gazebo verwendbar gemacht.
561
562
Das ActorPlugin benötigt für seine Funktion das übergeordnete Simulationsobjekt, dass durch das Plugin beeinflusst werden soll.
563
Dies erfordert die Implementation des \code{ISystemConfigure}-Interfaces für das ActorPlugin.
564
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.
565
566
Als Erstes wird durch das Laden des Plugins die Configure-Funktion aufgerufen.
567
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.
568
Trotz dieses Umstandes wartet das Plugin auf deren Erstellung, um bei Konfigurationsfehlern auffälliges Verhalten zu zeigen.
569
Im Log wird diese Aktion vermerkt, um das Debugging zu erleichtern.
570
Nach dem erfolgreichen Aufbau der Verbindung wird ein Thread gestartet, der die eingehenden Nachrichten verarbeitet.
571
Dabei wird zuerst eine Sperre gesetzt, um parallele Zugriffe durch die Update-Funktion zu verhindern.
572
Alle in der Anfrage gespeicherten Daten werden übernommen und der gewünschte State gesetzt.
573
Nach dem Entfernen der Sperre wird im nächsten Simulationsschritt die gewünschte Aktion durchgeführt.
574
575
Das Setzen aller obigen Zustände ist dabei möglich, jedoch werden nur Idle, Animation und Movement genutzt.
576
Der Idle-Zustand kann zum Beenden eines anderen Zustands eingesetzt werden, falls dieser abgebrochen werden soll.
577
Die Zustände Animation und Movement werden gesendet, falls neue Ziele gesetzt werden sollen.
578
Da beide Zustände Animationen verwenden, wird bei deren erster Ausführung in der Update-Funktion die gewünschte Animation gesetzt.
579
Um dies zu ermöglichen, werden alle in der Actor-Komponente gespeicherten Animationen durchsucht.
580
Sollte die Animation nicht gefunden werden, wird versucht, diese anhand ihres Namens zu laden.
581
Wurde eine Animation gefunden, wird deren Länge gespeichert, um diese später für das Feedback nutzen zu können.
582
583
Ab diesem Zeitpunkt unterscheiden sich die Implementation von Animation und Movement.
584
Im Zustand der Animation wird die Komponente AnimationTime bei jedem Update aktualisiert.
585
Um die Ausführungsgeschwindigkeit einer Animation anpassen zu können, wird ein Skalierungsfaktor genutzt.
586
Dieser optionale Faktor kann mit der abgelaufenen Zeit multipliziert werden.
587
Dies verursacht eine Beschleunigung oder Verlangsamung der Ausführung.
588
Nach jedem Update-Schritt wird eine Feedback-Nachricht gesendet, die den aktuellen Fortschritt der Animation enthält.
589
Wurde die Animation vollständig durchlaufen, wird der Zustand des ActorPlugins auf Idle gesetzt.
590
591
\begin{figure}
592
\includegraphics[width=\textwidth]{uml/out/plugin_states.eps}
593
\caption{Zustandsübergänge im ActorPlugin}
594
\label{plugin_states}
595
\end{figure}
596
Alle Zustandsübergänge sind in Abbildung \ref{plugin_states} zusammengefasst.
597
598
Soll über den Movement-Zustand eine Bewegung abgespielt werden, müssen noch weitere Parameter der Bewegung berechnet werden.
599
Dies geschieht nach dem Setzen der Animation während des ersten Update-Aufrufs.
600
Zuerst wird ein Vektor zur Zielposition berechnet, der später zur Bewegung genutzt wird.
601
Sollte dieser über einer gewissen Mindestlänge liegen, wird eine Rotation des Menschen in Bewegungsrichtung ausgeführt.
602
Nach dieser Rotation wird die Bewegung an die Zielposition umgesetzt.
603
Dabei wird die Bewegungsanimation abgespielt, die durch einen Faktor an die zurückgelegte Distanz angepasst wird.
604
Dies vermeidet, dass die Beine der Person über den Boden gleiten.
605
Wurde eine Endrotation angegeben, die nicht dem Nullvektor entspricht, wird nach der Bewegung noch eine Rotation in diese Richtung ausgeführt.
606
Dabei werden auch die Beine wieder in die Ausgangslage bewegt.
607
Wenn sowohl die Zielrotation ausgeführt wurde und die Beine wieder in Ausgangslage sind, wird der Zustand auf Idle gesetzt.
608
609
Das ActorPlugin besitzt kein Konzept eines ROS-ActionServers und verlässt sich auf den ActorServer, der die Feedbacknachrichten in das richtige Format bringt.
610
Um Zustandsübergänge erkennen zu können, werden diese als Feedback über die zweite Message Queue an den ActorServer gesendet.
611
Weitere Feedbacknachrichten werden in den Zuständen Movement und Animation zu jedem Simulationsschritt gesendet.
612
613
In diesen zusätzlichen Nachrichten werden die aktuelle Position des Menschen und der Fortschritt der laufenden Aktion aktualisiert.
614
Der Fortschritt einer Aktion wird aus der Animationszeit oder der berechneten Bewegungszeit und der bereits vergangenen Simulationszeit berechnet.
615
616
\subsubsection{ActorServer}
617
Der ActorServer ist die Brücke zwischen ROS und dem ActorPlugin.
618
Er ist als das Programm \code{ros_actor_action_server} im gleichnamigen Paket enthalten.
619
Dieser weitere Dienst bindet das ActorPlugin an ROS an.
620
621
Nach dem Start des ActorServers werden zwei ROS-ActionServer gestartet.
622
Diese können jeweils zum Abspielen von Animationen oder zum Starten von Bewegungen des simulierten Menschen genutzt werden.
623
Wenn ein Client eine dieser Aktionen startet, überträgt er die Zieldaten an den entsprechenden ActionServer.
624
Beide ActionServer prüfen nach dem Empfang eines neuen Ziels als erstes, ob bereits eine andere Aktion ausgeführt wird.
625
Wird bereits eine andere Aktion ausgeführt, kommt es zur Ablehnung der aktuellen Anfrage.
626
Im anderen Fall wird die Anfrage akzeptiert und in das MessageQueue-Format übersetzt und an das ActorPlugin gesandt.
627
628
Um das Starten mehrerer gleichzeitiger Aktionen zu unterbinden, muss der Empfang einer neuen Anfrage bestätigt werden, bevor weitere Befehle über den ROS-ActionServer entgegen genommen werden können.
629
Hierzu wird ein Mutex verwendet, der die Auswertung neuer Nachrichten verhindert, solange der aktuelle Befehl noch nicht durch das Plugin bestätigt wurde.
630
Parallel werden alle eingehenden Feedback-Nachrichten der Message Queue des ActorPlugins in Feedback für die aktuell laufende Action umgewandelt.
631
632
Im Falle des Bewegungs-ActionServers werden mehrere Parameter benötigt.
633
Zuerst werden Animationsname und -distanz benötigt, um die richtige Animation auszuwählen und die Bewegung mit der Animation zu synchronisieren.
634
Als Feedbacknachricht erhält der Client die aktuelle Pose des Actors im Simulationsraum.
635
636
Soll eine Animation über den ActionServer abgespielt werden, wird neben dem Animationsnamen noch die Animationsgeschwindigkeit als Parameter benötigt.
637
Die Feedbacknachricht enthält den Fortschritt der Animation als Gleitkommazahl von null bis eins.
638
\section{Roboter}
639
Der Roboter besteht aus mehreren interagierenden Systemen, die in ihrer Gesamtheit das vollständige Robotermodell in der Simulation verwendbar machen.
640
641
Zuerst muss ein Modell des Roboters erstellt werden, dass in Gazebo geladen werden kann.
642
Dieses Modell muss dann für die Bewegungsplanung mit MoveIt erweitert werden.
643
Hierbei werden Controller von ros_control mit dem Modell verbunden, um den aktuellen Zustand der Achsen zu überwachen und diese steuern zu können.
644
645
Um diese Vielfalt an Daten standardisiert für andere Nodes in ROS weitergeben zu können, wird eine MoveGroup in ROS gestartet, welche die Planung von Bewegungen durch andere Programme zulässt.
646
\subsection{Modellierung}
647
Für den Kuka LBR iisy ist kein Simulationsmodell für Gazebo und ROS verfügbar.
648
Daher wurde das für die Simulation benötigte Modell aus einer .stl Datei des Herstellers generiert.
649
Diese Datei enthält eine geometrische Beschreibung des Roboters, zu sehen in Abbildung \ref{robot_raw}, welche nicht direkt im Simulator nutzbar ist.
650
Aus dieser Datei wurden mit FreeCAD \cite{freecad} alle Glieder des Roboters als separate Collada-Dateien exportiert.
651
Dabei muss darauf geachtet werden, dass die exportierten Daten eine ausreichende Meshgröße haben.
652
Diese kann vor dem Export in FreeCAD eingestellt werden.
653
Durch diese Einstellung bleiben feine Strukturen erhalten, die später in Blender wieder reduziert werden können.
654
Ein solches Vorgehen erlaubt es Blender, bessere Entscheidungen über die Reduktion von Strukturen zu treffen.
655
Das Resultat ist ein exakteres Endmodell des Roboters.
656
657
\begin{figure}
658
\includegraphics[width=\textwidth/2]{img/MA-Roboter-Rohdaten}
659
\centering
660
\caption{Rohdaten aus .stl-Datei}
661
\label{robot_raw}
662
\end{figure}
663
664
Diese Dateien können dann in Blender bearbeitet werden, um sie für die Simulation tauglich zu machen.
665
Hierfür wurde die hohe Auflösung der Modelle reduziert, was sich positiv auf die Dateigröße, die Startzeit der Simulation und die Rendergeschwindigkeit auswirkt.
666
Außerdem wurden die Glieder so ausgerichtet, dass sich der Verbindungspunkt zum vorherigen Glied im Nullpunkt des Koordinatensystems befindet.
667
Das vollständige visuelle Modell ist in Abbildung \ref{robot_visual} zu sehen.
668
669
Um die Simulation weiter zu beschleunigen, wurden die Kollisionsboxen des Arms noch weiter vereinfacht, was die Kollisionsüberprüfung deutlich beschleunigt.
670
Dabei werden stark simplifizierte Formen verwendet, die das hochqualitative visuelle Modell mit einfachen Formen umfassen.
671
Das resultierende Modell, in Abbildung \ref{robot_collision} dargestellt, wird später zur Kollisionserkennung verwendet.
672
673
Diese Herangehensweise ist nötig, da die Kollisionserkennung auf der CPU durchgeführt und durch komplexe Formen stark verlangsamt wird.
674
675
Um aus den generierten Gliedermodellen ein komplettes Robotermodell erstellen zu können, wurde eine .urdf-Datei erstellt.
676
In dieser werden die verwendeten Gelenktypen zwischen den einzelnen Gliedern, aber auch deren Masse, maximale Geschwindigkeit, maximale Motorkraft, Reibung und Dämpfung hinterlegt.
677
Diese Daten können später zur Simulation der Motoren genutzt werden, die den Arm bewegen.
678
679
Die Gelenkpositionen sind dabei relative Angaben, die sich auf das Glied beziehen, an dem ein weiteres Glied über das Gelenk verbunden werden soll.
680
Alle kontrollierbaren Gelenke benötigen auch eine Gelenkachse, die je nach Gelenktyp die mögliche Beweglichkeit bestimmt.
681
682
Alle hier erstellten Dateien wurden im Paket \code{iisy_config} zusammengefasst, um diese einfacher wieder auffinden zu können.
683
\begin{figure}
684
\begin{minipage}{.49\textwidth}
685
\includegraphics[width=\textwidth]{img/MA-Roboter-Visuell}
686
\centering
687
\caption{Visuelles Modell}
688
\label{robot_visual}
689
\end{minipage}
690
\begin{minipage}{.49\textwidth}
691
\includegraphics[width=\textwidth]{img/MA-Roboter-Kollision}
692
\centering
693
\caption{Kollisionsmodell}
694
\label{robot_collision}
695
\end{minipage}
696
\end{figure}
697
\subsection{MoveIt 2 Konfiguration}
698
Das im Abschnitt Modellierung erstellte Paket mit dem Roboter-Modell kann mit dem neu implementierten MoveIt Configurator um die benötigten Kontrollstrukturen erweitert werden.
699
Dazu wurde der Setupassistent von MoveIt2 verwendet, der das Modell für MoveIt anpasst.
700
Dabei wird das Modell mit weiteren Parametern versehen, die durch MoveIt genutzt werden.
701
702
Die Erstellung des erweiterten Modells mit dem Assistenten funktionierte komplett fehlerfrei, jedoch ließen sich die generierten Dateien nicht direkt nutzen.
703
704
Um die generierten Dateien nutzen zu können, mussten diese weiter angepasst werden.
705
Dies beinhaltete die korrekte Integration der Roboterdefinitionen im Paket, aber auch zahlreiche Pfadreferenzen auf verwendete Dateien, die nicht korrekt generiert wurden.
706
Diese können standardmäßig nicht in Gazebo, RViz und MoveGroup gleichzeitig geladen werden, da diese Programme unterschiedliche Pfadangaben verlangen, was die Nutzung verhindert.
707
708
Eine Möglichkeit zur Lösung des Problems ist die Verwendung von \code{file://}-URIs, die von allen dieser Programme gelesen werden können.
709
Der Moveit Setup Assistent kann diese URIs nicht lesen, was zu Fehlern bei einer Rekonfiguration führen kann.
710
Falls eine Neukonfiguration des Roboters mit dem Assistenten durchgeführt werden soll, muss diese Umwandlung temporär rückgängig gemacht werden.
711
712
Das so erstellte Modell kann über den Aufruf von \code{ros2 launch iisy_config demo.launch.py} in RViz getestet werden.
713
Hierfür erscheint das Robotermodell mit mehreren Markern und Planungsoptionen, die genutzt werden können, um beliebige Bewegungen zu planen und auszuführen.
714
\subsection{Integration mit Gazebo}
715
Das so erweiterte Modell kann zur Laufzeit in Gazebo geladen werden.
716
Dafür wird das Paket \code{ros_gz_sim} verwendet, dass das \code{create}-Programm beinhaltet.
717
Mit diesem Werkzeug wird ein Modell unter einem bestimmten Namen anhand einer Datei oder eines übergebenen Strings in Gazebo importiert.
718
Das Modell kann dabei über Argumente im Raum verschoben und rotiert werden, falls diese Funktionalität benötigt wird.
719
720
In diesem Fall wird das Modell als String geladen, der durch \code{xacro} erstellt wurde.
721
Dies ist nötig, um Informationen aus anderen Dateien in das generierte XML übernehmen zu können.
722
723
Im Modell sind auch die verwendeten Gazebo-Plugins deklariert, die für die Integration mit \code{ros_control} verantwortlich sind.
724
Das Gazebo-Plugin lädt dabei die verwendeten Controller und versorgt diese mit Informationen über den Roboter.
725
726
\section{Behavior Trees}
727
Alle Behavior Trees wurden im Paket \code{btree} organisiert, das die Bäume im XML-Format und die Implementation der Nodes und umliegenden Infrastruktur in C++ enthält.
728
729
730
Für die Umsetzung des Szenarios wurden neue Nodes für den Behavior Tree erstellt.
731
Diese lassen sich nach Nutzung in verschiedene Gruppen einordnen.
732
733
\subsubsection{Allgemein nutzbare Nodes}
734
\begin{description}
735
\item[GenerateXYPose]
736
generiert eine Pose in einem durch den \code{area} Parameter angegebenen Bereich.
737
Um dies zu ermöglichen, wird zuerst die Fläche aller Dreiecke berechnet, die den Bereich definieren.
738
Diese werden durch den Gesamtinhalt geteilt, um eine Wichtung der Dreiecke zum Gesamtinhalt zu erreichen.
739
Darauf wird eine Zufallszahl zwischen 0 und 1 gebildet.
740
Von dieser werden die Wichtungen der Dreiecke abgezogen, bis diese Zufallszahl im nächsten abzuziehenden Dreieck liegt.
741
Als letzter Schritt wird in diesem Dreieck eine zufällige Position ermittelt, die über den Ausgabeparameter \code{pose} ausgegeben wird.
742
\item[InAreaTest]
743
prüft, ob eine Pose, vorgegeben durch den \code{pose} Parameter, in einer durch den \code{area} Parameter definierten Zone liegt.
744
Hierfür wird überprüft, ob die X und Y-Werte der Pose in einem der Dreiecke liegen, welche die Area definieren.
745
Der Rückgabewert ist das Ergebnis dieser Überprüfung, wobei SUCCESS bedeutet, dass sich die Pose in der Area befindet.
746
\item[OffsetPose]
747
wird genutzt, um eine Pose im Raum zu bewegen und/oder deren Orientierung zu verändern.
748
Falls der \code{offset} Parameter gesetzt ist, wird dieser mit dem \code{input} Parameter summiert.
749
Außerdem wird die Orientierung der Pose auf den \code{orientation} Parameter gesetzt, falls dieser vorhanden ist, was den ursprünglichen Wert überschreibt.
750
\item[InterruptableSequence]
751
stellt eine Sequence dar, die auch nach ihrem Abbruch ihre Position behält.
752
Dies ist notwendig, wenn ein bestimmtes Verhalten unterbrechbar ist, aber zu einem späteren Zeitpunkt fortgesetzt werden soll.
753
Hierzu wird der Iterator der unterlegenden Sequenz nur erhöht, wenn die untergeordnete Node SUCCESS zurückmeldet.
754
Außerdem wird der Iterator nicht zurückgesetzt, wenn die Ausführung dieser modifizierten Sequenz abgebrochen wird.
755
\item[WeightedRandom]
756
ist eine Steuerungsnode, die mehrere untergeordnete Nodes besitzt.
757
Dabei werden diese nicht, wie bei anderen Steuerungsnodes üblich, sequentiell ausgeführt.
758
Anhand einer vorgegebenen Wichtung im \code{weights} Parameter wird eine der untergeordneten Nodes zufällig ausgewählt.
759
Diese Node wird als einzige Node ausgeführt, bis diese den SUCCESS-Status zurückgibt.
760
Nachdem dieser Status erreicht wurde, wird bei dem nächsten Durchlauf eine neue Node ausgewählt.
761
Der Rückgabewert ist der Rückgabewert der ausgewählten untergeordneten Node.
762
\item[IsCalled]
763
fragt den aktuellen Called-Status des Actors ab, der in einigen Szenarien vom Roboter verwendet wird, um den simulierten Menschen zu rufen.
764
Der Rückgabewert der Node ist dabei SUCCESS, falls der Mensch gerufen wird, oder FAILURE, wenn kein RUF durchgeführt wird.
765
\item[SetCalledTo]
766
setzt den aktuellen Called-Status auf den Wert des übergebenen \code{state} Parameters.
767
Da diese Aktion nicht fehlschlagen kann, liefert diese Node immer SUCCESS als Rückgabewert.
768
\item[RandomFailure]
769
generiert eine Zufallszahl von 0 bis 1, die mit dem \code{failure_chance} Parameter verglichen wird.
770
Der Rückgabewert ist das Ergebnis des Vergleichs, FAILURE, wenn die Zufallszahl kleiner als der \code{failure_chance} Parameter ist, oder im anderen Falle SUCCESS.
771
\end{description}
772
773
\subsubsection{Menschenspezifische Nodes}
774
\begin{description}
775
\item[ActorAnimation]
776
wird verwendet, um dem simulierten Menschen eine auszuführende Animation zu senden.
777
Die Node benötigt zur Ausführung einen Animationsnamen, der im \code{animation_name} Parameter angegeben wird.
778
Ein optionaler \code{animation_speed} Parameter gibt die Ausführungsgeschwindigkeit vor.
779
Der Rückgabewert ist SUCCESS, wenn die komplette Ausführung gelang, oder FAILURE, falls diese abgebrochen oder abgelehnt wurde.
780
\item[ActorMovement]
781
funktioniert wie eine ActorAnimation, sendet jedoch eine Bewegungsanfrage.
782
Auch für diese wird ein Animationsname benötigt, der im \code{animation_name} Parameter definiert wird.
783
Jedoch wird für die Synchronisation zur Bewegung ein Distanzwert benötigt, der in einem Animationsdurchlauf zurückgelegt wird.
784
Dieser wird im \code{animation_distance} Parameter übergeben.
785
Eine Zielpose wird im \code{target} Parameter gesetzt.
786
Eine Besonderheit dieses Parameters ist die Verwendung des Null-Quaternions als Richtungsangabe, was die Endrotation auf die Laufrichtung setzt.
787
\end{description}
788
789
\subsubsection{Roboterspezifische Nodes}
790
\begin{description}
791
\item[RobotMove] gibt dem Roboter eine neue Zielposition über den \code{target} Parameter vor.
792
Bei dieser Node handelt es sich um eine asynchrone Node, die nur bei der erfolgreichen Ausführung der Bewegung mit dem SUCCESS-Status beendet wird.
793
\item[SetRobotVelocity] setzt eine neue maximale Geschwindigkeit des Roboters, vorgegeben durch den \code{velocity} Parameter.
794
Der Rückgabewert ist immer SUCCESS.
795
\end{description}
796
Diese beiden roboterspezifischen Nodes beeinflussen im Hintergrund das gleiche System, da Bewegungen bei Geschwindigkeitsänderungen neu geplant und ausgeführt werden müssen.
797
Dazu wird das letzte Ziel bis zu dessen Erreichen vorgehalten, um die Ausführung neu zu starten, falls eine Geschwindigkeitsänderung durchgeführt werden muss.
798
Um die RobotMove-Node nicht zu unterbrechen, wird diese nur über einen Callback über den Erfolg oder Misserfolg der gesamten Bewegung und nicht über den Erfolg einzelner Teilbewegungen informiert.
799
800
\subsection{Subtrees}
801
Um die Wiederverwendung von bestimmten Abläufen zu erleichtern, wurden diese in Subtrees ausgelagert.
802
In diesem Fall wurden die Aktionen ``Arbeiten an der Werkbank'' und ``Ablegen eines Objekts im Lagerregal'' des Menschen ausgelagert, da diese in mehreren Fällen verwendet werden.
803
Diese Abstraktion erhöht die Lesbarkeit der Bäume und vereinfacht die Verwendung gleicher Aktionen in mehreren Bäumen.
804
805
Für das Arbeiten an der Werkbank ist eine Bewegung des Menschen hin zu dieser erforderlich.
806
Außerdem muss sich der Mensch zur Werkbank ausrichten, um die späteren Animationen korrekt auszuführen.
807
Dazu wird eine Bewegung zu einem Punkt vor der Werkbank mit vorgegebener Zielrichtung genutzt.
808
Nach dieser Bewegung soll ein Arbeitsprozess simuliert werden.
809
810
Da dieser Prozess weit vom Roboter entfernt ist, ist eine genaue Animation nicht erforderlich.
811
In diesem Fall wird die Arbeit durch ausstrecken und zurücknehmen der Hand in Richtung der Werkbank simuliert.
812
Dies wird durch zwei Animations-Nodes mit entsprechenden Parametern gesteuert.
813
814
Die Ausführung der Nodes dieser Gesamtaktion soll sequenziell erfolgen, weshalb die Nodes unterhalb einer Sequence-Node gruppiert werden.
815
Der vollständige resultierende Baum ist in Abbildung \ref{subtree_work} visualisiert.
816
817
\begin{figure}
818
\includegraphics[width=\textwidth]{img/MA-subtree-work}
819
\centering
820
\caption{Behavior Tree für das Arbeiten an der Werkbank}
821
\label{subtree_work}
822
\end{figure}
823
824
Das Ablegen von Objekten in einem Schrank ist ein komplizierterer Prozess, da der Schrank in mehreren Ebenen befüllt werden kann.
825
Außerdem sind mehrere Fächer verfügbar, die genutzt werden können.
826
827
Wie bereits bei der Werkbank wird zuerst eine Bewegung hin zum Schrank ausgeführt.
828
Diese hat eines der drei im Schrank vorhandenen Schrankteile zum Ziel.
829
Die Auswahl des Ziels erfolgt zufällig durch eine WeightedRandom-Node, die eine der drei Bewegungs-Nodes ausführt.
830
831
Danach erfolgt eine weitere zufällige Auswahl die entscheidet, ob das obere oder das untere Fach des betreffenden Schranks genutzt werden soll.
832
833
Im Falle eines oberen Faches werden nur zwei Animationen benötigt.
834
Die Hand wird zu einem oberen Fach ausgestreckt und zurückgezogen.
835
836
Für den Fall eines unteren Fachs werden vier Animationen genutzt.
837
Zuerst kniet die Person auf den Boden nieder, um das untere Fach erreichen zu können.
838
Danach wird ein Objekt durch Inspizieren und Ablegen in das Fach gelegt.
839
Jetzt kann die Person wieder aufstehen, was die Person in die gleiche Position wie am Anfang der Aktion bringt.
840
841
Für die beiden Fälle werden auch Sequenz-Nodes genutzt, da die Aktionen nacheinander ausgeführt werden sollen.
842
Die beiden zufälligen Auswahlverfahren werden durch eine Sequenz verbunden.
843
Der resultierende Ablauf wurde als Baum in Abbildung \ref{subtree_deposit} visualisiert.
844
845
\begin{figure}
846
\includegraphics[width=\textwidth]{img/MA-subtree-deposit}
847
\centering
848
\caption{Behavior Tree für das Ablegen von Objekten im Schrank}
849
\label{subtree_deposit}
850
\end{figure}
851
852
\subsection{Verhalten des Roboters}
853
Das grundlegende Verhalten des Roboters ist in jedem Anwendungsfall gleich.
854
Dies hängt mit der automatischen Geschwindigkeitsanpassung zusammen.
855
Der Roboter soll bei annäherndem Mensch zuerst seine Geschwindigkeit reduzieren, wenn dieser eine Warnzone betritt.
856
Falls sich der Mensch weiter bis in die Sicherheitszone begibt, ist ein temporärer Stopp des Roboters vorgesehen.
857
Dieser Stopp soll nach dem Entfernen des Menschen aus der Sicherheitszone wieder aufgehoben werden, um die Arbeit fortzusetzen.
858
859
Um diese Funktionen zu erlauben, ist eine Reaktion auf Statusänderungen von vorherigen Nodes nötig.
860
Dies wird durch eine übergeordnete ReactiveSequence erreicht.
861
Eine solche Node verhält sich ähnlich einer normalen Sequence, jedoch prüft sie zu jedem Ausführungsschritt noch einmal alle vorherigen Nodes.
862
Dies geschieht auch, wenn eine andauernde Aktion sich noch im Status RUNNING befindet.
863
Wenn eine vorherige Node einen Fehler zurückgibt, wird die aktuell laufende spätere Node abgebrochen.
864
865
Als erste Node in der ReactiveSequence wird getestet, ob sich der Mensch in der Sicherheitszone aufhält.
866
Wenn dies nicht der Fall ist, kann die Ausführung weiter fortgesetzt werden.
867
Dies wird durch eine über dem Test angeordnete Inverter-Node erreicht.
868
869
Nach diesem Schritt kann die Geschwindigkeitsanpassung vorgenommen werden, falls diese nötig ist.
870
Dies wird durch eine If-Then-Else Node erreicht.
871
Als Bedingung wird ein Test auf den Aufenthalt des Menschen in der Warnzone verwendet.
872
Wenn der Mensch sich in dieser befindet, wird die Geschwindigkeit auf 10\% gesetzt.
873
Sonst wird die Geschwindigkeit wieder auf 100\% erhöht.
874
875
Nach dieser Sequenz kann der spezifische Teil für die gewünschte Applikation hinzugefügt werden.
876
In Abbildung \ref{tree_base_robot} wurde dies durch eine Wolke repräsentiert.
877
878
\begin{figure}
879
\includegraphics[width=\textwidth]{img/MA-tree-base-robot}
880
\centering
881
\caption{Grundlegender Behavior Tree des Roboters}
882
\label{tree_base_robot}
883
\end{figure}
884
885
\subsubsection{Koexistenz}
886
887
Im ersten Szenario, der Koexistenz zwischen Mensch und Roboter, soll eine Arbeitsaufgabe durch den Roboter allein simuliert werden.
888
Hierfür soll der Roboter Objekte von der rechten auf die linke Tischseite transportieren.
889
Alle Nodes werden einer ReactiveSequence untergeordnet, um bei Unterbrechungen durch den Mensch den Fortschritt der Aktion behalten zu können.
890
Mit einer GenerateXYPose-Node wird zuerst ein Ziel auf der linken Tischseite generiert.
891
Dieses Ziel befindet sich auf dem Boden, und muss auf die Tischebene angehoben werden.
892
Das Anheben wird durch eine OffsetPose-Node realisiert.
893
Mit einer RobotMove-Node wird die Bewegung zum generierten Zielpunkt ausgeführt.
894
Dies geschieht auf gleichem Weg für die rechte Tischseite.
895
Der vollständige Baum ist in Abbildung \ref{tree_robot_coex} zu sehen.
896
897
\begin{figure}
898
\includegraphics[width=\textwidth]{img/MA-tree-robot-coex}
899
\centering
900
\caption{Erweiterter Behavior Tree des Roboters bei Koexistenz }
901
\label{tree_robot_coex}
902
\end{figure}
903
904
\subsubsection{Kooperation}
905
906
Im Kooperationsszenario wird der Ablauf des ersten Szenarios modifiziert.
907
Nach der Bewegung zu einem Objekt auf der linken Tischseite wird eine zufällige Entscheidung getroffen.
908
Mit einer Chance von 90\% ist das Objekt den Anforderungen gerecht, und kann durch den Roboter auf ein Förderband gelegt werden.
909
Im anderen Fall soll das Objekt auf den rechten Tisch gelegt werden.
910
Von dort aus soll der Mensch dieses Objekt abholen, um den Ausschuss im Regal zu verstauen.
911
Es wird dafür die gleiche Operationsabfolge aus dem ersten Szenario verwendet.
912
Am Ende der übernommenen Sequenz wird eine SetCalledTo-Node ergänzt, die den Menschen ruft.
913
Eine Visualisierung des modifizierten Baums wird in Abbildung \ref{tree_robot_coop} gezeigt.
914
915
\begin{figure}
916
\includegraphics[width=\textwidth]{img/MA-tree-robot-coop}
917
\centering
918
\caption{Erweiterter Behavior Tree des Roboters bei Kooperation}
919
\label{tree_robot_coop}
920
\end{figure}
921
922
\subsubsection{Kollaboration}
923
924
Für das dritte Szenario soll der Roboter mit dem Menschen kollaborieren.
925
Um dieses Szenario umzusetzen, wird wiederum das erste Szenario modifiziert.
926
Hier soll der Roboter eine Palette ausladen, wobei es durch die Beschaffenheit der Objekte zu Fehlern kommen kann.
927
Dies wird durch das Hinzufügen mehrerer RandomFailure-Nodes erreicht, welche die Sequenz abbrechen können.
928
Da diese Probleme durch den Menschen behoben werden sollen, muss ein Mechanismus geschaffen werden, um diesen zu rufen.
929
Hierfür wird eine Fallback-Node über der InterruptableSequence angeordnet.
930
Diese Fallback-Node führt im Fall eines Fehlers in der InterruptableSequence die nächste Node aus.
931
Bei dieser handelt es sich um eine SetCalledTo-Node, welche den Menschen ruft.
932
Der Aufbau des Baumes wird in Abbildung \ref{tree_base_colab} dargestellt.
933
934
\begin{figure}
935
\includegraphics[width=\textwidth]{img/MA-tree-robot-colab}
936
\centering
937
\caption{Erweiterter Behavior Tree des Roboters bei Kollaboration}
938
\label{tree_base_colab}
939
\end{figure}
940
941
\subsection{Verhalten des Menschen}
942
943
\subsubsection{Koexistenz}
944
945
Im ersten Szenario soll der Mensch nur neben dem Roboter arbeiten.
946
Um das Verhalten des Roboters trotzdem zu prüfen, soll der Mensch selten die Sicherheitszone betreten, um den Roboter zu überwachen.
947
Dies wird durch eine WeightedRandom-Node erreicht, die mit 95 prozentiger Wahrscheinlichkeit den normalen Arbeitsvorgang ausführt.
948
Im anderen Zweig wird mit einer Wahrscheinlichkeit von 5\% eine Bewegung in die Sicherheitszone ausgelöst.
949
950
Der normale Arbeitsvorgang ist ein linearer Ablauf und wird von einer Sequence-Node repräsentiert.
951
In dieser werden nacheinander die beiden Subtrees ``WorkOnBench'' und ``DepositToShelf'' ausgeführt.
952
Das Bewegen in die Sicherheitszone wird auch durch eine Sequence-Node erreicht.
953
Diese enthält eine GenerateXYPose-Node, um ein Ziel in der Sicherheitszone auszuwählen und eine ActorMovement-Node, um die Bewegung auszulösen.
954
Der Baum für diese Interaktion wird in Abbildung \ref{tree_actor_coex} dargestellt.
955
956
\begin{figure}
957
\includegraphics[width=\textwidth]{img/MA-tree-actor-coex}
958
\centering
959
\caption{Behavior Tree des Menschen bei Koexistenz }
960
\label{tree_actor_coex}
961
\end{figure}
962
963
\subsubsection{Kooperation}
964
965
Für das Kooperationsszenario wird diese Abfolge durch eine weitere, übergeordnete Sequence-Node ergänzt.
966
Diese wurde ausgewählt, da ein Ruf durch den Roboter in diesem Szenario nicht zeitkritisch ist.
967
Eine solche Implementation erlaubt das vollständige Ausführen der vorgehenden Aufgabe.
968
In dieser hinzugefügten Sequence-Node wird die nötige Funktionalität für das Abholen der aussortierten Objekte implementiert.
969
Dies erfolgt nach einer AmICalled-Node, welche die Sequence vorzeitig beendet, falls der Mensch nicht gerufen wurde.
970
Das vorzeitige Beenden führt zu einer erneuten Auswahl zwischen Arbeit und Inspektion.
971
Sollte der Mensch jedoch durch den Roboter gerufen werden, wird die Sequence weiter ausgeführt.
972
973
In diesem Fall soll der Mensch das Objekt vom rechten Tisch abholen und in das Regal legen.
974
Dies erfolgt durch eine ActorMovement-Node, welche den Mensch zum rechten Tisch bewegt.
975
Nach dieser werden zwei ActorAnimation-Nodes ausgeführt, welche die Animationen ``standing_extend_arm'' und ``standing_retract_arm'' durchführen.
976
Dies simuliert den Griff auf den Tisch, um das Objekt aufzuheben.
977
Um das Objekt im Schrank zu verstauen, wird der bereits definierte Subtree ``DepositToShelf'' genutzt.
978
Der Behavior Tree für die Kooperation des Menschen ist in Abbildung \ref{tree_actor_coop} dargestellt.
979
980
\begin{figure}
981
\includegraphics[width=\textwidth]{img/MA-tree-actor-coop}
982
\centering
983
\caption{Behavior Tree des Menschen bei Kooperation }
984
\label{tree_actor_coop}
985
\end{figure}
986
987
\subsubsection{Kollaboration}
988
989
Für das letzte Szenario soll der Mensch dem Roboter beim Entladen einer Palette assistieren.
990
Falls der Mensch nicht vom Roboter gerufen wird, soll dieser im Raum herumwandern.
991
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.
992
In diesem Fall soll er seine Arbeit unterbrechen, um auch diese Möglichkeit zu demonstrieren.
993
994
Ein solches Verhalten lässt sich mithilfe einer Fallback- mit untergeordneter ReactiveSequence-Node modellieren.
995
In der ReactiveSequence wird zuerst überprüft, ob der Mensch gerufen wurde.
996
Da dieser Zustand die ReactiveSequence abbrechen soll, wird die verantwortliche AmICalled-Node mit einer Inverter-Node versehen.
997
In der ReactiveSequence kann eine weitere Sequence nach der Inverter-Node angeordnet werden.
998
999
Diese Sequence-Node enthält den Teil des Baumes, der ausgeführt werden soll, solange der Mensch nicht gerufen wird.
1000
In diesem Fall wird mit einer WeightedRandom-Node eine von drei GenerateXYPose-Nodes ausgewählt.
1001
Diese geben jeweils Ziele in der sicheren Zone, Warnzone und Sicherheitszone zurück.
1002
Nach der WeightedRandom-Node wird eine ActorMovement-Node genutzt, welche den Mensch zu dem ausgewählten Ziel bewegt.
1003
1004
Neben der ReactiveSequence unter der Fallback-Node wird eine weitere Sequence angeordnet.
1005
Hier wird die gewünschte Aktionsfolge bei Ruf durch den Roboter definiert.
1006
In diesem Fall soll das Aufheben eines heruntergefallenen Objekts durchgeführt werden.
1007
Dazu wird zuerst ein Ziel in der Warnzone unter Zuhilfenahme einer GenerateXYPose-Node generiert.
1008
1009
Nach einer Bewegung zu diesem Ziel durch eine ActorMovement-Node wird ein Objekt aufgehoben.
1010
Dies geschieht durch vier ActorAnimation-Nodes, welche jeweils die Animationen ``standing_to_low'', ``low_inspect'', ``low_grab'' und ``low_to_standing'' ausführen.
1011
1012
Um das Objekt wieder abzulegen, wird eine Bewegung zum rechten Tisch des Roboters durch eine ActorMovement-Node ausgeführt.
1013
Auch hier wird zum Ablegen eine weitere Animationsfolge aus zwei ActorAnimation-Nodes genutzt.
1014
Dabei wird zuerst ``standing_extend_arm'' abgespielt, gefolgt von ``standing_retract_arm''.
1015
1016
Als letzte Aktion wird der Ruf nach dem Menschen durch eine SetCalledTo-Node auf false zurückgesetzt.
1017
Dieser Behavior Tree ist in Abbildung \ref{tree_actor_colab} dargestellt.
1018
1019
\begin{figure}
1020
\includegraphics[width=\textwidth]{img/MA-tree-actor-colab}
1021
\centering
1022
\caption{Behavior Tree des Menschen bei Kollaboration }
1023
\label{tree_actor_colab}
1024
\end{figure}
tex/3_Auswahl.tex
Found 196 warning(s)
1
\chapter{Komponenten-/Softwareauswahl}
2
Die Auswahl der verwendeten Softwarekomponenten beeinflusst den späteren Entwicklungsprozess nachhaltig.
3
4
Alle Komponenten sollen später in der entwickelten Softwareumgebung ihre jeweiligen Teilbereiche abdecken.
5
Alle diese Teilbereiche können dann zu einer Simulation verbunden werden, die das gesamte Problemfeld abdeckt.
6
7
Wie bereits in Abbildung \ref{concept_overview} dargestellt, ist für die Erfüllung der Aufgaben eine Dienst- und eine Simulationsumgebung erforderlich.
8
Dieses Kapitel beschreibt die Auswahl der Umgebungen und alle in den Umgebungen laufenden Prozesse.
9
\section{Dienstumgebung}
10
Die Dienstumgebung bestimmt maßgeblich, wie Software im Entwicklungsprozess geschrieben wird.
11
Durch sie werden häufig benötigte Funktionen bereitgestellt, die Programme innerhalb der Umgebung nutzen können.
12
13
Bei einer Dienstumgebung für Roboter gehört die Nachrichtenübergabe zwischen den einzelnen Programmen zu den grundlegenden Aspekten.
14
Diese wird genutzt, um eine gemeinsame Basis für ein erweiterbares System zu schaffen.
15
Außerdem sind Werkzeuge zur Parameterübergabe an Teilsysteme sinnvoll, um die Einstellungen an einer Stelle gesammelt anpassen zu können.
16
17
\subsection{Auswahl}
18
Es existieren mehrere Systeme, die als Dienstumgebung für Roboter infrage kommen, wenn man lediglich die Nachrichtenübergabe zwischen Programmen betrachtet.
19
Jede Dienstumgebung, die Nachrichten zwischen Prozessen austauschen kann, ist potenziell als ein Roboterframework einsetzbar.
20
21
Wichtige Aspekte sind dabei die Geschwindigkeit der Anbindung und die Definition der Nachrichten, die über das System ausgetauscht werden.
22
23
Nutzbare, bereits als Interprozesskommunikation integrierte Systeme sind zum Beispiel Pipes, die Daten zwischen Prozessen über Buffer austauschen.
24
Auch die Nutzung von Message Queues oder Shared Memory ist für diesen Einsatzzweck möglich.
25
Diese Systeme sind performant, jedoch schwerer zu verwalten.
26
Ein Problem dieser Methoden ist die direkte Kommunikation mehrerer Komponenten, da die Art der Kommunikation keine Modifikation von Nachrichten zur Anpassung an andere Szenarien vorsieht.
27
28
Eine Alternative stellen Sockets dar, die Daten zwischen mehreren Programmen austauschen können.
29
Dabei dient ein Programm als Server, der Anfragen von anderen Programmen, auch Clients genannt, entgegen nimmt.
30
Die Kommunikation zwischen Client und Server ist bidirektional möglich, was kompliziertere Protokolle ermöglicht.
31
32
Alle diese Lösungen besitzen einen gemeinsamen Nachteil in deren Nachrichtendefinition.
33
Dieser Nachteil besteht in der potenziellen Variabilität dieser Kommunikationsmechanismen.
34
Bei einem ausreichend großen Projekt treten so unweigerlich Unterschiede in der Handhabung von Nachrichten auf, die es zu berücksichtigen gilt.
35
Durch solche Unterschiede kann es zu Inkompatibilitäten zwischen Programmen kommen, was sich auf die universelle Nutzbarkeit der Programme negativ auswirkt.
36
37
Im Bereich der Robotik ist ROS \cite{doi:10.1126/scirobotics.abm6074}, bei dem es sich um ein quelloffenes System handelt, als Dienstumgebung etabliert.
38
Der oben genannte Nachteil einzelner Systeme wird in ROS durch mehrere standardisierte und erweiterbare Nachrichtendefinitionen gelöst, die von den Programmen in der Umgebung genutzt werden.
39
Um diese Nachrichten senden und empfangen zu können, liefert ROS bereits eine eigene Implementation des Protokolls für mehrere Programmiersprachen mit.
40
Zum Beispiel existieren für Python \cite{python}, C und C++ \cite{cpp} entsprechende Implementationen in Form der Pakete \code{rospy}, \code{rclc} und \code{rclcpp}.
41
42
Die neuste Version ROS2 bietet mehrere Verbesserungen im Vergleich zu früheren Version ROS1 \cite{changesRosII}.
43
Ein neues Nachrichtenformat mit Quality of Service kann beispielsweise Nachrichten zwischenspeichern und über sowohl TCP, als auch UDP kommunizieren.
44
Außerdem werden neben CMake \cite{cmake} auch andere Buildsysteme unterstützt, was die Verwendung von Python erlaubt.
45
46
Generell existieren im Feld der Roboter-Dienstumgebungen keine freien Alternativen mit ähnlichem Funktionsumfang und gleicher Reichweite.
47
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}.
48
49
ROS kann sowohl für simulierte Umgebungen als auch für echte Roboter eingesetzt werden.
50
Diese beiden Anwendungsfälle werden durch unterschiedliche Controller realisiert.
51
Für simulierte Umgebungen leitet der Controller die Steuerdaten an die Simulationsumgebung weiter.
52
Bei dem Einsatz echter Hardware werden die Zielpositionen durch den Controller an die Roboterhardware weitergeleitet.
53
54
55
56
57
58
59
\subsection{Beschreibung}
60
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}.
61
Hierbei ist ``operating system'' nicht in seiner herkömmlichen Bedeutung eines vollständigen Betriebssystems zu verstehen.
62
Es handelt sich dabei um eine gemeinsame Grundlage für Programme und Daten, die durch ROS bereitgestellt wird.
63
64
Einzelne Bestandteile in der Umgebung sind dabei in Pakete gegliedert, wobei jedes Paket beliebig viele Daten und Programme beinhalten kann.
65
Programme, die mit anderen Programmen in der Umgebung über die ROS internen Schnittstellen kommunizieren, werden in ROS ``Nodes'' genannt.
66
67
Zu den Aufgaben von ROS zählen folgende Teilbereiche:
68
\begin{description}
69
\item[Organisation]\hfill \\
70
Um die einzelnen Teile einer Roboterumgebung zu separieren, werden diese in ROS auf unterschiedliche Pakete aufgeteilt.
71
Jedes Paket enthält dabei eine \code{package.xml}-Datei.
72
In dieser befindet sich eine in XML verfasste Definition des Paketinhalts, die verschiedene Aspekte des Pakets beschreibt.
73
74
Darunter fallen Informationen über das Paket selbst, wie dessen Name, Beschreibung und Version.
75
Außerdem sind Name und Mailadresse des Autors, sowie die gewählte Lizenz des Codes vermerkt.
76
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.
77
78
\item[Buildumgebung]\hfill \\
79
ROS nutzt die eigene Buildumgebung \code{colcon} \cite{colcon}, um Pakete in den Workspaces reproduzierbar zu erstellen.
80
Zu deren Konfiguration wird eine \code{CMakeLists.txt}-Datei erstellt, die den Buildprozess beschreibt.
81
In dieser sind die Buildinstruktionen für den Compiler enthalten, mit welchen die im Paket befindlichen Programme kompiliert werden.
82
Der Aufruf des \code{ament_cmake}-Makros in dieser ergänzt den Kompiliervorgang um weitere Parameter aus der \code{package.xml}-Datei.
83
84
Nach diesen Vorbereitungsschritten kann CMake das Paket kompilieren.
85
Hierbei werden alle in der \code{CMakeLists.txt}-Datei angegebenen Programmteile kompiliert.
86
87
Es ist außerdem möglich, bestimmte Pfade des Pakets nach dem Buildvorgang zu exportieren.
88
Diese sind dann später im erstellten Workspace für die Nutzung durch andere Programme verfügbar.
89
90
\item[Workspaceverwaltung]\hfill \\
91
Gruppen von Paketen werden zur einfacheren Handhabung in sogenannten ``Workspaces'' zusammengefasst.
92
Diese vereinfachen das Auffinden der enthaltenen Pakete durch Skripte, die diese im System registrieren.
93
Die Erstellung der Skripte erfolgt anhand der bereits beschriebenen \code{CMakeLists.txt}-Datei.
94
Das Programm \code{colcon} analysiert diese und generiert die Skripte.
95
Um das Paket im System zu registrieren, muss der Nutzer die generierten Skripte ausführen, was die benötigten Umgebungsvariablen setzt.
96
Hierfür wird meist ein weiteres Skript verwendet, was alle im Workspace befindlichen Pakete nacheinander der Umgebung hinzufügt.
97
98
Dieser Vorgang erlaubt zum Beispiel das Auffinden von Paketen anhand deren Namen im Dateisystem.
99
Das erleichtert die Verwaltung durch die Unabhängigkeit von spezifischen Pfaden im entwickelten System.
100
Außerdem wird die Laufzeitumgebung für alle Programme konfiguriert, was definierte Bibliotheken für diese verfügbar macht.
101
102
\item[Abhängigkeitsverwaltung]\hfill \\
103
ROS kann durch die in den Paketen deklarierten Abhängigkeiten prüfen, ob diese in der aktuellen Umgebung ausführbar sind.
104
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.
105
106
\item[Datenübertragung]\hfill \\
107
Um Daten zwischen Nodes austauschen zu können, müssen die Nodes miteinander auf einem festgelegten Weg kommunizieren können.
108
Ein solcher Aufbau erlaubt den Austausch von Daten in vorher nicht durch die Entwickler bedachten Anwendungsfällen.
109
Die von ROS gebotene Schnittstelle zur Datenübertragung wird in Form mehrerer Bibliotheken für unterschiedliche Programmiersprachen bereitgestellt.
110
111
Der Datenaustausch geschieht in sogenannten Topics, die Nachrichtenkanäle zwischen den Nodes darstellen.
112
Eine Node kann entweder als Server ein Topic anbieten, was durch andere Nodes gelesen wird, oder als Client auf solche bereitgestellten Topics zugreifen.
113
Durch die Kombination mehrerer Topics ist eine komplexere Interaktion abbildbar, die zum Beispiel Rückgabewerte zum aktuell ausgeführten Steuerbefehl liefert.
114
115
\item[Parameterübergabe]\hfill \\
116
Um Nodes auf neue Anwendungsfälle anpassen zu können, wird ein Konfigurationsmechanismus benötigt.
117
In ROS geschieht dies durch die Übergabe sogenannter Parameter, die durch die Node gelesen werden können.
118
Diese eignen sich zur Übergabe von Informationen, wie zum Beispiel Daten über ein verwendetes Robotermodell.
119
Um neue Konfigurationen zu unterstützen, kann das Umbenennen von Topics einer Node notwendig werden, was auch mit einem Parameter erfolgen kann.
120
121
\item[Startverwaltung]\hfill \\
122
In sogenannten ``launch''-Files können verschiedene Nodes und andere ``launch''-Files zu komplexen Startvorgängen zusammengefasst werden.
123
Das Einstellen von bestimmten Parametern erlaubt die Anpassung der Funktionen an den gewünschten Anwendungsfall.
124
125
\end{description}
126
127
Eine solche Umgebung erlaubt die Zerlegung der geplanten Simulation in mehrere Komponenten.
128
Die daraus erfolgte Abgrenzung erhöht die Übersichtlichkeit der einzelnen Bestandteile.
129
Dies vereinfacht die spätere Wartung des Projekts.
130
131
\section{Simulationsumgebung}
132
133
\subsection{Auswahl}
134
Als Simulationsumgebung eignen sich verschiedenen Programme, die sich hinsichtlich ihres Funktionsumfangs stark unterscheiden.
135
Hierfür kommen beispielsweise dedizierte Werkzeuge zur Robotersimulation, aber auch universell einsetzbare Gameengines in Frage.
136
Ein Vergleich dieser Werkzeuge ist hierbei sinnvoll, da sich der gebotene Funktionsumfang der Softwares stark unterscheidet.
137
Auch andere Aspekte, wie Lizenzen oder die schwer bewertbare Nutzerfreundlichkeit, sind hierbei zu betrachten.
138
Eine Auswahl der als Simulationsumgebung in Frage kommenden Programme wird hier vorgestellt.
139
140
CoppeliaSim \cite{coppelia}, früher auch V-REP genannt, ist eine Robotersimulationsumgebung mit integriertem Editor und ROS-Unterstützung.
141
Es unterstützt viele Sprachen (C/C++, Python, Java, Lua, Matlab oder Octave) zur Entwicklung von Erweiterungen des Simulators.
142
Der Simulator selbst unterstützt menschliche Aktoren, diese können aber nur Animationen allein oder in Kombination mit einer Bewegung abspielen.
143
CoppeliaSim existiert in 3 Versionen, die sich hinsichtlich Funktionsumfang und Lizenz unterscheiden.
144
Jedoch besitzt nur die professionelle Version Zugriff auf alle Funktionen und Verwendungsszenarien.
145
146
Gazebo Ignition \cite{gazebo} ist wie CoppeliaSim eine Robotersimulationsumgebung, besitzt aber keinen integrierten Editor und direkte ROS-Unterstützung.
147
Gazebo setzt wie CoppeliaSim auf Erweiterungen, um zusätzliche Funktionen einbinden zu können.
148
So existiert zum Beispiel auch eine ROS-Brücke, die die Anbindung an ROS ermöglicht.
149
Auch hier unterstützt der Simulator nur Animationen für menschliche Aktoren.
150
Das Projekt ist Open Source, unter der Apache Lizenz (Version 2.0), was die Verwendung in jeglichen Szenarien erleichtert.
151
152
Unity \cite{unity} hingegen ist primär eine Grafikengine für die Nutzung in Computerspielen.
153
Es existieren mehrere Systeme zur Anbindung der Engine an ROS, vor allem das offizielle ``Robotics Simulation''-Paket und ZeroSim.
154
Beide Systeme erlauben die Erweiterung der Gameengine um die Simulation von Robotern.
155
Unity besitzt eine gute Dokumentation, die vor allem auf die Nutzung im Einsteigerbereich zurückzuführen ist.
156
Auch die Optionen zur Menschensimulation sind umfangreich, da diese häufig in Spielen verwendet werden.
157
Ein großer Nachteil hingegen ist die Lizenz, die nur für Einzelpersonen kostenfrei ist.
158
159
Die Unreal Engine \cite{unreal} ist wie Unity eine Grafikengine aus dem Spielebereich.
160
Auch hier ist die Menschensimulation aufgrund oben genannter Gründe gut möglich.
161
Jedoch existiert für Unreal Engine keine offizielle Lösung zur Anbindung an ROS2.
162
Die Programmierung der Engine erfolgt in C++, was die Erstellung eines Plugins zur ROS-Anbindung der Unreal Engine ermöglichte, die von Nutzern gewartet wird.
163
Die Lizenz der Unreal Engine erlaubt die kostenfreie Nutzung bis zu einem gewissen Umsatz mit der erstellten Software.
164
165
Eine weitere Möglichkeit zur Simulation stellt die Grafikengine Godot \cite{godot} dar.
166
Im Vergleich zu Unity und Unreal Engine ist Godot quelloffene Software unter der MIT-Lizenz.
167
Auch hier stellt die Simulation von menschlichen Aktoren eine Standardaufgabe dar, jedoch befinden sich Teile des dafür verwendeten Systems derzeit in Überarbeitung.
168
Auch für diese Engine existiert eine ROS2-Anbindung, jedoch ist diese nicht offiziell.
169
170
Alle vorgestellten Softwares besitzen ein integriertes Physiksystem, dass die Simulation von starren Körpern und Gelenken erlaubt.
171
Diese Funktionen erlauben den Aufbau eines Roboterarms, der durch eine ROS-Brücke gesteuert wird.
172
173
Um den Fokus dieser Arbeit auf die gestellte Aufgabe zu ermöglichen, ist die Auswahl einer Umgebung mit bereits existierender ROS-Unterstützung sinnvoll.
174
Durch diese Einschränkung scheiden sowohl Unreal Engine aber auch Godot aus.
175
Sie bieten zwar diese Funktionalität, jedoch werden sie nur durch Nutzer gewartet und sind demzufolge nicht offiziell unterstützt.
176
Für einen späteren Einsatz ist eine offene Lizenz von Vorteil, da diese einen Einsatz unter nahezu allen Umständen erlaubt.
177
178
Die Wahl der hier zu verwendenden Simulationsumgebung fiel deshalb auf Gazebo Ignition, welche gleichzeitig bereits im ROS-Ökosystem etabliert ist.
179
Dabei erlauben die offizielle ROS-Anbindung und die offene Lizenz eine zuverlässige Verwendung in unterschiedlichsten Szenarien.
180
\subsection{Welt- und Modellbeschreibung}
181
Gazebo nutzt das .sdf-Dateiformat, um die Simulationsumbebung zu beschreiben \cite{sdf-format}.
182
Dieses Format basiert auf XML und wird zur Definition gesamter Welten, aber auch einzelner Objekte innerhalb dieser Welten benutzt.
183
Eine Welt ist in Gazebo eine Umgebung aus mehreren Objekten, welche simuliert werden sollen.
184
Die Welt beschreibt außerdem die simulierte Physikumgebung und deren Konstanten, wie zum Beispiel die Gravitation.
185
186
Um verschiedene Versionen des Formats zu unterstützen, enthält das einzige sdf-Element die gewünschte Versionsnummer.
187
Eine solche Datei kann, wie bereits oben beschrieben, unterschiedliche Daten enthalten.
188
Im Falle eines Objekts ist dies eine einzige Instanz von entweder einem Modell, Actor oder Licht.
189
Andernfalls können in der Datei eine oder mehrere Welten definiert werden.
190
191
Eine Welt definiert in Gazebo den kompletten Aufbau des Simulators.
192
Zuerst enthält ein Welt-Element die Daten über die physikalischen Konstanten der Simulationsumgebung.
193
Zudem werden alle benötigten Teile der Nutzeroberfläche deklariert, die im ausgeführten Simulator verfügbar sein sollen.
194
Letztendlich ist die Definition mehrerer Modelle, Aktoren und Lichter in der Welt möglich.
195
Diese können auch aus anderen URIs stammen, die in der Welt deklariert wurden.
196
Dies erlaubt zum Beispiel das Laden von vorher definierten Objekten oder Objekten aus der offiziellen Bibliothek \cite{gazebo-app}.
197
198
Ein Modell enthält einen Roboter oder ein anderes physikalisches Objekt in der Simulation.
199
Die Deklaration eines weiteren Untermodells ist möglich, um komplexere Strukturen abbilden zu können.
200
Über ein include-Element können auch andere .sdf-Dateien, die nur ein einzelnes Modell enthalten, zu einem Modell hinzugefügt werden.
201
202
Jedes Modell wird über eine Translation und Rotation im Simulationsraum verankert.
203
Dies geschieht immer relativ zum Referenzsystem des überliegenden Modells.
204
Außerdem können im Modell Einstellungen für dessen Physiksimulation vorgenommen werden.
205
206
Ein Modell enthält meist mindestens ein Link-Element, dass zur Darstellung von dessen Geometrie verwendet wird.
207
Mehrere Link-Elemente können dabei mit der Welt oder anderen Link-Elementen über Joint-Elemente verbunden werden.
208
Diese Joint-Elemente können jedoch nicht von außerhalb gesteuert werden, was das Dateiformat ungeeignet für Roboterdefinitionen macht.
209
210
Lichter besitzen einen Lichttyp, der die Ausbreitung des Lichtes im Raum bestimmt.
211
Die erste Art ist direktionales Licht, dass parallel zur gewünschten Achse auftrifft.
212
Solche Lichter werden vor allem zur grundlegenden Raumausleuchtung genutzt.
213
Weiterhin sind Punktlichtquellen verfügbar, deren Licht von einer Position im Raum ausgeht.
214
Neben den Punklichtquellen existieren auch noch Spots, die nur einen gewissen Winkel ausleuchten.
215
216
Die Actor-Komponente wird für animierte Modelle in der Simulation eingesetzt.
217
Sie besteht aus einem Namen für das Modell, einer Skin, welche das Aussehen des Modells definiert und mehreren Animationen.
218
Diese können durch in einem Skript definierte Trajectories ausgeführt werden, was eine einfache, aber statische, Simulation des Menschen erlaubt.
219
220
Eine solche Befehlsfolge kann nicht von außerhalb der Simulation zur Laufzeit angepasst werden.
221
Diese Funktionalität wurde im Rahmen der Arbeit hinzugefügt.
222
223
\subsection{Robotersimulation}
224
Für die Robotersimulation wird ein Modell des Roboters benötigt, in dem dieser für die Simulationsumgebung beschrieben wird.
225
Gazebo und ROS nutzen hierfür .urdf-Dateien \cite{urdf-format}, die auf XML basieren.
226
In diesen werden die einzelnen Glieder des Roboterarms und die verbindenden Gelenke beschrieben.
227
228
Jedes Glied des Modells besitzt eine Masse, einen Masseschwerpunkt und eine Trägheitsmatrix für die Physiksimulation in Gazebo.
229
Außerdem werden Modelle für die visuelle Repräsentation des Roboters in Gazebo und die Kollisionserkennung in der Physiksimulation hinterlegt.
230
Für beide existieren einfache Modelle wie Zylinder, Boxen und Kugeln.
231
Da diese Formen nicht jeden Anwendungsfall abdecken und in der visuellen Repräsentation nicht ausreichen, können auch eigene Modelle hinterlegt werden.
232
Hierbei werden die Modelle für die Physiksimulation und das Aussehen des Roboters unterschieden.
233
234
Gelenke werden separat von den Gliedern definiert und verbinden jeweils zwei Glieder miteinander.
235
Durch das Aneinanderreihen von mehreren Gliedern und Gelenken ist die Beschreibung eines beliebigen Roboteraufbaus möglich.
236
Jedes Gelenk besitzt eine Position und Rotation im Raum.
237
Diese werden für die Berechnung der Effekte genutzt, die vom spezifischen Gelenktyp abhängen.
238
Aspekte wie Reibung und Dämpfung können auch hier für die Nutzung in der Physiksimulation beschrieben werden.
239
Folgende Typen von Gelenken können in urdf-Dateien genutzt werden:
240
\begin{description}
241
\item[freie Gelenke]
242
ermöglichen vollständige Bewegung in allen 6 Freiheitsgraden (Rotation und Translation). Sie stellen den normalen Zustand der Glieder zueinander dar.
243
\item[planare Gelenke]
244
erlauben Bewegungen senkrecht zur Achse des Gelenks. Sie werden zum Beispiel für Oberflächen eingesetzt, auf welchen Objekte gleiten sollen.
245
\item[feste Gelenke]
246
sperren alle 6 Freiheitsgrade und werden häufig zur Fixierung von Objekten in einer Szene genutzt.
247
\item[kontinuierliche Gelenke]
248
erlauben die beliebige Rotation um die Achse des Gelenks. Sie sind nur selten in rotierenden Gelenken mit Schleifkontakten oder anderen frei rotierbaren Übertragungsmechanismen zu finden.
249
\item[drehbare Gelenke]
250
verhalten sich wie kontinuierliche Gelenke, haben jedoch minimale und maximale Auslenkungen. Sie sind die häufigste Art von Gelenken in Roboterarmen.
251
\item[prismatische Gelenke]
252
ermöglichen die lineare Bewegung entlang der Achse des Gelenks. Sie werden zur Umsetzung von Linearaktuatoren in der Simulation verwendet.
253
\end{description}
254
\subsection{Menschensimulation}
255
Gazebo besitzt bereits ein simples Animationssystem für bewegliche Aktoren, dass auch für Menschen nutzbar ist.
256
Für diesen existiert bereits ein Modell mit mehreren Animationen, die allein abgespielt, oder an Bewegungen gekoppelt werden können.
257
Dadurch ist zum Beispiel eine Laufanimation realisierbar, die synchronisiert zu einer Bewegung abgespielt wird.
258
259
Dies setzt jedoch voraus, dass der gesamte Bewegungsablauf zum Simulationsstart bekannt ist.
260
Der Grund dafür ist auf die Definition der Pfade zurückzuführen, die Aktionen wie Bewegungen und Animationen auslösen.
261
Diese können nur als dem Actor untergeordnetes Element in der .sdf-Datei definiert werden, was Veränderungen zur Laufzeit ausschließt.
262
Durch diesen Umstand ist der damit realisierbare Simulationsumfang nicht ausreichend, um die gewünschten Szenarien abzubilden.
263
264
Um diese Einschränkung zu beheben, ist die Entwicklung eines eigenen Systems zum Bewegen und Animieren des Menschen unausweichlich.
265
Dieses System muss, wie im Konzept beschrieben, Steuerbefehle von außen empfangen, umsetzen und Feedback liefern können.
266
Dafür soll ein ROS Action-Server verwendet werden, der die Befehle entgegennimmt, unter konstantem Feedback ausführt und nach erfolgreicher Ausführung den Empfang des nächsten Befehls zulässt.
267
268
Ein solches System soll als Gazebo-Plugin einbindbar sein, um Modifikationen an der Simulationsumgebung selbst auszuschließen, die konstant weiter entwickelt wird.
269
Dies vereinfacht die Wartung, da bei Updates der Simulationsumgebung nicht die Menschensimulation an den neuen Code angepasst werden muss.
270
\section{Roboterumgebung}
271
MoveIt2 \cite{moveit-docs} ist das meist genutzte ROS2 Paket für die Bewegungsplanung von Robotern.
272
Deshalb existiert eine umfangreiche Dokumentation für die zahlreichen Komponenten, was die Entwicklung neuer Komponenten erleichtert.
273
Außerdem sind zahlreiche direkte Integrationen mit anderen ROS-Paketen verfügbar, was die Nutzung dieser zusammen mit MoveIt erlaubt.
274
Aufgrund dieser Eigenschaften ist MoveIt eine vorteilhafte Bewegungsplanungsumgebung für dieses Projekt.
275
276
MoveIt besteht aus mehreren Komponenten, die in ihrer Gesamtheit den Bereich der Bewegungsplanung abdecken.
277
Der Nutzer kann mit MoveIt auf verschiedenen Wegen Steuerbefehle für den Roboter absenden, die durch die Software umgesetzt werden.
278
279
Die erste Inbetriebnahme ist über das mitgelieferte RViz-Plugin und die demo-Launch-Files möglich.
280
Diese wurden mit dem mitgelieferten Setupassistenten für den Roboter generiert.
281
Durch die Ausführung dieser Demo startet RViz, eine Test- und Visualisierungsumgebung für ROS.
282
In der Demo können Roboterbewegungen unter Zuhilfenahme von Markierungen in RViz geplant und ausgeführt werden.
283
284
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.
285
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}.
286
287
Die direkte Nutzung der C++-API ist aktuell die einzige offizielle Möglichkeit, mit MoveIt2 direkt zu interagieren.
288
Dabei können sowohl die Planung und die Ausführung von Bewegungen ausgelöst aber auch Exklusionszonen eingerichtet werden.
289
Außerdem können Objekte virtuell mit dem Roboter verbunden werden, wodurch sich diese in RViz mit dem Roboter bewegen.
290
Natürlich können die Befehle auch direkt an die entsprechenden Topics gesendet werden, um einzelne Bereiche des Systems zu testen.
291
292
Um die durch den Setupassistenten generierten Informationen an MoveIt zu übergeben, wird intern ein RobotStatePublisher verwendet.
293
Dieser lädt alle Daten des Robotermodells und übergibt sie an andere Programme, die Roboterparameter zur Laufzeit anfordern, unter diesen auch MoveIt selbst.
294
295
Durch die vorher erwähnte C++-API erhält die MoveGroup die Informationen über die gewünschte Bewegung.
296
Dabei können auch bestimmte Einschränkungen des Arbeitsraums, spezielle Trajektorien oder Limitierungen der Gelenke in der Planung berücksichtigt werden.
297
298
Diese Daten können durch eine OccupancyMap ergänzt werden, welche die Bereiche beschreibt, die sich um den Roboter befinden.
299
Eine solche Erweiterung erlaubt die automatische Nutzung von Kollisionsvermeidung mit Objekten im Planungsbereich.
300
301
Die Planung der Bewegung wird durch einen der in MoveIt implementierten Solver realisiert, der durch die MoveGroup aufgerufen wird.
302
Um die generierte Bewegung umzusetzen, werden die gewünschten Gelenkpositionen als Abfolge an die \code{ros_control} Controller des Roboters weitergegeben.
303
304
Diese Abstraktion erlaubt die Nutzung von sowohl simulierten, aber auch echten Robotern.
305
Dazu werden für echte und simulierte Roboter unterschiedliche ros_control Controller verwendet.
306
Der Erfolg der gesamten Pipeline kann dabei durch einen Feedbackmechanismus überwacht werden.
307
308
Im Falle von Gazebo wird \code{ign_ros_control} genutzt, dass die benötigten \code{ros_control} Controller in die Simulation einbindet.
309
Diese können dann wie normale Controller von \code{ros_control} genutzt werden.
310
311
Der Ablauf der Bewegungsplanungspipeline von MoveIt ist im Anhang unter Abbildung \ref{moveitpipeline} visualisiert.
312
313
\section{Programmiersprache}
314
Als Programmiersprache kommen in ROS standardmäßig Python \cite{python} und C++ \cite{cpp} zum Einsatz.
315
Beide Sprachen sind in der Softwareentwicklung beliebt, unterscheiden sich jedoch stark im Funktionsumfang und im Entwicklungsprozess.
316
317
Python ist eine interpretierte Skriptsprache, die zu den hohen Programmiersprachen zählt.
318
Sie wird in ROS zum Beispiel in \code{.launch.py}-Dateien eingesetzt, die den Start von Diensten in der Umgebung verwalten.
319
Die Sprache kann aber auch für die Programmierung von Nodes innerhalb des ROS-Systems verwendet werden.
320
321
C++ hingegen ist eine kompilierte, statisch typisierte, maschinennahe Programmiersprache.
322
In ROS wird C++ für Code verwendet, der entweder häufig oder in zeitkritischen Szenarien ausgeführt wird.
323
Aus diesem Grund wird C++ in Nodes verwendet, die schnell auf große Datenmengen reagieren müssen.
324
325
Die Nutzung eines Kompilierers beschleunigt C++ deutlich im Vergleich zu Python, ist jedoch weniger geeignet für häufige Modifikation.
326
Dies ist vor allem in häufig geänderten Programmen ein Nachteil, die nach einer Änderung erneut kompiliert werden müssen.
327
Aus diesem Grund wird Python vor allem in .launch.py-Dateien verwendet, welche die Interaktion der anderen Programme in der Umgebung verwalten.
328
329
Um die gewünschten Funktionen für die Simulation umzusetzen ist die Verwendung der Programmiersprache C++ nahezu unumgänglich.
330
Zum Beispiel sind Gazebo-Plugins in C++ erstellt, was die Nutzung anderer Sprachen stark einschränkt.
331
332
Ein weiterer Grund für die Nutzung von C++ ist die hohe Geschwindigkeit, die bei einer hohen Anzahl von Simulationsschritten pro Sekunde benötigt wird.
333
Außerdem kann MoveIt2 derzeit nur mit C++ direkt gesteuert werden.
334
335
Die Verwendung von C++ für die zu entwickelnden Nodes erscheint deshalb aus oben genannten Gründen naheliegend.
336
In den Launch-Skripten wird jedoch Python verwendet werden, da hier die Vorteile einer Skriptsprache überwiegen.
337
338
\section{Behavior Trees}
339
Zur Verwaltung der Abläufe sollen Behavior Trees genutzt werden, die durch die Bibliothek \code{BehaviorTree.CPP} bereitgestellt werden.
340
Diese Bibliothek wurde in C++ geschrieben, und ist somit in ROS und dem geplanten Konzept integrierbar.
341
342
Es existieren viele Beispiele und eine gute Dokumentation über die erweiterten Funktionen der Bibliothek, die im Folgenden vorgestellt werden.
343
344
\begin{description}
345
\item[Asynchrone Nodes]
346
sind in \code{BehaviorTree.CPP} leichter umsetzbar, da diese in Form verschiedener Zustände der Nodes beim Konzept der Bibliothek mit bedacht wurden.
347
Dies resultiert in Nodes, die ohne spezielle Logik langanhaltende Aktionen ausführen können, ohne die Ausführung des Behavior Trees zu behindern.
348
\item[Reaktives Verhalten] ist ein neues Konzept, um die Handhabung von asynchronen Nodes zu vereinfachen.
349
Diese Strukturelemente erlauben die parallele Ausführung von mehreren Zweigen, die die aktuell ausgeführte Aktion beeinflussen können.
350
Darunter fällt die Modifizierung von Parametern der Aktionen, aber auch der vollständige Abbruch einer Aktion durch äußere Einflüsse.
351
\item[Das .xml-Format der Behavior Trees] ermöglicht einen Austausch des Verhaltens, ohne die unterliegenden Programme verändern zu müssen.
352
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.
353
\item[Plugins] können zum Start geladen werden, um weitere Nodes dem ausgeführten Programm hinzufügen zu können.
354
Dies vereinfacht die Erweiterung um neue Funktionen und das mehrfache Nutzen von Code.
355
\item[Das Blackboard] ist eine Interaktionsebene, die den Datenfluss zwischen den Nodes erlaubt.
356
In diesem System kann unter Verwendung einer Zeichenkette als Identifikator ein Wert in Form einer Referenz hinterlegt werden.
357
Sogenannte Ports erlauben Nodes, Daten aus dem Blackboard zu lesen und auf dieses zu schreiben.
358
\item[Integriertes Logging] erlaubt es, Zustandsänderungen im Behavior Tree zu visualisieren, aufzunehmen und wieder abzuspielen.
359
Dies erleichtert das häufig schwierige Debuggen von Zustandsmaschinen erheblich, da das Verhalten genau untersucht werden kann.
360
\end{description}
361
362
Behavior Trees werden bei Verwendung von \code{BehaviorTree.CPP} in Form von .xml-Dateien gespeichert.
363
Diese Dateien enthalten die Anordnung der Nodes selbst, aber auch weitere Konfigurationsmöglichkeiten in Form von Ein- und Ausgabeports.
364
365
Ports können verwendet werden, um Nodes generischer zu gestalten.
366
Durch veränderbare Parameter im später erstellten Tree können Nodes ohne Programmänderung verändert werden.
367
Falls die Nodes mit Bedacht erstellt wurden, kann so auf viele spezialisierte Nodes verzichtet werden.
368
Um dies zu ermöglichen, kann deren Funktion durch mehrere andere Nodes in einem Subtree mit Parametern abgebildet werden.
369
Diese in den Ports übertragenen Daten können sowohl aus einem String ausgelesen, aber auch aus dem sogenannten Blackboard entnommen werden.
370
371
Um die Übersetzung aus einem String zu ermöglichen, muss eine entsprechende Funktion implementiert werden, die einen String in den gewünschten Zieltyp übersetzt.
372
Viele primitive Datentypen, wie Ganzzahlen und Gleitkommazahlen, werden von Behavior Tree.Cpp bereits durch native Funktionen unterstützt.
373
374
Das Blackboard ist ein System, dass die Nutzung von Variablen als Parameter für Ports erlaubt.
375
Diese werden im Hintergrund als eine Referenz auf den eigentlichen Wert gespeichert.
376
Eine solche Funktion erlaubt das weitere Zerlegen von Vorgängen innerhalb des Behavior Trees.
377
Solche kleineren Nodes sind durch ihren limitierten Umfang universeller einsetzbar, da sie nur kleinere Teilprobleme betrachten, die zu komplexeren Strukturen zusammengesetzt werden können.
378
379
Um die dadurch wachsenden Strukturen besser überblicken zu können, lassen sich Gruppen von Nodes als sogenannte Subtrees abspeichern.
380
Diese bilden in ihrer Gesamtheit eine neue Node, die im Behavior Tree eingesetzt werden kann.
381
Um den Einsatz von Variablen innerhalb eines Subtrees zu ermöglichen, besitzt jeder Subtree ein separates Blackboard.
382
Dadurch kann auch ein Eingriff durch äußere Einflüsse verhindert werden.
383
384
Natürlich sollte es auch möglich sein, Variablen an solche Subtrees zu übergeben.
385
Diese können, wie auch bei normalen Nodes, als Parameter an den Subtree übergeben werden.
386
Die Bibliothek \code{BehaviorTree.CPP} verbindet dann diese Werte und erlaubt die Datenübergabe zum und vom Subtree.
387
388
\subsection{Asynchrone Nodes}
389
Da nicht jeder Prozess sofort vollständig durchgeführt werden kann, muss die Möglichkeit geschaffen werden, lang anhaltende Prozesse abzubilden.
390
Dies geschieht in \code{BehaviorTree.CPP} durch asynchrone Nodes.
391
392
Eine asynchrone Node besitzt neben den Zuständen SUCCESS und FAILURE einer normalen Node auch die beiden neuen Zustände RUNNING und IDLE.
393
Außerdem werden mehrere Funktionen definiert, die den Lebenszyklus der Node definieren.
394
395
Wird eine Node durch den Aufruf der \code{onStart}-Funktion gestartet, geht diese in einen der Zustände RUNNING, SUCCESS oder FAILURE über.
396
397
Der Zustand RUNNING steht dabei für eine Node, die sich noch in der Ausführung befindet.
398
Solange dieser Zustand anhält, wird die Node nicht noch ein weiteres Mal gestartet, sondern nur der Zustand in der neuen \code{onRunning}-Funktion abgefragt.
399
400
Der IDLE-Zustand ist ein besonderer Zustand, der nur durch eine vollständige Ausführung erreichbar ist.
401
Er wird von der Node angenommen, nachdem deren Ausführung durch SUCCESS oder FAILURE beendet wurde.
402
403
Im Falle eines Abbruchs, der durch andere Nodes im Baum ausgelöst werden könnte, muss die Ausführung der Node vorzeitig beendet werden können.
404
Dies geschieht mit der neuen \code{onHalted}-Funktion, welche ausgeführt wird, wenn die Ausführung der Node abgebrochen werden soll.
405
\subsection{Dateiformat}
406
Das in Behavior Tree.Cpp verwendete Dateiformat, um Behavior Trees zu erstellen, basiert auf XML.
407
Jedes Dokument beginnt dabei mit einem Root-Element, dass alle Behavior Trees und eine Referenz auf die ID des Hauptbaumes enthält.
408
Diese wird benötigt, da auch Unterbäume im selben Dokument deklariert und genutzt werden können, die aber sonst nicht vom Hauptbaum unterscheidbar sind.
409
410
Jeder Baum beginnt mit einem Behavior Tree-Element, das als Attribut die ID des Baumes besitzen muss.
411
Als untergeordnete Elemente des Baumes werden die Nodes entsprechend der gewünschten Baumstruktur angeordnet.
412
413
Als Beispiel wird der bereits im Konzept verwendete Behavior Tree (siehe Abbildung \ref{choice_tree_xml}) in die entsprechende XML-Repräsentation umgewandelt.
414
Dabei ist zu beachten, dass die Root-Node in der Datei nicht existiert, da diese nur den Eintrittspunkt in die Struktur darstellt.
415
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.
416
\begin{figure}[hpt]
417
\includegraphics[width=\textwidth]{img/MA-tree-demo}
418
\centering
419
\caption{Beispiel eines Behavior Trees}
420
\label{choice_tree_demo}
421
\end{figure}
422
\begin{figure}[hpt]
423
\begin{minted}[breaklines,frame=single,linenos]{xml}
424
<?xml version="1.0"?>
425
<root main_tree_to_execute="demoTree">
426
<Behavior Tree ID="actorTree">
427
<Sequence>
428
<Fallback>
429
<Action ID="IsDoorOpen"/>
430
<Action ID="OpenDoor"/>
431
<Action ID="BreakDoor"/>
432
</Fallback>
433
<CanWalkThrough/>
434
<WalkThrough/>
435
</Sequence>
436
</Behavior Tree>
437
</root>
438
\end{minted}
439
\caption{Beispiel eines Behavior Trees als .xml}
440
\label{choice_tree_xml}
441
\end{figure}
442
443
\section{Virtualisierungsumgebung}
444
445
Bei Virtualisierungsumgebungen wird zwischen virtuellen Maschinen und Containerumgebungen unterschieden.
446
447
Bei einer virtuellen Maschine (VM) werden alle Komponenten der Maschine simuliert, was die Nutzung anderer Betriebssysteme ermöglicht.
448
Dies beinhaltet auch die Abstraktion von Speichermedien und anderen Geräten.
449
Eine virtualisierte Umgebung erzeugt kleine Performanceverluste durch die Abstraktion.
450
451
Eine Containerumgebung nutzt den Kernel des Hostsystems mit, was die Virtualisierung auf die Ebenen über dem Betriebssystem beschränkt.
452
Die auszuführende Umgebung muss also mit dem Systemkernel lauffähig sein, um in einem Container ausgeführt werden zu können.
453
Die Performanceverluste dieser Umgebung sind kleiner als die einer virtuellen Maschine, da grundlegende Teile des Systems nicht mehrfach ausgeführt werden müssen.
454
455
Da bereits eine Linux-Maschine zur Entwicklung vorhanden ist, wäre die Virtualisierung eines weiteren Linux-Kernels nur mit weiterem Performanceverlust verbunden.
456
Außerdem soll in der Virtualisierungsumgebung Grafikbeschleunigung genutzt werden, wozu in einer VM eine Grafikkarte an das Zielsystem durchgereicht wird, die dann von der VM exklusiv genutzt wird.
457
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.
458
459
Diese Punkte sprechen für die Nutzung einer Containerumgebung.
460
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.
461
462
Ein Container wird in Docker über sogenannte Build-Files definiert.
463
Das Build-File enthält exakte Instruktionen, wie der Container aus anderen Containern, Dateien oder einer Kombination beider erstellt werden kann.
464
Der so erstellte Container wird anhand dieser Definition durch den Host erstellt.
465
Um diesen Prozess weiter zu beschleunigen, ist auch der Einsatz eines Buildservers möglich, der benötigte Container als Download bereitstellt.
466
467
Jeder Container enthält ein eigenes Dateisystem, das aus dem im Buildfile definierten Dateien und einem Overlay besteht.
468
In diesem Overlay werden temporär Änderungen gespeichert, die am Container während dessen Laufzeit vorgenommen werden.
469
Sofern nicht definiert, werden diese Änderungen beim Neustart des Containers wieder entfernt.
470
471
Um dies zu vermeiden, kann entweder ein Volume, eine Art virtuelles Laufwerk in einem Systemverzeichnis des Hostsystems, oder ein ``bind mount'' eingerichtet werden.
472
Ein ``bind mount'' ist eine direkte Verbindung zu einem Ort des Host-Dateisystems, dass in den Container hereingereicht wird.
473
474
Docker-Compose stellt eine Erweiterung von Docker dar.
475
Diese Erweiterung verwaltet die Inbetriebnahme der Container über ein spezielles Dateiformat.
476
Eine solche Funktion erlaubt das wiederholte Einrichten von Containern mit gleichen Parametern.
477
In dieser Datei werden weitere Optionen angegeben, die in die Umgebung des laufenden Containers eingreifen.
478
Dazu gehört zum Beispiel das automatisierte Übergeben von Umgebungsvariablen, Einrichten von Netzwerkumgebungen und Erstellen von Volumes und ``bind mounts''.
479
480
Diese Automatisierung erleichtert die initiale Einrichtung eines Containers auf einem neuen System, da alle benötigten Aspekte leicht angepasst werden können.
tex/5_Evaluation_und_Diskussion.tex
Found 92 warning(s)
1
\chapter{Evaluation und Diskussion}
2
3
\section{Grundlagen}
4
5
\subsubsection{Auswahl einer geeigneten Umgebung}
6
Die Auswahl einer geeigneten Umgebung für die gewünschte Simulation erfolgte in mehreren Auswahlschritten.
7
Hierfür wurden mehrere Komponenten einzeln verglichen und ausgewählt.
8
Folgende Komponenten wurden für die Umgebung ausgewählt:
9
\begin{itemize}
10
\item ROS2 als Dienstumgebung,
11
\item Gazebo Ignition als Simulationssoftware und
12
\item BehaviorTree.CPP als Beschreibungssprache.
13
\end{itemize}
14
15
Alle Komponenten können prinzipiell miteinander kommunizieren, was den Aufbau einer Simulationsumgebung erlaubt.
16
17
\subsubsection{Nutzung der Virtualisierungsumgebung}
18
Die auf Docker basierende Virtualisierungsumgebung stellt eine vollständige ROS2-Installation dar.
19
In dieser Umgebung sind alle für die Arbeit benötigten Pakete enthalten.
20
Der Start der Umgebung erfolgt über das im Projektverzeichnis befindliche \code{start.sh}-Shellskript.
21
Dieses Skript wird ohne Parameter ausgeführt.
22
23
Beim ersten Start der Umgebung wird automatisch eine neue Containervorlage erstellt.
24
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.
25
Während der Nutzung der Umgebung muss das Terminal weiter geöffnet bleiben.
26
Nach dem Senden eines Terminiersignals durch das Schließen des Terminals oder die Tastenkombination \code{Ctrl+C} wird die Containerumgebung beendet.
27
28
\begin{figure}
29
\includegraphics[width=\textwidth]{img/MA-Docker-Started}
30
\centering
31
\caption{Konsole mit gestarteter Virtualisierungsumgebung}
32
\label{console-docker-started}
33
\end{figure}
34
35
Die Verbindung in die ROS-Umgebung erfolgt über SSH in einer separaten Konsole.
36
Eine SSH-Verbindung wird mit dem Befehl \code{ssh ros@localhost -p 2222} aufgebaut.
37
In dieser Session kann die Hardwarebeschleunigung des Hostsystems automatisch genutzt werden.
38
Dies wurde in Abbildung \ref{console-docker-passthrough} durch die Ausführung von \code{glxgears}, einer OpenGL-Anwendung zum Testen der Grafikpipeline, demonstriert.
39
40
Das entworfene Containersystem ist mit der bereitgestellten Funktionalität eine Grundlage für die weitere Implementation.
41
42
\begin{figure}
43
\includegraphics[width=\textwidth]{img/MA-Docker-Passthrough}
44
\centering
45
\caption{Konsole in der virtuellen Umgebung mit Grafiktests}
46
\label{console-docker-passthrough}
47
\end{figure}
48
49
\subsubsection{Erstellung der benötigten Modelle}
50
Für den simulierten Menschen und Roboter werden verschiedene Modelle benötigt.
51
Das Robotermodell wurde aus Herstellerdaten exportiert und in Blender nachbearbeitet.
52
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.
53
54
Für das Modell des Menschen wurde eine bereits in Gazebo enthaltene Animation als Grundlage verwendet.
55
Das in dieser enthaltene Modell wurde angepasst, um das Erstellen weiterer Animationen zu vereinfachen.
56
Mithilfe dieses modifizierten Modells wurden dann die benötigten Animationen erstellt.
57
58
\subsubsection{Steuerung des Menschen}
59
60
Durch den Start der Simulation wird selbstständig das erstellte ActorPlugin geladen.
61
Der Start des für diese Arbeit implementierten ActorServers erfolgt zeitgleich, um die Anbindung an ROS zu gewährleisten.
62
Beide Anwendungen zusammen erlauben das Ausführen von Bewegungen und Animationen während der Laufzeit der Simulation.
63
64
Alle für die Simulation des Menschen erstellten Animationen werden automatisch geladen, sobald diese durch das Plugin verwendet werden.
65
Dies kann durch die erstellten BehaviorTree-Nodes erfolgen, aber auch durch das Verwenden von Terminalbefehlen zu Testzwecken.
66
67
68
\subsubsection{Definition von Verhalten mit einer Beschreibungssprache}
69
70
Die Definition von verschiedenen Verhaltensweisen über eine Beschreibungssprache wurde durch die Erstellung neuer Nodes für einen Behavior Tree erreicht.
71
Für die Bewegung und Animation des Menschen sind die Nodes ActorMovement und ActorAnimation verfügbar.
72
Die Steuerung des Roboters erfolgt durch die RobotMove- und SetRobotVelocity-Node.
73
Beide Nodes zur Kontrolle des Roboters starten eine neue Bewegung mit den neuen Parametern.
74
Im Falle einer laufenden Bewegung wird diese vorher gestoppt.
75
76
Um Bewegungen in Zonen zu ermöglichen, kann die GenerateXYPose-Node zufällige Positionen in einer Zone generieren.
77
Die InAreaTest-Node erlaubt eine Auskunft über die Position von Objekten.
78
Eine Redefinition von bestehenden Parametern der generierten Pose ist über die OffsetPose-Node möglich.
79
80
Eine Wiederaufnahme von unvollendeten Aktionen ist durch die implementierte Interruptable\-Sequence-Node möglich.
81
82
Die Entscheidung über die Ausführung einer von mehreren möglichen Aktionen wird mit der WeightedRandom-Node realisiert.
83
Um Fehler simulieren zu können, ist der Abbruch von Aktionen nötig.
84
Dies wird durch die RandomFailure-Node erreicht.
85
86
Eine Kombination dieser neu implementieren und den bereits in BehaviorTree.CPP verfügbaren Nodes kann alle in den Szenarien benötigten Verhaltensweisen darstellen.
87
88
\subsection{Erstellen der benötigten Pakete}
89
90
Alle benötigten Pakete müssen vor der ersten Ausführung der Simulation kompiliert werden.
91
Dies wird durch das Ausführen des \code{build.sh}-Skripts im Verzeichnis \code{\textasciitilde/workspace} des Containers ausgelöst.
92
Nach diesem Vorgang muss der Workspace neu geladen werden, damit die jetzt verfügbaren Pakete registriert werden.
93
94
Die kann sowohl durch einen erneuten Aufbau der SSH-Verbindung erfolgen, da bei Start der Session die entsprechende Datei geladen wird, oder manuell geschehen.
95
Für das manuelle Laden des Workspaces muss der Befehl \code{source /home/ros/workspace/install/setup.bash} in der Konsole ausgeführt werden.
96
97
Nach dem Laden des Workspaces ist die Umgebung für die Simulation einsatzbereit.
98
99
\section{Simulation der Szenarien}
100
Das Starten der Simulation erfolgt über ein Skript innerhalb des \code{ign_world}-Pakets.
101
Dieses Skript wird durch den Befehl \code{ros2 launch ign_world gazebo_controller_launch.py} ausgeführt.
102
In diesem Skript werden alle für die Simulation benötigten ROS2-Nodes gestartet und konfiguriert.
103
104
Durch die Verwendung des optionalen Parameters \code{scene} kann das gewünschte Szenario ausgewählt werden.
105
Dieser muss in folgendem Format verwendet werden:
106
\code{ros2 launch ign_world gazebo_controller_launch.py scene:=[Coex|Coop|Colab]}.
107
Als Standard wird die Option \code{Coex} genutzt, falls der \code{scene}-Parameter nicht spezifiziert wird.
108
109
Nach dem Start der Simulationsumgebung ist der Raum vollständig geladen und einsatzbereit (Abbildung \ref{sim-room}).
110
Der Roboter befindet sich nach dem Start in der Ausgangsposition, siehe Abbildung \ref{robot-still}.
111
112
\begin{figure}
113
\begin{minipage}{.45\textwidth}
114
\includegraphics[width=\textwidth]{img/MA-Sim-Room}
115
\centering
116
\caption{Raum in der Simulation}
117
\label{sim-room}
118
\end{minipage}
119
\hspace{.09\textwidth}
120
\begin{minipage}{.45\textwidth}
121
\includegraphics[width=\textwidth]{img/MA-Sim-Robot-Still}
122
\centering
123
\caption{Roboterarm in Ausagangslage}
124
\label{robot-still}
125
\end{minipage}
126
\end{figure}
127
128
Alle beschriebenen Szenarien sind mit Ausnahme des Fließbandes aus dem Kooperationsszenario als Behavior Trees umgesetzt.
129
Diese werden nach dem Start einer Simulation ausgeführt und definieren das Verhalten von Roboter und Mensch.
130
131
\subsubsection{Koexistenzszenario}
132
133
Im Koexistenzszenario interagieren Roboter und Mensch nur im Ausnahmefall.
134
Der Roboter simuliert einen Entladevorgang, bei welchem Objekte vom linken Tisch auf den rechten Tisch bewegt werden (Abbildung \ref{coex-move}).
135
Die für diesen Zweck implementierten Bewegungsnodes werden in späteren Szenarien weiter verwendet.
136
Um den Menschen nicht zu gefährden, wird die Verfahrgeschwindigkeit automatisch an die Aufenthaltszone des Menschen angepasst.
137
138
Der Arbeitsvorgang des Menschen besteht aus dem Arbeiten an einer Werkbank und dem Verbringen von Material in das Regal (Abbildung \ref{coex-shelf}).
139
In diesem Szenario begibt sich der Mensch nur mit einer Wahrscheinlichkeit von 5\% nach jedem Arbeitsvorgang zum Roboter.
140
141
\begin{figure}
142
\begin{minipage}{.45\textwidth}
143
\includegraphics[width=\textwidth]{img/MA-Sim-Robot-Move}
144
\centering
145
\caption{Roboter in Bewegung}
146
\label{coex-move}
147
\end{minipage}
148
\hspace{.09\textwidth}
149
\begin{minipage}{.45\textwidth}
150
\includegraphics[width=\textwidth]{img/MA-Sim-Human-Shelf}
151
\centering
152
\caption{Mensch am Regal}
153
\label{coex-shelf}
154
\end{minipage}
155
\end{figure}
156
157
\subsubsection{Kooperationsszenario}
158
159
Eine Ausweitung der Interaktion erfolgt im Kooperationsszenario.
160
In diesem werden durch den Roboter Objekte entweder weitergereicht oder aussortiert.
161
Nach jedem aussortierten Objekt wird der Mensch gerufen.
162
Der Mensch holt die aussortierten Objekte nach dem Erledigen seiner aktuellen Aufgabe ab.
163
Diese Interaktion und das in diesem Szenario hinzugefügte Fließband sind in Abbildung \ref{coop-human} dargestellt.
164
165
\begin{figure}
166
\includegraphics[width=\textwidth]{img/MA-Sim-Human-Coop}
167
\centering
168
\caption{Mensch am Tisch des Roboters mit Förderband}
169
\label{coop-human}
170
\end{figure}
171
172
\subsubsection{Kollaborationsszenario}
173
174
Für das Kollaborationsszenario durchschreitet der Mensch den Raum, was die Kontrolle mehrerer Systeme simuliert.
175
Der Roboter bewegt in diesem Szenario Objekte vom linken auf den rechten Tisch, wobei Fehler auftreten können.
176
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}).
177
Der Roboter bricht den fehlgeschlagenen Vorgang ab und setzt die Arbeit mit dem nächsten Objekt fort.
178
179
\begin{figure}
180
\begin{minipage}{.45\textwidth}
181
\includegraphics[width=\textwidth]{img/MA-Sim-Human-Colab-Pickup}
182
\centering
183
\end{minipage}
184
\hspace{.09\textwidth}
185
\begin{minipage}{.45\textwidth}
186
\includegraphics[width=\textwidth]{img/MA-Sim-Human-Colab-Drop}
187
\centering
188
\end{minipage}
189
\caption{Mensch beim Aufhebevorgang}
190
\label{colab-drop}
191
\end{figure}
192
193
\section{Zusammenfassung}
194
Es wurden entsprechende Nodes für die Bewegung von Mensch und Roboter geschaffen.
195
Mit diesen Nodes wurden alle simulierten Szenarien in einer Beschreibungssprache abgebildet.
196
Die vollständige Kontrolle der Endeffektorposition des Roboters und der Bewegung des Menschen in der Simulation sind möglich.
197
198
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.
199
Einen Überblick über die dafür notwendigen Erweiterungen wird in Sektion \ref{objectsim} skizziert.
200
\section{Lessons Learned}
201
202
Während der Entwicklung des Projekts wurden zahlreiche Erkenntnisse gesammelt, welche die Entwicklung weiterer Projekte mit dieser Plattform erleichtern können.
203
204
\begin{description}
205
\item[Testen einzelner Komponenten]\hfill\\
206
Alle ROS-Nachrichtentypen sind mit Kommandozeilenbefehlen versend- und empfangbar.
207
Um einzelne Teilsysteme zu testen, können so deren Zustände gesetzt und überwacht werden.
208
\item[Überprüfung auf Updates]\hfill\\
209
Die regelmäßige Prüfung von verwendeten Bestandteilen auf Updates kann helfen, neue oder verbesserte Funktionen einzusetzen.
210
\item[Verwendung eines Debuggers]\hfill\\
211
Viele Nodes in ROS können über Kommandozeilenparameter im Debugmodus ausgeführt werden \cite{rosDebug}.
212
Da Programme wie Gazebo aber über weitere Launch-Files eingebunden werden, ist dies hier nicht möglich.
213
Eine Lösung ist in diesem Fall der separate Start der Gazebo-Umgebung in einem Debugger \cite{gazeboDebug}.
214
\end{description}
tex/6_Ausblick.tex
Found 17 warning(s)
1
\chapter{Ausblick}
2
\section{Umsetzung in anderem Simulator}
3
Die Umsetzung des gleichen Problems in einem anderen Simulator bietet die Möglichkeit, weitere Simulationsplattformen zu testen und miteinander zu vergleichen.
4
Hierbei ist vor allem die Anbindung an ROS interessant, welche mit Gazebo mit nur einem Plugin gleichzeitig funktioniert.
5
6
Eine verbesserte Anbindung an ROS würde die schnellere Entwicklung von Komponenten und Szenarien erlauben.
7
Da diese für viele andere Simulatoren erst geschaffen werden muss, kann von Anfang an der Fokus auf Erweiterbarkeit gelegt werden.
8
9
Je nach gewählter Umgebung ist es potenziell nötig, bestimmte Basisfunktionen neu zu implementieren, falls diese noch nicht unterstützt werden.
10
Moderne Gameengines sind für diesen Einsatzzweck geeignet, da diese viele Bestandteile einer Simulationsplattform bereits enthalten.
11
Außerdem ist die hohe Verfügbarkeit von Tutorials und Dokumentation für diese weitläufig eingesetzten Engines vorteilhaft.
12
13
Mitgelieferte Werkzeuge bekannter Engines wie Unity, Unreal Engine und Godot beinhalten ausgereifte Physik- und Animationssysteme.
14
Diese können für Roboterbewegungen und Menschensimulation verwendet werden.
15
16
\section{Simulation bewegter Objekte}\label{objectsim}
17
Die Simulation bewegter Objekte benötigt ein neues Gazebo-Plugin, welches mit den bereits entwickelten Komponenten der aktuellen Umgebung interagiert.
18
Um ein Objekt mit dem Roboter oder Menschen zu bewegen, muss dieses auf eine von zwei Arten bewegt werden.
19
20
Die Bewegung von Objekten mit dem Roboter ist möglich, da dieser mit der gegenwärtigen Implementation aus mehreren Physikobjekten besteht.
21
Das zu bewegende Objekt kann somit dem Objekt des Endeffektors als Unterobjekt hinzugefügt werden.
22
Der daraus resultierende Übergang in lokale Koordinaten kann potenzielle Umrechnung anhand der Transformationen vorhergehender Armteile erfordern.
23
24
Eine Bewegung mit dem Menschen erfordert vor allem bei Animationen einen anderen Mechanismus.
25
Da der Mensch nicht aus einzelnen Physikobjekten besteht, ist die Anbringung als Unterobjekt nicht möglich.
26
Stattdessen muss die aktuelle Position des Armes anhand der Animationsdaten verfolgt werden, um die Position des Objektes an diese anzupassen.
27
28
Die unterschiedliche Anbindung von Roboter und Mensch erfordert mehrere Implementationen, welche Zustandsdaten über das Objekt austauschen müssen.
29
Um die Objekte zu steuern, muss eine weitere ROS-Anbindung in einem entsprechenden Gazebo-Plugin erfolgen.
30
31
Dieses Plugin unterliegt denselben Limitierungen, die auch schon im ActorPlugin beachtet werden mussten.
32
Eine weitere Nachrichtenübergabe als Zwischenschritt vor dem eigentlichen ROS-Server ist so unausweichlich.
33
34
Dieser Kommunikationsmechanismus muss das Erstellen, Entfernen und Bewegen von Objekten zwischen Roboter, Umgebung und Mensch unterstützen.
35
\section{Erweiterung um Umgebungserkennung}
36
Eine Ergänzung von simulierten Tiefenkameras zur Umgebungserkennung stellt eine weitere mögliche Ausbaustufe des Projekts dar.
37
Mit den Kameras kann eine Tiefenkarte erstellt werden, um die Verfahrgeschwindigkeit des Roboters zu kontrollieren.
38
MoveIt implementiert für diesen Verwendungszweck bereits sogenannte Octomaps.
39
Diese Octomaps repräsentieren die Belegung eines Raums durch Objekte mit gleichseitigen Würfeln.
40
41
Der Einsatz dieser Octomaps zum Ausweichen von Hindernissen ist bereits in der Bewegungsplanung implementiert.
42
Für die Reduktion der Verfahrgeschwindigkeit muss der erwartete Raum mit dem aktuellen Raum verglichen werden.
43
Daraus kann die Distanz zu einem unerwarteten Objekt berechnet werden, um die Verfahrgeschwindigkeit dementsprechend anzupassen.
44
\section{Zusammenführung von ActorPlugin und ActorServer}
45
Die aktuelle, separate Implementation von ActorServer und ActorPlugin kann durch eine Vereinigung der Implementation verbessert werden.
46
Folgende Versuche wurden bereits durchgeführt, führten aber zu keinem Erfolg:
47
\begin{itemize}
48
\item{Die Ausführung in einem separaten Thread,}
49
\item{eine Trennung vom Hauptprogramm mittels Fork und}
50
\item{das Weglassen der Initialisierung von rclcpp, da diese später durch ign_ros2_control durchgeführt wird.}
51
\end{itemize}
52
53
\section{Migration auf die neuste ROS-Version}
54
Die neuste ROS-Version bietet keine expliziten Vorteile der Umgebung selbst, jedoch sind in dieser mehr Pakete verfügbar.
55
In der für das Projekt genutzten Umgebung befinden sich mehrere Pakete, die so auf eine neuere Version gebracht werden könnten.
56
Jedoch ist der Aufwand einer Migration nur schwer abschätzbar.
57
Dies führte zu der Entscheidung, diesen Prozess in dieser Arbeit nicht durchzuführen.
58
59
Ein Vorteil dieser Maßnahme ist die Möglichkeit, das Paket \code{gz_ros2_control} aus einer offiziellen Paketquelle zu beziehen.
60
Dieses Paket stellt das Gazebo-Plugin für den Roboter bereit und muss so nicht manuell auf dem neusten Stand gehalten werden.
61
62
\section{Verbesserung der Behavior Trees}
63
Eine weitere mögliche Verbesserung ist der Ausbau der Implementation der Behavior Trees.
64
65
Ein Update auf die neuste Version, die während der Entwicklung dieses Projektes erschienen ist, würde die verbesserte Nutzung von asynchronen Nodes erlauben.
66
Die Integration von Pre- und Post-Conditions erlaubt die Ausführung von Events vor und nach dem Ausführen einer Node.
67
Weitere universelle Node-Parameter vereinfachen den Aufbau von Bäumen durch die Vereinfachung von Schleifen und Bedingungen.
68
69
Ein Nachteil der Migration wäre jedoch das Wegfallen einiger Funktionen des Editors, welcher in dieser Version unter einer neuen Lizenz vertrieben wird.
70
Die Analyse von Logdateien nach der Ausführung und die Überwachung von Bäumen zur Laufzeit sind ohne kostenpflichtige Lizenz nicht mehr möglich.
71
72
Eine weitere Alternative ist die Nutzung von MoveIt Studio \cite{moveItStudio}, welches ebenfalls mit Behavior Trees arbeitet.
73
Die direkte Integration mit MoveIt vereinfacht die Anbindung an den Roboter, da wichtige Funktionen bereits implementiert sind.
74
Jedoch ist die Unterstützung für eigene Befehle nur schlecht dokumentiert.
75
Diese werden aber für die Steuerung des Menschen benötigt, was dieses Alternative nur für die Robotersteuerung attraktiv macht.
76
77
Die Anpassung der aktuellen Implementation für größere Projekte ist eine weitere Option.
78
Um die Übersichtlichkeit des Projekts zu erhöhen, werden häufig separate Module verwendet.
79
Diese können einzelne Funktionen bereitstellen, die separat von anderen Modulen agieren.
80
Alle Module müssen aktuell im Buildfile deklariert und mit in das Programm kompiliert werden.
81
Bei einer großen Anzahl an Modulen erschwert dieser Umstand die Übersicht über benötigte Module für spezifische Trees.
tex/2_Konzept.tex
Found 17 warning(s)
1
\chapter{Konzept}
2
Die zu entwickelnde Simulation soll die bisher meist separaten Zweige der Roboter- und Menschensimulation verbinden.
3
Um die beiden Akteure in der simulierten Umgebung zu steuern, werden Befehle von außerhalb der Simulation eingesetzt.
4
Diese Befehle werden dabei von externer Software unter der Verwendung einer Beschreibungssprache und Feedback aus der Simulation generiert.
5
6
Hierfür wird die Beschreibungssprache in der Dienstumgebung ausgeführt, in der auch die Bewegungsplanung stattfindet.
7
Die Beschreibungssprache kommuniziert direkt mit der Simulation und der Bewegungsplanung des simulierten Menschen.
8
Damit der Roboter in der Simulation von der Bewegungsplanung gesteuert werden kann, werden zwischen Simulation und Bewegungsplanung auch Nachrichten ausgetauscht.
9
Der gesamte Vorgang ist in Abbildung \ref{concept_overview} visualisiert.
10
11
Die zu erarbeitende Softwareumgebung soll einfach erweiterbar sein, um weitere Modifikationen und die Umsetzung anderer Projekte zuzulassen.
12
Hierzu zählt die Austauschbarkeit und Erweiterbarkeit von Komponenten wie der simulierten Welt, dem Roboter oder dem simulierten Mensch.
13
Um diese Möglichkeiten zu schaffen, sind die Systeme modular aufzubauen.
14
15
\begin{figure}
16
\includegraphics{img/MA-Konzept-Übersicht}
17
\centering
18
\caption{Visualisierung des Konzepts}
19
\label{concept_overview}
20
\end{figure}
21
22
\section{Simulation des Roboters}
23
Der simulierte Roboter soll für viele unterschiedliche Szenarien nutzbar sein, was spezialisierte Robotertypen ausschließt.
24
Außerdem ist die enge Interaktion mit Menschen gewünscht, was für einen auf Mensch-Roboter-Kollaboration ausgelegten Roboter spricht.
25
Für diese beschriebenen Kriterien eignet sich der KUKA LBR iisy, der als Cobot vermarktet wird.
26
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.
27
Der Roboter besitzt einen modifizierbaren Endeffektor, um unterschiedlichste Aufgaben erfüllen zu können.
28
29
Um den Kuka iisy in der Simulation verwenden zu können, muss ein Modell des Roboterarms erstellt werden.
30
Dieses Modell sollte die physikalischen Eigenschaften des Roboters möglichst genau abbilden.
31
Anhand dieses Modells kann der Roboter dann in der Simulation dargestellt werden und mit anderen Objekten interagieren.
32
33
\section{Simulation des Menschen}
34
Der Mensch soll in der Simulation typische Aufgaben erledigen und häufiges Verhalten abbilden können.
35
Hierzu sollen in der Simulationsumgebung mehrere Animationen verwendet werden, welche die aktuelle Tätigkeit darstellen.
36
Für komplexere Verhaltensweisen können Animationen und andere Aktionen, wie zum Beispiel eine Bewegung und Rotation kombiniert werden, um zum Beispiel die Aktion ``Laufen in eine bestimmte Richtung'' auszuführen.
37
38
Um diese Animationen erstellen zu können, wird zuerst ein animierbares Modell des Menschen benötigt.
39
Das zu erstellende Modell soll dabei um weitere Animationen erweiterbar sein.
40
Unterschiedliche Animationen gehen dabei meist von verschiedenen Ursprungszuständen aus.
41
Um zwischen diesen Ursprungszuständen wechseln zu können, werden weitere Animationen benötigt.
42
43
Die so erstellten Animationen müssen von außerhalb der Simulationsumgebung ausführbar gemacht werden.
44
Ein solcher Mechanismus erlaubt die spätere Steuerung der Animation durch die Beschreibungssprache.
45
Hierfür muss eine Komponente entwickelt werden, die in der Simulation die Anfragen der Beschreibungssprache entgegennimmt und umsetzt.
46
Um die spätere Steuerung des Menschen von außerhalb zu erleichtern, soll diese Komponente die Ausführung der Befehle überwachen.
47
Da mehrere Befehle nacheinander ausgeführt werden sollen, wird der aktuelle Fortschritt der Aktion zurückgemeldet.
48
Außerdem kann durch andere Komponenten in der Simulation der Abbruch einer Aktion des Menschen nötig werden.
49
Die Weitergabe eines Abbruchbefehls soll demzufolge auch über die geplante Komponente realisiert werden können.
50
51
\section{Behavior Trees als Beschreibungssprache}
52
Bislang wird das Verhalten von Akteuren in Simulationsumgebungen, darunter Roboter und Menschen, häufig in Form von State-Machines ausgedrückt.
53
Diese besitzen jedoch einen großen Nachteil, der vor allem bei komplexeren Abläufen hervortreten kann.
54
Dabei handelt es sich um die Übersichtlichkeit, die bei einer wachsenden State-Machine leicht verloren geht.
55
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.
56
57
Behavior Trees lösen dieses Problem, in dem sie sogenannte Nodes definieren, die in einer übersichtlichen Baumstruktur angeordnet werden.
58
Die einzelnen Nodes verändern dabei das System und lösen den Wechsel zu neuen Nodes aus.
59
60
Ursprünglich wurde das Konzept der Behavior Trees von Rodney Brooks entwickelt, der diese für mobile Roboter einsetzen wollte. \cite{1087032}
61
Das System setzte sich später jedoch zuerst in der Spieleindustrie, für die Beschreibung von menschlichem Verhalten, durch. \cite{isla2005handling}
62
63
Der Ablauf eines Behavior Trees startet vom sogenannten Root, der Wurzel des Baums.
64
Von dort an werden Nodes, die je nach Node unterschiedliches Verhalten abbilden, miteinander verbunden.
65
Die Nodes werden untereinander angeordnet, was die Relation der Nodes zueinander beschreibt.
66
Jede Node ist entweder direkt unter der Root-Node oder einer anderen Node angeordnet.
67
Außerdem kann jede Node eine beliebige Anzahl an untergeordneten Nodes besitzen.
68
Es gibt mehrere grundlegende Arten von Tree-Nodes, die in vier Kategorien unterschieden werden.
69
\begin{description}
70
\item[Aktions-Nodes]
71
beschreiben einzelne ausführbare Aktionen, die das System beeinflussen können.
72
Jede Aktion liefert dabei einen Rückgabewert über ihren Erfolg, der durch die darüber liegende Node ausgewertet werden kann.
73
\item[Dekorations-Nodes]
74
können den Rückgabewert einer anderen Node modifizieren.
75
Zumeist wird die Negation des Rückgabewerts verwendet, aber auch das Forcieren eines bestimmten Rückgabewertes ist möglich.
76
\item[Sequenz-Nodes]
77
beschreiben eine nacheinander ausgeführte Abfolge von darunter liegenden Nodes.
78
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.
79
Beim erfolgreichen Durchlauf gibt die Sequenz einen Erfolg zurück.
80
\item[Fallback-Nodes]
81
verhalten sich ähnlich wie Sequenz-Nodes, jedoch werden die darunter liegenden Nodes nacheinander ausgeführt, bis eine Node Erfolg zurückgibt.
82
In diesem Fall wird die Ausführung der Fallback-Node mit einem Erfolg abgebrochen.
83
Ein Fehler wird hier zurückgegeben, wenn alle Nodes ohne eine Erfolgsmeldung durchlaufen wurden.
84
\end{description}
85
86
\begin{figure}
87
\includegraphics[]{img/MA-tree-demo}
88
\centering
89
\caption{Beispiel eines BehaviorTrees}
90
\label{concept_tree_demo}
91
\end{figure}
92
93
Das in Abbildung \ref{concept_tree_demo} visualisierte Beispiel zeigt die Abfolge, um eine Tür zu öffnen und zu durchschreiten.
94
Die Ausführung des Baumes beginnt an der Root-Node, wobei die Zahlen über den Nodes die Reihenfolge der Rückgabewerte angeben.
95
96
Von dort aus wird als Erstes die Sequenz-Node ausgeführt, die drei untergeordnete Nodes besitzt.
97
Diese drei Nodes werden in Leserichtung, in diesem Falle von links nach rechts, ausgeführt.
98
99
Daraus resultierend wird zuerst die linke Fallback-Node, die ihrerseits untergeordnete Nodes besitzt, ausgeführt.
100
Da der Rückgabewert der Fallback-Node von den unter ihr befindlichen Nodes bestimmt wird, werden diese nacheinander ausgeführt.
101
102
Von diesem Punkt an beginnen die Rückgaben, die das weitere Verhalten beeinflussen.
103
Folgender Kontrollfluss findet in diesem Beispiel statt:
104
105
\begin{enumerate}
106
\item{
107
In dieser Node wird geprüft, ob die Tür bereits offen ist.
108
Da die Tür nicht offen ist, wird ein Misserfolg zurückgemeldet.
109
}
110
\item{
111
Dieses Ergebnis löst die Ausführung der nächsten untergeordneten Node der Fallback-Node aus.
112
Die so ausgewählte Node soll die Tür öffnen.
113
Der Versuch gelingt und der Erfolg wird an die Fallback-Node übergeben.
114
}
115
\item{
116
Da die untergeordnete Node eine erfolgreiche Ausführung meldet, wird die Ausführung der Fallback-Node mit einem erfolgreichen Rückgabewert beendet.
117
Aus diesem Grund wird die Node ``Tür eintreten'' nicht mehr ausgeführt.
118
}
119
\item{
120
Dadurch wird die nächste Node in der Sequenz ausgeführt, die prüft, ob die Tür durchlaufen werden kann.
121
Da dies nicht möglich ist, da die Tür zwar offen, aber durch dahinter liegende Gegenstände blockiert ist, wird ein Misserfolg gemeldet.
122
}
123
\item{
124
Der gemeldete Misserfolg der untergeordneten Node bricht die Ausführung der Sequenz mit einem negativen Rückgabewert ab.
125
}
126
\end{enumerate}
127
128
Dieser Ablauf würde nun von neuem beginnen, da die Root-Node ihre untergeordnete Node ohne Berücksichtigung des Rückgabewertes neu startet.
129
130
Durch die Definition neuer Nodes und einer anderen Baumstruktur lassen sich neue Verhalten implementieren.
131
Dies erlaubt die schnelle Anpassung des Verhaltens der gesteuerten Systeme.
132
133
In dieser Arbeit sollen deshalb BehaviorTrees für die Steuerung von Mensch und Roboter verwendet werden.
134
Die hierfür erstellten Nodes sollen universell gestaltet werden, um alle Szenarien, die in dieser Arbeit betrachtet werden, abzudecken.
135
136
\section{Virtualisierungsumgebung als Plattform}
137
Der Einsatz fest definierter Prozesse in einer stabilen Umgebung ist unerlässlich, um Fehler durch die unvollständige Einrichtung der Umgebung zu vermeiden.
138
Dies kann durch den Einsatz einer Virtualisierungsumgebung geschehen, in der das zu entwerfende System ausgeführt wird.
139
140
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.
141
Eine solche Struktur erhöht die Zuverlässigkeit der Umgebung, da die Änderungen an der Umgebung auf alle ausführenden Systeme gespiegelt werden.
142
143
Ein weiterer Vorteil ist die beschleunigte Entwicklung, weil Änderungen nicht mehr an einzelne Zielsysteme angepasst werden müssen.
144
Hinzu kommt die einfachere Inbetriebnahme eines bereits entwickelten Systems, da keine Anpassungen am Hostsystem vorgenommen werden müssen.
145
146
Natürlich existieren auch Nachteile der Virtualisierung, die mit den Vorteilen abgewogen werden müssen.
147
Alle Virtualisierungssysteme benötigen zusätzliche Rechenleistung, die dann der virtualisierten Anwendung nicht mehr zur Verfügung steht.
148
Außerdem muss bei grafischen Systemen die Darstellung der relevanten grafischen Daten auf dem Hostsystem berücksichtigt werden.
149
150
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.
151
Dies erlaubt zum Beispiel unabhängige, dedizierte Versionen der Softwarekomponenten und die Möglichkeit isolierter Upgrades dieser Komponenten.
152
Eine solche Plattform sorgt somit für die Reproduzierbarkeit der Ergebnisse auf verschiedenen Systemen.
main.tex
Found 12 warning(s)
1
\documentclass[paper=a4,
2
ngerman,
3
captions=tableabove,
4
fontsize=11pt,
5
numbers=noenddot,
6
parskip=half,
7
]{scrreprt}
8
\usepackage[ngerman]{babel}
9
\usepackage[T1]{fontenc}
10
\usepackage{lmodern}
11
\usepackage[newfloat=true]{minted}
12
\usepackage{csquotes}
13
\usepackage[includehead, includefoot, left=3.0cm, right=2.5cm, top=1.5cm, bottom=1.5cm]{geometry}
14
\usepackage{acro}
15
\usepackage[style=numeric,backend=biber,sorting=none]{biblatex}
16
\usepackage{notoccite}
17
\usepackage{pdfpages}
18
\usepackage{xcolor}
19
\usepackage{enumitem}
20
\usepackage[onehalfspacing]{setspace}
21
\usepackage{hyperref}
22
\usepackage{tabularray}
23
\usepackage{xurl}
24
\usepackage{soul}
25
\usepackage{xcolor}
26
\usepackage{subcaption}
27
\usepackage[strings]{underscore}
28
29
\usepackage[letterspace=150]{microtype}
30
31
\usepackage[page]{totalcount}
32
\usepackage[automark,headsepline=.4pt,plainheadsepline]{scrlayer-scrpage}
33
34
35
\newcommand{\source}[1]{\caption*{Quelle: {#1}} }
36
37
\clearpairofpagestyles
38
\renewcommand*{\chaptermarkformat}{
39
\chaptername~\thechapter\autodot\quad-\quad
40
}
41
\definecolor{light-gray}{gray}{0.95}
42
43
\newcommand{\code}[1]{
44
\begingroup
45
\sethlcolor{light-gray}
46
\hl{\texttt{#1}}
47
\endgroup
48
}
49
50
\ihead*{\rightmark}
51
\ohead*{\thepage}
52
\setkomafont{pageheadfoot}{\normalfont}
53
54
\pagestyle{scrheadings}
55
56
\pdfminorversion=7
57
58
\addbibresource{main.bib}
59
60
61
\title{}
62
\subtitle{mechatronisches Forschungsprojekt}
63
\author{Bastian Maximilian Hofmann}
64
65
66
\DeclareAcronym{ros}{
67
short=ROS,
68
long=Robot Operating System,
69
}
70
\DeclareAcronym{fsm}{
71
short=FSM,
72
long=Finite-State-Machine,
73
}
74
\DeclareAcronym{mrk}{
75
short=MRK,
76
long=Mensch-Roboter-Kollaboration,
77
}
78
79
\begin{document}
80
81
\setcounter{page}{1}
82
\pagenumbering{Roman}
83
84
\begin{titlepage}
85
86
\includepdf[pages=-]{tex/Deckblatt.pdf}
87
88
\end{titlepage}
89
90
\tableofcontents
91
\listoffigures
92
93
\includepdf[pages=-]{tex/Aufgabenstellung.pdf}
94
95
\setcounter{page}{1}
96
\pagenumbering{arabic}
97
98
\input{tex/1_Einleitung.tex}
99
\input{tex/2_Konzept.tex}
100
\input{tex/3_Auswahl.tex}
101
\input{tex/4_Umsetzung.tex}
102
\input{tex/5_Evaluation_und_Diskussion.tex}
103
\input{tex/6_Ausblick.tex}
104
105
\printbibliography
106
\newpage
107
\markboth{Anhang}{Anhang}
108
\begin{figure}[ht]
109
\includegraphics[width=14cm]{img/moveit_pipeline}
110
\caption{Visualisierung der MoveIt Pipeline}
111
\source{\cite{moveitpipeline}}
112
\label{moveitpipeline}
113
\end{figure}
114
115
\end{document}
tex/1_Einleitung.tex
Found 7 warning(s)
1
\chapter{Einleitung}
2
\section{Motivation}
3
Die Simulation von Maschinen wird im industriellen Umfeld immer beliebter, um deren Verhalten schon vor der eigentlichen Produktion zu testen.
4
Dazu wird ein Modell des gesamten Prozesses in der Simulation geschaffen, der durch die Maschine beeinflusst werden soll.
5
Das Modell wird um die Maschine selbst erweitert, die Einfluss auf das System nimmt.
6
Die Veränderungen durch die Maschine werden analysiert, und erlauben Rückschlüsse auf die Funktion des Systems.
7
Ein solches Modell kann für die Erkennung von Fehlverhalten und Problemen schon weit vor der eigentlichen Inbetriebnahme der Maschine genutzt werden.
8
9
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.
10
11
Im wachsenden Feld der Mensch-Roboter-Kollaboration existieren bereits einige Lösungen, um auch die namensgebende Interaktion von Mensch und Roboter zu simulieren.
12
Eine häufige Einschränkung der Simulatoren ist dabei, dass der Bewegungsablauf in der Simulation bereits vor deren Ausführung fest definiert werden muss.
13
Dies erlaubt lediglich die Reproduktion des geplanten Bewegungsablaufes, aber nicht dessen Variation im Prozess, ausgelöst durch Ereignisse in der Simulation.
14
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.
15
16
Diese Steuerung soll durch eine eingängige Beschreibungssprache erfolgen, die einfach erweitert und auf neue Szenarien angepasst werden kann.
17
Um die Funktionalität zu demonstrieren, sind 3 unterschiedliche Testszenarien in der Simulationsumgebung abzubilden.
18
Diese sollen durch verschiedene Aufgaben unterschiedliche Interaktionsgrade zwischen Mensch und Roboter simulieren.
19
20
\section{Stand der Wissenschaft}
21
Aktuelle wissenschaftliche Arbeiten befassen sich mit vielen unterschiedlichen Teilaspekten der Simulation eines Mensch-Roboter-Kollaborationsszenarios.
22
23
Die Planung von unterschiedlichen Reaktionen von Roboter auf den Menschen in verschiedenen Interaktionsszenarien stellt eine Grundlage für spätere
24
Projekte dar \cite{DOMBROWSKI2018134}.
25
Hierbei wird die erwünschte Interaktion betrachtet und aus den gewonnenen Daten werden Einschränkungen generiert.
26
Diese Einschränkungen können in der Interaktion verwendet werden, um zum Beispiel Verletzungen des Menschen durch den Roboter auszuschließen.
27
28
Ein anderer Weg der Kollisionsvermeidung ist die Planung der maximal zurücklegbaren Distanz eines Menschen aus seiner aktuellen Position \cite{ffdrobotsim}.
29
Dafür werden die maximalen Beschleunigungen einzelner Körperteile ermittelt, um diese während der Interaktion zu überwachen.
30
Sollte ein Mensch den Roboter erreichen können, muss dieser in der dafür benötigten Zeit stoppen können.
31
Dies sorgt für eine Geschwindigkeitsanpassung im Nahfeld, da hier schnellere Bewegungen möglich sind.
32
33
Es existieren auch zahlreiche Ansätze, die Bewegungs- und Interaktionsplanung eines Roboters mit Beschreibungssprachen abzudecken \cite{btintro}.
34
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.
35
36
In Computerspielen werden Beschreibungssprachen schon seit langer Zeit eingesetzt, um verschiedene Systeme, wie zum Beispiel die Steuerung von Nichtspielercharakteren, zu beschreiben \cite{halo2}.
37
38
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.
39
40
\section{Auswahl der Szenarien}
41
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.
42
Hierfür kommen bestimmte Aufgaben, wie zum Beispiel die Interaktion mit Objekten besonders infrage.
43
Diese besitzen viele ähnliche Bestandteile, die in mehreren Umständen nutzbar sind.
44
Das erlaubt den Einsatz von wenigen Animationen in vielen Szenarien.
45
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.
46
47
Das erste Szenario soll sich mit der Simulation einer bereits vollautomatisierten Fertigungsaufgabe befassen, in der ein Roboter im Arbeitsbereich eines Menschen Teile fertigt.
48
Die zu erwartende Interaktion beschränkt sich hierbei auf die Anpassung der Fahrgeschwindigkeit des Roboters bei Annäherung des Menschen, um Kollisionen zu vermeiden.
49
Der Mensch soll in diesem Szenario an einer anderen Aufgabe arbeiten.
50
Während dieser Arbeit betritt der Mensch vereinzelt den Arbeitsbereich des Roboters, was die entsprechende Reaktion des Roboters hervorrufen soll.
51
52
Dieses Szenario ist ein Beispiel für eine Koexistenz zwischen Roboter und Mensch, wo beide im selben Raum, jedoch an unterschiedlichen Aufgaben arbeiten.
53
Außerdem werden grundlegende Aspekte der Simulation getestet, wie zum Beispiel das Bewegen von Mensch und Roboter und die sicherheitsrelevante Aktion der Geschwindigkeitsanpassung.
54
55
Im zweiten Szenario prüft und sortiert der Roboter Teile und legt die fehlerfreien Exemplare auf einem Fließband zur Weiterverarbeitung ab.
56
Die Mängelexemplare werden hingegen in einer dafür vorgesehenen Zone abgelegt, von wo sie vom Menschen abtransportiert werden.
57
Auch hier soll der Mensch so lange eigenständig arbeiten, bis der Roboter ein aussortiertes Teil ablegt, das transportiert werden muss.
58
59
Die dritte simulierte Aufgabe stellt ein Kollaborationsszenario dar, in dem Mensch und Roboter an derselben Aufgabe arbeiten.
60
Hierbei soll der Roboter eine Palette entladen, wobei er nicht jedes Objekt ausreichend manipulieren kann.
61
Dies wird durch zufällige Fehler beim Aufheben, Transport und Ablegen der Objekte abgebildet.
62
In diesen Fällen muss ein Mensch aushelfen, wodurch er mit dem Roboter in Interaktion tritt.
63
Der Mensch soll, wenn seine Hilfe nicht benötigt wird, andere Roboter kontrollieren, was durch das Laufen im Raum abgebildet werden soll.
64
\section{Contributions}
65
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.
66
67
Dazu ist eine schnelle Adaption von sowohl Roboter als auch Mensch auf unterschiedliche Szenarien nötig.
68
Die Szenarien sollen dabei durch eine Beschreibungssprache definiert werden.
69
Durch deren Struktur soll komplexes Verhalten einfach und überschaubar abbildbar sein, dass dann in der Simulation getestet werden kann.
Output produced by TeXtidote v0.8.2, © 2018-2020 Sylvain Hallé - All rights reserved.
See the TeXtidote website for more information.