Änderungen bis 12.04

.kile/mechforsch.kilepr.gui

@@ -39,13 +39,13 @@ CursorColumn=14
 CursorLine=109
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"a7e42fe12fca343bb119c9438c9707efb60af457","ranges":[]}
+TextFolding={"checksum":"4af487415133a6dcd896d70e042ef9ac694f0ea6","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:main.tex]
 CursorColumn=0
-CursorLine=361
+CursorLine=455
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"9f78138bb44f610a790c5c58bc907bb95d19caa9","ranges":[]}
+TextFolding={"checksum":"1d8262bd4fab97ca3ac166d2d70ba8518a0c146f","ranges":[]}
 ViMarks=

main.tex

@@ -20,6 +20,7 @@ parskip=half,
 \usepackage{enumitem}
 \usepackage{hyperref}
 \usepackage{tabularray}
+\usepackage{xurl}
 \usepackage[strings]{underscore}
 
 \usepackage[letterspace=150]{microtype}
@@ -141,9 +142,13 @@ Die zu erarbeitende Softwareumgebung soll einfach erweiterbar sein, um weitere M
 Hierzu zählt die Austauschbarkeit und Erweiterbarkeit von Komponenten wie der simulierten Welt, dem Roboter oder dem simulierten Mensch.
 Um diese Möglichkeiten zu schaffen, sind die Systeme modular aufgebaut.
 
--Mensch und Roboter in Simulation
--Austauschbare Welt
--Beliebig erweiterbar
+\begin{figure}[]
+\includegraphics[]{Konzept_Overview}
+\centering
+\caption{Visualisierung des Konzepts}
+\label{concept_overview}
+\end{figure}
+
 \section{Simulation des Roboters}
 Der simulierte Roboter soll für viele unterschiedliche Szenarien nutzbar sein, was spezialisierte Robotertypen ausschließt.
 Außerdem ist die enge Interaktion mit Menschen interessant, was einen für Mensch-Roboter-Kollaboration ausgelegten Roboter spricht.
@@ -155,8 +160,6 @@ Um den Kuka iisy in der Simulation verwenden zu können, muss ein Modell des Rob
 Dieses Modell sollte die physikalischen Eigenschaften des Roboters möglichst gut wiederspiegeln.
 Anhand dieses Modells kann der Roboter dann in der Simulation dargestellt werden und mit anderen Objekten interagieren.
 
--Beruhend auf echtem Roboter (Kuka iisy)
--Kollision
 \section{Simulation des Menschen}
 Der Mensch soll in der Simulation typische Aufgaben erledigen und häufiges Verhalten abbilden können.
 Hierzu werden Animationen verwendet, welche die aktuelle Tätigkeit darstellen.
@@ -167,15 +170,17 @@ Außerdem werden mehrere Animationen und Übergänge zwischen diesen benötigt,
 Hinzu kommt noch eine Komponente, welche diese Animationen und andere Parameter von außen entgegennehmen kann, um sie in der Simulation ausführen zu können.
 Um die spätere Steuerung des Menschen von außerhalb zu erleichtern, müssen diese Aktionen im Fortschritt überwacht und abgebrochen werden können.
 
--Dynamische Ausführung von Befehlen
--Erkennbare Bewegungsabläufe
 \section{Behavior Trees}
 Häufig wird Verhalten in State-Machines ausgedrückt, welche jedoch einige Nachteile besitzen.
 State-Machines werden ab einer gewissen Größe schnell unübersichtlich.
-Dies erschwert die schnelle Erfassung von Abfolgen und Zustandsübergängen, welche jedoch essentiell für den Betrieb einer Maschine sind.
-Ein BehaviorTree ist eine Struktur, um Verhalten als ein Baum zu beschreiben.
+Dies erschwert die schnelle Erfassung von Abfolgen und Zustandsübergängen bei Änderungen am Code, welche jedoch essentiell für den Betrieb einer Maschine sind.
+Um diese Probleme zu adressieren, entstand das Konzept der Behavior Trees.
+
+Ein Behavior Tree ist eine Struktur, um Verhalten als ein Baum zu beschreiben.
 Der Ablauf startet vom sogenannten Root, der Wurzel des Baums.
-Von dort an werden verschiedene Tree-Nodes in einer parent-child Struktur mit dem Root verbunden.
+Von dort an werden sogenannte Nodes, welche je nach Node unterschiedliches Verhalten abbilden, miteinander verbunden.
+Die Nodes werden untereinander angeordnet, welches die Relation der Nodes zueinander beschreibt.
+Jede Node hat dabei entweder die Root-Node oder eine andere Node über ihr im Baum und eine beliebige Anzahl an Nodes unter sich.
 Hierbei gibt es mehrere grundlegende Arten von Tree-Nodes.
 \begin{description}
  \item[Aktions-Nodes]
@@ -188,8 +193,9 @@ Hierbei gibt es mehrere grundlegende Arten von Tree-Nodes.
   werden verwendet, um Verhalten zu definieren, welches nur bei Fehlern in vorherigen Nodes ausgeführt wird.
 \end{description}
 
--Steuerung von Mensch und Roboter
--Vermeidung der Nachteile von großen State-Machines
+In dieser Arbeit sollen BehaviorTrees für die Steuerung von Mensch und Roboter verwendet werden.
+Die hierfür erstellten Nodes sollen universell gestaltet werden, um alle Szenarien, welche in dieser Arbeit bearbeitet werden, abzudecken.
+
 \chapter{Komponenten-/Softwareauswahl}
 \section{Dienstumgebung (ROS2)}
 \subsection{Auswahl}
@@ -276,19 +282,22 @@ Unity besitzt eine gute Dokumentation, die vor allem auf die Nutzung im Einsteig
 Auch die Optionen zur Menschensimulation sind gut, da diese häufig in Spielen verwendet werden.
 Ein großer Nachteil hingegen ist die Lizenz, welche nur für Einzelpersonen kostenlos ist.
 
+Die Unreal Engine ist wie Unity eine Grafikengine aus dem Spielebereich.
+Auch hier ist die Menschensimulation aufgrund oben genannter Gründe gut möglich.
+Jedoch existiert für Unreal Engine keine offizielle Lösung zur Anbindung an ROS2.
+Die Programmierung der Engine erfolgt in C++, was einer Drittlösung erlaubte, eine ROS-Anbindung für Unreal Engine zu erstellen.
+Die Lizenz der Unreal Engine erlaubt die kostenfreie Nutzung bis zu einem gewissen Umsatz mit der erstellten Software.
 
-Unreal:
-3rd Party Lösung verfügbar
-Gute Dokumentation
-Gute Werkzeuge für Menschensimulation.
-Lizenz komplex, nicht offen.
+Eine weitere Möglichkeit zur Simulation stellt die Grafikengine 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 für diese Engine existiert eine ROS2-Anbindung, jedoch ist diese nicht offiziell.
 
-Godot:
-3rd Party Lösung verfügbar
-Dokumentation stark im Wandel
-Gute Werkzeuge für Menschensimulation.
-Lizenz offen
-Keine explizite Robotersimulation, wäre nachzurüsten
+Jede der drei Gameengines besitzt ein integriertes Physiksystem, welches die Simulation von starren Körpern und Gelenken erlaubt.
+Aus diesen Funktionen könnte ein Roboterarm aufgebaut werden, welcher dann durch eine der ROS-Brücken der Engines gesteuert werden kann.
+
+Die Wahl der Simulationsumgebung fiel auf Gazebo Ignition, da dieser Simulator bereits im ROS-Framework etabliert ist.
+Dabei erlauben die offizielle ROS-Anbindung und offene Lizenz eine zuverlässige Verwendung in unterschidlichsten Szenarien.
 
 \subsection{Robotersimulation}
 Für die Robotersimulation wird ein Modell des Roboters benötigt, in welchem dieser für die Siimulationsumgebung beschrieben wird.
@@ -360,33 +369,88 @@ Diese können dann wie normale Controller von ros_control genutzt werden.
 Dieser Ablauf ist auch im Anhang unter Abbildung \ref{moveitpipeline} visualisiert.
 
 \chapter{Umsetzung}
+
 \section{Grundlegender Systemaufbau}
+Der grundlegende Systemaufbau musste stark modifiziert werden, wie in Abbildung \ref{umsetzung_overview} zu sehen, um die gesetzten Aufgaben erfüllen zu können.
+Dabei fallen vor allem die überarbeitete Kommunikation mit dem simulierten Menschen und die komplexere Steuerung des Roboterarms auf.
+
+Die komplexere Steuerung des Roboters ist auf die Struktur von MoveIt zurückzuführen, welches in viele einzelne Teilmodule aufgeteilt ist.
+Diese müssen durch ihren modularen Aufbau, welcher für die Vielseitigkeit verantwortlich ist, einzeln konfiguriert werden, um miteinander in Interaktion treten zu können.
+
+Außerdem musste die Kommunikation des Modells des Menschen überarbeitet werden, da die ROS-Kommunikation in Gazebo nur mit Einschränkungen möglich ist.
+
+\begin{figure}[]
+\includegraphics[width=\textwidth]{Umsetzung_Overview}
+\centering
+\caption{Visualisierung des überarbeiteten Konzepts}
+\label{umsetzung_overview}
+\end{figure}
+
 -BehaviorTree -> ActorPluginServer -> ActorPluginServer
 
 -BehaviorTree -> MoveIt -> ros\_control -> Gazebo
 \section{Mensch}
 \subsection{Übersicht (Diagramme)}
+Das angepasste Verfahren zur Menschensteuerung 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 über eine Posix-Message-Queue vom ActorServer an das ActorPlugin in Gazebo gesendet.
+
+Dieses verwendet die Daten, um eine interne State-Machine in den entsprechenden Zustand zu setzen, welcher zur Ausführung des Befehls benötigt wird.
+
+Um Feedback an den Client des ROS-Action-Servers übertragen zu können, werden bei der Ausführung von Befehlen oder Zustandswechseln des ActorPlugins Feedbackdaten über eine separate MessageQueue zurück an den ActorServer übertragen.
+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, welche im Kontext der zur erfüllenden Aufgabe relevant sind.
+Dafür muss dan Modell in einen animierbaren Zustand gebracht werden, in welchem dann weitere Animationen erstellt und in die Simulation eingebunden werden können.
 \subsection{Modellierung}
-Rerigging des Actor-Modells
-Animation in eigenem Rig
-Konflikte durch 'verschiedene' Rigs in Animationen
-Erstellung eines neuen Rigify-Rigs
-Erneutes Erstellen von Animationen
-Disconnect Bones in Rig
-Flatten Hierarchy
+-Rerigging des Actor-Modells
+-Animation in eigenem Rig
+-Konflikte durch 'verschiedene' Rigs in Animationen
+-Erstellung eines neuen Rigify-Rigs
+-Erneutes Erstellen von Animationen
+-Disconnect Bones in Rig
+-Flatten Hierarchy
 \subsection{Programmierung}
 \subsubsection{Message Queue}
--2 rclcpp Instanzen kollidieren
+Bei der Implementierung des ActorPlugins stellte sich heraus, dass die nun im ActorServer ausgelagerten Befehle mit den Befehlen im ros_control-Plugin kollidieren.
+Dies geschieht, da beide Plugins rclcpp, eine Bibliothek zur Kommunikation mit ROS, verwenden.
 
--Anderes Protokoll nötig
+In dieser Bibliothek wird eine globale Instanz angelegt, welche 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.
 
--Möglichst einfach, von anderen Sprachen verwendbar und schnell
+Eine Anpassung beider Plugins auf die gemeinsame Nutzung einer Ressource ist möglich, erfordert jedoch weitere Anpassungen, welche zeitlich nur schwer planbar sind.
+Die Nutzung eines separaten Dienstes, welcher keinen globalen Kontext benötigt, ist die sicherste Lösung des Problems.
+Durch einen solchen Dienst werden auch in Zukunft keine Plugins gestört, auch wenn sie selbigen Dienst zur Kommunikation verwenden.
 
--Websocket zu langsam
+Die Auswahl eines Dienstes wurde dabei aus einer Reihe an unterschielichen Möglichkeiten getroffen.
+Eine REST-API hat den Vorteil, dass sie durch fast jede Programmiersprache genutzt werden kann, die Sockets unterstützt, hat jedoch keinen einheitlichen Feedbackmechanismus.
+Die neueren Websockets bieten die Möglichkeit, bidirektional Daten zu übertragen und erlauben somit Feedback an das aufrufende Programm.
+Beide Technologien basieren jedoch auf einem Webserver, welcher auf einem bestimmten Port des Systems ausgeführt werden muss, was Kollisionen mit anderen Serveices 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, welcher bei den hohen Updateraten der Gazebo-Simulation zu Problemen führen könnte.
 
--Shared memory schwer zu synchronisieren
+Eine andere Möglichkeit ist die Nutzung von ``shared memory'', einem geteilten Speicherbereich zwischen beiden Programmen.
+Dieser kann zur bidirektionalen Kommunikation genutzt werden, da beide Programme auf den Speicher zugreifen können.
+Alle Zugriffe auf den Bereich sind extrem schnell, was diese Technik ideal zur schnellen Datenübertragung zwischen Prozessen macht.
+Durch das erlauben gleichzeitiger Zugriffe kann es hierbei vorkommen, dass die selbe Adresse gleichzeitig von einem Programm gelesen und von einem anderen geschrieben wird.
+Die dabei gelesenen Daten können Schäden aufweisen, weswegen Zugriffe auf den Speicherbereich koordiniert werden müssen.
 
--Message Queue guter Mix aus beiden
+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, mit welchem Anwendungen Zugriff auf diesen erlangen können.
+Ein Programm kann in diesem Bereich Nachrichten ablegen, welche durch das andere Programm gelesen werden können.
+Die Koordinierung der Zugriffe erfolgt dabei durch das Betriebssystem, was gleichzeitige Zugriffe, wie bei shared memory, aussschließt.
+Hierdurch kommt es zu einem Anstieg an Latenzzeit, jedoch ist dieser ausreichend gering.
+
+Die Wahl des Dienstes fiel auf eine MessageQueue, jedoch existieren unter Linux 2 unabhängige Implementationen.
+Die erste Implementation ist die System V MessageQueue, und verwendet zur Identifikation einfache Integer.
+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 Strings 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 verbessert wurde.
 \subsubsection{ROS-Server}
 -Transformieren von ROS2 action server in Message Queue