More Changes.

.kile/mechforsch.kilepr.gui

@@ -2,7 +2,7 @@
 kile_livePreviewEnabled=true
 kile_livePreviewStatusUserSpecified=true
 kile_livePreviewTool=LivePreview-PDFLaTeX
-lastDocument=tex/4_Umsetzung.tex
+lastDocument=main.tex
 
 [document-settings,item:Einleitung.tex]
 Bookmarks=
@@ -139,67 +139,67 @@ TextFolding={"checksum":"","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:main.bib]
-CursorColumn=33
+CursorColumn=18
-CursorLine=321
+CursorLine=326
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"64bbdc6d25aa8e655ff2b9b9aaa47140545f4269","ranges":[]}
+TextFolding={"checksum":"4baf2bb15fceb5c9f2aabf1cf70c4c7dba5ec9f5","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:main.tex]
 CursorColumn=0
-CursorLine=105
+CursorLine=96
 Dynamic Word Wrap=false
 JumpList=
 TextFolding={"checksum":"80ccd936ce5ae7dc5995816ffe293139ed94b427","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/1_Einleitung.tex]
-CursorColumn=0
+CursorColumn=68
-CursorLine=7
+CursorLine=43
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"752ca31e1c24d1d85d2d8fb12ebdefa2996283f2","ranges":[]}
+TextFolding={"checksum":"75bcf6c0e7387bff6aee008e1995bfd43ba5a46b","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/2_Konzept.tex]
-CursorColumn=12
+CursorColumn=39
-CursorLine=19
+CursorLine=116
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"6ef833b681fc8f01a09442bcb6e152ae53c9a838","ranges":[]}
+TextFolding={"checksum":"03b463289e4adf34859cce5e79432be3ca9c3f53","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/3_Auswahl.tex]
-CursorColumn=15
+CursorColumn=0
-CursorLine=45
+CursorLine=446
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"7cc0088b0b9cf29bb8431a83dabf12502827f1cd","ranges":[]}
+TextFolding={"checksum":"0163bec2d59ee0fdc7502865f6859d4fffa2ee1b","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/4_Umsetzung.tex]
-CursorColumn=29
+CursorColumn=14
-CursorLine=953
+CursorLine=915
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"109c6b373243657c2344cec26c14be91fef98dc1","ranges":[]}
+TextFolding={"checksum":"f6689d8b4009907e1b500952fcd8c46a3c8d88d0","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/5_Evaluation_und_Diskussion.tex]
-CursorColumn=45
+CursorColumn=82
-CursorLine=91
+CursorLine=135
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"ab50ad5132cf05a1290a02b2b48c793d41937fb9","ranges":[]}
+TextFolding={"checksum":"f0868d9f15eec0ec90ab265f5c740a42a7b52d9b","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/6_Ausblick.tex]
-CursorColumn=82
+CursorColumn=28
-CursorLine=21
+CursorLine=66
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"85f5725ed69452476240fe61ecbb12cc35b38976","ranges":[]}
+TextFolding={"checksum":"08c80e4a421859760de9f6abca5d28d188b891d5","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/Einleitung.tex]

main.bib

@@ -214,8 +214,8 @@
 }
 
 @misc{gamerig,
-  title = {Arminando/GameRig: GameRig is an auto rigging for games addon for Blender. Built on top of Rigify, it adds rigs, metarigs and additional functionality that enable game engine friendly rig creation. Open source and can be used for personal and commercial projects.},
+  title = {BlenderBoi/Game_Rig_Tools},
-  url = {https://github.com/Arminando/GameRig},
+  url = {https://github.com/BlenderBoi/Game_Rig_Tools},
   note = {letzter Zugriff: 23.04.2023},
 }
 
@@ -323,3 +323,8 @@ doi = {https://doi.org/10.1201/9780429489105}
   url = {https://github.com/goldsborough/ipc-bench},
   note = {letzter Zugriff 30.06.2023},
 }
+@misc{moveItStudio,
+  title = {MoveIt Studio Developer Platform \& SDK | PickNik},
+  url = {https://picknik.ai/studio/},
+  note = {letzter Zugriff 30.06.2023},
+}

tex/1_Einleitung.tex

@@ -14,19 +14,19 @@ Dies erlaubt lediglich die Reproduktion des geplanten Bewegungsablaufes, aber ni
 Um eine solche Funktionalität bereitzustellen, müssen die Bewegungsabläufe sowohl von Roboter als auch Mensch zur Laufzeit der Simulation gesteuert werden können.
 
 Diese Steuerung soll durch eine eingängliche Beschreibungssprache erfolgen, die einfach erweitert und auf neue Szenarien angepasst werden kann.
-Um diese Funktionalität zu demonstrieren, sind 3 unterschiedliche Testszenarien in der Simulationsumgebung abzubilden.
+Um die Funktionalität zu demonstrieren, sind 3 unterschiedliche Testszenarien in der Simulationsumgebung abzubilden.
 Diese sollen durch verschiedene Aufgaben unterschiedliche Interaktionsgrade zwischen Mensch und Roboter simulieren.
 
 \section{Stand der Wissenschaft}
-Aktuelle wissenschaftliche Arbeiten befassen sich mit vielen unterschiedlichen Teilaspekten einer Simulation eines Mensch-Roboter-Kollaborationsszenarios.
+Aktuelle wissenschaftliche Arbeiten befassen sich mit vielen unterschiedlichen Teilaspekten der Simulation eines Mensch-Roboter-Kollaborationsszenarios.
 
 Die Planung von unterschiedlichen Reaktionen von Roboter auf den Menschen in verschiedenen Interaktionsszenarien stellt eine Grundlage für spätere
 Projekte dar.\cite{DOMBROWSKI2018134}
 Hierbei wird die erwünschte Interaktion betrachtet und aus den gewonnenen Daten werden Einschränkungen generiert.
-Diese Einschränkungen können in der Interaktion verwendet werden, zum Beispiel Verletzungen des Menschen durch den Roboter auszuschließen.
+Diese Einschränkungen können in der Interaktion verwendet werden, um zum Beispiel Verletzungen des Menschen durch den Roboter auszuschließen.
 
 Ein anderer Weg der Kollisionsvermeidung ist die Planung der maximal zurücklegbaren Distanz eines Menschen aus seiner aktuellen Position.\cite{ffdrobotsim}
-Dafür werden die maximalen Beschleunigungen einzelner Körperteile ermittelt, um diese während der Interaktion überwachen zu können.
+Dafür werden die maximalen Beschleunigungen einzelner Körperteile ermittelt, um diese während der Interaktion zu überwachen.
 Sollte ein Mensch den Roboter erreichen können, muss dieser in der dafür benötigten Zeit stoppen können.
 Dies sorgt für eine Geschwindigkeitsanpassung im Nahfeld, da hier schnellere Bewegungen möglich sind.
 
@@ -35,14 +35,14 @@ Dabei kommt es auf die Umsetzung in der Beschreibungssprache, aber auch auf Anfo
 
 In Computerspielen werden Beschreibungssprachen schon seit langer Zeit eingesetzt, um verschiedene Systeme, wie zum Beispiel die Steuerung von Nichtspielercharakteren, zu beschreiben.\cite{halo2}
 
-Eine vollständige Umsetzung einer erweiterbaren Simulation mit Mensch und Roboter, gesteuert durch eine Beschreibungssprache konnte bei der Recherche zu dieser Arbeit jedoch nicht gefunden werden.
+Eine vollständige Umsetzung einer erweiterbaren Simulation mit Mensch und Roboter, gesteuert durch eine Beschreibungssprache, konnte bei der Recherche zu dieser Arbeit jedoch nicht gefunden werden.
 
 \section{Auswahl der Szenarien}
-Die drei zu modellierenden Szenarien sollten so gewählt werden, dass spätere komplexere Szenarien auf einfacheren Vorgängern aufsetzten und deren Funktionen weiter nutzen und ergänzen.
+Die drei zu modellierenden Szenarien sollten so gewählt werden, dass spätere komplexere Szenarien auf einfacheren Vorgängern aufsetzen und deren Funktionen weiter nutzen und ergänzen.
 Hierfür kommen bestimmte Aufgaben, wie zum Beispiel die Interaktion mit Objekten besonders in Frage.
-Diese besitzen viele ähnliche Bestandteile, die in mehrere Umständen nutzbar sind.
+Diese besitzen viele ähnliche Bestandteile, die in mehreren Umständen nutzbar sind.
 Das erlaubt den Einsatz von wenigen Animationen in vielen Szenarien.
-Dazu zählen zum Beispiel das Hineingreifen in einen Prozess, das Aufheben von Material oder das Begutachten eines Objekts, die jeweils nur eine ähnliche Bewegungsabfolge des beteiligten Menschen sind.
+Dazu zählen zum Beispiel das Hineingreifen in einen Prozess, das Aufheben von Material oder das Begutachten eines Objekts, welche jeweils nur eine ähnliche Bewegungsabfolge des beteiligten Menschen sind.
 
 Das erste Szenario soll sich mit der Simulation einer bereits vollautomatisierten Fertigungsaufgabe befassen, in der ein Roboter im Arbeitsbereich eines Menschen Teile fertigt.
 Die zu erwartende Interaktion beschränkt sich hierbei auf die Anpassung der Fahrgeschwindigkeit des Roboters bei Annäherung des Menschen, um Kollisionen zu vermeiden.
@@ -66,4 +66,4 @@ Durch diese Arbeit soll in zukünftigen Projekten die Möglichkeit geschaffen we
 
 Dazu ist eine schnelle Adaption von sowohl Roboter als auch Mensch auf unterschiedliche Szenarien nötig.
 Die Szenarien sollen dabei durch eine Beschreibungssprache definiert werden.
-Durch deren einfache Struktur soll komplexes Verhalten einfach und überschaubar definierbar sein, dass dann in der Simulation getestet werden kann.
+Durch deren Struktur soll komplexes Verhalten einfach und überschaubar abbildbar sein, dass dann in der Simulation getestet werden kann.

tex/2_Konzept.tex

@@ -44,7 +44,7 @@ Die so erstellten Animationen müssen von außerhalb der Simulationsumgebung aus
 Ein solcher Mechanismus erlaubt die spätere Steuerung der Animation durch die Beschreibungssprache.
 Hierfür muss eine Komponente entwickelt werden, die in der Simulation die Anfragen der Beschreibungssprache entgegennimmt und umsetzt.
 Um die spätere Steuerung des Menschen von außerhalb zu erleichtern, soll diese Komponente die Ausführung der Befehle überwachen.
-Da mehrere Befehle nacheinander ausgeführt werden sollen, soll der aktuelle Fortschritt der Aktion zurückgemeldet werden.
+Da mehrere Befehle nacheinander ausgeführt werden sollen, wird der aktuelle Fortschritt der Aktion zurückgemeldet.
 Außerdem kann durch andere Komponenten in der Simulation der Abbruch einer Aktion des Menschen nötig werden.
 Die Weitergabe eines Abbruchbefehls soll demzufolge auch über die geplante Komponente realisiert werden können.
 
@@ -58,7 +58,7 @@ Behavior Trees lösen dieses Problem, in dem sie sogenannte Nodes definieren, di
 Die einzelnen Nodes verändern dabei das System und lösen den Wechsel zu neuen Nodes aus.
 
 Ursprünglich wurde das Konzept der Behavior Trees von Rodney Brooks entwickelt, der diese für mobile Roboter einsetzen wollte. \cite{1087032}
-Das System setzte sich später jedoch zuerst in der Spieleindustrie, für die Beschreibung von menschlichem Verhalten durch. \cite{isla2005handling}
+Das System setzte sich später jedoch zuerst in der Spieleindustrie, für die Beschreibung von menschlichem Verhalten, durch. \cite{isla2005handling}
 
 Der Ablauf eines Behavior Trees startet vom sogenannten Root, der Wurzel des Baums.
 Von dort an werden Nodes, die je nach Node unterschiedliches Verhalten abbilden, miteinander verbunden.
@@ -78,7 +78,7 @@ Es gibt mehrere grundlegende Arten von Tree-Nodes, die in vier Kategorien unters
   Sollte eine Node einen Fehler zurückgeben, wird die Ausführung der Sequenz abgebrochen, was wiederum zur Rückgabe eines Fehlers durch die Sequenz selbst führt.
   Beim erfolgreichen Durchlauf gibt die Sequenz einen Erfolg zurück.
  \item[Fallback-Nodes]
-  verhalten sich ähnlich wie Sequenz-Nodes, jedoch werden darunter liegenden Nodes nacheinander ausgeführt, bis eine Node Erfolg zurück gibt.
+  verhalten sich ähnlich wie Sequenz-Nodes, jedoch werden die darunter liegenden Nodes nacheinander ausgeführt, bis eine Node Erfolg zurück gibt.
   In diesem Fall wird die Ausführung der Fallback-Node mit einem Erfolg abgebrochen.
   Ein Fehler wird hier zurückgegeben, wenn alle Nodes ohne eine Erfolgsmeldung durchlaufen wurden.
 \end{description}
@@ -114,7 +114,7 @@ Folgender Kontrollfluss findet in diesem Beispiel statt:
  }
  \item{
   Da die untergeornete Node eine erfolgreiche Ausführung meldet, wird die Ausführung der Fallback-Node mit einem erfolgreichen Rückgabewert beendet.
-  Daher wird die Node "Tür eintreten" nicht mehr ausgeführt.
+  Aus diesem Grund wird die Node ``Tür eintreten'' nicht mehr ausgeführt.
  }
  \item{
   Dadurch wird die nächste Node in der Sequenz ausgeführt, die prüft, ob die Tür durchlaufen werden kann.
@@ -134,13 +134,13 @@ In dieser Arbeit sollen deshalb BehaviorTrees für die Steuerung von Mensch und
 Die hierfür erstellten Nodes sollen universell gestaltet werden, um alle Szenarien, die in dieser Arbeit betrachtet werden, abzudecken.
 
 \section{Virtualisierungsumgebung als Plattform}
-Um Fehler durch die unvollständige Einrichtung der Umgebung zu vermeiden, ist der Einsatz fest definierter Prozesse in einer stabilen Umgebung unerlässlich.
+Der Einsatz fest definierter Prozesse in einer stabilen Umgebung ist unerlässlich, um Fehler durch die unvollständige Einrichtung der Umgebung zu vermeiden.
 Dies kann durch den Einsatz einer Virtualisierungsumgebung geschehen, in der das zu entwerfende System ausgeführt wird.
 
 Dadurch können benötigte Programme, Pfade und Umgebungsvariablen in der Virtualisierungsumgebung hinterlegt werden, die diese bei der Ausführung auf einem anderen Grundsystem korrekt abbildet.
 Eine solche Struktur erhöht die Zuverlässigkeit der Umgebung, da die Änderungen an der Umgebung auf alle ausführenden Systeme gespiegelt werden.
 
-Ein weiterer Vorteil ist die beschleunigte Entwicklung, da Änderungen nicht mehr an einzelne Zielsysteme angepasst werden müssen.
+Ein weiterer Vorteil ist die beschleunigte Entwicklung, weil Änderungen nicht mehr an einzelne Zielsysteme angepasst werden müssen.
 Hinzu kommt die einfachere Inbetriebnahme eines bereits entwickelten Systems, da keine Anpassungen am Hostsystem vorgenommen werden müssen.
 
 Natürlich existieren auch Nachteile der Virtualisierung, die mit den Vorteilen abgewogen werden müssen.

tex/3_Auswahl.tex

@@ -2,7 +2,7 @@
 Die Auswahl der verwendeten Softwarekomponenten beeinflusst den späteren Entwicklungsprozess nachhaltig.
 
 Alle Komponenten sollen später in der entwickelten Softwareumgebung ihre jeweiligen Teilbereiche abdecken.
-Alle diese Teilbereiche können dann zu einer Simulation vebunden werden, die das gesamte Problemfeld abdeckt.
+Alle diese Teilbereiche können dann zu einer Simulation verbunden werden, die das gesamte Problemfeld abdeckt.
 
 Wie bereits in Abbildung \ref{concept_overview} dargestellt, ist für die Erfüllung der Aufgaben eine Dienst- und eine Simulationsumgebung erforderlich.
 Dieses Kapitel beschreibt die Auswahl der Umgebungen und der in diesen laufenden Prozesse.
@@ -12,10 +12,10 @@ Durch sie werden häufig benötigte Funktionen bereitgestellt, die Programme inn
 
 Bei einer Dienstumgebung für Roboter gehört die Nachrichtenübergabe zwischen den einzelnen Programmen zu den grundlegenden Aspekten.
 Diese wird genutzt, um eine gemeinsame Basis für ein erweiterbares System zu schaffen.
-Außerdem sind Werkzeuge zur Einstellungsübergabe an Teilsysteme sinnvoll, um die Einstellungen an einer Stelle gesammelt anpassen zu können.
+Außerdem sind Werkzeuge zur Parameterübergabe an Teilsysteme sinnvoll, um die Einstellungen an einer Stelle gesammelt anpassen zu können.
 
 \subsection{Auswahl}
-Es existieren mehrere Systeme, die als Dienstumgebung für Roboter in Frage kommen, wenn es lediglich um die Nachrichtenübergabe zwischen Programmen geht.
+Es existieren mehrere Systeme, die als Dienstumgebung für Roboter in Frage kommen, wenn man lediglich die Nachrichtenübergabe zwischen Programmen betrachtet.
 Jede Dienstumgebung, die Nachrichten zwischen Prozessen austauschen kann, ist potentiell als ein Roboterframework einsetzbar.
 
 Wichtige Aspekte sind dabei die Geschwindigkeit der Anbindung und die Definition der Nachrichten, die über das System ausgetauscht werden.
@@ -23,7 +23,7 @@ Wichtige Aspekte sind dabei die Geschwindigkeit der Anbindung und die Definition
 Nutzbare, bereits als Interprozesskommunikation integrierte Systeme sind zum Beispiel Pipes, die Daten zwischen Prozessen über Buffer austauschen.
 Auch die Nutzung von Message Queues oder Shared Memory ist für diesen Einsatzzweck möglich.
 Diese Systeme sind performant, jedoch schwerer zu verwalten.
-Ein Problem dieser Methoden ist die direkte Kommunikation mehrerer Komponenten, da diese Art der Kommunikation keine Modifikation von Nachrichten zur Anpassung an andere Szenarien vorsieht.
+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.
 
 Eine Alternative stellen Sockets dar, die Daten zwischen mehreren Programmen austauschen können.
 Dabei dient ein Programm als Server, der Anfragen von anderen Programmen, auch Clients genannt, entgegen nimmt.
@@ -34,19 +34,19 @@ Dieser Nachteil besteht in der potentiellen Variabilität dieser Kommunikationsm
 Bei einem ausreichend großen Projekt treten so unweigerlich Unterschiede in der Handhabung von Nachrichten auf, die es zu berücksichtigen gilt.
 Durch solche Unterschiede kann es zu Inkompatibilitäten zwischen Programmen kommen, was sich auf die universelle Nutzbarkeit der Programme negativ auswirkt.
 
-Im Bereich der Robotik ist ROS\cite{doi:10.1126/scirobotics.abm6074} als Dienstumgebung für Roboter bekannt, da es sich um ein etabliertes und quelloffenes System handelt.
+Im Bereich der Robotik ist ROS\cite{doi:10.1126/scirobotics.abm6074}, bei dem es sich um ein quelloffenes System handelt, als Dienstumgebung etabliert.
-Der oben genannte Nachteil einzelner Systeme wird in ROS durch mehrere standardisierte und erweiterbare Nachrichtendefinition gelöst, die von den Programmen in der Umgebung genutzt werden.
+Der oben genannte Nachteil einzelner Systeme wird in ROS durch mehrere standardisierte und erweiterbare Nachrichtendefinitionen gelöst, die von den Programmen in der Umgebung genutzt werden.
-Um diese Nachrichten senden und empfangen zu können, liefert ROS eine eigene Implementation des Protokolls für mehrere Programmiersprachen mit.
+Um diese Nachrichten senden und empfangen zu können, liefert ROS bereits eine eigene Implementation des Protokolls für mehrere Programmiersprachen mit.
-Für zum Beispiel Python\cite{python}, C und C++\cite{cpp} existieren entsprechende Implementationen in Form der Pakete \code{rospy}, \code{rclc} und \code{rclcpp}.
+Zum Beispiel existieren für Python\cite{python}, C und C++\cite{cpp} entsprechende Implementationen in Form der Pakete \code{rospy}, \code{rclc} und \code{rclcpp}.
 
-Die neuste Version ROS2 bietet dabei mehrere Verbesserungen im Vergleich zu früheren Version ROS1 \cite{changesRosII}.
+Die neuste Version ROS2 bietet mehrere Verbesserungen im Vergleich zu früheren Version ROS1 \cite{changesRosII}.
 Ein neues Nachrichtenformat mit Quality of Service kann beispielsweise Nachrichten zwischenspeichern und über sowohl TCP, als auch UDP kommunizieren.
 Außerdem werden neben CMake\cite{cmake} auch andere Buildsysteme unterstützt, was die Verwendung von Python erlaubt.
 
 Generell existieren im Feld der Roboter-Dienstumgebungen keine freien Alternativen mit ähnlichem Funktionsumfang und gleicher Reichweite.
 Vor allem die Vielzahl von ROS-Bibliotheken, die von Nutzern des Systems über die Jahre erstellt wurden, machen das System so populär.\cite{rospackages}
 
-ROS kann für simulierte Umgebungen, aber auch für echte Roboter eingesetzt werden.
+ROS kann sowohl für simulierte Umgebungen als auch für echte Roboter eingesetzt werden.
 Diese beiden Anwendungsfälle werden durch unterschiedliche Controller realisiert.
 Für simulierte Umgebungen leitet der Controller die Steuerdaten an die Simulationsumgebung weiter.
 Bei dem Einsatz echter Hardware werden die Zielpositionen durch den Controller an die Roboterhardware weitergeleitet.
@@ -78,7 +78,7 @@ Zu den Aufgaben von ROS zählen folgende Teilbereiche:
  \item[Buildumgebung]\hfill \\
   ROS nutzt die eigene Buildumgebung \code{colcon} \cite{colcon}, um Pakete in den Workspaces reproduzierbar zu erstellen.
   Zu deren Konfiguration wird eine \code{CMakeLists.txt}-Datei erstellt, die den Buildprozess beschreibt.
-  In dieser sind die Buildinstruktionen für den Kompiler enhalten, mit welchen die im Paket befindlichen Programme kompiliert werden können.
+  In dieser sind die Buildinstruktionen für den Kompiler enhalten, mit welchen die im Paket befindlichen Programme kompiliert werden.
   Der Aufruf des \code{ament_cmake}-Makros in dieser ergänzt den Kompiliervorgang um weitere Parameter aus der \code{package.xml}-Datei.
 
   Nach diesen Vorbereitungsschritten kann CMake das Paket kompilieren.
@@ -88,7 +88,7 @@ Zu den Aufgaben von ROS zählen folgende Teilbereiche:
   Diese sind dann später im erstellten Workspace für die Nutzung durch andere Programme verfügbar.
 
  \item[Workspaceverwaltung]\hfill \\
-  Gruppen von Paketen befinden sich in sogenannen ``Workspaces''.
+  Gruppen von Paketen werden zur einfacheren Handhabung in sogenannen “Workspaces” zusammengefasst.
   Diese vereinfachen das Auffinden der enthaltenen Pakete durch Skripte, die diese im System registrieren.
   Die Erstellung der Skripte erfolgt anhand der bereits beschriebenen \code{CMakeLists.txt}-Datei.
   Das Programm \code{colcon} analysiert diese und generiert die Skripte.
@@ -116,7 +116,7 @@ Zu den Aufgaben von ROS zählen folgende Teilbereiche:
   Um Nodes auf neue Anwendungsfälle anpassen zu können, wird ein Konfigurationsmechanismus benötigt.
   In ROS geschieht dies durch die Übergabe sogenannter Parameter, die durch die Node gelesen werden können.
   Diese eignen sich zur Übergabe von Informationen, wie zum Beispiel Daten über ein verwendetes Robotermodell.
-  Um neue Konfigurationen zu unterstützen, kann das Umbenennen von Topics einer Node nötig werden, was auch mit einen Parameter erfolgen kann.
+  Um neue Konfigurationen zu unterstützen, kann das Umbenennen von Topics einer Node notwendig werden, was auch mit einem Parameter erfolgen kann.
 
  \item[Startverwaltung]\hfill \\
   In sogenannten ``launch''-Files können verschiedene Nodes und andere ``launch''-Files zu komplexen Startvorgängen zusammengefasst werden.
@@ -132,29 +132,29 @@ 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 dedizierte Werkzeuge zur Robotersimulation, aber auch beispielsweise universell einsetzbare Gameengines in Frage.
+Hierfür kommen beispielsweise dedizierte Werkzeuge zur Robotersimulation, aber auch universell einsetzbare Gameengines in Frage.
-Ein Vergleich dieser Werkzeuge ist hierbei sinnvoll, da der gebotene Funktionsumfang der Softwares sich stark unterscheidet.
+Ein Vergleich dieser Werkzeuge ist hierbei sinnvoll, da sich der gebotene Funktionsumfang der Softwares stark unterscheidet.
-Auch andere Aspekte, wie Lizenzen oder schwer bewertbare Aspekte wie Nutzerfreundlichkeit, sind hierbei zu betrachten.
+Auch andere Aspekte, wie Lizenzen oder die schwer bewertbare Nutzerfreundlichkeit, sind hierbei zu betrachten.
 Eine Auswahl der als Simulationsumgebung in Frage kommenden Programme wird hier vorgestellt.
 
 CoppeliaSim\cite{coppelia}, früher auch V-REP genannt, ist eine Robotersimulationsumgebung mit integriertem Editor und ROS-Unterstützung.
 Es unterstützt viele Sprachen (C/C++, Python, Java, Lua, Matlab oder Octave) zur Entwicklung von Erweiterungen des Simulators.
-Der Simulator selbst unterstützt menschliche Aktoren, jedoch können diese nur Animationen abspielen oder zusammen mit Bewegungen abspielen.
+Der Simulator selbst unterstützt menschliche Aktoren, diese können aber nur Animationen allein oder in Kombination mit einer Bewegung abspielen.
-CoppeliaSim existiert in 3 Versionen, die sich im Funktionsumfang und Lizenz unterscheiden.
+CoppeliaSim existiert in 3 Versionen, die sich hinsichtlich Funktionsumfang und Lizenz unterscheiden.
 Jedoch besitzt nur die professionelle Version Zugriff auf alle Funktionen und Verwendungsszenarien.
 
-Gazebo Ignition\cite{gazebo} ist wie CoppeliaSim eine Robotersimulationsumgebung, jedoch ohne integrierten Editor und direkte ROS-Unterstützung.
+Gazebo Ignition\cite{gazebo} ist wie CoppeliaSim eine Robotersimulationsumgebung, besitzt aber keinen integrierten Editor und direkte ROS-Unterstützung.
-Gazebo setzt wie CoppeliaSim auf Erweiterungen, die die gewünschten Funktionen einbinden können.
+Gazebo setzt wie CoppeliaSim auf Erweiterungen, um zusätzliche Funktionen einbinden zu können.
-Zum Beispiel existiert auch eine ROS-Brücke, welche die Anbindung an ROS ermöglicht.
+So existiert zum Beispiel auch eine ROS-Brücke, die die Anbindung an ROS ermöglicht.
 Auch hier unterstützt der Simulator nur Animationen für menschliche Aktoren.
 Das Projekt ist Open Source, unter der Apache Lizenz (Version 2.0), was die Verwendung in jeglichen Szenarien erleichtert.
 
-Unity\cite{unity} hingegen ist primär eine Grafikengine für Nutzung in Computerspielen.
+Unity\cite{unity} hingegen ist primär eine Grafikengine für die Nutzung in Computerspielen.
 Es existieren mehrere Systeme zur Anbindung der Engine an ROS, vor allem das offizielle ``Robotics Simulation''-Paket und ZeroSim.
 Beide Systeme erlauben die Erweiterung der Gameengine um die Simulation von Robotern.
 Unity besitzt eine gute Dokumentation, die vor allem auf die Nutzung im Einsteigerbereich zurückzuführen ist.
 Auch die Optionen zur Menschensimulation sind umfangreich, da diese häufig in Spielen verwendet werden.
-Ein großer Nachteil hingegen ist die Lizenz, die nur für Einzelpersonen kostenlos ist.
+Ein großer Nachteil hingegen ist die Lizenz, die nur für Einzelpersonen kostenfrei ist.
 
 Die Unreal Engine\cite{unreal} ist wie Unity eine Grafikengine aus dem Spielebereich.
 Auch hier ist die Menschensimulation aufgrund oben genannter Gründe gut möglich.
@@ -164,21 +164,21 @@ Die Lizenz der Unreal Engine erlaubt die kostenfreie Nutzung bis zu einem gewiss
 
 Eine weitere Möglichkeit zur Simulation stellt die Grafikengine Godot\cite{godot} dar.
 Im Vergleich zu Unity und Unreal Engine ist Godot quelloffene Software unter der MIT-Lizenz.
-Auch hier stellt die Simulation von menschlichen Aktoren eine Standartaufgabe dar, jedoch befinden sich Teile des dafür verwendeten Systems derzeit in Überarbeitung.
+Auch hier stellt die Simulation von menschlichen Aktoren eine Standardaufgabe dar, jedoch befinden sich Teile des dafür verwendeten Systems derzeit in Überarbeitung.
 Auch für diese Engine existiert eine ROS2-Anbindung, jedoch ist diese nicht offiziell.
 
-Alle vorgestellten Softwares besitzten ein integriertes Physiksystem, dass die Simulation von starren Körpern und Gelenken erlaubt.
+Alle vorgestellten Softwares besitzen ein integriertes Physiksystem, dass die Simulation von starren Körpern und Gelenken erlaubt.
 Diese Funktionen erlauben den Aufbau eines Roboterarms, der durch eine ROS-Brücke gesteuert wird.
 
 Um den Fokus dieser Arbeit auf die gestellte Aufgabe zu ermöglichen, ist die Auswahl einer Umgebung mit bereits existierender ROS-Unterstützung sinnvoll.
 Durch diese Einschränkung scheiden sowohl Unreal Engine aber auch Godot aus.
-Diese bieten zwar diese Funktionalität, jedoch wird diese nur durch Nutzer gewartet und ist demzufolge nicht offiziell unterstützt.
+Sie bieten zwar diese Funktionalität, jedoch werden sie nur durch Nutzer gewartet und sind demzufolge nicht offiziell unterstützt.
-Für einen späteren Einsatz ist eine offene Lizenz von Vorteil, da diese einen Einsatz in nahezu allen Umständen erlaubt.
+Für einen späteren Einsatz ist eine offene Lizenz von Vorteil, da diese einen Einsatz unter nahezu allen Umständen erlaubt.
 
-Die Wahl der hier zu verwendenden Simulationsumgebung fiel deshalb auf Gazebo Ignition, dass gleichzeitig bereits im ROS-Ökosystem etabliert ist.
+Die Wahl der hier zu verwendenden Simulationsumgebung fiel deshalb auf Gazebo Ignition, welche gleichzeitig bereits im ROS-Ökosystem etabliert ist.
-Dabei erlauben die offizielle ROS-Anbindung und offene Lizenz eine zuverlässige Verwendung in unterschiedlichsten Szenarien.
+Dabei erlauben die offizielle ROS-Anbindung und die offene Lizenz eine zuverlässige Verwendung in unterschiedlichsten Szenarien.
 \subsection{Welt- und Modellbeschreibung}
-Um die Simulationsumgebung zu beschreiben, nutzt Gazebo das .sdf-Dateiformat\cite{sdf-format}.
+Gazebo nutzt das .sdf-Dateiformat, um die Simulationsumbebung zu beschreiben\cite{sdf-format}.
 Dieses Format basiert auf XML und wird zur Definition gesamter Welten, aber auch einzelner Objekte innerhalb dieser Welten benutzt.
 Eine Welt ist in Gazebo eine Umgebung aus mehreren Objekten, welche simuliert werden sollen.
 Die Welt beschreibt außerdem die simulierte Physikumgebung und deren Konstanten, wie zum Beispiel die Gravitation.
@@ -188,10 +188,10 @@ Eine solche Datei kann, wie bereits oben beschrieben, unterschiedliche Daten ent
 Im Falle eines Objekts ist dies eine einzige Instanz von entweder einem Modell, Actor oder Licht.
 Andernfalls können in der Datei eine oder mehrere Welten definiert werden.
 
-Eine Welt definiert in Gazebo den kompletten Aubau des Simulators.
+Eine Welt definiert in Gazebo den kompletten Aufbau des Simulators.
 Zuerst enthält ein Welt-Element die Daten über die physikalischen Konstanten der Simulationsumgebung.
 Außerdem werden alle benötigten Teile der Nutzeroberfläche deklariert, die im ausgeführten Simulator verfügbar sein sollen.
-Letzendlich ist auch die Definition mehrerer Modelle, Aktoren und Lichter in der Welt möglich.
+Letzendlich ist die Definition mehrerer Modelle, Aktoren und Lichter in der Welt möglich.
 Diese können auch aus anderen URIs stammen, die in der Welt deklariert wurden.
 Dies erlaubt zum Beispiel das Laden von vorher definierten Objekten oder Objekten aus der offiziellen Bibliothek\cite{gazebo-app}.
 
@@ -205,19 +205,19 @@ Außerdem können im Modell Einstellungen für dessen Physiksimulation vorgenomm
 
 Ein Modell enhält meist mindestens ein Link-Element, dass zur Darstellung von dessen Geometrie verwendet wird.
 Mehrere Link-Elemente können dabei mit der Welt oder anderen Link-Elementen über Joint-Elemente verbunden werden.
-Diese Joint-Elemente können jedoch nicht von außerhalb gesteuert werden, was dieses Dateiformat ungeeignet für Roboterdefinitionen macht.
+Diese Joint-Elemente können jedoch nicht von außerhalb gesteuert werden, was das Dateiformat ungeeignet für Roboterdefinitionen macht.
 
 Lichter besitzen einen Lichttyp, der die Ausbreitung des Lichtes im Raum bestimmt.
 Die erste Art ist direktionales Licht, dass parallel zur gewünschten Achse auftrifft.
 Solche Lichter werden vor allem zur grundlegenden Raumausleuchtung genutzt.
-Außerdem existieren noch Punktlichtquellen, die von einer Position im Raum ausgehen.
+Weiterhin sind Punktlichtquellen verfügbar, deren Licht von einer Position im Raum ausgeht.
-Neben den Punklichtquellen existieren auch noch Spots, die außerdem noch nur einen gewissen Winkel ausleuchten.
+Neben den Punklichtquellen existieren auch noch Spots, die außerdem 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.
-Diese können durch in einem Skript definierte Trajectories ausgeführt werden, was eine einfache Simulation eines Menschen erlaubt.
+Diese können durch in einem Skript definierte Trajectories ausgeführt werden, was eine einfache, aber statische, Simulation des Menschen erlaubt.
 
-Eine solche Befehlsfolge kann jedoch nicht von außerhalb der Simulation zur Laufzeit angepasst werden.
+Eine solche Befehlsfolge kann nicht von außerhalb der Simulation zur Laufzeit angepasst werden.
 Diese Funktionalität wurde im Rahmen der Arbeit hinzugefügt.
 
 \subsection{Robotersimulation}
@@ -259,16 +259,16 @@ Dadurch ist zum Beispiel eine Laufanimation realisierbar, die synchronisiert zu
 Dies setzt jedoch voraus, dass der gesamte Bewegungsablauf zum Simulationsstart bekannt ist.
 Der Grund dafür ist auf die Definition der Pfade zurückzuführen, die Aktionen wie Bewegungen und Animationen auslösen.
 Diese können nur als dem Actor untergeordnetes Element in der .sdf-Datei definiert werden, was Veränderungen zur Laufzeit ausschließt.
-Durch diesen Umstand ist der somit realisierbare Simulationsumfang nicht ausreichend, um die gewünschten Szenarien abzubilden.
+Durch diesen Umstand ist der damit realisierbare Simulationsumfang nicht ausreichend, um die gewünschten Szenarien abzubilden.
 
 Um diese Einschränkung zu beheben, ist die Entwicklung eines eigenen Systems zum Bewegen und Animieren des Menschen unausweichlich.
 Dieses System muss, wie im Konzept beschrieben, Steuerbefehle von außen empfangen, umsetzen und Feedback liefern können.
-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 Befehlts zulässt.
+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.
 
 Ein solches System soll als Gazebo-Plugin einbindbar sein, um Modifikationen an der Simulationsumgebung selbst auszuschließen, die konstant weiter entwickelt wird.
 Dies vereinfacht die Wartung, da bei Updates der Simulationsumgebung nicht die Menschensimulation an den neuen Code angepasst werden muss.
 \section{Roboterumgebung}
-MoveIt2\cite{moveit-docs} ist das meist genutzte ROS2 Paket für Bewegungsplanung von Robotern.
+MoveIt2\cite{moveit-docs} ist das meist genutzte ROS2 Paket für die Bewegungsplanung von Robotern.
 Deshalb existiert eine umfangreiche Dokumentation für die zahlreichen Komponenten, was die Entwicklung neuer Komponenten erleichtert.
 Außerdem sind zahlreiche direkte Integrationen mit anderen ROS-Paketen verfügbar, was die Nutzung dieser zusammen mit MoveIt erlaubt.
 Aufgrund dieser Eigenschaften ist MoveIt eine vorteilhafte Bewegungsplanungsumgebung für dieses Projekt.
@@ -279,21 +279,21 @@ Der Nutzer kann mit MoveIt auf verschiedenen Wegen Steuerbefehle für den Robote
 Die erste Inbetriebnahme ist über das mitgelieferte RViz-Plugin und die demo-Launch-Files möglich.
 Diese wurden mit dem mitgelieferten Setupassistenten für den Roboter generiert.
 Durch die Ausführung dieser Demo startet RViz, eine Test- und Visualisierungsumgebung für ROS.
-In dieser können Roboterbewegungen unter Zuhilfenahme von Markierungen in RViz geplant und ausgeführt werden.
+In der Demo können Roboterbewegungen unter Zuhilfenahme von Markierungen in RViz geplant und ausgeführt werden.
 
-Da sich eine solche Bewegungsplanung nur beschränkt zur Automatisierung durch Software eignet, müssen die der Demo zugrundeliegenden Schnittstellen genutzt werden.
+Da sich eine Bewegungsplanung in einer Nutzeroberfläche nur beschränkt zur Automatisierung durch Software eignet, müssen die der Demo zugrundeliegenden Schnittstellen genutzt werden.
-Für die Sprache Python existierte für die Vorgängerversion MoveIt noch das moveit_commander Paket, dass den Zugriff auf MoveIt in Pyhon erlaubt, dass aber für MoveIt2 noch nicht portiert wurde\cite{moveitpython}.
+Für die Sprache Python existierte für die Vorgängerversion von MoveIt das moveit_commander Paket, welches den Zugriff auf MoveIt in Pyhon erlaubt, aber für MoveIt2 noch nicht portiert wurde\cite{moveitpython}.
 
 Die direkte Nutzung der C++-API ist aktuell die einzige offizielle Möglichkeit, mit MoveIt2 direkt zu interagieren.
-Dabei können sowohl die Planung und Ausführung von Bewegungen ausgelöst aber auch Exklusionszonen eingerichtet werden.
+Dabei können sowohl die Planung und die Ausführung von Bewegungen ausgelöst aber auch Exklusionszonen eingerichtet werden.
 Außerdem können Objekte virtuell mit dem Roboter verbunden werden, wodurch sich diese in RViz mit dem Roboter bewegen.
-Natürlich können die Befehle auch direkt an die entsprechenden Topics gesendet werden um einzelne Bereiche des Systems zu testen.
+Natürlich können die Befehle auch direkt an die entsprechenden Topics gesendet werden, um einzelne Bereiche des Systems zu testen.
 
 Um die durch den Setupassistenten generierten Informationen an MoveIt zu übergeben, wird intern ein RobotStatePublisher verwendet.
-Dieser läd alle Daten des Robotermodells und gibt sie an andere Programme weiter, die Roboterparameter zur Laufzeit anfordern, unter diesen auch MoveIt selbst.
+Dieser lädt alle Daten des Robotermodells und übergibt sie an andere Programme, die Roboterparameter zur Laufzeit anfordern, unter diesen auch MoveIt selbst.
 
-Durch die vorher erwähne C++-API erhält die MoveGroup die Informationen über die gewünschte Bewegung.
+Durch die vorher erwähnte C++-API erhält die MoveGroup die Informationen über die gewünschte Bewegung.
-Dabei können auch bestimmte Einschränkungen des Arbeitsraums, spezielle Trajektorien, oder Limitierungen der Gelenke in der Planung berücksichtigt werden.
+Dabei können auch bestimmte Einschränkungen des Arbeitsraums, spezielle Trajektorien oder Limitierungen der Gelenke in der Planung berücksichtigt werden.
 
 Diese Daten können durch eine OccupancyMap ergänzt werden, welche die Bereiche beschreibt, die sich um den Roboter befinden.
 Eine solche Erweiterung erlaubt die automatische Nutzung von Kollisionsvermeidung mit Objekten im Planungsbereich.
@@ -308,11 +308,11 @@ Der Erfolg der gesamten Pipeline kann dabei durch einen Feedbackmechanismus übe
 Im Falle von Gazebo wird \code{ign_ros_control} genutzt, dass die benötigten \code{ros_control} Controller in die Simulation einbindet.
 Diese können dann wie normale Controller von \code{ros_control} genutzt werden.
 
-Dieser Ablauf ist auch im Anhang unter Abbildung \ref{moveitpipeline} im Anhang visualisiert.
+Der Ablauf der Bewegungsplanungspipeline von MoveIt ist im Anhang unter Abbildung \ref{moveitpipeline} visualisiert.
 
 \section{Programmiersprache}
 Als Programmiersprache kommen in ROS standardmäßig Python\cite{python} und C++\cite{cpp} zum Einsatz.
-Diese beiden Sprachen sind in der Softwareentwicklung beliebt, unterscheiden sich jedoch stark in Funktionsumfang und Entwicklungsprozess.
+Beide Sprachen sind in der Softwareentwicklung beliebt, unterscheiden sich jedoch stark im Funktionsumfang und im Entwicklungsprozess.
 
 Python ist eine interpretierte Skriptsprache, die zu den hohen Programmiersprachen zählt.
 Sie wird in ROS zum Beispiel in \code{.launch.py}-Dateien eingesetzt, die den Start von Diensten in der Umgebung verwalten.
@@ -326,10 +326,10 @@ Die Nutzung eines Kompilierers beschleunigt C++ deutlich im Vergleich zu Python,
 Dies ist vor allem in häufig geänderten Programmen ein Nachteil, die nach einer Änderung erneut kompiliert werden müssen.
 Aus diesem Grund wird Python vor allem in .launch.py-Dateien verwendet, welche die Interaktion der anderen Programme in der Umgebung verwalten.
 
-Um die gewünschten Funktionen für die Simulation umsetzen zu können, ist die Programmierung in C++ nahezu unumgänglich.
+Um die gewünschten Funktionen für die Simulation umzusetzen ist die Verwendung der Programmiersprache C++ nahezu unumgänglich.
 Zum Beispiel sind Gazebo-Plugins in C++ erstellt, was die Nutzung anderer Sprachen stark einschränkt.
 
-Ein Grund für die Nutzung von C++ ist die hohe Geschwindigkeit, die bei einer hohen Anzahl von Simulationsschritten pro Sekunde benötigt wird.
+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.
 Außerdem kann MoveIt2 derzeit nur mit C++ direkt gesteuert werden.
 
 Die Verwendung von C++ für die zu entwickelnden Nodes erscheint deshalb aus oben genannten Gründen naheliegend.
@@ -339,27 +339,27 @@ In den Launch-Skripten wird jedoch Python verwendet werden, da hier die Vorteile
 Zur Verwaltung der Abläufe sollen BehaviorTrees genutzt werden, die durch die Bibliothek \code{BehaviorTree.CPP} bereitgestellt werden.
 Diese Bibliothek wurde in C++ geschrieben, und ist somit in ROS und dem geplanten Konzept integrierbar.
 
-Es existieren auch viele Beispiele und eine gute Dokumentation über die erweiterten Funktionen der Bibliothek, die im folgenden vorgestellt werden.
+Es existieren viele Beispiele und eine gute Dokumentation über die erweiterten Funktionen der Bibliothek, die im Folgenden vorgestellt werden.
 
 \begin{description}
   \item[Asynchrone Nodes]
   sind in \code{BehaviorTree.CPP} leichter umsetzbar, da diese in Form verschiedener Zustände der Nodes beim Konzept der Bibliothek mit bedacht wurden.
   Dies resultiert in Nodes, die ohne spezielle Logik langanhaltende Aktionen ausführen können, ohne die Ausführung des BehaviorTrees zu behindern.
-  \item[Reaktives Verhalten] ist ein neues Konzept, um die Handhabung von asnchronen Nodes zu vereinfachen.
+  \item[Reaktives Verhalten] ist ein neues Konzept, um die Handhabung von asynchronen Nodes zu vereinfachen.
   Diese Strukturelemente erlauben die parallele Ausführung von mehreren Zweigen, die die aktuell ausgeführte Aktion beeinflussen können.
   Darunter fällt die Modifizierung von Parametern der Aktionen, aber auch der vollständige Abbruch einer Aktion durch äußere Einflüsse.
-  \item[Das .xml-Format der Behavior Trees] ermöglicht einen Austausch des Verhaltens, ohne die unterliegende Programme verändern zu müssen.
+  \item[Das .xml-Format der Behavior Trees] ermöglicht einen Austausch des Verhaltens, ohne die unterliegenden Programme verändern zu müssen.
   Dies ist vor allem in kompilierten Sprachen wie C++ sinnvoll, da Änderungen im Verhaltensablauf keiner Neukompilierung bedürfen, was die Iterationszeit für Änderungen verbessert.
   \item[Plugins] können zum Start geladen werden, um weitere Nodes dem ausgeführten Programm hinzufügen zu können.
-  Dies vereinfacht die Erweiterung um neue Funktionen und das mehrfachen Nutzen von Code.
+  Dies vereinfacht die Erweiterung um neue Funktionen und das mehrfache Nutzen von Code.
   \item[Das Blackboard] ist eine Interaktionsebene, die den Datenfluss zwischen den Nodes erlaubt.
   In diesem System kann unter Verwendung einer Zeichenkette als Identifikator ein Wert in Form einer Referenz hinterlegt werden.
   Sogenannte Ports erlauben Nodes, Daten aus dem Blackboard zu lesen und auf dieses zu schreiben.
   \item[Integriertes Logging] erlaubt es, Zustandsänderungen im Behavior Tree zu visualisieren, aufzunehmen und wieder abzuspielen.
-  Dies erleichtert das häufig schwierige Debuggen von Zustandsmaschienen erheblich, da das Verhalten genau untersucht werden kann.
+  Dies erleichtert das häufig schwierige Debuggen von Zustandsmaschinen erheblich, da das Verhalten genau untersucht werden kann.
 \end{description}
 
-BehaviorTrees werden in \code{BehaviorTree.CPP} in Form von .xml-Dateien gespeichert.
+BehaviorTrees werden bei Verwendung von \code{BehaviorTree.CPP} in Form von .xml-Dateien gespeichert.
 Diese Dateien enthalten die Anordnung der Nodes selbst, aber auch weitere Konfigurationsmöglichkeiten in Form von Ein- und Ausgabeports.
 
 Ports können verwendet werden, um Nodes generischer zu gestalten.
@@ -369,15 +369,15 @@ Um dies zu ermöglichen, kann deren Funktion durch mehrere andere Nodes in einem
 Diese in den Ports übertragenen Daten können sowohl aus einem String ausgelesen, aber auch aus dem sogenannten Blackboard entnommen werden.
 
 Um die Übersetzung aus einem String zu ermöglichen, muss eine entsprechende Funktion implementiert werden, die einen String in den gewünschten Zieltyp übersetzt.
-Viele primitive Datentypen, wie Ganzzahlen und Gleitkommazahlen, werden von BehaviorTree.Cpp bereits durch mitgelieferte Funktionen unterstützt.
+Viele primitive Datentypen, wie Ganzzahlen und Gleitkommazahlen, werden von BehaviorTree.Cpp bereits durch native Funktionen unterstützt.
 
 Das Blackboard ist ein System, dass die Nutzung von Variablen als Parameter für Ports erlaubt.
 Diese werden im Hintergrund als eine Referenz auf den eigentlichen Wert gespeichert.
 Eine solche Funktion erlaubt das weitere Zerlegen von Vorgängen innerhalb des BehaviorTrees.
 Solche kleineren Nodes sind durch ihren limitierten Umfang universeller einsetzbar, da sie nur kleinere Teilprobleme betrachten, die zu komplexeren Strukturen zusammengesetzt werden können.
 
-Um die dadurch wachsenden Strukturen besser überblicken zu können, lassen sich Nodes als sogenannte Subtrees abspeichern.
+Um die dadurch wachsenden Strukturen besser überblicken zu können, lassen sich Gruppen von Nodes als sogenannte Subtrees abspeichern.
-Diese bilden dann in ihrer Gesamtheit eine neue Node, die im BehaviorTree eingesetzt werden kann.
+Diese bilden in ihrer Gesamtheit eine neue Node, die im BehaviorTree eingesetzt werden kann.
 Um den Einsatz von Variablen innerhalb eines Subtrees zu ermöglichen, besitzt jeder Subtree ein separates Blackboard.
 Dadurch kann auch ein Eingriff durch äußere Einflüsse verhindert werden.
 
@@ -389,29 +389,28 @@ Die Bibliothek \code{BehaviorTree.CPP} verbindet dann diese Werte und erlaubt di
 Da nicht jeder Prozess sofort vollständig durchgeführt werden kann, muss die Möglichkeit geschaffen werden, lang anhaltende Prozesse abzubilden.
 Dies geschieht in \code{BehaviorTree.CPP} durch asynchrone Nodes.
 
-Eine asynchrone Node besitzt neben den Zuständen SUCCESS und FAILURE einer normalen Node auch noch die beiden neuen Zustände RUNNING und IDLE.
+Eine asynchrone Node besitzt neben den Zuständen SUCCESS und FAILURE einer normalen Node auch die beiden neuen Zustände RUNNING und IDLE.
 Außerdem werden mehrere Funktionen definiert, die den Lebenszyklus der Node definieren.
 
 Wird eine Node durch den Aufruf der \code{onStart}-Funktion gestartet, geht diese in einen der Zustände RUNNING, SUCCESS oder FAILURE über.
 
 Der Zustand RUNNING steht dabei für eine Node, die sich noch in der Ausführung befindet.
-So lang dieser Zustand anhält, wird die Node nicht noch ein weiteres Mal gestartet, sondern nur der Zustand in der neuen \code{onRunning}-Funktion abgefragt.
+So lange dieser Zustand anhält, wird die Node nicht noch ein weiteres Mal gestartet, sondern nur der Zustand in der neuen \code{onRunning}-Funktion abgefragt.
 
 Der IDLE-Zustand ist ein besonderer Zustand, der nur durch eine vollständige Ausführung erreichbar ist.
 Er wird von der Node angenommen, nachdem deren Ausführung durch SUCCESS oder FAILURE beendet wurde.
 
 Im Falle eines Abbruchs, der durch andere Nodes im Baum ausgelöst werden könnte, muss die Ausführung der Node vorzeitig beendet werden können.
-Dies geschieht mit der neuen \code{onHalted}-Funktion.
+Dies geschieht mit der neuen \code{onHalted}-Funktion, welche ausgeführt wird, wenn die Ausführung der Node abgebrochen werden soll.
-Diese wird ausgeführt, wenn die Ausführung der Node abgebrochen werden soll.
 \subsection{Dateiformat}
 Das in BehaviorTree.Cpp verwendete Dateiformat, um Behavior Trees zu erstellen, basiert auf XML.
 Jedes Dokument beginnt dabei mit einem Root-Element, dass alle BehaviorTrees und eine Referenz auf die ID des Hauptbaumes enthält.
-Diese wird benötigt, da auch Unterbäume im selben Dokument deklariert und genuzt werden können, diese aber sonst nicht vom Hauptbaum unterscheidbar sind.
+Diese wird benötigt, da auch Unterbäume im selben Dokument deklariert und genutzt werden können, die aber sonst nicht vom Hauptbaum unterscheidbar sind.
 
 Jeder Baum beginnt mit einem BehaviorTree-Element, das als Attribut die ID des Baumes besitzen muss.
-Als untergeornete Elemente des Baumes werden die Nodes entsprechend der gewünschten Baumstruktur angeordnet.
+Als untergeordnete Elemente des Baumes werden die Nodes entsprechend der gewünschten Baumstruktur angeordnet.
 
-Als Beispiel wird der bereits im Konzept verwendete Behavior Tree (hier nochmals in Abbildung \ref{choice_tree_xml} zu sehen) in die entsprechende XML-Repräsentation umgewandelt.
+Als Beispiel wird der bereits im Konzept verwendete Behavior Tree (siehe Abbildung \ref{choice_tree_xml}) in die entsprechende XML-Repräsentation umgewandelt.
 Dabei ist zu beachten, dass die Root-Node in der Datei nicht existiert, da diese nur den Eintrittspunkt in die Struktur darstellt.
 Außerdem können selbst definierte Nodes sowohl direkt mit ihrem Namen, aber auch über den Namen Action mit ihrem Namen als ID-Parameter, referenziert werden.
 \begin{figure}[hpt]
@@ -443,22 +442,22 @@ Außerdem können selbst definierte Nodes sowohl direkt mit ihrem Namen, aber au
 
 \section{Virtualisierungsumgebung}
 
-Die Auswahl der Virtualisierungsumgebung erfolgt zwischen einer virtuellen Maschine und einer Containerumgebung.
+Bei Virtualisierungsumgebungen wird zwischen virtuellen Maschinen und Containerumgebungen unterschieden.
 
-Bei einer virtuellen Maschine (VM) werden alle Komponenten der Maschine simuliert, was das Nutzen anderer Betriebssysteme ermöglicht.
+Bei einer virtuellen Maschine (VM) werden alle Komponenten der Maschine simuliert, was die Nutzung anderer Betriebssysteme ermöglicht.
 Dies beinhaltet auch die Abstraktion von Speichermedien und anderen Geräten.
-Eine virtualisierte Umgebung erzeugt kleine Performanceverluste durch diese Abstraktion.
+Eine virtualisierte Umgebung erzeugt kleine Performanceverluste durch die Abstraktion.
 
 Eine Containerumgebung nutzt den Kernel des Hostsystems mit, was die Virtualisierug auf die Ebenen über dem Betriebssystem beschränkt.
 Die auszuführende Umgebung muss also mit dem Systemkernel lauffähig sein, um in einem Container ausgeführt werden zu können.
 Die Performanceverluste dieser Umgebung sind kleiner als die einer virtuellen Maschine, da grundlegende Teile des Systems nicht mehrfach ausgeführt werden müssen.
 
-Da bereits eine Linux-Maschine zur Entwicklung vorhanden ist, ist die Virtualisierung eines weiteren Linux-Kernels nur mit weiterem Performanceverlust verbunden.
+Da bereits eine Linux-Maschine zur Entwicklung vorhanden ist, wäre die Virtualisierung eines weiteren Linux-Kernels nur mit weiterem Performanceverlust verbunden.
-Außerdem soll in der Virtualisierungsumgebung Grafikbeschleunigung genutzt werden, wozu in einer VM eine Grafikkarte an das Zielsystem durchgereicht wird.
+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.
-In einer Containerumgebung kann die Grafikeinheit des Hostsystems mit genutzt werden, indem die Geräte in den Container hereingereicht werden.
+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.
 
-Auf Grund dieser Punkte wurde eine Containerumgebung verwendet.
+Diese Punkte sprechen für die Nutzung einer Containerumgebung.
-Docker ist eine verbreitete Umgebung für die Ausführung von Containern, die auf Grund der extensiven Dokumentation und Verfügbarkeit auf allen gängigen Linux-Systemen ausgewählt wurde.
+Docker ist eine etablierte Umgebung für die Ausführung von Containern, die auf Grund der extensiven Dokumentation und Verfügbarkeit auf allen gängigen Linux-Systemen ausgewählt wurde.
 
 Ein Container wird in Docker über sogenannte Build-Files definiert.
 Das Build-File enthält exakte Instruktionen, wie der Container aus anderen Containern, Dateien oder einer Kombination beider erstellt werden kann.

tex/4_Umsetzung.tex

@@ -22,7 +22,7 @@ Um Docker für die Verwaltung einer ROS-Installation verwenden zu können, müss
 Da viele Anwendungen, unter anderem auch die Simulationsumgebung, eine Desktopumgebung benötigen, musste der Zugriff auf eine solche Umgebung berücksichtigt werden.
 
 Diese Probleme können nicht durch Docker allein gelöst werden, da die Virtualisierungsumgebung eine Trennung der Systeme vorsieht.
-Die Isolation des Containers von der Benutzeroberfläche des Systemskann durch eine Kombination aus zwei Komponenten aufgehoben werden.
+Die Isolation des Containers von der Benutzeroberfläche des Systems kann durch eine Kombination aus zwei Komponenten aufgehoben werden.
 
 Um diese Modifikationen trotzdem reproduzierbar zu machen, wurde ein Shellscript geschrieben, dass zum Starten des Containers verwendet wird.
 
@@ -38,31 +38,36 @@ Um Zugriff auf die Grafikbeschleunigung des Systems zu erhalten, muss deren Repr
 Der Zugriff auf die Desktopumgebung, der im vorherigen Schritt entsperrt wurde, wird durch das mounten von \code{/tmp/.X11-unix} erreicht.
 Dabei handelt es sich um den Unix-Socket des X11 Displayservers.
 
-Zum Starten des Containers muss das Script \code{start.sh} im Verzeichnis der Containerinstallation ausgeführt werden.
+Zum Starten des Containers wird das Script \code{start.sh} im Verzeichnis der Containerinstallation ausgeführt.
-Dieser führt die obengenannten Schritte aus und startet den Container.
+Das Script führt die obengenannten Schritte aus und startet den Container.
 Eine Verbindung zum Container ist möglich, nachdem die Meldung \code{ros_1 | Ready to connect.} in der Konsole erscheint.
 
-Dafür wird ein SSH-Client eingesetzt, der eine Verbindung zu der lokalen Netzadresse des Systems mit dem Benutzer \code{ros} aufbauen kann.
+Dafür wird ein SSH-Client eingesetzt, der eine Verbindung zu der lokalen Netzadresse des Systems mit dem Benutzer \code{ros} aufbaut.
 Der Port des SSH-Servers wird dabei durch die Deklaration im docker-compose.yaml an das Hostsystem durchgereicht.
-Hierbei ist zu beachten, dass der SSH-Server im Container auf Port 2222 ausgeführt wird.
+Hierbei ist zu beachten, dass der SSH-Server im Container vom Host aus über Port 2222 erreichbar ist.
 
 Nach der Verbindung wird automatisch die ROS2-Umgebung eingerichtet.
-Diese kann ohne weitere Befehle nach Verbindungsaufbau genutzt werden.
+Diese kann ohne weitere Befehle nach dem Verbindungsaufbau genutzt werden.
-Um die erstellten Pakete zu kompilieren, wurde das Skript \code{build.sh} im \code{workspace}-Verzeichnis erstellt.
+Um die erstellten Pakete zu kompilieren, wurde das Skript \code{build.sh} (Abbildung \ref{buildscript}) im \code{workspace}-Verzeichnis erstellt.
 
+
+\begin{figure}
 \begin{minted}[breaklines,frame=single]{bash}
 #!/bin/bash
 pushd "$(dirname "$0")" || exit
 colcon build --event-handlers console_cohesion+ --cmake-args -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -G Ninja
 popd || exit
 \end{minted}
+\caption{build.sh Shellskript}
+\label{buildscript}
+\end{figure}
 
 Dieses Skript nutzt \code{colcon}, um alle Pakete in \code{~/workspace}-Verzeichnis zu erstellen.
 Dabei wird auch eine \code{compile_commands.json}-Datei im build-Unterordner erstellt, die von Entwicklungsumgebungen zur Syntaxvervollständigung genutzt werden.
 Um eine Nutzung in allen Entwicklungsumgebungen zu erlauben, wurde diese zusätzlich in das Hauptverzeichnis des Workspaces gelinkt.
-Dies ist dem Fakt geschuldet, dass einige Entwicklungsumgebungen nur dort nach dieser Datei suchen.
+Dies ist notwendig, da einige Entwicklungsumgebungen nur dort nach dieser Datei suchen.
 
-Da der Kompiliervorgang parallel abläuft, erscheinen Informationen zu allen Paketen gleichzeitig, was das Finden von Fehlern erschwert.
+Da der Kompiliervorgang parallel abläuft, erscheinen Informationen zu allen Paketen gleichzeitig, was die Zuordnung von Fehlern erschwert.
 Um trotzdem alle wichtigen Informationen zu erhalten, kommt der Event-Handler \code{console_cohesion} zum Einsatz, der die Ausgaben neu formatiert.
 Durch diesen werden die Ausgaben gruppiert, und erst nach einen vollständigen Kompiliervorgang eines Pakets nacheinander ausgegeben.
 Dies ermöglicht es, aufgetretene Fehler einfacher auf ein bestimmtes Paket zurückführen zu können, ohne das gesamte Log zu durchsuchen.
@@ -98,21 +103,20 @@ Dazu wird beim Start einer Verbindung zu einem entfernten System dieser Server a
 Die anfängliche Entwicklung wurde mit PyCharm und CLion durchgeführt, da diese durch ihre interne Codeanalyse die ROS-Umgebung ohne Konfiguration nutzen konnten.
 Jedoch sind diese Umgebungen sehr ressourcenintensiv, was die gleichzeitige Ausführung erheblich verlangsamt.
 
-Aus diesem Grund wurde später eine Entwicklungsumgebung mit LSP-Unterstützung, in diesem Fall Lapce, verwendet.
+Daher wurde später eine Entwicklungsumgebung mit LSP-Unterstützung, in diesem Fall Lapce, verwendet.
-Die Verwendung dieser Entwicklungsumgebung erfordert einen LSP-Server.
+Der dafür notwenige LSP-Server wird durch eine Veränderung des Buildscripts automatisch im Container installiert.
-Dieser wird durch eine Veränderung des Buildscripts automatisch im Container installiert.
 Unter Verwendung dieser neuen Server kann Lapce die Codevervollständigung und Codeanalyse wie PyCharm und CLion durchführen.
-Durch diese Maßnahme wird der Ressourcenverbrauch gesenkt, da nur ein einziger Editor benötigt wird.
+Gleichzeitig wird der Ressourcenverbrauch gesenkt, da nur ein einziger Editor benötigt wird.
 
-\begin{figure}
+\begin{figure}[ht]
 \includegraphics[width=\textwidth]{img/MA-Umsetzung-Lapce}
 \centering
 \caption{Entwicklungsumgebung Lapce}
 \label{lapce}
 \end{figure}
-
+\newpage
 \section{Verwendete Datentypen}\label{datatypes}
-In diesem Projekt werden viele unterschiedliche Datentypen für sowohl den Datenaustauch zwischen Nodes, aber auch in der internen Implementation der Nodes verwendet.
+In diesem Projekt werden viele unterschiedliche Datentypen sowohl für den Datenaustauch zwischen Nodes, als auch in der internen Implementation der Nodes verwendet.
 Diese Datentypen sind größtenteils aus der Programmiersprache C++ bekannt, jedoch werden auch weitere Typen aus eigenem Code oder eingebundenen Bibliotheken verwendet.
 Um die Verständlichkeit der Dokumentation zu erleichtern, sind die in der Implementation verwendeten Datentypen hier zusammengefasst und beschrieben.
 \begin{description}
@@ -123,29 +127,29 @@ Um die Verständlichkeit der Dokumentation zu erleichtern, sind die in der Imple
   Objekte wie der Mensch liegen in der Hierarchie der Simulation direkt unter der Welt, deren Pose sich direkt im Nullpunkt und ohne Rotation befindet.
   Durch diesen Umstand sind die Koordinaten des Menschen absolut, da sie nicht durch die Welt verschoben und rotiert werden.
   \item[Area]
-  ist eine Datenstruktur mit einem Vektor an Positionen, die eine Zone im Zweidimensionalen Raum definieren.
+  ist eine Datenstruktur mit einem Vektor an Positionen, die eine Zone im zweidimensionalen Raum definieren.
-  Jede Position ist eine einfache Datenstruktur aus 2 Gleitkommazahlen für je die X- und Y-Koordinate der Position.
+  Jede Position ist eine einfache Datenstruktur aus 2 Gleitkommazahlen, die den X- und Y-Koordinaten der Position entsprechen.
-  Der Verwendungszweck dieser Struktur ist die einfache Definition von Zonen, die für Positionsgenerierungen und Postionsabfragen genutzt werden können.
+  Der Verwendungszweck dieser Struktur ist die einfache Definition von Zonen, die für Positionsgenerierungen und Positionsabfragen genutzt werden können.
   \item[ActorPluginState]
   definiert 4 Zustände, die das ActorPlugin annehmen kann. Diese 4 Werte sind SETUP, IDLE, MOVEMENT und ANIMATION.
   \item[FeedbackMessage]
   beschreibt die erste der beiden MessageQueue-Nachrichten, die vom ActorPlugin an den ActorServer gesendet wird.
-  In dieser Struktur befindet sich der aktuelle Plugin-Zustand als \code{state} Parameter vom Typ ActorPluginState.
+  In dieser Struktur befindet sich der aktuelle Plugin-Zustand als \code{state} Parameter vom Typ ActorPluginState
-  Außerdem ein \code{progress} Parameter in Form einer Gleitkommazahl, die den Fortschritt der aktuellen Aktion angibt.
+  und außerdem ein \code{progress} Parameter in Form einer Gleitkommazahl, die den Fortschritt der aktuellen Aktion angibt.
-  Um bei Bewegungen die aktuelle Position des Menschen zu erhalten, ist auch die aktuelle Pose des Modells im Parameter \code{current} enthalten.
+  Um bei Bewegungen die aktuelle Position des Menschen zu erhalten, ist zusätzlich die aktuelle Pose des Modells im Parameter \code{current} enthalten.
   \item[ActionMessage]
   ist die zweite Nachricht, die über die zweite MessageQueue vom ActorServer an das ActorPlugin gesendet wird.
   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.
-  Ein \code{animationName} Parameter wird als ein char-Array mit einer maximalen Länge von 255 Zeichen übergeben.
+  Ein \code{animationName} Parameter wird als char-Array mit einer maximalen Länge von 255 Zeichen übergeben.
   Dieser bestimmt später die Animation, die je nach ActorPluginState während einer Bewegung oder Animation ausgeführt wird.
   Der \code{animationSpeed} Parameter beschreibt entweder die Abspielgeschwindigkeit der Animation, oder die zurückgelegte Distanz pro Animationsdurchlauf.
   Außerdem wird im Falle einer Bewegung der Parameter \code{target} vom Typ Pose verwendet, um die Endposition und Rotation des Actors zu bestimmen.
 \end{description}
 \section{Simulationswelt}
-Die Definition aller Simulationselemente findet im Paket \code{ign_world} statt.
+Die Definition aller Simulationselemente erfolgt im Paket \code{ign_world}.
 In diesem Paket sind sowohl die Geometrien der Welt, aber auch die benötigten Dateien zum Starten der Simulation enthalten.
 
-In diesem Fall handelt es sich um den Raum, in dem die Interaktion zwischen Mensch und Roboter stattfinden soll.
+Diese Dateien enthalten zum Beispiel die Definition des virtuellen Raumes, in dem die Simulation der Mensch-Roboter-Interaktion abläuft.
 Für diesen Raum wurde ein Raumplan erstellt, der alle benötigten Bereiche für die Szenarien besitzt (Abbildung \ref{room-plan}).
 
 Zuerst wird ein Stellplatz für den Roboter benötigt.
@@ -184,44 +188,41 @@ Dieses veranlasst mit dem \code{create}-Programm das Erstellen der übergebenen
 \end{figure}
 
 \section{Mensch}
-\subsection{Übersicht}
-Das angepasste Verfahren zur Steuerung des simulierten Menschens in der Simulation verwendet mehrere Kommunikationswege.
-Als erstes wird eine Bewegungs- oder Animationsanfrage an den ROS-Action-Server im ActorServer gesendet.
-Wenn die Simulation aktuell keinen Befehl ausführt, wird diese Anfrage akzeptiert, ansonsten wird sie abgebrochen.
-Daraufhin werden die Daten der Anfrage in Form des \code{ActionMessage}-Typs über eine Posix-Message-Queue vom ActorServer an das ActorPlugin in Gazebo gesendet.
 
-Anhand der \code{ActionMessage} wird die State-Machine im ActorPlugin in den richtigen Zustand für die angefragte Aktion gesetzt.
+Der Mensch soll in der Simulation verschiedene Aufgaben ausführen, die durch Behavior Trees definiert sind.
-Um diese auszuführen, werden der gewünschte Animationsname und weitere Parameter, die die Aktion beschreiben, aus der Nachricht übernommen.
+Um diese Aufgaben visuell darzustellen, werden verschiedene Animationen für ein Modell des Menschen benötigt.
+Ein Modell eines Menschen ist bereits in Gazebo integriert, welches als sogenannter ``Actor'' durch vorher definierte Pfade bewegt werden kann.
+Die für das Modell existierenden Animationen müssen um die gewünschten Animationen erweitert werden.
 
-Das Feedback an den Client des ROS-Action-Servers wird bei Zustandswechseln und während laufenden Aktionen des ActorPlugins generiert.
+Um diese Animationen eines Modells in Bewegungen und Verhalten umzuwandeln, muss das Verhalten während der Simulation gesteuert werden.
-Dabei wird der aktuelle Zustand mitsamt einigen weiteren Daten, in diesem Fall die Position des Actors und der aktuelle Fortschritt der Aktion an den ActorServer gesendet.
+Dies erfolgt über das ActorPlugin, welches in Gazebo ausgeführt wird.
-Dies geschieht über eine zweite MessageQueue, die den \code{FeedbackMessage}-Datentyp überträgt.
+Mit diesem Plugin kann der Mensch in der Simulation gesteuert werden.
-Diese werden durch den ActorServer aufbereitet, da nicht alle Daten für die jeweilige laufende Aktion relevant sind und an den ROS-Action-Client gesendet.
+Da eine Anbindung an ROS in Gazebo nicht möglich ist, kommuniziert das ActorPlugin mit dem ActorServer über MessageQueues.
+Dieser ActorServer übersetzt Nachrichten und Anfragen zwischen ROS und der MessageQueue des ActorPlugins.
 
-Um diese Befehle in der Simulation auch visuell umsetzen zu können, werden weitere Animationen für das Modell des Menschen benötigt, die im Kontext der zur erfüllenden Aufgabe relevant sind.
-Dafür muss das Modell in einen animierbaren Zustand gebracht werden, in dem dann weitere Animationen erstellt und in die Simulation eingebunden werden können.
 \subsection{Modellierung}
 Um neue Animationen für den Menschen in der Simulation erstellen zu können, muss ein Modell für diesen erstellt werden.
-Dafür wurde eine der bereits modellierten Laufanimationen von Gazebo in Blender geöffnet und das visuelle Modell kopiert.
+Dafür wurde eine der bereits modellierten Laufanimationen von Gazebo in Blender geöffnet und bearbeitet.
 
+Eine Kopie des Menschenmodells aus der Laufanimation dient als Grundlage für das neue Modell.
 Dieses Modell ist durch die interne Geometrie, zum Beispiel zwischen Körper und Pullover der Person, nur schlecht für Animationen geeignet.
-Die Geometrie bildet ``Falten'' im Modell, die während der Animation hervortreten können, was zu unerwarteten Artefakten führen kann.
+Die interne Geometrie bildet ``Falten'' im Modell, die während der Animation hervortreten können, was zu unerwarteten Artefakten führen kann.
-Solche Artefakte entstehen durch unterschiedliche Verschiebung der Strukturen, die aus dem inneren des ursprünglichen Modells hervortreten, wenn dieses bewegt wird.
+Solche Artefakte entstehen durch unterschiedliche Verschiebung der Strukturen, die aus dem inneren des ursprünglichen Modells hervortreten, wenn es bewegt wird.
-In diesem Fall kam es häufig zum Hervortreten der Haut unter dem Rollkragen und der Hose.
+Beim kopierten Modell kam es häufig zum Hervortreten der Haut unter dem Rollkragen und der Hose.
-Diese Artefakte wurden durch die Vereinfachung des Modells an diesen Stellen behoben.
+Diese Artefakte wurden durch die Vereinfachung des Modells an den entsprechenden Stellen behoben.
 
 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.
 Diese fehlenden Knochen werden für einige der gewünschten Animationen benötigt und müssten hinzugefügt werden.
-Da das importierte Skelett noch andere Fehler aufwies, wurde dieses verworfen.
+Da das importierte Skelett noch andere Fehler aufwies, wurde es verworfen.
 
 Um ein neues, passendes Skelett zu erstellen, wurde mit dem ``Rigify''\cite{rigify}-Plugin ein standartisiertes Menschenskelett generiert.
 Dieses neue Skelett kann an das bereits vorhandene Modell angepasst werden.
-Um eine bessere Übersicht zu ermöglichen, sollten als erstes alle nicht benötigten Skeletteile, wie zum Beispiel für Gesichtsanimationen, entfernt werden.
+Um eine bessere Übersicht zu ermöglichen, sollten zuerst alle nicht benötigten Skeletteile, wie zum Beispiel für Gesichtsanimationen, entfernt werden.
 Danach müssen die Knochen durch Verschiebung und Skalierung an die richtigen Positionen im Modell gebracht werden.
 
 Dabei muss auf die Ausrichtung der Knochen zueinander geachtet werden.
 Das Kreuzprodukt der Vektoren beider Knochensegmente bestimmt die Richtung der Beugeachse, die sich im Verbindungspunkt beider Knochen befindet.
-Ist diese nicht richtig ausgerichtet, wenn zum Beispiel beide Knochen auf einer Gerade liegen, bewegen sich Gelenke bei der Verwendung von inverser Kinematik zur Positionsvorgabe falsch.
+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.
 Der Grund dafür ist das Kreuzprodukt, dass im oben genannten Fall ein Nullvektor ist, wodurch keine Beugeachse bestimmt werden kann.
 
 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.
@@ -245,7 +246,7 @@ Dieser muss senkrecht zu dieser Gerade und der gewünschten Biegeachse verschobe
 \end{figure}
 
 \begin{figure}
-\includegraphics[width=.8\textwidth]{img/MA-Umsetzung-Joint}
+\includegraphics[width=.5\textwidth]{img/MA-bend-axis}
 \centering
 \caption{Visualisierung der generierten Beugeachse}
 \label{bend}
@@ -256,6 +257,7 @@ Das neu erstellte Skelett ist in Abbildung \ref{person-bones} visualisiert.
 Um eine bessere Verformung bei der Bewegung von Knochen zu erreichen, wird das so genannte ``weight painting'' eingesetzt.
 Hierfür werden für jeden Knochen entweder automatisch oder manuell Teile des Meshes mit Gewichten versehen.
 Je höher die Wichtung, desto stärker ist die Verformung an dieser Stelle, wenn der Knochen bewegt oder skaliert wird.
+Die so erstellten Knochen werden auch als deformierende Knochen bezeichnet, da deren Bewegung das Modell beeinflusst.
 
 Da das Animieren aller Knochen einzeln sehr zeitaufwändig ist, werden diese in Gruppen zusammengefasst.
 Hierfür werden in Blender sogenannte Constraints eingesetzt, die Knochen automatisch durch eingestellte Bedingungen positionieren können.
@@ -283,13 +285,41 @@ Der Quader in der Hüfte gibt die gewünschte Höhe des Modells vor, die auch f
 Die anderen Knochen beeinflussen die Rotation des Beckens, der Wirbelsäule, der Schultern und des Kopfes.
 
 Das hier erstellte, verbesserte Rigify-Skelett kann durch den Einsatz der neuen Constraints einfacher animiert werden.
-Die Verwendung des so erstellten Rigs ist in vielen Grafikengines, darunter auch Gazebo, noch nicht möglich.
+
-Es bedarf einer zusätzlichen Anpassung des Skeletts, bei der die verschachtelte Knochenstruktur aufgelöst wird.
+\subsection{Erstellen von Animationen}
+
+Animationen werden in Blender über sogenannte Keyframes erstellt.
+Ein Keyframe stellt dabei einen spezifischen Zeitpunkt in der Animation dar.
+Jedem Keyframe kann eine beliebige Anzahl von Knochenpositionen zugeordnet werden.
+
+Eine Animation entsteht, sobald mehrere Keyframes auf der Zeitachse existieren.
+Alle zugeordneten Positionen werden zwischen beiden Keyframes durch auswählbare Kurven interpoliert.
+In Abbildung \ref{actorinterpolate} wird dieser Prozess am Beispiel der ``low_to_standing''-Animation dargestellt.
+
+Für die neuen Animationen werden die erstellten Steuerknochen verwendet, welche die später in Gazebo sichtbaren Knochen über Constraints beeinflussen.
+
+\begin{figure}
+\centering
+\begin{minipage}{.25\textwidth}
+\includegraphics[width=\textwidth]{img/MA-Animation-Human-Start}
+\end{minipage}
+\begin{minipage}{.25\textwidth}
+\includegraphics[width=\textwidth]{img/MA-Animation-Human-Interpolated}
+\end{minipage}
+\begin{minipage}{.25\textwidth}
+\includegraphics[width=\textwidth]{img/MA-Animation-Human-End}
+\end{minipage}
+\caption{Erste und letzte Keyframes einer Animation mit interpoliertem Zwischenbild}
+\label{actorinterpolate}
+\end{figure}
 
 \subsection{Export der Modellanimationen}
 
-Um aus einem existierenden, vollständig verbundenen Skelett einzelne Knochen zu extrahieren, exisitiert ein weiteres Plugin mit dem Namen ``GameRig''\cite{gamerig}.
+Die Verwendung des hier erstellten, verbesserten und animierten Rigs ist in vielen Grafikengines, darunter auch Gazebo, noch nicht möglich.
-Dieses separiert die neuen Steuerknochen wieder vom ursprünglichen Modell, wodurch in diesem nur noch die deformierenden Knochen enthalten sind.
+Es bedarf einer zusätzlichen Anpassung des Skeletts, bei der die neu erstellte Knochenstruktur aufgelöst wird, da Gazebo keine Constraints unterstützt.
+
+Um aus einem existierenden, vollständig verbundenen Skelett ein Skelett ohne verbundene Knochen zu extrahieren, exisitiert ein weiteres Plugin mit dem Namen ``Game_Rig_Tools''\cite{gamerig}.
+Dieses separiert die neuen Steuerknochen wieder vom ursprünglichen Modell, damit in diesem nur noch die deformierenden Knochen enthalten sind.
 
 Alle erstellten Animationen der Steuerknochen müssen in direkte Bewegungen der deformierenden Knochen des Modells umgewandelt werden.
 Um dies zu erreichen wird der in Abbildung \ref{export-prepare} visualisierte Arbeitsablauf verwendet.
@@ -328,7 +358,7 @@ Ein solcher Fehler äußert sich in Gazebo durch verdrehte Knochen während der
 \hfill
 \includegraphics[width=.5\textwidth]{img/MA-Umsetzung-Animation-Prepare2}
 \end{subfigure}
-\caption{Vorbereitung zum Export mit GameRig}
+\caption{Vorbereitung zum Export mit Game_Rig_Tools}
 \label{export-prepare}
 \end{figure}
 
@@ -371,7 +401,7 @@ da diese zur Kommunikation genutzt werden
 Das HTTP besitzt jedoch keinen einheitlichen Feedbackmechanismus.
 Dieser müsste entweder durch kontinuierliche Abfragen des aktuellen Status, auch ``polling'' genannt, oder eine lang anhaltende Request realisiert werden.
 Eine Verwendung von kontinuierlichen Abfragen ist zwar mit fast jeder Programmiersprache möglich, jedoch ist die Reaktionszeit des Systems an die Antwortzeit des Servers gebunden.
-Der Einsatz einer lang anhaltenden Request umgeht dieses Problem, jedoch müssen der eingesetzte Webserver und Client dieses Feature unterstützen.
+Der Einsatz einer lang anhaltenden Request umgeht dieses Problem, jedoch müssen der eingesetzte Webserver und der Client diese Funktion unterstützen.
 
 Das neuere Websocket-Protokoll\cite{websocket} bieten die Möglichkeit, bidirektional Daten zu übertragen.
 Dadurch können Aktionsanfragen und Feedback auf dem gleichen Kanal übertragen werden, was das Protokoll übersichtlicher macht.
@@ -397,8 +427,9 @@ Die Angaben zu den Durchsätzen der verschiedenen Datenübertragungsmechanismen
 
 Als Nachrichtendienst wurde die MessageQueue ausgewählt, da die integrierten Funktionen die Entwicklung erleichtern und die Geschwindigkeit ausreichend für das Einsatzszenario ist.
 Jedoch existieren unter Linux 2 unabhängige Implementationen von MessageQueues mit unterschiedlichen Funktionen.
+
 Die erste Implementation ist die System V MessageQueue\cite{mqSystemV}, und verwendet zur Identifikation einfache Ganzzahlen.
-Eine Spezialität dieser alten Implementation ist das Sortieren der Nachrichten nach Nachrichtentyp in der gleichen Warteschlange.
+
 Die neuere Implementation der MessageQueue ist die POSIX-MessageQueue.\cite{mqPosix}
 Sie bietet einige weitere Funktionen, wie zum Beispiel asynchrone Benachrichtigungen bei neuen Nachrichten, Quality of Service und nutzt bis zu 256 Zeichen lange Zeichenketten zur Identifikation.
 
@@ -440,6 +471,7 @@ Ein ActionServer innerhalb eines Programmes definiert 3 Funktionen, welche die H
   Diese erhält als Parameter ein Objekt, mit dem Feedback- und Endnachrichten an den Client gesendet werden können.
  }
 \end{itemize}
+
 Die gesamte Kommunikation einer Anfrage verläuft wie in Abbildung \ref{plugin_sequence} dargestellt.
 Zuerst wird durch den Client eine Zielvorgabe an den Server gesendet.
 Sollte der Server diese abweisen, wird die Kommunikation beendet.
@@ -482,7 +514,7 @@ Das Plugin wird durch den Startvorgang und später von den empfangenen Nachricht
   Diese kann durch einen Skalierungsfaktor beschleunigt oder verlangsamt werden.
 \end{description}
 
-In diesen Zuständen muss das ActorPlugin die Simulationsumgebung beeinflussen, in dem die simulierte Person bewegt und animiert wird.
+In diesen Zuständen muss das ActorPlugin die Simulationsumgebung beeinflussen, in der die simulierte Person bewegt und animiert wird.
 Dies erfordert den Zugriff auf simulationsinterne Daten, die durch das Plugin gelesen und verändert werden sollen.
 Der Zugriff auf diese Daten wird durch ein EntityComponentManager-Objekt ermöglicht.
 
@@ -490,6 +522,7 @@ Durch den EntityComponentManager kann auf das so genannte ``Entity Component Sys
 Ein Entity Component System besteht aus einer oder mehr Entities, die Objekte innerhalb der Simulation abbilden.
 Objekte können beliebig viele Components besitzen, bei denen es sich um zusätzliche Eigenschaften und Erweiterungen der Funktionen des betroffenen Objekts handelt.
 Die wichtigsten Komponenten für die Funktion des Plugins sind dabei:
+
 \begin{description}
  \item[components::Actor]
   Dieses Objekt beschreibt die simulierte Person mit allen weiteren Daten, wie zum Beispiel deren Animationen.
@@ -531,14 +564,14 @@ Das ActorPlugin benötigt für seine Funktion das übergeornete Simulationsobjek
 Dies erfordert die Implementation des \code{ISystemConfigure}-Interfaces für das ActorPlugin.
 Außerdem soll die simulierte Person bewegt werden. Da dieser Vorgang während der Simulationszeit ablaufen soll, muss hierfür das \code{ISystemUpdate}-Interface genutzt werden.
 
-Als erstes wird durch das Laden die Configure-Funktion aufgerufen.
+Als erstes wird durch das Laden des Plugins die Configure-Funktion aufgerufen.
 Da das Plugin erst durch Gazebo geladen werden muss, kann davon ausgegangen werden, dass alle benötigten Message Queues bereits durch den ActorServer erstellt wurden.
 Trotz dieses Umstandes wartet das Plugin auf deren Erstellung, um bei Konfigurationsfehlern auffälliges Verhalten zu zeigen.
 Im Log wird diese Aktion vermerkt, um das Debugging zu erleichtern.
 Nach dem erfolgreichen Aufbau der Verbindung wird ein Thread gestartet, der die eingehenden Nachrichten verarbeitet.
 Dabei wird zuerst ein Sperre gesetzt, um parallele Zugriffe durch die Update-Funktion zu verhindern.
 Alle in der Anfrage gespeicherten Daten werden übernommen und der gewünschte State gesetzt.
-Nach dem Entsperren der Sperre wird im nächsten Simulationschritt die gewünschte Aktion durchgeführt.
+Nach dem Entfernen der Sperre wird im nächsten Simulationschritt die gewünschte Aktion durchgeführt.
 
 Das Setzen aller obrigen Zustände ist dabei möglich, jedoch werden nur Idle, Animation und Movement genutzt.
 Der Idle-Zustand kann zum Beenden eines anderen Zustands eingesetzt werden, falls dieser abgebrochen werden soll.
@@ -549,7 +582,7 @@ Sollte die Animation nicht gefunden werden, wird versucht, diese anhand ihres Na
 Wurde eine Animation gefunden, wird deren Länge gespeichert, um diese später für das Feedback nutzen zu können.
 
 Ab diesem Zeitpunkt unterscheiden sich die Implementation von Animation und Movement.
-Im Zustand der Animation wird die Komponente AnimationTime jedes Update aktualisiert.
+Im Zustand der Animation wird die Komponente AnimationTime bei jedem Update aktualisiert.
 Um die Ausführungsgeschwindigkeit einer Animation anpassen zu können, wird ein Skalierungsfaktor genutzt.
 Dieser optionale Faktor kann mit der abgelaufenen Zeit multipliziert werden.
 Dies verursacht eine Beschleunigung oder Verlangsamung der Ausführung.
@@ -601,10 +634,9 @@ Im Falle des Bewegungs-ActionServers werden mehrere Parameter benötigt.
 Zuerst werden Animationsname und -diztanz benötigt, um die richtige Animation auszuwählen und die Bewegung mit der Animation zu synchronisieren.
 Als Feedbacknachricht erhält der Client die aktuelle Pose des Actors im Simulationsraum.
 
-Soll eine Animation über den Action Server abgespielt werden, wird auch hier ein Animationsname, jedoch auch eine Animationsgeschwindigkeit benötigt.
+Soll eine Animation über den Action Server abgespielt werden, wird neben dem Animationsnamen noch die Animationsgeschwindigkeit als Parameter benötigt.
-Die Feedbacknachricht enthält den Fortschritt der Animation als Gleitkommazahl.
+Die Feedbacknachricht enthält den Fortschritt der Animation als Gleitkommazahl von null bis eins.
 \section{Roboter}
-\subsection{Übersicht}
 Der Roboter besteht aus mehreren interagierenden Systemen, die in ihrer Gesamtheit das vollständige Robotermodell in der Simulation verwendbar machen.
 
 Zuerst muss ein Modell des Roboters erstellt werden, dass in Gazebo geladen werden kann.
@@ -621,7 +653,7 @@ Dabei muss darauf geachtet werden, dass die exportierten Daten eine ausreichende
 Diese kann vor dem Export in FreeCAD eingestellt werden.
 Durch diese Einstellung bleiben feine Strukturen erhalten, die später in Blender wieder reduziert werden können.
 Ein solches Vorgehen erlaubt es Blender, bessere Entscheidungen über die Reduktion von Strukturen zu treffen.
-Das Resultat ist ein besseres Endmodell des Roboters.
+Das Resultat ist ein exakteres Endmodell des Roboters.
 
 \begin{figure}
 \includegraphics[width=\textwidth/2]{img/MA-Roboter-Rohdaten}
@@ -631,13 +663,13 @@ Das Resultat ist ein besseres Endmodell des Roboters.
 \end{figure}
 
 Diese Dateien können dann in Blender bearbeitet werden, um sie für die Simulation tauglich zu machen.
-Hierfür wurde die hohe Auflösung der Modelle reduziert, was sich in kleineren Dateien und Startzeiten der Simulation, aber auch in der Renderzeit der Simulation, auswirkt.
+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.
 Außerdem wurden die Glieder so ausgerichtet, dass sich der Verbindungspunkt zum vorherigen Glied im Nullpunkt des Koordinatensystems befindet.
 Das vollständige visuelle Modell ist in Abbildung \ref{robot_visual} zu sehen.
 
-Um die Simulation weiter zu beschleunigen, wurden die Kollisionsboxen des Arms noch weiter vereinfacht, was die Kollisionsüberprüfung dramatisch beschleunigt.
+Um die Simulation weiter zu beschleunigen, wurden die Kollisionsboxen des Arms noch weiter vereinfacht, was die Kollisionsüberprüfung deutlich beschleunigt.
 Dabei werden stark simplifizierte Formen verwendet, die das hochqualitative visuelle Modell mit einfachen Formen umfassen.
-Das resultierende Modell, dass in Abbildung \ref{robot_collision} dargestellt wird, wird später zur Kollisionserkennung verwendet.
+Das resultierende Modell, in Abbildung \ref{robot_collision} dargestellt, wird später zur Kollisionserkennung verwendet.
 
 Diese Herangehensweise ist nötig, da die Kollisionserkennung auf der CPU durchgeführt und durch komplexe Formen stark verlangsamt wird.
 
@@ -676,7 +708,7 @@ Diese können standardmäßig nicht in Gazebo, RViz und MoveGroup gleichzeitig g
 
 Eine Möglichkeit zur Lösung des Problems ist die Verwendung von \code{file://}-URIs, die von allen dieser Programme gelesen werden können.
 Der Moveit Setup Assistent kann diese URIs nicht lesen, was zu Fehlern bei einer Rekonfiguration führen kann.
-Fall eine Neukonfiguration des Roboters mit dem Assistenten durchgeführt werden soll, muss diese Umwandlung temporär rückgängig gemacht werden.
+Falls eine Neukonfiguration des Roboters mit dem Assistenten durchgeführt werden soll, muss diese Umwandlung temporär rückgängig gemacht werden.
 
 Das so erstellte Modell kann über den Aufruf von \code{ros2 launch iisy_config demo.launch.py} in RViz getestet werden.
 Hierfür erscheint das Robotermodell mit mehreren Markern und Planungsoptionen, die genutzt werden können, um beliebige Bewegungen zu planen und auszuführen.
@@ -719,7 +751,7 @@ Diese lassen sich nach Nutzung in verschiedene Gruppen einordnen.
   \item[InterruptableSequence]
   stellt eine Sequence dar, die auch nach ihrem Abbruch ihre Position behält.
   Dies ist notwendig, wenn ein bestimmtes Verhalten unterbrechbar ist, aber zu einem späteren Zeitpunkt fortgesetzt werden soll.
-  Hierzu wird der Iterator der unterlegenden Sequenz nur erhöht, wenn die untergeordnete Node SUCCESS zurück gibt.
+  Hierzu wird der Iterator der unterlegenden Sequenz nur erhöht, wenn die untergeordnete Node SUCCESS zurückmeldet.
   Außerdem wird der Iterator nicht zurückgesetzt, wenn die Ausführung dieser modifizierten Sequenz abgebrochen wird.
   \item[WeightedRandom]
   ist eine Steuerungsnode, die mehrere untergeordnete Nodes besitzt.
@@ -769,9 +801,9 @@ Um die RobotMove-Node nicht zu unterbrechen, wird diese nur über einen Callback
 \subsection{Subtrees}
 Um die Wiederverwendung von bestimmten Abläufen zu erleichtern, wurden diese in Subtrees ausgelagert.
 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.
-Dies erhöht die Lesbarkeit der Bäume und vereinfacht die Verwendung gleicher Aktionen in mehreren Bäumen.
+Diese Abstraktion erhöht die Lesbarkeit der Bäume und vereinfacht die Verwendung gleicher Aktionen in mehreren Bäumen.
 
-Für das Arbeiten an der Werkbank ist eine Bewegung zu dieser erforderlich.
+Für das Arbeiten an der Werkbank ist eine Bewegung des Menschen hin zu dieser erforderlich.
 Außerdem muss sich der Mensch zur Werkbank ausrichten, um die späteren Animationen korrekt auszuführen.
 Dazu wird eine Bewegung zu einem Punkt vor der Werkbank mit vorgegebener Zielrichtung genutzt.
 Nach dieser Bewegung soll ein Arbeitsprozess simuliert werden.
@@ -793,12 +825,11 @@ Der vollständige resultierende Baum ist in Abbildung \ref{subtree_work} visuali
 Das Ablegen von Objekten in einem Schrank ist ein komplizierterer Prozess, da der Schrank in mehreren Ebenen befüllt werden kann.
 Außerdem sind mehrere Fächer verfügbar, die genutzt werden können.
 
-Wie bereits bei der Werkbank wird zuerst eine Bewegung zum Schrank ausgeführt.
+Wie bereits bei der Werkbank wird zuerst eine Bewegung hin zum Schrank ausgeführt.
 Diese hat eines der drei im Schrank vorhandenen Schrankteile zum Ziel.
 Die Auswahl des Ziels erfolgt zufällig durch eine WeightedRandom-Node, die eine der drei Bewegungs-Nodes ausführt.
 
-Nachdem erfolgt eine weitere zufällige Auswahl.
+Danach erfolgt eine weitere zufällige Auswahl die entscheidet, ob das obere oder das untere Fach des betreffenden Schranks genutzt werden soll.
-Diese entscheidet, ob ein oberes oder unteres Fach genutzt werden soll.
 
 Im Falle eines oberen Faches werden nur zwei Animationen benötigt.
 Die Hand wird zu einem oberen Fach ausgestreckt und zurückgezogen.
@@ -824,7 +855,7 @@ Das grundlegende Verhalten des Roboters ist in jedem Anwendungsfall gleich.
 Dies hängt mit der automatischen Geschwindigkeitsanpassung zusammen.
 Der Roboter soll bei annäherndem Mensch zuerst seine Geschwindigkeit reduzieren, wenn dieser eine Warnzone betritt.
 Falls sich der Mensch weiter bis in die Sicherheitszone begibt, ist ein temporärer Stopp des Roboters vorgesehen.
-Dieser Stopp soll nach dem Entfernen aus der Sicherheitszone wieder aufgehoben werden, um die Arbeit fortzusetzen.
+Dieser Stopp soll nach dem Entfernen des Menschen aus der Sicherheitszone wieder aufgehoben werden, um die Arbeit fortzusetzen.
 
 Um diese Funktionen zu erlauben, ist eine Reaktion auf Statusänderungen von vorherigen Nodes nötig.
 Dies wird durch eine übergeordnete ReactiveSequence erreicht.
@@ -880,11 +911,12 @@ Im anderen Fall soll das Objekt auf den rechten Tisch gelegt werden.
 Von dort aus soll der Mensch dieses Objekt abholen, um den Ausschuss im Regal zu verstauen.
 Es wird dafür die gleiche Operationsabfolge aus dem ersten Szenario verwendet.
 Am Ende der übernommenen Sequenz wird eine SetCalledTo-Node ergänzt, die den Menschen ruft.
+Eine Visualisierung des modifizierten Baums wird in Abbildung \ref{tree_robot_coop} gezeigt.
 
 \begin{figure}
 \includegraphics[width=\textwidth]{img/MA-tree-robot-coop}
 \centering
-\caption{BehaviorTree für das Ablegen von Objekten im Schrank}
+\caption{Erweiterter BehaviorTree des Roboters bei Kooperation}
 \label{tree_robot_coop}
 \end{figure}
 
@@ -898,11 +930,12 @@ Da diese Probleme durch den Menschen behoben werden sollen, muss ein Mechanismus
 Hierfür wird eine Fallback-Node über der InterruptableSequence angeordnet.
 Diese Fallback-Node führt im Fall eines Fehlers in der InterruptableSequence die nächste Node aus.
 Bei dieser handelt es sich um eine SetCalledTo-Node, welche den Menschen ruft.
+Der Aufbau des Baumes wird in Abbildung \ref{tree_base_colab} dargestellt.
 
 \begin{figure}
 \includegraphics[width=\textwidth]{img/MA-tree-robot-colab}
 \centering
-\caption{BehaviorTree für das Ablegen von Objekten im Schrank}
+\caption{Erweiterter BehaviorTree des Roboters bei Kollaboration}
 \label{tree_base_colab}
 \end{figure}
 

tex/5_Evaluation_und_Diskussion.tex

@@ -85,6 +85,17 @@ Dies wird durch die RandomFailure-Node erreicht.
 
 Eine Kombination dieser neu implementieren und den bereits in BehaviorTree.CPP verfügbaren Nodes kann alle in den Szenarien benötigten Verhaltensweisen darstellen.
 
+\subsection{Erstellen der benötigten Pakete}
+
+Alle benötigten Pakete müssen vor der ersten Ausführung der Simulation kompilliert werden.
+Dies wird durch das Ausführen des \code{build.sh}-Skripts im Verzeichnis \code{\textasciitilde/workspace} des Container ausgelöst.
+Nach diesem Vorgang muss der Workspace neu geladen werden, damit die jetzt verfügbaren Pakete registriert werden.
+
+Die kann sowohl durch einen erneuten Aufbau der SSH-Verbindung erfolgen, da bei Start der Session die entsprechende Datei geladen wird, oder manuell geschehen.
+Für das manuelle Laden des Workspaces muss der Befehl \code{source /home/ros/workspace/install/setup.bash} in der Konsole ausgeführt werden.
+
+Nach dem Laden des Workspaces ist die Umgebung für die Simulation einsatzbereit.
+
 \section{Simulation der Szenarien}
 Das Starten der Simulation erfolgt über ein Skript innerhalb des \code{ign_world}-Pakets.
 Dieses Skript wird durch den Befehl \code{ros2 launch ign_world gazebo_controller_launch.py} ausgeführt.
@@ -122,7 +133,7 @@ Diese werden nach dem Start einer Simulation ausgeführt und definieren das Verh
 Im Koexistenzszenario interagieren Roboter und Mensch nur im Ausnahmefall.
 Der Roboter simuliert einen Entladevorgang, bei welchem Objekte vom linken Tisch auf den rechten Tisch bewegt werden (Abbildung \ref{coex-move}).
 Die für diesen Zweck implementierten Bewegungsnodes werden in späteren Szenarien weiter verwendet.
-Um den Menschen nicht zu gefährden, wird die Verfahrgeschwindigkeit automatisch and die Aufenthaltszone des Menschen angepasst.
+Um den Menschen nicht zu gefährden, wird die Verfahrgeschwindigkeit automatisch an die Aufenthaltszone des Menschen angepasst.
 
 Der Arbeitsvorgang des Menschen besteht aus dem Arbeiten an einer Werkbank und dem Verbringen von Material in das Regal (Abbildung \ref{coex-shelf}).
 In diesem Szenario begibt sich der Mensch nur mit einer Wahrscheinlichkeit von 5\% nach jedem Arbeitsvorgang zum Roboter.

tex/6_Ausblick.tex

@@ -17,13 +17,13 @@ Diese können für Roboterbewegungen und Menschensimulation verwendet werden.
 Die Simulation bewegter Objekte benötigt ein neues Gazebo-Plugin, welches mit den bereits entwickelten Komponenten der aktuellen Umgebung interagiert.
 Um ein Objekt mit dem Roboter oder Menschen zu bewegen, muss dieses auf eine von zwei Arten bewegt werden.
 
-Die Bewegung mit dem Roboter ist möglich, da dieser aus mehreren Physikobjekten besteht.
+Die Bewegung von Objekten mit dem Roboter ist möglich, da dieser mit der gegenwärtigen Implementation aus mehreren Physikobjekten besteht.
-Das Objekt kann somit an das Objekt des Endeffektors als Unterobjekt hinzugefügt werden.
+Das zu  bewegende Objekt kann somit dem Objekt des Endeffektors als Unterobjekt hinzugefügt werden.
 Der daraus resultierende Übergang in lokale Koordinaten kann potentielle Umrechnung anhand der Transformationen vorhergehender Armteile erfordern.
 
 Eine Bewegung mit dem Menschen erfordert vor allem bei Animationen einen anderen Mechanismus.
 Da der Mensch nicht aus einzelnen Physikobjekten besteht, ist die Anbringung als Unterobjekt nicht möglich.
-Stattdessen muss die aktuelle Position des Armes anhand der Animationsdaten verfolgt werden, um die Position des Objektes diesen anzupassen.
+Stattdessen muss die aktuelle Position des Armes anhand der Animationsdaten verfolgt werden, um die Position des Objektes an diese anzupassen.
 
 Die unterschiedliche Anbindung von Roboter und Mensch erfordert mehrere Implementationen, welche Zustandsdaten über das Objekt austauschen müssen.
 Um die Objekte zu steuern, muss eine weitere ROS-Anbindung in einem entsprechenden Gazebo-Plugin erfolgen.
@@ -69,7 +69,7 @@ Weitere universelle Node-Parameter vereinfachen den Aufbau von Bäumen durch die
 Ein Nachteil der Migration wäre jedoch das Wegfallen einiger Funktionen des Editors, welcher in dieser Version unter einer neuen Lizenz vertrieben wird.
 Die Analyse von Logdateien nach der Ausführung und die Überwachung von Bäumen zur Laufzeit sind ohne kostenpflichtige Lizenz nicht mehr möglich.
 
-Eine weitere Alternative ist die Nutzung von MoveIt Studio, welches auch mit Behavior Trees arbeitet.
+Eine weitere Alternative ist die Nutzung von MoveIt Studio\cite{moveItStudio}, welches ebenfalls mit Behavior Trees arbeitet.
 Die direkte Integration mit MoveIt vereinfacht die Anbindung an den Roboter, da wichtige Funktionen bereits implementiert sind.
 Jedoch ist die Unterstützung für eigene Befehle nur schlecht dokumentiert.
 Diese werden aber für die Steuerung des Menschen benötigt, was dieses Alternative nur für die Robotersteuerung attraktiv macht.

uml/plugin_connectivity.puml

@@ -11,20 +11,17 @@ participant ActorPlugin as plugin
 activate server
 activate plugin
 
-==Goal==
-
 [-> client: neuer ActionClient
 activate client
 
-client -> server: Goal-Anfrage
+client -> server: Zielvorgabe
-server -->> client: Antwort auf Anfrage
+server -->> client: Antwort auf Zielvorgabe
 
-alt Anfrage akzeptiert?
+alt Zielvorgabe akzeptiert?
 server ->> plugin: neuen Status und Ziel setzen
 plugin -->> server: Zustandswechsel bei\nnächstem Simulationsschritt
-== Feedback==
 group opt par [Abbruch der Aktion]
-client->server: Cancel-Anfrage
+client->server: Abbruchanfrage
 server->plugin: Status auf Idle setzen
 plugin -->> server: Zustandswechsel auf Idle
 server-->>client: positive Abbruchantwort
@@ -33,9 +30,8 @@ loop Bis Aktion vollständig ausgeführt oder abgebrochen ist
 plugin -->> server: Feedback
 server -->> client: Feedback
 end
-==Result==
 plugin -->> server: Zustandswechsel auf Idle
-server -->> client: Result-Antwort
+server -->> client: Endnachricht
 end
 destroy client
 @enduml