Fixes for errors in chapter 4

.kile/mechforsch.kilepr.gui

@@ -2,7 +2,7 @@
 kile_livePreviewEnabled=true
 kile_livePreviewStatusUserSpecified=true
 kile_livePreviewTool=LivePreview-PDFLaTeX
-lastDocument=tex/6_Ausblick.tex
+lastDocument=tex/5_Evaluation_und_Diskussion.tex
 
 [document-settings,item:Einleitung.tex]
 Bookmarks=
@@ -139,11 +139,11 @@ TextFolding={"checksum":"","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:main.bib]
-CursorColumn=20
+CursorColumn=0
-CursorLine=108
+CursorLine=0
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"7dd721e78f3a584f245ca717d88453d9d1888b82","ranges":[]}
+TextFolding={"checksum":"b10ad087170976892139d22580412bc441722b7c","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:main.tex]
@@ -171,35 +171,35 @@ TextFolding={"checksum":"60485ed57cc9cd7aa26821b7c57cadfc76a24734","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/3_Auswahl.tex]
-CursorColumn=0
+CursorColumn=28
-CursorLine=49
+CursorLine=132
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"860366adcb7dc59b870dcd7c34c98c68b581d6d0","ranges":[]}
+TextFolding={"checksum":"6b7f9d13d5c6f43641e50a66c4529ff479e866b6","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/4_Umsetzung.tex]
-CursorColumn=41
+CursorColumn=91
-CursorLine=6
+CursorLine=853
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"3d0063a21b9a74ae5488307f1048b49b8724b500","ranges":[]}
+TextFolding={"checksum":"5c4f9f82c6c2646c073a4757f197beed4b273c78","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/5_Evaluation_und_Diskussion.tex]
-CursorColumn=41
+CursorColumn=0
-CursorLine=118
+CursorLine=51
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"b17d8b3f6bc2bdeb9ad7095d96896e959cba5b05","ranges":[]}
+TextFolding={"checksum":"ab50ad5132cf05a1290a02b2b48c793d41937fb9","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/6_Ausblick.tex]
-CursorColumn=53
+CursorColumn=0
-CursorLine=22
+CursorLine=39
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"7fca53ae81408bb5cfc595cefb1dbfffcdb121bd","ranges":[]}
+TextFolding={"checksum":"85f5725ed69452476240fe61ecbb12cc35b38976","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/Einleitung.tex]

main.bib

@@ -298,3 +298,28 @@ doi = {https://doi.org/10.1201/9780429489105}
   url = {https://answers.ros.org/question/267261/how-can-i-run-ros2-nodes-in-a-debugger-eg-gdb/},
   note = {letzter Zugriff 29.06.2023},
 }
+@misc{mqPosix,
+  title = {mq_overview(7) — Linux manual page},
+  url = {https://man7.org/linux/man-pages/man7/mq_overview.7.html},
+  note = {letzter Zugriff 30.06.2023},
+}
+@misc{mqSystemV,
+  title = {sysvipc(7) — Linux manual page},
+  url = {https://man7.org/linux/man-pages/man7/sysvipc.7.html},
+  note = {letzter Zugriff 30.06.2023},
+}
+@misc{shmem,
+  title = {shm\_overview(7) — Linux manual page},
+  url = {https://man7.org/linux/man-pages/man7/shm_overview.7.html},
+  note = {letzter Zugriff 30.06.2023},
+}
+@misc{websocket,
+  title = {RFC 6455 - The WebSocket Protocol},
+  url = {https://datatracker.ietf.org/doc/html/rfc6455},
+  note = {letzter Zugriff 30.06.2023},
+}
+@misc{ipcBench,
+  title = {goldsborough/ipc-bench: :horse_racing: Benchmarks for Inter-Process-Communication Techniques},
+  url = {https://github.com/goldsborough/ipc-bench},
+  note = {letzter Zugriff 30.06.2023},
+}

main.tex

@@ -26,7 +26,6 @@ parskip=half,
 \usepackage{subcaption}
 \usepackage[strings]{underscore}
 
-
 \usepackage[letterspace=150]{microtype}
 
 \usepackage[page]{totalcount}

tex/1_Einleitung.tex

@@ -4,8 +4,7 @@ Die Simulation von Maschinen wird im industriellen Umfeld immer beliebter, um de
 Dazu wird ein Modell des gesamten Prozesses in der Simulation geschaffen, der durch die Maschine beeinflusst werden soll.
 Das Modell wird um die Maschine selbst erweitert, die Einfluss auf das System nimmt.
 Die Veränderungen durch die Maschine werden analysiert, und erlauben Rückschlüsse auf die Funktion des Systems.
-Ein solches Modell kann nun für die Erkennung von Fehlverhalten und Problemen schon weit vor der eigentlichen Inbetriebnahme der Maschine genutzt werden.
+Ein solches Modell kann für die Erkennung von Fehlverhalten und Problemen schon weit vor der eigentlichen Inbetriebnahme der Maschine genutzt werden.
-
 
 Im wachsenden Feld der Mensch-Roboter-Kollaboration existieren bereits einige Lösungen, um auch die namensgebende Interaktion von Mensch und Roboter simulieren zu können.
 Eine häufige Einschränkung der Simulatoren ist dabei, dass der Bewegungsablauf in der Simulation bereits vor deren Ausführung fest definiert werden muss.
@@ -24,7 +23,7 @@ Aktuelle wissenschaftliche Arbeiten befassen sich mit vielen unterschiedlichen T
 Die Planung von unterschiedlichen Reaktionen von Roboter auf den Menschen in verschiedenen Interaktionsszenarien stellt eine Grundlage für spätere
 Projekte dar.\cite{DOMBROWSKI2018134}
 Hierbei wird die erwünschte Interaktion betrachtet und aus den gewonnenen Daten werden Einschränkungen generiert.
-Diese Einschränkungen können nun in der Interaktion verwendet werden, um Verletzungen durch den Roboter auszuschließen.
+Diese Einschränkungen können in der Interaktion verwendet werden, um Verletzungen 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.
@@ -60,7 +59,7 @@ Auch hier soll der Mensch solange eigenständig arbeiten, bis der Roboter ein au
 Die dritte simulierte Aufgabe stellt ein Kollaborationsszenario dar, in dem Mensch und Roboter an der selben Aufgabe arbeiten.
 Hierbei soll eine Palette entladen werden, wobei der Roboter nicht jedes Objekt ausreichend manipulieren kann.
 Dies resultiert in Problemen beim Aufheben, Transport und Ablegen der Objekte.
-In diesen Fällen muss nun ein Mensch aushelfen, wodurch er mit dem Roboter in Interaktion tritt.
+In diesen Fällen muss ein Mensch aushelfen, wodurch er mit dem Roboter in Interaktion tritt.
 Dieser soll, wenn seine Hilfe nicht benötigt wird, andere Roboter kontrollieren, was durch das Laufen im Raum abgebildet werden soll.
 \section{Contributions}
 Durch diese Arbeit soll in zukünftigen Projekten die Möglichkeit geschaffen werden, konzeptionelle Probleme bei der Erstellung neuer Aufgabenbereiche eines Roboters frühzeitig durch Simulation erkennbar zu machen.

tex/2_Konzept.tex

@@ -40,7 +40,7 @@ Das zu erstellende Modell soll dabei um weitere Animationen erweiterbar sein.
 Unterschiedliche Animationen gehen dabei meist von verschidenen Ursprungszuständen aus.
 Um zwischen diesen Ursprungszuständen wechseln zu können, werden weitere Animationen benötigt.
 
-Die so erstellten Animationen müssen nun von außerhalb der Simulationsumgebung ausführbar gemacht werden.
+Die so erstellten Animationen müssen von außerhalb der Simulationsumgebung ausführbar gemacht werden.
 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.
@@ -96,7 +96,7 @@ Von dort aus wird als erstes die Sequenz-Node ausgeführt, die drei untergeordne
 
 Diese drei Nodes werden in Leserichtung, in diesem Falle von links nach rechts, ausgeführt.
 Daraus resultierend wird als erstes die linke Node ausgeführt, diese ist jedoch eine Fallback-Node mit weiteren untergeordneten Nodes.
-Da der Rückgabewert der Fallback-Node von den in ihr befindlichen Nodes bestimmt wird, werden diese nun nacheinander ausgeführt.
+Da der Rückgabewert der Fallback-Node von den in ihr befindlichen Nodes bestimmt wird, werden diese nacheinander ausgeführt.
 Hier gelten die oben genannten Regeln für Fallback-Nodes.
 In diesem Fall wird geprüft, ob die Tür bereits offen ist.
 Da dies nicht der Fall ist, wird die nächste Node ausgeführt, welche die Tür öffnen soll.
@@ -104,7 +104,7 @@ Dieser Versuch gelingt, weshalb die Ausführung der Fallback-Node mit einem Erfo
 
 Dadurch wird die nächste Node in der Sequenz ausgeführt, die prüft, ob die Tür durchlaufen werden kann.
 Da dies nicht möglich ist, da die Tür zwar offen, aber durch dahinter liegende Gegenstände blockiert ist, wird ein Misserfolg gemeldet, der die Ausführung der Sequenz abbricht.
-Diese würde nun von neuem beginnen, da die Root-Node ihre untergeornete Node ohne Berücksichtigung des Rückgabewertes neu startet.
+Diese würde von neuem beginnen, da die Root-Node ihre untergeornete Node ohne Berücksichtigung des Rückgabewertes neu startet.
 
 Durch die Definition neuer Nodes und einer anderen Baumstruktur lassen sich so einfach neue Verhalten implementieren.
 Dies erlaubt die schnelle Anpassung des Verhaltens der gesteuerten Systeme.

tex/3_Auswahl.tex

@@ -43,7 +43,7 @@ Für zum Beispiel Python\cite{python}, C und C++\cite{cpp} existieren entspreche
 
 Die neuste Version ROS2 bietet dabei mehrere Verbesserungen im Vergleich zu früheren Version ROS1 \cite{changesRosII}.
 Ein neues Nachrichtenformat mit Quality of Service kann beispielsweise Nachrichten zwischenspeichern und über sowohl TCP, als auch UDP kommunizieren.
-Außerdem werden nun neben CMake\cite{cmake} auch andere Buildsysteme unterstützt, was die Verwendung von Python erlaubt.
+Außerdem werden neben CMake\cite{cmake} auch andere Buildsysteme unterstützt, was die Verwendung von Python erlaubt.
 
 Generell existieren im Feld der Roboter-Dienstumgebungen keine freien Alternativen mit ähnlichem Funktionsumfang und gleicher Reichweite.
 Vor allem die unzähligen ROS-Bibliotheken, die von Nutzern des Systems über die Jahre erstellt wurden, machen das System so populär.\cite{rospackages}

tex/4_Umsetzung.tex

@@ -35,7 +35,7 @@ Diese Änderung gestattet es dem Container, Fenster auf dem Desktop anzuzeigen,
 Dies geschieht durch Einträge in der compose.yml-Datei, die diese als ``bind mount'' in den Container hereinreicht.
 
 Um Zugriff auf die Grafikbeschleunigung des Systems zu erhalten, muss deren Repräsentation im SysFS unter \code{/dev/dri} hineingereicht werden.
-Der Zugriff auf die Desktopumgebung, der im vorherigen Schritt entsperrt wurde, wird nun durch das mounten von \code{/tmp/.X11-unix} erreicht.
+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.
@@ -78,7 +78,7 @@ Um diese Funktionen bieten zu können, analysieren Entwicklungsumgebungen den ge
 Dies geschieht meist auf eine von zwei unterschiedlichen Weisen.
 
 Die Entwicklungsumgebung kann eine interne Repräsentation des geschriebenen Codes generieren.
-Diese Repräsentation kann nun genutzt werden, um die implementierten Funktionen der Entwicklungsumgebung bereitzustellen.
+Diese Repräsentation kann genutzt werden, um die implementierten Funktionen der Entwicklungsumgebung bereitzustellen.
 Um dies zu erreichen, muss für jede unterstützte Sprache Code geschrieben werden, der in die Entwicklungsumgebung integriert wird.
 
 Als Alternative existiert das Language Server Protocol, kurz LSP\cite{lsp}, dass eine Schnittstelle in Form eines JSON-RPC Protokolls zur Verfügung stellt, um Infomationen über den Code an die Entwicklungsumgebung zu übergeben.
@@ -101,7 +101,7 @@ Jedoch sind diese Umgebungen sehr ressourcenintensiv, was die gleichzeitige Ausf
 Aus diesem Grund wurde später eine Entwicklungsumgebung mit LSP-Unterstützung, in diesem Fall Lapce, verwendet.
 Die Verwendung dieser Entwicklungsumgebung erfordert einen LSP-Server.
 Dieser wird durch eine Veränderung des Buildscripts automatisch im Container installiert.
-Unter Verwendung dieser neuen Server kann Lapce nun Codevervollständigung und Codeanalyse wie PyCharm und CLion durchführen.
+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.
 
 \begin{figure}
@@ -111,7 +111,7 @@ Durch diese Maßnahme wird der Ressourcenverbrauch gesenkt, da nur ein einziger
 \label{lapce}
 \end{figure}
 
-\section{Verwendete Datentypen}
+\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.
 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.
@@ -217,7 +217,7 @@ Da das importierte Skelett noch andere Fehler aufwies, wurde dieses 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.
-Nun müssen die Knochen durch Verschiebung und Skalierung an die richtigen Positionen im Modell gebracht 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.
@@ -263,7 +263,7 @@ Hierfür werden in Blender sogenannte Constraints eingesetzt, die Knochen automa
 Durch das Verwenden von Rigify und einem standardisierten Skelett ist die automatische Generierung der Constraints möglich.
 Hierfür können die in dem Skelett enthaltenen Informationen vom Plugin genutzt werden, um alle häufig genutzten Constraints automatisch zu generieren.
 In diesem Schritt werden auch neue Knochen eingefügt, die das Skelett durch Constraints beeinflussen.
-Das neue Animationsmodell, visualisiert in Abbildung \ref{person-armature}, kann nun für Animationen genutzt werden.
+Das neue Animationsmodell, visualisiert in Abbildung \ref{person-armature}, kann jetzt für Animationen genutzt werden.
 
 Hierfür stehen mehrere Knochengruppen zur Verfügung, die typische Animationsmethoden abdecken.
 
@@ -282,7 +282,7 @@ Die gelben Knochen beeinflussen die generelle Pose des Modells.
 Der Quader in der Hüfte gibt die gewünschte Höhe des Modells vor, die auch für die inverse Kinematik benutzt wird.
 Die anderen Knochen beeinflussen die Rotation des Beckens, der Wirbelsäule, der Schultern und des Kopfes.
 
-Das hier erstellte, verbesserte Rigify-Skelett kann nun durch den Einsatz der neuen Constraints einfacher animiert werden.
+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.
 
@@ -291,7 +291,7 @@ Es bedarf einer zusätzlichen Anpassung des Skeletts, bei der die verschachtelte
 Um aus einem existierenden, vollständig verbundenen Skelett einzelne Knochen zu extrahieren, exisitiert ein weiteres Plugin mit dem Namen ``GameRig''\cite{gamerig}.
 Dieses separiert die neuen Steuerknochen wieder vom ursprünglichen Modell, wodurch in diesem nur noch die deformierenden Knochen enthalten sind.
 
-Alle erstellten Animationen der Steuerknochen müssen nun in direkte Bewegungen der deformierenden Knochen des Modells umgewandelt werden.
+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.
 
 Im ersten Schritt wird das zu exportierende Skelett ausgewählt, um diesem später die neue Animation zuweisen zu können.
@@ -300,11 +300,11 @@ Dann muss im zweiten Schritt die gewünschte Animation der Liste der bekannten A
 Danach muss die durch die Constraints abgebildete Animation auf das ausgewählte Skelett übertragen werden, was mit dem ``Bake Action Bakery''-Knopf ausgelöst wird.
 Dabei wird die Position aller deformierenden Knochen zu jedem Zeitpunkt der Animation bestimmt, und in einer neuen Animation mit modifiziertem Namen abgespeichert.
 
-Diese neu erstellte Animation kann nun im vierten Schritt dem ausgewählten Skelett zugewiesen werden.
+Diese neu erstellte Animation kann im vierten Schritt dem ausgewählten Skelett zugewiesen werden.
 Nach dieser Veränderung kann die Animation im Collada-Format exportiert werden.
 Dazu muss das visuelle Modell der Selektion hinzugefügt werden, da Gazebo dieses für jede Animation benötigt.
 
-Nun kann der Export über die in Blender integrierte Exportoption ausgelöst werden.
+Jetzt kann der Export über die in Blender integrierte Exportoption ausgelöst werden.
 Hierfür müssen die in Abbildung \ref{export-settings} gezeigten Exporteinstellungen verwendet werden, damit Gazebo die exportierte Animation nutzen kann.
 Alle in der Blender-Version 3.5 nicht standardmäßigen Einstellungen wurden dabei durch Punkte hervorgehoben.
 
@@ -316,7 +316,7 @@ Die Punkte 3. und 4. bewirken, dass das exportierte Modell die in Gazebo verwend
 In Blender ist Y als Vorwärtsachse üblich, jedoch verwendet Gazebo die X-Achse für diesen Zweck.
 Wird diese Modifikation nicht vorgenommen, sind die Modelle um 90 Grad verdreht.
 
-Nun muss im mit 5 markierten Animations-Reiter noch eine letzte Einstellung vorgenommen werden.
+Zuletzt muss im mit 5 markierten Animations-Reiter noch eine weitere Einstellung vorgenommen werden.
 Die mit 6 markierte Einstellung bewirkt, dass alle Bewegungen der exportierten Knochen mit gespeichert werden, auch wenn diese sich nicht bewegen.
 Da sich einige Knochen in der Animation in einer konstanten Pose befinden, exportiert Blender diese nicht.
 Dies führt zu Fehlern, falls die Knochen von der Standartposition abweichen.
@@ -351,85 +351,95 @@ Um dies zu ermöglichen werden beim Start der Simulation zusätzliche Programme
 
 Nach der ersten Implementation des ActorPlugins kam es zu Kollisionen mit \code{ros_control}, die beide \code{rclcpp} zur Kommunikation benutzen.
 Diese Kollisionen führt zu einem Crash, wenn beide Plugins in der Simulation geladen werden.
-Dies geschieht, da beide Plugins rclcpp, eine Bibliothek zur Kommunikation mit ROS-Topics, verwenden.
+Der Crash geschieht, da beide Plugins rclcpp, eine Bibliothek zur Kommunikation mit ROS-Topics, verwenden.
 
 In dieser Bibliothek wird eine globale Instanz angelegt, die den Zustand des Kommunikationsprotokolls abbildet.
 Da jedoch von beiden Plugins auf diesen Zustand zugegriffen wird, kommt es zur Problemen, da kein Synchronisationsmechanismus existiert.
 Die dadurch entstehenden gleichzeitigen Zugriffe auf die selben Ressourcen führen zur Terminierung des Programms.
 
-Nach dem Debuggen des Crashes wurden einige Problemlösungen ausprobiert, jedoch ließ sich der Konflikt durch Modifikation des ActorPlugins allein nicht verhindern, weshalb ein anderer Weg zur Problembehebung gewählt werden musste.
+Nachdem die Fehlerursache ermittelt war, stellte sich heraus, daß der Konflikt allein durch Modifikation des ActorPlugins nicht aufzulösen ist.
 
-Eine Anpassung beider Plugins auf die gemeinsame Nutzung einer Ressource ist möglich, erfordert jedoch potentiell weitreichende Neuimplementationen, die zeitlich nur schwer planbar sind.
+Eine Anpassung beider Plugins auf die gemeinsame Nutzung der Bibliothek ist möglich, erfordert aber potentiell weitreichende Neuimplementationen, die zeitlich im Rahmen dieser Arbeit nicht umsetzbar waren.
 Die Nutzung eines separaten Nachrichtendienstes, der keinen globalen Kontext benötigt, ist die sicherste und schnellste Lösung des Problems.
-Jedoch erfordert diese Implementation zusätzliche Logik, um die beiden Dienste ineinander übersetzen zu können.
+Eine solche Implementation erfordert jedoch zusätzliche Logik, um die beiden Dienste ineinander übersetzen zu können.
 
-Die Auswahl eines Dienstes wurde dabei aus einer Reihe an unterschielichen Möglichkeiten getroffen.
+Die Auswahl eines Dienstes wurde dabei aus einer Reihe an unterschiedlichen Möglichkeiten getroffen.
-Webdienste, wie zum Beispiel REST-API's und Websockets werden von vielen Sprachen nativ untersützt, was sie zu guten Kanidaten für solche Kommunikation macht.
+Webdienste, wie zum Beispiel REST-API's und Websockets werden von vielen Sprachen nativ untersützt, was diese universell einsetzbar macht.
 
-Eine REST-API hat den Vorteil, dass sie durch fast jede Programmiersprache genutzt werden kann, die Sockets unterstützt, besitzt jedoch keinen einheitlichen Feedbackmechanismus.
+Eine REST-API hat den Vorteil, dass sie durch fast jede Programmiersprache genutzt werden kann, die Hyper Text Transfer Protocol, auch HTTP genannt, unterstützt.
-Dieser müsste entweder durch kontinuierliche Abfragen des aktuellen Status oder eine lang laufende Request mit zerstückelter Antwort realisiert werden.
+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 von zerstückelten Antworten 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 Client dieses Feature unterstützen.
 
-Die neueren Websockets bieten die Möglichkeit, bidirektional Daten zu übertragen.
+Das neuere Websocket-Protokoll\cite{websocket} bieten die Möglichkeit, bidirektional Daten zu übertragen.
 Dadurch können Aktionsanfragen und Feedback auf dem gleichen Kanal übertragen werden, was das Protokoll übersichtlicher macht.
-Beide Technologien basieren jedoch auf einem Webserver, der auf einem bestimmten Port des Systems ausgeführt werden muss, was Kollisionen mit anderen Serveices ermöglicht.
+Beide Technologien basieren auf einem Webserver, der auf einem bestimmten Port des Systems ausgeführt werden muss, was Kollisionen mit anderen Services ermöglicht.
 Die Portnummer kann zwar geändert werden, ist jedoch nicht einfach mit einer Komponente assoziierbar, was sie zu einer ``Magischen Zahl'' macht.
 Dies sorgt für schlechte Lesbarkeit in einem wichtigen Teil des Kontrollflusses.
-Außerdem besitzen beide Terchnologien durch TCP oder UDP und HTTP relativ großen Protokolloverhead, der bei den hohen Updateraten der Gazebo-Simulation zu Problemen führen könnte.
+Außerdem besitzen beide Technologien durch TCP oder UDP und HTTP relativ großen Protokolloverhead, der bei den hohen Updateraten der Gazebo-Simulation zu Problemen führen könnte.
 
-Eine andere Möglichkeit ist die Nutzung von ``shared memory'', einem geteilten Speicherbereich zwischen beiden Programmen.
+Eine andere Möglichkeit ist die Nutzung von ``shared memory'', einem geteilten Speicherbereich zwischen beiden Programmen.\cite{shmem}
 Dieser kann zur bidirektionalen Kommunikation genutzt werden, da beide Programme auf den gleichen Speicherbereich zugreifen können.
 Alle Zugriffe auf den Bereich sind extrem schnell, da sie den Arbeitsspeicher des Systems nie verlassen, was diese Technik ideal zur Datenübertragung zwischen Prozessen macht.
-Durch das erlauben gleichzeitiger Zugriffe kann es hierbei vorkommen, dass beide Programme gleichzeitig versuchen, Änderungen am Speicher vorzunehmen.
+Durch das Erlauben gleichzeitiger Zugriffe kann es vorkommen, dass beide Programme gleichzeitig versuchen, Änderungen am Speicher vorzunehmen.
-Diese gleichzeitige Modifikation kann zu Fehlern führen, wenn die Zugriffe auf den Bereich nicht kontrolliert werden.
+Diese gleichzeitige Modifikation, auch ``race condition'' genannt, kann zu Fehlern führen, wenn die Zugriffe auf den Bereich nicht kontrolliert werden.
 
 Die letzte betrachtete Methode ist die Verwendung einer Message Queue.
 Hier wird im Betriebssystem ein Speicherbereich mit bestimmter Größe für den Datenaustauch reserviert.
 Dieser Bereich besitzt ein Identifikationsmerkmal, dass es Anwendungen erlaubt, Zugriff auf diesen zu erlangen.
 Ein Programm kann in diesem Bereich Daten ablegen, die durch andere Programme gelesen und geschrieben werden können.
-Die Koordinierung der Zugriffe erfolgt dabei durch das Betriebssystem, was gleichzeitige Zugriffe, wie bei shared memory, aussschließt.
+Die Koordinierung der Zugriffe erfolgt dabei durch das Betriebssystem, was gleichzeitige Zugriffe, wie bei shared memory, ausschließt.
-Durch diesen Umstand kommt es zu einem Anstieg an Latenzzeit.
+Durch diesen Umstand kommt es zu einer Reduktion des Nachrichtendurchsatzes.
 
-Die Wahl des Dienstes fiel auf eine MessageQueue, da die integrierten Funktionen die Entwicklung erleichtern und die Geschwindigkeit ausreichend für das Einsatzszenario ist.
+Die Angaben zu den Durchsätzen der verschiedenen Datenübertragungsmechanismen wurden mit \code{ipc-bench}\cite{ipcBench} auf dem Entwicklungssystem ermittelt.
-Jedoch existieren unter Linux 2 unabhängige Implementationen von MessageQueues mit unterschidelichen Funktionen.
+
-Die erste Implementation ist die System V MessageQueue, und verwendet zur Identifikation einfache Ganzzahlen.
+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 POSIX MessageQueue bietet einige weitere Funktionen, wie zum Beispiel aynchrone Benachrichtigungen bei neuen Nachrichten, Quality of Service und nutzt bis zu 256 Zeichen lange Zeichenketten zur Identifikation.
+Die neuere Implementation der MessageQueue ist die POSIX-MessageQueue.\cite{mqPosix}
+Sie bietet einige weitere Funktionen, wie zum Beispiel asynchrone Benachrichtigungen bei neuen Nachrichten, Quality of Service und nutzt bis zu 256 Zeichen lange Zeichenketten zur Identifikation.
 
 Die ausgewählte Implementation ist die neuere POSIX-Implementation einer Message Queue, da diese basierend auf den Erfahrungen mit der System V Implementation entwickelt wurde.
 \subsubsection{ROS-Nachrichten}
 Die verwendeten Nachrichten für den ActionServer, als auch für die Message Queue sind in den entsprechenden Paketen \code{ros_actor_action_server_msgs} und \code{ros_actor_message_queue_msgs} organisiert.
 Sie sind absichtlich nicht in den nutzenden Paketen untergebracht, da sie durch ein externes Programm in den benötigten Code umgewandelt werden.
-Dieser Schritt muss vor dem Kompiliervorgang der nutzenden Pakete geschehen, was so am einfachsten realisiert werden kann.
+Dieser Schritt muss vor dem Kompiliervorgang der nutzenden Pakete geschehen.
-Dazu werden diese Nachrichtenpakete als Dependency der nutzenden Pakete angegeben, was eine automatische Anpassung der Kompilantionsreihenfolge bewirkt.
+Dazu werden diese Nachrichtenpakete als Dependency der nutzenden Pakete angegeben, was eine automatische Anpassung der Kompilationsreihenfolge bewirkt.
 
 Eine Action des \code{ros_action}-Pakets besteht immer aus 3 einzelnen Nachrichten, deren Inhalt frei definiert werden kann.
-
+\begin{enumerate}
-Zum Start der Action wird die erste Nachricht vom Client an den Server gesendet.
+ \item{Zum Start der Action wird die erste Nachricht vom Client an den Server gesendet.
 In dieser Startnachricht befinden sich alle Informationen, die zur Ausführung der Action benötigt werden.
-Nach dieser Nachricht kann der Server später entscheiden, ob die Aktion ausgeführt werden soll und sie gegebenenfalls abbrechen.
+Nach dieser Nachricht kann der Server später entscheiden, ob die Aktion ausgeführt werden soll und sie gegebenenfalls abbrechen.}
-
+ \item{Nach dem Beginn der Action werden vom Server eine oder mehrere Feedbacknachrichten an den Client gesendet, die den Fortschritt der Action beschreiben.
-Nach dem Beginn der Action werden vom Server Feedbacknachrichten an den Client gesendet, die den Fortschritt der Action beschreiben.
+Dabei ist es die Aufgabe des Programmierers, diese an signifikanten Punkten des Ablaufs zu senden.}
-Dabei ist es die Aufgabe des Programmierers, diese an sinnvollen Punkten des Ablaufs zu senden.
+ \item{Am Ende der Action wird die Endnachricht an den Client gesendet, die weitere Rückgabewerte liefern kann.
-
+Die Endnachricht enthält standardmäßig eine Erfolgsangabe, weshalb diese nicht angegeben werden muss.}
-Am Ende der Action wird die Endnachricht an den Client gesendet, die weitere Rückgabewerte liefern kann.
+\end{enumerate}
-Die Endnachricht enthält standartmäßig eine Erfolgsangabe, weshalb diese nicht angegeben werden muss.
 
 Ein ActionServer innerhalb eines Programmes definiert 3 Funktionen, welche die Handhabung einer Aktion definieren.
-Die erste Funktion übergibt den Wert der Startnachricht, die mit einer Antwort quittiert werden muss.
-Hierbei sind die Antworten ACCEPT_AND_DEFER, ACCEPT_AND_EXECUTE und REJECT möglich.
 
-Die erste mögliche Antwort ACCEPT_AND_EXECUTE signalisiert die sofortige Ausführung des gewünschten Befehls.
+\begin{enumerate}
-Als Alternative existiert die Antwort ACCEPT_AND_DEFER, die für eine verspätete Ausführung der gewünschten Aktion steht.
+ \item{
-Die REJECT-Antwort weist die Ausführung der Aktion vorzeitig ab.
+  Die erste Funktion übergibt den Wert der Startnachricht, die mit einer Antwort quittiert werden muss.
-
+  Hierbei sind die Antworten ACCEPT_AND_DEFER, ACCEPT_AND_EXECUTE und REJECT möglich.
-Die zweite Funktion übergibt Abbruchanfragen an den Server, falls die Aktion durch den Client abgebrochen werden soll.
-Auch diese Anfrage kann entweder mit ACCEPT akzeptiert werden, oder mit REJECT zurückgewiesen werden.
-
-Um Feedback während der Ausführung der Aktion geben zu können, exisitiert die dritte Funktion.
-Diese erhält als Parameter ein Objekt, mit dem Feedback- und Endnachrichten an den Client gesendet werden können.
 
+  Die erste mögliche Antwort ACCEPT_AND_EXECUTE signalisiert die sofortige Ausführung des gewünschten Befehls.
+  Als Alternative existiert die Antwort ACCEPT_AND_DEFER, die für eine verspätete Ausführung der gewünschten Aktion steht.
+  Die REJECT-Antwort weist die Ausführung der Aktion vorzeitig ab.
+ }
+ \item{
+  Die zweite Funktion übergibt Abbruchanfragen an den Server, falls die Aktion durch den Client abgebrochen werden soll.
+  Auch diese Anfrage kann entweder mit ACCEPT akzeptiert werden, oder mit REJECT zurückgewiesen werden.
+ }
+ \item{
+  Um Feedback während der Ausführung der Aktion geben zu können, exisitiert die dritte Funktion.
+  Diese erhält als Parameter ein Objekt, mit dem Feedback- und Endnachrichten an den Client gesendet werden können.
+ }
+\end{enumerate}
 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.
@@ -456,15 +466,15 @@ Dieser Zustandswechsel löst die Meldung einer vollständigen Ausführung des ge
 \end{figure}
 
 \subsubsection{ActorPlugin}
-Das ActorPlugin steuert anhand von empfangenen Nachrichten aus der eingehenden Message Queue den Menschen in der Simulationsumgebung.
+Das ActorPlugin steuert den Menschen in der Simulationsumgebung anhand von empfangenen Nachrichten aus der eingehenden Message Queue.
 Der Code des Plugins ist dabei im Paket \code{ign_actor_plugin} organisiert, dass im Gazebo-Modell der Welt referenziert werden muss, um das Plugin zu laden.
 
-Das Plugin wird durch den Startvorgang und später von den empfangenen Nachrichten in mehrere Zustände versetzt, die im folgenden erläutert werden:
+Das Plugin wird durch den Startvorgang und später von den empfangenen Nachrichten in folgende Zustände versetzt werden:
 \begin{description}
  \item[Setup]
   wird ausschließlich zu Simulationsbeginn verwendet, um alle benötigten Referenzen aus der Simualtionumgebung im Plugin zu hinerlegen, so dass diese in den anderen Zuständen genutzt werden können.
  \item[Idle]
-  ist der Zustand, der nach erfolgreicher Ausführung eines Befehls angenommen wird.
+  definiert den Zustand, der nach erfolgreicher Ausführung eines Befehls angenommen wird.
  \item[Movement]
   bedeutet die Ausführung einer Bewegung in potentiell mehreren Schritten.
  \item[Animation]
@@ -482,19 +492,19 @@ Objekte können beliebig viele Components besitzen, bei denen es sich um zusätz
 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 dessen Animationen.
+  Dieses Objekt beschreibt die simulierte Person mit allen weiteren Daten, wie zum Beispiel deren Animationen.
  \item[components::AnimationName]
   In dieser Komponente wird der aktuell verwendete Animationsname abgelegt, der von Gazebo zur Auswahl der aktuell laufenden Animation verwendet wird.
  \item[components::AnimationTime]
   enthält den aktuellen Zeitpunkt innerhalb der Animation, um die richtigen Positionsdaten aus dieser auswählen zu können. Dabei wird zwischen einzelnen Positionen linear interpoliert, falls der Zeitpunkt zwischen diesen liegt.
  \item[components::Pose]
-  entspricht einer bereits beschriebenen Pose, jedoch verwendet Gazebo dafür diesen neuen Datentyp.
+  entspricht der bereits beschriebenen Pose aus Abschnitt \ref{datatypes}, jedoch verwendet Gazebo dafür diesen eigenen Datentyp.
  \item[components::TrajectoryPose]
   beschreibt eine Pose während einer Bewegung. Ist diese nicht gesetzt, werden keine Animationen abgespielt.
 \end{description}
 
-Durch das Verändern dieser Komponenten kann nun die gewünschte Funktionalität des Plugins erreicht werden.
+Durch das Verändern dieser Komponenten kann die gewünschte Funktionalität des Plugins erreicht werden.
-Diese Veränderungen müssen jeden Simulationschritt erneut vorgenommen werden, um einen flüssigen Ablauf zu gewährleisten.
+Diese Veränderungen müssen zu jedem Simulationschritt erneut vorgenommen werden, um einen flüssigen Ablauf zu gewährleisten.
 Um dies zu erreichen, können im Plugin bestimmte Interfaces mit entsprechenden Funktionen implementiert werden.\cite{ignPlugin}
 Diese Funktionen werden später in der Simulation aufgerufen.
 Folgende Funktionen werden von Gazebo unterstützt:
@@ -508,7 +518,7 @@ Folgende Funktionen werden von Gazebo unterstützt:
  Diese Funktion erlaubt die Modifikation von Entities und Components und wird vor der eigentlichen Physiksimulation aufgerufen.
  \item[Update] wird genutzt, um die in der Simulation abgelaufene Zeit zu simulieren.
  Auch hier ist die Modifikation von Entities und Components möglich.
- In dieser Funktion werden Beispielsweise die Physiksimulation der Objekte durchgeführt.
+ In dieser Funktion wird beispielsweise die Physiksimulation der Objekte durchgeführt.
  \item[PostUpdate] bietet die Möglichkeit, die Ergebnisse der Simulation vor dem nächsten Simulationsschritt auszulesen.
  Dies wird zum Beispiel für die simulierten Sensoren in Gazebo genutzt, die hier ihren Status prüfen.
  In dieser Funktion kann nur lesend auf Entities und Components zugegriffen werden.
@@ -524,11 +534,11 @@ Außerdem soll die simulierte Person bewegt werden. Da dieser Vorgang während d
 Als erstes wird durch das Laden 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 Debugging zu erleichtern.
+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 Mutex gesperrt, um parallele Zugriffe durch die Update-Funktion zu verhindern.
+Dabei wird zuerst ein Sperre gesetzt, um parallele Zugriffe durch die Update-Funktion zu verhindern.
-Alle in der Anfrage gespeicherten Daten werden nun übernommen und der gewünschte State gesetzt.
+Alle in der Anfrage gespeicherten Daten werden übernommen und der gewünschte State gesetzt.
-Nach dem Entsperren des Mutex wird im nächsten Simulationschritt die gewünschte Aktion durchgeführt.
+Nach dem Entsperren 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.
@@ -539,10 +549,10 @@ 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 nun die Komponente AnimationTime jedes Update aktualisiert.
+Im Zustand der Animation wird die Komponente AnimationTime jedes 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.
+Dies verursacht eine Beschleunigung oder Verlangsamung der Ausführung.
 Nach jedem Update-Schritt wird eine Feedback-Nachricht gesendet, die den aktuellen Fortschritt der Animation enthält.
 Wurde die Animation vollständig durchlaufen, wird der Zustand des ActorPlugins auf Idle gesetzt.
 
@@ -565,8 +575,11 @@ Dabei werden auch die Beine wieder in die Ausgangslage bewegt.
 Wenn sowohl die Zielrotation ausgeführt wurde und die Beine wieder in Ausgangslage sind, wird der Zustand auf Idle gesetzt.
 
 Das ActorPlugin besitzt kein Konzept eines ROS-ActionServers und verlässt sich auf den ActorServer, der die Feedbacknachrichten in das richtige Format bringt.
-Feedback wird in den Zuständen Movement und Animation in eine zweiten Message Queue zu jedem Simulationsschritt gesendet.
+Um Zustandsübergänge erkennen zu können, werden diese als Feedback über die zweite Message Queue an den ActorServer gesendet.
-Um Zustandsübergänge erkennen zu können, werden auch diese als Feedback an den ActorServer gesendet.
+Weitere Feedbacknachrichten werden in den Zuständen Movement und Animation zu jedem Simulationsschritt gesendet.
+
+In diesen zusätzlichen Nachrichten werden die aktuelle Position des Menschen und der Fortschritt der laufenden Aktion aktualisiert.
+Der Fortschritt einer Aktion wird aus der Animationszeit oder der berechneten Bewegungszeit und der bereits vergangenen Simulationszeit berechnet.
 
 \subsubsection{ActorServer}
 Der ActorServer ist die Brücke zwischen ROS und dem ActorPlugin.
@@ -576,7 +589,7 @@ Dieser weitere Dienst bindet das ActorPlugin an ROS an.
 Nach dem Start des ActorServers werden zwei ROS-ActionServer gestartet.
 Diese können jeweils zum Abspielen von Animationen oder zum Starten von Bewegungen des simulierten Menschen genutzt werden.
 Wenn ein Client eine dieser Aktionen startet, überträgt er die Zieldaten an den entsprechenden ActionServer.
-Beide ActionServer prüfen bei dem Empfang eines neuen Ziels als erstes, ob bereits eine andere Aktion ausgeführt wird.
+Beide ActionServer prüfen nach dem Empfang eines neuen Ziels als erstes, ob bereits eine andere Aktion ausgeführt wird.
 Wird bereits eine andere Aktion ausgeführt, kommt es zur Ablehnung der aktuellen Anfrage.
 Im anderen Fall wird die Anfrage akzeptiert und in das MessageQueue-Format übersetzt und an das ActorPlugin gesandt.
 
@@ -592,16 +605,16 @@ Soll eine Animation über den Action Server abgespielt werden, wird auch hier ei
 Die Feedbacknachricht enthält den Fortschritt der Animation als Gleitkommazahl.
 \section{Roboter}
 \subsection{Übersicht}
-Der Roboter besteht aus vielen interagierenden Systemen, die in ihrer Gesamtheit das vollständige Robotermodell in der Simulation verwendbar machen.
+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.
 Dieses Modell muss dann für die Bewegungsplanung mit MoveIt erweitert werden.
 Hierbei werden Controller von ros_control mit dem Modell verbunden, um den aktuellen Zustand der Achsen zu überwachen und diese steuern zu können.
 
-Um diese Vielfalt an Daten standartisiert an andere Software in ROS weitergeben zu können, wird eine MoveGroup in ROS gestartet, welche die Planung von Bewegungen durch andere Programme zulässt.
+Um diese Vielfalt an Daten standardisiert für andere Nodes in ROS weitergeben zu können, wird eine MoveGroup in ROS gestartet, welche die Planung von Bewegungen durch andere Programme zulässt.
 \subsection{Modellierung}
-Für den Kuka LBR iisy existiert kein Simulationsmodell für Gazebo und ROS, weswegen dieses Modell aus Herstellerdaten generiert wurden.
+Für den Kuka LBR iisy ist kein Simulationsmodell für Gazebo und ROS verfügbar.
-Hierzu stand eine .stl-Datei des Herstellers zur Verfügung.
+Daher wurde das für die Simulation benötigte Modell aus einer .stl Datei des Herstellers generiert.
 Diese Datei enthält eine geometrische Beschreibung des Roboters, zu sehen in Abbildung \ref{robot_raw}, welche nicht direkt im Simulator nutzbar ist.
 Aus dieser Datei wurden mit FreeCAD\cite{freecad} alle Glieder des Roboters als separate Collada-Dateien exportiert.
 Dabei muss darauf geachtet werden, dass die exportierten Daten eine ausreichende Meshgröße haben.
@@ -619,14 +632,14 @@ Das Resultat ist ein besseres Endmodell des Roboters.
 
 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.
-Außerdem wuden die Glieder so ausgerichtet, dass der Verbindungspunkt zum vorherigen Glied im Nullpunkt des Koordinatensystems befindet.
+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.
 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.
 
-Diese Herangehensweise ist nötig, da Kollisionserkennung auf der CPU durchgeführt wird, die durch komplexe Formen stark verlangsamt wird.
+Diese Herangehensweise ist nötig, da die Kollisionserkennung auf der CPU durchgeführt und durch komplexe Formen stark verlangsamt wird.
 
 Um aus den generierten Gliedermodellen ein komplettes Robotermodell erstellen zu können, wurde eine .urdf-Datei erstellt.
 In dieser werden die verwendeten Gelenktypen zwischen den einzelnen Gliedern, aber auch deren Masse, maximale Geschwindigkeit, maximale Motorkraft, Reibung und Dämpfung hinterlegt.
@@ -651,35 +664,36 @@ Alle hier erstellten Dateien wurden im Paket \code{iisy_config} zusammengefasst,
 \end{minipage}
 \end{figure}
 \subsection{MoveIt 2 Konfiguration}
-Das somit erstellte Paket kann nun mit dem neu implementierten MoveIt Configurator um die benötigten Kontrollstrukturen erweitert werden.
+Das im Abschnitt Modellierung erstellte Paket mit dem Roboter-Modell kann mit dem neu implementierten MoveIt Configurator um die benötigten Kontrollstrukturen erweitert werden.
-Dazu wurde der neue Setupassistent von MoveIt2 verwendet, der das Modell für MoveIt anpasst.
+Dazu wurde der Setupassistent von MoveIt2 verwendet, der das Modell für MoveIt anpasst.
 Dabei wird das Modell mit weiteren Parametern versehen, die durch MoveIt genutzt werden.
 
-Die Erstellung des erweiterten Modells mit dem Assistenten funktionierte komplett fehlerfrei, jedoch ließen sich die generierten Dateien nicht nutzen.
+Die Erstellung des erweiterten Modells mit dem Assistenten funktionierte komplett fehlerfrei, jedoch ließen sich die generierten Dateien nicht direkt nutzen.
 
 Um die generierten Dateien nutzen zu können, mussten diese weiter angepasst werden.
 Dies beinhaltete die korrekte Integration der Roboterdefinitionen im Paket, aber auch zahlreiche Pfadreferenzen auf verwendete Dateien, die nicht korrekt generiert wurden.
-Diese können standartmäßig nicht in Gazebo, RViz und MoveGroup gleichzeitig geladen werden, da diese Programme unterschiedliche Pfadangaben verlangen, was die Nutzung verhindert.
+Diese können standardmäßig nicht in Gazebo, RViz und MoveGroup gleichzeitig geladen werden, da diese Programme unterschiedliche Pfadangaben verlangen, was die Nutzung verhindert.
 
 Eine Möglichkeit zur Lösung des Problems ist die Verwendung von \code{file://}-URIs, die von allen dieser Programme gelesen werden können.
-Jedoch ist hier als Nachteil zu verzeichnen, dass der Moveit Setup Assistent diese URIs nicht lesen kann, was zu Fehlern bei einer Rekonfiguration führen kann.
+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.
 
-Das so erstellte Modell kann ber den Aufruf von \code{ros2 launch iisy_config demo.launch.py} in RViz getestet 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.
 \subsection{Integration mit Gazebo}
-Das so erstellte Modell kann nun zur Laufzeit in Gazebo geladen werden.
+Das so erweiterte Modell kann zur Laufzeit in Gazebo geladen werden.
 Dafür wird das Paket \code{ros_gz_sim} verwendet, dass das \code{create}-Programm beinhaltet.
-Mit diesem Werkzeug kann ein Modell unter einem bestimmten Namen anhand einer Datei oder eines übergebenen Strings in Gazebo importiert werden.
+Mit diesem Werkzeug wird ein Modell unter einem bestimmten Namen anhand einer Datei oder eines übergebenen Strings in Gazebo importiert.
 Das Modell kann dabei über Argumente im Raum verschoben und rotiert werden, falls diese Funktionalität benötigt wird.
 
 In diesem Fall wird das Modell als String geladen, der durch \code{xacro} erstellt wurde.
 Dies ist nötig, um Informationen aus anderen Dateien in das generierte XML übernehmen zu können.
 
 Im Modell sind auch die verwendeten Gazebo-Plugins deklariert, die für die Integration mit \code{ros_control} verantwortlich sind.
-Das Gazebo-Plugin läd dabei die verwendeten Controller und versorgt diese mit Informationen über den Roboter.
+Das Gazebo-Plugin lädt dabei die verwendeten Controller und versorgt diese mit Informationen über den Roboter.
 
 \section{Behavior Trees}
-Alle Behavior Trees wurden im Paket \code{btree} organisert, dass die Bäume im XML-Format und die Implementation der Nodes und umliegenden Infrastruktur enthält.
+Alle Behavior Trees wurden im Paket \code{btree} organisiert, das die Bäume im XML-Format und die Implementation der Nodes und umliegenden Infrastruktur in C++ enthält.
 
 
 Für die Umsetzung des Szenarios wurden neue Nodes für den BehaviorTree erstellt.
@@ -691,9 +705,9 @@ Diese lassen sich nach Nutzung in verschiedene Gruppen einordnen.
   generiert eine Pose in einem durch den \code{area} Parameter angegebenen Bereich.
   Um dies zu ermöglichen, wird zuerst die Fläche aller Dreiecke berechnet, die den Bereich definieren.
   Diese werden durch den Gesamtinhalt geteilt, um eine Wichtung der Dreiecke zum Gesamtinhalt zu erreichen.
-  Nun wird eine Zufallszahl zwischen 0 und 1 gebildet.
+  Darauf wird eine Zufallszahl zwischen 0 und 1 gebildet.
-  Von dieser werden nun die Wichtungen der Dreiecke abgezogen, bis dies Zufallszahl im nächsten abzuziehenden Dreieck liegt.
+  Von dieser werden die Wichtungen der Dreiecke abgezogen, bis diese Zufallszahl im nächsten abzuziehenden Dreieck liegt.
-  Nun wird in diesem Dreieck eine zufällige Position ermittelt, die über den Ausgabeparameter \code{pose} ausgegeben wird.
+  Als letzter Schritt wird in diesem Dreieck eine zufällige Position ermittelt, die über den Ausgabeparameter \code{pose} ausgegeben wird.
   \item[InAreaTest]
   prüft, ob eine Pose, vorgegeben durch den \code{pose} Parameter, in einer durch den \code{area} Parameter definierten Zone liegt.
   Hierfür wird überprüft, ob die X und Y-Werte der Pose in einem der Dreiecke liegen, welche die Area definieren.
@@ -704,16 +718,16 @@ Diese lassen sich nach Nutzung in verschiedene Gruppen einordnen.
   Außerdem wird die Orientierung der Pose auf den \code{orientation} Parameter gesetzt, falls dieser vorhanden ist, was den ursprünglichen Wert überschreibt.
   \item[InterruptableSequence]
   stellt eine Sequence dar, die auch nach ihrem Abbruch ihre Position behält.
-  Dies ist von Nöten, wenn bestimmtes Verhalten unterbrechbar ist, aber zu einem späteren Zeitpunkt fortgesetzt werden soll.
+  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.
   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.
   Dabei werden diese nicht, wie bei anderen Steuerungsnodes üblich, sequentiell ausgeführt.
   Anhand einer vorgegebenen Wichtung im \code{weights} Parameter wird eine der untergeordneten Nodes zufällig ausgewählt.
-  Diese Node wird nun als einzige Node ausgeführt, bis diese den SUCCESS-Status zurück gibt.
+  Diese Node wird als einzige Node ausgeführt, bis diese den SUCCESS-Status zurück gibt.
   Nach dem dieser Status erreicht wurde, wird bei dem nächsten Durchlauf eine neue Node ausgewählt.
-  Der Rückgabewert ist der Rückgabewert der ausgewählten untergeorneten Node.
+  Der Rückgabewert ist der Rückgabewert der ausgewählten untergeordneten Node.
   \item[IsCalled]
   fragt den aktuellen Called-Status des Actors ab, der in einigen Szenarien vom Roboter verwendet wird, um den simulierten Menschen zu rufen.
   Der Rückgabewert der Node ist dabei SUCCESS, falls der Mensch gerufen wird, oder FAILURE, wenn kein RUF durchgeführt wird.
@@ -725,7 +739,7 @@ Diese lassen sich nach Nutzung in verschiedene Gruppen einordnen.
   Der Rückgabewert ist das Ergebnis des Vergleichs, FAILURE, wenn die Zufallszahl kleiner als der \code{failure_chance} Parameter ist, oder im anderen Falle SUCCESS.
 \end{description}
 
-\subsubsection{Menschenspezifisch}
+\subsubsection{Menschenspezifische Nodes}
 \begin{description}
   \item[ActorAnimation]
   wird verwendet, um dem simulierten Menschen eine auszuführende Animation zu senden.
@@ -741,30 +755,32 @@ Diese lassen sich nach Nutzung in verschiedene Gruppen einordnen.
   Eine Besonderheit dieses Paramerters ist die Verwendung des Null-Quaternions als Richtungsangabe, was die Endrotation auf die Laufrichtung setzt.
 \end{description}
 
-\subsubsection{Roboterspezifisch}
+\subsubsection{Roboterspezifische Nodes}
 \begin{description}
   \item[RobotMove] gibt dem Roboter eine neue Zielposition über den \code{target} Parameter vor.
-  Bei dieser Node handelt es sich um eine asynchrone Node, die nur bei der erfolgreiche Ausführung der Bewegung mit dem SUCCESS-Status beendet wird.
+  Bei dieser Node handelt es sich um eine asynchrone Node, die nur bei der erfolgreichen Ausführung der Bewegung mit dem SUCCESS-Status beendet wird.
   \item[SetRobotVelocity] setzt eine neue maximale Geschwindigkeit des Roboters, vorgegeben durch den \code{velocity} Parameter.
   Der Rückgabewert ist immer SUCCESS.
 \end{description}
 Diese beiden roboterspezifischen Nodes beeinflussen im Hintergrund das gleiche System, da Bewegungen bei Geschwindigkeitsänderungen neu geplant und ausgeführt werden müssen.
-Dazu wird das letzte Ziel bis zu dessen erreichen vorgehalten, um die Ausführung neu zu starten, fall eine Geschwindigkeitsänderung durchgeführt werden muss.
+Dazu wird das letzte Ziel bis zu dessen Erreichen vorgehalten, um die Ausführung neu zu starten, falls eine Geschwindigkeitsänderung durchgeführt werden muss.
 Um die RobotMove-Node nicht zu unterbrechen, wird diese nur über einen Callback über den Erfolg oder Misserfolg der gesamten Bewegung und nicht über den Erfolg einzelner Teilbewegungen informiert.
 
 \subsection{Subtrees}
-Um die Wiederverwendung von bestimmten Verhaltensweisen zu erleichtern, wurden diese in Subtrees ausgelagert.
+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.
 
 Für das Arbeiten an der Werkbank ist eine Bewegung zu dieser erforderlich.
-Außerdem muss der Mensch sich zur Werkbank ausrichten, um die späteren Animationen korrekt auszuführen.
+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.
+
 Da dieser Prozess weit vom Roboter entfernt ist, ist eine genaue Animation nicht erforderlich.
 In diesem Fall wird die Arbeit durch ausstrecken und zurücknehmen der Hand in Richtung der Werkbank simuliert.
 Dies wird durch zwei Animations-Nodes mit entsprechenden Parametern gesteuert.
-Die Ausführung der Nodes dieser Gesamtaktion soll Sequenziell erfolgen, weshalb die Nodes unterhalb einer Sequence-Node gruppiert werden.
+
+Die Ausführung der Nodes dieser Gesamtaktion soll sequenziell erfolgen, weshalb die Nodes unterhalb einer Sequence-Node gruppiert werden.
 Der vollständige resultierende Baum ist in Abbildung \ref{subtree_work} visualisiert.
 
 \begin{figure}
@@ -774,19 +790,24 @@ Der vollständige resultierende Baum ist in Abbildung \ref{subtree_work} visuali
 \label{subtree_work}
 \end{figure}
 
-Das Ablegen von Objekten in einem Schrank ist ein komplizierterer Prozess, da der Schank in mehreren Ebenen befüllt werden kann.
+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 Werkank wird zuerst eine Bewegung zum Schrank ausgeführt.
+
-Diese hat ein einzelnes Schrankteil als Ziel, wobei drei Schrankteile existieren.
+Wie bereits bei der Werkbank wird zuerst eine Bewegung 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.
 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.
+
 Für den Fall eines unteren Fachs werden vier Animationen genutzt.
 Zuerst kniet die Person auf den Boden nieder, um das untere Fach erreichen zu können.
-Danach wird ein Objekt durch inspizieren und ablegen in das Fach gelegt.
+Danach wird ein Objekt durch Inspizieren und Ablegen in das Fach gelegt.
-Nun kann die Person wieder aufstehen, was die Person wieder zum gleichen Lage wie am Anfang der Aktion bringt.
+Jetzt kann die Person wieder aufstehen, was die Person in die gleiche Position wie am Anfang der Aktion bringt.
+
 Für die beiden Fälle werden auch Sequenz-Nodes genutzt, da die Aktionen nacheinander ausgeführt werden sollen.
 Die beiden zufälligen Auswahlverfahren werden durch eine Sequenz verbunden.
 Der resultierende Ablauf wurde als Baum in Abbildung \ref{subtree_deposit} visualisiert.
@@ -802,12 +823,14 @@ Der resultierende Ablauf wurde als Baum in Abbildung \ref{subtree_deposit} visua
 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 vollständiger Stopp des Roboters vorgesehen.
+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.
 
 Um diese Funktionen zu erlauben, ist eine Reaktion auf Statusänderungen von vorherigen Nodes nötig.
 Dies wird durch eine übergeordnete ReactiveSequence erreicht.
-Eine solche Node verhält sich ähnlich einer normalen Sequence, jedoch prüft sie vor jedem Tick noch einmal vorherige Nodes.
+Eine solche Node verhält sich ähnlich einer normalen Sequence, jedoch prüft sie zu jedem Ausführungsschritt noch einmal alle vorherigen Nodes.
-Wenn eine vorherige Node Failure zurückgibt, wird die aktuell laufende spätere Node abgebrochen.
+Dies geschieht auch, wenn eine andauernde Aktion sich noch im Status RUNNING befindet.
+Wenn eine vorherige Node einen Fehler zurückgibt, wird die aktuell laufende spätere Node abgebrochen.
 
 Als erste Node in der ReactiveSequence wird getestet, ob sich der Mensch in der Sicherheitszone aufhält.
 Wenn dies nicht der Fall ist, kann die Ausführung weiter fortgesetzt werden.
@@ -837,7 +860,7 @@ Alle Nodes werden einer ReactiveSequence untergeordnet, um bei Unterbrechungen d
 Mit einer GenerateXYPose-Node wird zuerst ein Ziel auf der linken Tischseite generiert.
 Dieses Ziel befindet sich auf dem Boden, und muss auf die Tischebene angehoben werden.
 Das Anheben wird durch eine OffsetPose-Node realisiert.
-Mit einer RobotMove-Node wird nun die Bewegung zum generierten Zielpunkt ausgeführt.
+Mit einer RobotMove-Node wird die Bewegung zum generierten Zielpunkt ausgeführt.
 Dies geschieht auf gleichem Weg für die rechte Tischseite.
 Der vollständige Baum ist in Abbildung \ref{tree_robot_coex} zu sehen.
 
@@ -868,7 +891,7 @@ Am Ende der übernommenen Sequenz wird eine SetCalledTo-Node ergänzt, die den M
 \subsubsection{Kollaboration}
 
 Für das dritte Szenario soll der Roboter mit dem Menschen kollaborieren.
-Um dieses Szenario umzusetzen, wird ein weiteres Mal das erste Szenario modifiziert.
+Um dieses Szenario umzusetzen, wird wiederum das erste Szenario modifiziert.
 Hier soll der Roboter eine Palette ausladen, wobei es durch die Beschaffenheit der Objekte zu Fehlern kommen kann.
 Dies wird durch das Hinzufügen mehrerer RandomFailure-Nodes erreicht, welche die Sequenz abbrechen können.
 Da diese Probleme durch den Menschen behoben werden sollen, muss ein Mechanismus geschaffen werden, um diesen zu rufen.
@@ -914,7 +937,7 @@ Dies erfolgt nach einer AmICalled-Node, welche die Sequence vorzeitig beendet, f
 Das vorzeitige Beenden führt zu einer erneuten Auswahl zwischen Arbeit und Inspektion.
 Sollte der Mensch jedoch durch den Roboter gerufen werden, wird die Sequence weiter ausgeführt.
 
-In diese Fall soll der Mensch das Objekt vom rechten Tisch abholen und in das Regal legen.
+In diesem Fall soll der Mensch das Objekt vom rechten Tisch abholen und in das Regal legen.
 Dies erfolgt durch eine ActorMovement-Node, welche den Mensch zum rechten Tisch bewegt.
 Nach dieser werden zwei ActorAnimation-Nodes ausgeführt, welche die Animationen ``standing_extend_arm'' und ``standing_retract_arm'' durchführen.
 Dies simuliert den Griff auf den Tisch, um das Objekt aufzuheben.
@@ -932,15 +955,15 @@ Um das Objekt im Schrank zu verstauen, wird der bereits definierte Subtree ``Dep
 
 Für das letzte Szenario soll der Mensch dem Roboter beim Entladen einer Palette assistieren.
 Falls der Mensch nicht vom Roboter gerufen wird, soll dieser im Raum herumwandern.
-Für die festlegung einer Baumstruktur ist es wichtig, ob der Mensch sofort, oder erst nach vollenden seiner Arbeit dem Roboter zu Hilfe kommt.
+Für die Festlegung einer Baumstruktur ist es wichtig, ob der Mensch sofort, oder erst nach dem Vollenden seiner Arbeit dem Roboter zu Hilfe kommt.
 In diesem Fall soll er seine Arbeit unterbrechen, um auch diese Möglichkeit zu demonstrieren.
 
 Ein solches Verhalten lässt sich mit Hilfe einer Fallback- mit untergeordneter ReactiveSequence-Node modellieren.
 In der ReactiveSequence wird zuerst überprüft, ob der Mensch gerufen wurde.
 Da dieser Zustand die ReactiveSequence abbrechen soll, wird die verantwortliche AmICalled-Node mit einer Inverter-Node versehen.
-In der ReactiveSequence kann nun eine weitere Sequence nach der Inverter-Node angeornet werden.
+In der ReactiveSequence kann eine weitere Sequence nach der Inverter-Node angeornet werden.
 
-Diese enthält den Teil des Baumes, der ausgeführt werden soll, solange der Mensch nicht gerufen wird.
+Diese Sequence-Node enthält den Teil des Baumes, der ausgeführt werden soll, solange der Mensch nicht gerufen wird.
 In diesem Fall wird mit einer WeightedRandom-Node eine von drei GenerateXYPose-Nodes ausgewählt.
 Diese geben jeweils Ziele in der sicheren Zone, Warnzone und Sicherheitszone zurück.
 Nach der WeightedRandom-Node wird eine ActorMovement-Node genutzt, welche den Mensch zu dem ausgewählen Ziel bewegt.
@@ -949,11 +972,14 @@ Neben der ReactiveSequence unter der Fallback-Node wird eine weitere Sequence an
 Hier wird die gewünschte Aktionsfolge bei Ruf durch den Roboter definiert.
 In diesem Fall soll das Aufheben eines heruntergefallenen Objekts durchgeführt werden.
 Dazu wird zuerst ein Ziel in der Warnzone unter Zuhilfenahme einer GenerateXYPose-Node generiert.
-Nach einer Bewegung zu diesem Ziel durch eine ActorMovement-Node wir ein Objekt aufgehoben.
+
-Dies geschieht durch vier ActorAnimation-Nodes, welche jeweils die Animationen ``standing_to_low'', ``low_inspect'', ``low_grab'' und ``low_to_standing'' ausfühen.
+Nach einer Bewegung zu diesem Ziel durch eine ActorMovement-Node wird ein Objekt aufgehoben.
-Um das Objekt wieder abzulegen, wird nun eine Bewegung zum rechte Tisch des Roboters durch eine ActorMovement-Node ausgeführt.
+Dies geschieht durch vier ActorAnimation-Nodes, welche jeweils die Animationen ``standing_to_low'', ``low_inspect'', ``low_grab'' und ``low_to_standing'' ausführen.
+
+Um das Objekt wieder abzulegen, wird eine Bewegung zum rechten Tisch des Roboters durch eine ActorMovement-Node ausgeführt.
 Auch hier wird zum Ablegen eine weitere Animationsfolge aus zwei ActorAnimation-Nodes genutzt.
 Dabei wird zuerst ``standing_extend_arm'' abgespielt, gefolgt von ``standing_retract_arm''.
+
 Als letzte Aktion wird der Ruf nach dem Menschen durch eine SetCalledTo-Node auf false zurückgesetzt.
 
 \begin{figure}

tex/5_Evaluation_und_Diskussion.tex

@@ -46,6 +46,10 @@ Das entworfene Containersystem ist mit der bereitgestellten Funktionalität eine
 \end{figure}
 
 \subsubsection{Erstellung der benötigten Modelle}
+Für den simulierten Menschen und Roboter werden verschiedene Modelle benötigt.
+Das Robotermodell wurde aus Herstellerdaten exportiert und in Blender nachbearbeitet.
+Eine Definition des Roboters wurde für Gazebo und MoveIt erstellt, um die Zusammenhänge der einzelnen Armglieder und die physikalische Eigenschaften der Gelenke festzulegen.
+
 
 \subsubsection{Steuerung des Menschen}