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.
1
\chapter{Komponenten-/Softwareauswahl}
2
Die Auswahl der verwendeten Softwarekomponenten beeinflusst den späteren Entwicklungsprozess nachhaltig.
@@ -1254,40 +1254,40 @@ h1.textidote {
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.
+
135
Hierfür kommen beispielsweise dedizierte Werkzeuge zur Robotersimulation, aber auch universell einsetzbare Gameengines infrage.
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.
+
138
Eine Auswahl der als Simulationsumgebung infrage 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.
+
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.
+
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.
+
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.
+
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.
+
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.
+
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.
+
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.
+
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.
@@ -1297,15 +1297,15 @@ h1.textidote {
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.
+
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}.
+
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.
+
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.
@@ -1314,12 +1314,12 @@ h1.textidote {
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.
+
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.
+
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.
@@ -1333,21 +1333,21 @@ h1.textidote {
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.
+
214
Neben den Punktlichtquellen 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.
+
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.
+
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.
+
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.
@@ -1358,8 +1358,8 @@ h1.textidote {
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}
+
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]
@@ -1367,12 +1367,12 @@ h1.textidote {
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.
+
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}
+
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.
@@ -1380,14 +1380,14 @@ h1.textidote {
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.
+
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.
+
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.
@@ -1398,29 +1398,29 @@ h1.textidote {
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.
+
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}.
+
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.
+
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.
+
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.
+
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.
+
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.
+
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.
@@ -1433,11 +1433,11 @@ h1.textidote {
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.
+
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.
+
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.
@@ -1446,7 +1446,7 @@ h1.textidote {
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.
+
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.
@@ -1458,74 +1458,74 @@ h1.textidote {
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.
+
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}
+
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.
+
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.
+
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.
+
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.
+
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}
+
360
\end{description}
361
-
362
Behavior Trees werden bei Verwendung von \code{BehaviorTree.CPP} in Form von .xml-Dateien gespeichert.
+
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.
+
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.
+
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.
+
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.
+
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.
+
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.
+
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.
+
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.
+
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.
+
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.
+
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.
+
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.
+
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
@@ -1568,13 +1568,13 @@ h1.textidote {
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.
+
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.
+
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.
+
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
@@ -1584,20 +1584,20 @@ h1.textidote {
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.
+
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.
+
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.
+
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.
+
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''.
+
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.
diff --git a/dict.txt b/dict.txt
index 30fac0d..23b5db5 100644
--- a/dict.txt
+++ b/dict.txt
@@ -59,3 +59,6 @@ iisy
IDLE
MOVEMENT
state}
+Subtree
+Blackboard
+Subtrees
diff --git a/tex/3_Auswahl.tex b/tex/3_Auswahl.tex
index f4e6ceb..c130800 100644
--- a/tex/3_Auswahl.tex
+++ b/tex/3_Auswahl.tex
@@ -132,10 +132,10 @@ Dies vereinfacht die spätere Wartung des Projekts.
\subsection{Auswahl}
Als Simulationsumgebung eignen sich verschiedenen Programme, die sich hinsichtlich ihres Funktionsumfangs stark unterscheiden.
-Hierfür kommen beispielsweise dedizierte Werkzeuge zur Robotersimulation, aber auch universell einsetzbare Gameengines in Frage.
+Hierfür kommen beispielsweise dedizierte Werkzeuge zur Robotersimulation, aber auch universell einsetzbare Gameengines infrage.
Ein Vergleich dieser Werkzeuge ist hierbei sinnvoll, da sich der gebotene Funktionsumfang der Softwares stark unterscheidet.
Auch andere Aspekte, wie Lizenzen oder die schwer bewertbare Nutzerfreundlichkeit, sind hierbei zu betrachten.
-Eine Auswahl der als Simulationsumgebung in Frage kommenden Programme wird hier vorgestellt.
+Eine Auswahl der als Simulationsumgebung infrage kommenden Programme wird hier vorgestellt.
CoppeliaSim \cite{coppelia}, früher auch V-REP genannt, ist eine Robotersimulationsumgebung mit integriertem Editor und ROS-Unterstützung.
Es unterstützt viele Sprachen (C/C++, Python, Java, Lua, Matlab oder Octave) zur Entwicklung von Erweiterungen des Simulators.
@@ -147,7 +147,7 @@ Gazebo Ignition \cite{gazebo} ist wie CoppeliaSim eine Robotersimulationsumgebun
Gazebo setzt wie CoppeliaSim auf Erweiterungen, um zusätzliche Funktionen einbinden zu können.
So existiert zum Beispiel auch eine ROS-Brücke, die die Anbindung an ROS ermöglicht.
Auch hier unterstützt der Simulator nur Animationen für menschliche Aktoren.
-Das Projekt ist Open Source, unter der Apache Lizenz (Version 2.0), was die Verwendung in jeglichen Szenarien erleichtert.
+Das Projekt ist Open Source, unter der Apache-Lizenz (Version 2.0), was die Verwendung in jeglichen Szenarien erleichtert.
Unity \cite{unity} hingegen ist primär eine Grafikengine für die Nutzung in Computerspielen.
Es existieren mehrere Systeme zur Anbindung der Engine an ROS, vor allem das offizielle ``Robotics Simulation''-Paket und ZeroSim.
@@ -211,7 +211,7 @@ Lichter besitzen einen Lichttyp, der die Ausbreitung des Lichtes im Raum bestimm
Die erste Art ist direktionales Licht, dass parallel zur gewünschten Achse auftrifft.
Solche Lichter werden vor allem zur grundlegenden Raumausleuchtung genutzt.
Weiterhin sind Punktlichtquellen verfügbar, deren Licht von einer Position im Raum ausgeht.
-Neben den Punklichtquellen existieren auch noch Spots, die nur einen gewissen Winkel ausleuchten.
+Neben den Punktlichtquellen existieren auch noch Spots, die nur einen gewissen Winkel ausleuchten.
Die Actor-Komponente wird für animierte Modelle in der Simulation eingesetzt.
Sie besteht aus einem Namen für das Modell, einer Skin, welche das Aussehen des Modells definiert und mehreren Animationen.