Changes on the go.

tex/4_Umsetzung.tex

@@ -117,10 +117,11 @@ Diese Datentypen sind größtenteils aus der Programmiersprache C++ bekannt, jed
 Um die Verständlichkeit der Dokumentation zu erleichtern, sind die in der Implementation verwendeten Datentypen hier zusammengefasst und beschrieben.
 \begin{description}
   \item[Pose]
-  ist einer der häufigsten Datentypen im Umgang mit Gazebo. Dieser Datentyp enthält die Information über die Lage und Rotation eines Objekts im Raum.
+  ist einer der häufigsten Datentypen im Umgang mit Gazebo.
-  Diese werden als relative Werte im Bezug auf das übergeornete Objekt gespeichert.
+  Der Pose-Datentyp enthält die Information über die Lage und Rotation eines Objekts im Raum.
+  Die Daten werden als relative Werte im Bezug auf das übergeornete Objekt gespeichert.
   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 diese nicht durch die Welt verschoben und rotiert werden.
+  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.
   Jede Position ist eine einfache Datenstruktur aus 2 Gleitkommazahlen für je die X- und Y-Koordinate der Position.
@@ -133,7 +134,7 @@ Um die Verständlichkeit der Dokumentation zu erleichtern, sind die in der Imple
   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.
   \item[ActionMessage]
-  ist die andere Nachricht, die über die zweite MessageQueue vom ActorServer an das ActorPlugin gesendet wird.
+  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.
   Dieser bestimmt später die Animation, die je nach ActorPluginState während einer Bewegung oder Animation ausgeführt wird.
@@ -141,22 +142,23 @@ Um die Verständlichkeit der Dokumentation zu erleichtern, sind die in der Imple
   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 Welt der Simulation wird im Paket \code{ign_world} zur Verfügung gestellt.
+Die Definition aller Simulationselemente findet im Paket \code{ign_world} statt.
 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.
-Für diesen Raum wurde zuerst ein Raumplan erstellt, der alle benötigten Bereiche für die Szenarien besitzt (Abbildung \ref{room-plan}).
+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.
 Dieser sollte an einer Ecke des Raumes positioniert werden, was zu höheren Verfahrgeschwindigkeiten führt.
 Das ist durch die dynamische Verfahrgeschwindigkeit bedingt, die bei geringerer Distanz zum Menschen abnimmt.
 
-Des weiteren werden eine Arbeits- und Lagersätte für den Menschen benötigt, die in den Szenarien genutzt werden sollen.
+Des weiteren werden eine Arbeits- und Lagerstätte für den Menschen benötigt, die in den Szenarien genutzt werden sollen.
-Im Koexistenzszenario soll der Mensch nur an diesen Stellen seine Arbeit verrichten, jedoch sich selten dem Roboter nähern, um dessen Fortschritt zu begutachten.
+Im Koexistenzszenario soll der Mensch nur an diesen Stellen seine Arbeit verrichten, sich jedoch seltener dem Roboter nähern, um dessen Fortschritt zu begutachten.
-Die Lagerstätte soll im Kooperationsszenario neben der Arbeit des Menschen auch für die fehlerhaften Teile verwendet werden, die durch den Roboter aussortiert und durch den Menschen dorthin verbracht werden sollen.
+Die Lagerstätte soll im Kooperationsszenario neben der Arbeit des Menschen auch für die fehlerhaften Teile verwendet werden.
-Eine Nutzung im Kollaborationsszenario ist nicht nicht geplant, da der Mensch den Roboter überwachen und dessen Fehler korrigieren soll.
+Diese Teile werden durch den Roboter aussortiert und durch den Menschen in das Lager verbracht.
+Eine Nutzung der Arbeits- und Lagerstätte im Kollaborationsszenario ist nicht geplant, da der Mensch den Roboter überwachen und dessen Fehler korrigieren soll.
 
-Der so geplante Raum wurde in Blender modelliert und als .stl-Datei exportiert, um sie in die Welt einbinden zu können.
+Der so geplante Raum wurde in Blender modelliert und als Datei im .stl-Format exportiert, um sie in die Welt einbinden zu können.
 Das Resultat des Exports ist in Abbildung \ref{room-finished} dargestellt.
 Für das Kooperationsszenario wurde ein Förderband erstellt, das nur in diesem Szenario dem Raum hinzugefügt wird.
 
@@ -183,13 +185,13 @@ Dieses veranlasst mit dem \code{create}-Programm das Erstellen der übergebenen
 
 \section{Mensch}
 \subsection{Übersicht}
-Das angepasste Verfahren zur Menschensteuerung in der Simulation verwendet mehrere Kommunikationswege.
+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.
-Um diese ausführen zu können, wird der gewünschte Animationsname, aber auch andere Parameter für die Aktion aus der Nachricht übernommen.
+Um diese auszuführen, werden der gewünschte Animationsname und weitere Parameter, die die Aktion beschreiben, aus der Nachricht übernommen.
 
 Das Feedback an den Client des ROS-Action-Servers wird bei Zustandswechseln und während laufenden Aktionen des ActorPlugins generiert.
 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.
@@ -197,34 +199,34 @@ Dies geschieht über eine zweite MessageQueue, die den \code{FeedbackMessage}-Da
 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.
 
 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 dan Modell in einen animierbaren Zustand gebracht werden, in dem dann weitere Animationen erstellt und in die Simulation eingebunden werden können.
+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 inkludierten Animationen in Blender geöffnet und das visuelle Modell kopiert.
+Dafür wurde eine der bereits modellierten Laufanimationen von Gazebo in Blender geöffnet und das visuelle Modell kopiert.
-
-Dieses Modell war auf Grund von vielen inneren Falten nur schlecht für Animationen geeignet, weshalb das Modell an diesen Stellen vereinfacht wurde.
-Eine solches Vorgehen beugt späteren Anomalien bei der Animation des Modells vor.
-Diese entstehen durch unterschiedliche Verschiebung der Strukturen, die aus dem inneren des Modells hervortreten, wenn dieses bewegt wird.
-
 
+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.
+Solche Artefakte entstehen durch unterschiedliche Verschiebung der Strukturen, die aus dem inneren des ursprünglichen Modells hervortreten, wenn dieses bewegt wird.
+In diesem Fall 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.
 
 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 jedoch für einige der gewünschten Animationen benötigt und müssten hinzugefügt werden.
+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.
 
 Um ein neues, passendes Skelett zu erstellen, wurde mit dem ``Rigify''\cite{rigify}-Plugin ein standartisiertes Menschenskelett generiert.
-Dieses neue Skelett kann nun an das bereits vorhandene Modell angepasst werden.
+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.
 
 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, verbiegen sich Gelenke bei der Verwendung von inverser Kinematik zur Positionsvorgabe falsch.
+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.
 Der Grund dafür ist das Kreuzprodukt, dass im oben genannten Fall ein Nullvektor ist, wodurch keine Beugeachse bestimmt werden kann.
 
-Deswegen muss bei der Platzierung darauf geachtet werden, dass der Startpunkt A des ersten und der Endpunkt C des zweiten Knochens auf einer Gerade liegen.
+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.
-Der Verbindungspunkt B der beiden Knochen wird nun vorerst auf dieser Gerade platziert.
+Der Verbindungspunkt B der beiden Knochen wird vorerst auf dieser Gerade platziert.
-Dieser muss nun senkrecht zu dieser Gerade und der gewünschten Biegeachse verschoben werden, wie in Abbildung \ref{bend} gezeigt.
+Dieser muss senkrecht zu dieser Gerade und der gewünschten Biegeachse verschoben werden, wie in Abbildung \ref{bend} gezeigt.
 
 \begin{figure}
 \begin{minipage}{.45\textwidth}
@@ -258,16 +260,16 @@ Je höher die Wichtung, desto stärker ist die Verformung an dieser Stelle, wenn
 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.
 
-Durch das Verwenden von Rigify und einem standartisierten Skelett ist die Generierung der Constraints einfach.
+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.
 
-Hierfür sehen mehrere Knochengruppen zur Verfügung, die typische Animationsmethoden abdecken.
+Hierfür stehen mehrere Knochengruppen zur Verfügung, die typische Animationsmethoden abdecken.
 
-In der Farbe Rot sind im Modell Knochen markiert, die für inverse Kinematik genutzt werden, in diesem Fall Arme und Beine.
+In der Farbe Rot sind im Modell (siehe Abbildung \ref{person-armature}) Knochen markiert, die für inverse Kinematik genutzt werden, in diesem Fall Arme und Beine.
-Diese Knochen geben gewünschte Ausrichtung und die Zielposition des untersten Knochens vor.
+Die Knochen geben die gewünschte Ausrichtung und die Zielposition des untersten Knochens vor.
-Aus diesen Angaben wird die wirkliche Position der Knochen berechnet, die durch die Constraints automatisch auf diese übertragen wird.
+Aus diesen Angaben wird die wirkliche Position der Knochen berechnet, die durch die Constraints automatisch auf die entsprechenden Knochen übertragen wird.
 
 Orange gefärbte Knochen werden für generelle Einstellungen von Fingern, Handfläche und Zehen genutzt.
 Die Handfläche kann so gekrümmt werden, wodurch sich alle Finger mit der Krümmung mitbewegen.
@@ -281,7 +283,8 @@ 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 nun durch den Einsatz der neuen Constraints einfacher animiert werden.
-Jedoch ist das Exportieren eines solchen Rigs ist schwierig, da viele Grafikengines verschachtelten Skelette und Constraints nicht verwenden können.
+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{Export der Modellanimationen}
 
@@ -298,24 +301,26 @@ Danach muss die durch die Constraints abgebildete Animation auf das ausgewählte
 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.
-Nach dieser Veränderung kann die diese Animation als Collada-Animation exportiert werden.
+Nach dieser Veränderung kann die Animation im Collada-Format exportiert werden.
-Dazu muss noch das visuelle Modell der Selektion hinzugefügt werden, da Gazebo dieses für jede Animation benötigt.
+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.
-Hierfür müssen die in Abbildung \ref{export-settings} verwendeten Exporteinstellungen verwendet werden, damit Gazebo die exportierte Animation nutzen kann.
+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 standartmäßigen Einstellungen wurden dabei durch Punkte hervorgehoben.
+Alle in der Blender-Version 3.5 nicht standardmäßigen Einstellungen wurden dabei durch Punkte hervorgehoben.
 
 Zuerst müssen im Reiter ``Main'' die globalen Exporteinstellungen angepasst werden.
 Der markierte Punkt 2. bewirkt, dass nur die vorher ausgewählten Modellteile exportiert werden.
 Dies verkleinert das Modell, da alle Steuerknochen von Gazebo nicht verwendet werden können, was die Ladezeit der Simulation verbessert.
 
-Punkt 3. und 4. bewirken, dass das exportierte Modell in Gazebo verwendete Vorwärtsachse erhält.
+Die Punkte 3. und 4. bewirken, dass das exportierte Modell die in Gazebo verwendete Vorwärtsachse erhält.
 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.
 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 nur am Anfang der Animation in einer bestimmten Pose befinden, exportiert Blender diese nicht, was in Gazebo zu verdrehten Knochen führt.
+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.
+Ein solcher Fehler äußert sich in Gazebo durch verdrehte Knochen während der Animation.
 
 \begin{figure}
 \begin{subfigure}[b]{\textwidth}