Chnages to 29.06

.kile/mechforsch.kilepr.gui

@@ -2,7 +2,7 @@
 kile_livePreviewEnabled=true
 kile_livePreviewStatusUserSpecified=true
 kile_livePreviewTool=LivePreview-PDFLaTeX
-lastDocument=tex/4_Umsetzung.tex
+lastDocument=tex/6_Ausblick.tex
 
 [document-settings,item:Einleitung.tex]
 Bookmarks=
@@ -76,6 +76,15 @@ Indentation Mode=normal
 Mode=LaTeX
 Mode Set By User=false
 
+[document-settings,item:tex/6_Ausblick.tex]
+Bookmarks=
+Encoding=UTF-8
+Highlighting=LaTeX
+Highlighting Set By User=false
+Indentation Mode=normal
+Mode=LaTeX
+Mode Set By User=false
+
 [document-settings,item:tex/Einleitung.tex]
 Bookmarks=
 Encoding=UTF-8
@@ -87,7 +96,7 @@ Mode Set By User=false
 
 [item:main.bib]
 open=true
-order=6
+order=7
 
 [item:main.tex]
 open=true
@@ -117,6 +126,10 @@ order=4
 open=true
 order=5
 
+[item:tex/6_Ausblick.tex]
+open=true
+order=6
+
 [view-settings,view=0,item:Einleitung.tex]
 CursorColumn=0
 CursorLine=0
@@ -134,51 +147,59 @@ TextFolding={"checksum":"7dd721e78f3a584f245ca717d88453d9d1888b82","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:main.tex]
-CursorColumn=32
-CursorLine=26
+CursorColumn=0
+CursorLine=97
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"19a710817310e6ac5ce296cc7073fcf7cdc1cc55","ranges":[]}
+TextFolding={"checksum":"a9f3802ff2422622f2ccbc846c82d7d7d46db982","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/1_Einleitung.tex]
 CursorColumn=0
-CursorLine=22
+CursorLine=19
 Dynamic Word Wrap=false
 JumpList=
 TextFolding={"checksum":"578f69b0ffbc27d095768d7a3111120650ffd5d0","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/2_Konzept.tex]
-CursorColumn=0
-CursorLine=8
+CursorColumn=67
+CursorLine=116
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"a590f5cb77a9b42aa1d412e8c60088086c2e8f81","ranges":[]}
+TextFolding={"checksum":"60485ed57cc9cd7aa26821b7c57cadfc76a24734","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/3_Auswahl.tex]
-CursorColumn=107
-CursorLine=273
+CursorColumn=0
+CursorLine=49
 Dynamic Word Wrap=false
 JumpList=
 TextFolding={"checksum":"860366adcb7dc59b870dcd7c34c98c68b581d6d0","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/4_Umsetzung.tex]
-CursorColumn=0
-CursorLine=428
+CursorColumn=41
+CursorLine=6
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"6678e5fe5aa540fc73ddc9fc5e763f132f521e9f","ranges":[]}
+TextFolding={"checksum":"3d0063a21b9a74ae5488307f1048b49b8724b500","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/5_Evaluation_und_Diskussion.tex]
-CursorColumn=0
-CursorLine=59
+CursorColumn=41
+CursorLine=118
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"618c3dd623e4798cc57536a05b4dd83a099ea683","ranges":[]}
+TextFolding={"checksum":"b17d8b3f6bc2bdeb9ad7095d96896e959cba5b05","ranges":[]}
+ViMarks=
+
+[view-settings,view=0,item:tex/6_Ausblick.tex]
+CursorColumn=53
+CursorLine=22
+Dynamic Word Wrap=false
+JumpList=
+TextFolding={"checksum":"7fca53ae81408bb5cfc595cefb1dbfffcdb121bd","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:tex/Einleitung.tex]

main.tex

@@ -95,47 +95,13 @@ parskip=half,
 
 \setcounter{page}{1}
 \pagenumbering{arabic}
+
 \input{tex/1_Einleitung.tex}
 \input{tex/2_Konzept.tex}
 \input{tex/3_Auswahl.tex}
 \input{tex/4_Umsetzung.tex}
 \input{tex/5_Evaluation_und_Diskussion.tex}
-
-\chapter{Ausblick}
-\section{Ergebnisse}
-\subsection{Graphische Repräsentation der Szenarien}
--Szenarien graphisch abgebildet
-\subsection{Anpassung der Behavior Trees an Szenarien}
--Trees angepasst
-\section{Diskussion}
--Viele Iterationen benötigt
-
--Funktionstüchtige Simulation der Szenarien
-
--Bewegung der Objekte schwerer als gedacht
-
--Synchronisationsmechanismus Gazebo <-> MoveIt benötigt
-\section{Ausblick}
-\subsection{Umsetzung in anderem Simulator}
--Einfachere ROS Anbindung
--Potentiell einfacher ausbaubar auf Basis einer erweiterbaren Gameengine
--Mangelhafte Dokumentation von Gazebo
-\subsection{Simulation bewegter Objekte}
--Aufgrund von Komplexität des Prozesses nicht integriert
-\subsection{Ergänzung von Umgebungserkennung}
--MoveIt hat Unterstützung
-
--Daten aus Gazebo extrahieren und in MoveIt einbinden
-
--Person in OctoMap\cite{octomap} erkennen
-\subsection{Zusammenbringen von ActorPlugin und ActorServer}
--Mechanismus für Datenaustausch zwischen ROS und Gazebo überdenken/überarbeiten
-
--Geteilte ROS Instanz zwischen Plugins? Wie?
-
--Potentielle Integration von ROS als Messagedients in Gazebo
-
-\subsection{Separieren der Subtrees in eigene Dateien}
+\input{tex/6_Ausblick.tex}
 
 \printbibliography
 \newpage

mechforsch.kilepr

@@ -65,3 +65,9 @@ archive=true
 encoding=UTF-8
 highlight=LaTeX
 mode=LaTeX
+
+[item:tex/6_Ausblick.tex]
+archive=true
+encoding=UTF-8
+highlight=LaTeX
+mode=LaTeX

tex/2_Konzept.tex

@@ -13,7 +13,7 @@ Hierzu zählt die Austauschbarkeit und Erweiterbarkeit von Komponenten wie der s
 Um diese Möglichkeiten zu schaffen, sind die Systeme modular aufzubauen.
 
 \begin{figure}
-\includegraphics{img/MA-Konzept-Übersicht.drawio.pdf}
+\includegraphics{img/MA-Konzept-Übersicht}
 \centering
 \caption{Visualisierung des Konzepts}
 \label{concept_overview}

tex/4_Umsetzung.tex

@@ -8,10 +8,10 @@ Zudem ist die Bewegungsplanung mit MoveIt2 deutlich komplexer als vorerst angeno
 Diese Komplexität entsteht aus der Interaktion mehrerer Komponenten, die das Gesamtsystem zur Ausführung benötigt.
 Alle Einzelsysteme mussten hierfür konfiguriert werden, um die Kommunikation dieser zu ermöglichen.
 
-Anhand der hier genannten Änderungen wurde die Übersicht des Systems angepasst, die in Abbildung \ref{umsetzung_overview} zu sehen ist.
+Die hier genannten Änderungen erfordern eine Anpassung der Systemübersicht, deren neue Version in Abbildung \ref{umsetzung_overview} zu sehen ist.
 
 \begin{figure}
-\includegraphics[width=\textwidth]{img/MA-Umsetzung-Übersicht.drawio}
+\includegraphics[width=\textwidth]{img/MA-Umsetzung-Übersicht}
 \centering
 \caption{Visualisierung des überarbeiteten Konzepts}
 \label{umsetzung_overview}
@@ -38,13 +38,13 @@ Um Zugriff auf die Grafikbeschleunigung des Systems zu erhalten, muss deren Repr
 Der Zugriff auf die Desktopumgebung, der im vorherigen Schritt entsperrt wurde, wird nun 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 der Befehl \code{./start.sh} im Verzeichnis der Containerinstallation ausgeführt werden.
+Zum Starten des Containers muss das Script \code{start.sh} im Verzeichnis der Containerinstallation ausgeführt werden.
 Dieser führt die obengenannten Schritte aus und den Container startet.
 Eine Verbindung zum Container ist möglich, nachdem die Meldung \code{ros_1 | Ready to connect.} in der Konsole erscheint.
 
 Dafür wird ein SSH-Client eingesetzt, der eine Verbindung zu der lokalen Netzadresse des Systems mit dem Benutzer \code{ros} aufbauen kann.
 Der Port des SSH-Servers wird dabei durch die Deklaration im docker-compose.yaml an das Hostsystem durchgereicht.
-Hierbei ist zu beachten, dass der SSH-Server im Container auf Port 2222 antwortet, was nicht dem standartmäßigen Port 22 entspricht.
+Hierbei ist zu beachten, dass der SSH-Server im Container auf Port 2222 ausgeführt wird.
 
 Nach der Verbindung wird automatisch die ROS2-Umgebung eingerichtet.
 Diese kann ohne weitere Befehle nach Verbindungsaufbau genutzt werden.
@@ -63,7 +63,7 @@ Um eine Nutzung in allen Umgebungen zu erlauben, wurde diese in das Hauptverzeic
 
 
 Da der Kompiliervorgang parallel abläuft, erscheinen Informationen zu allen Paketen gleichzeitig, was das Finden eines Fehlers erschwert.
-Um trotzdem alle wichtigen Informationen zu erhalten, kommt der Event-Handler \code{console_cohesion+} zum Einsatz, der die Ausgaben neu formatiert.
+Um trotzdem alle wichtigen Informationen zu erhalten, kommt der Event-Handler \code{console_cohesion} zum Einsatz, der die Ausgaben neu formatiert.
 Durch diesen werden die Ausgaben gruppiert, und erst nach einen vollständigen Kompiliervorgang eines Pakets nacheinander ausgegeben.
 Dies ermöglicht es, aufgetretene Fehler einfacher auf ein bestimmtes Paket zurückführen zu können, ohne das gesamte Log zu durchsuchen.
 Hierbei ist es hilfreich, dass die verbleibenden Kompiliervorgänge abgebrochen werden, falls der Kompiliervorgang eines Pakets fehlschlägt.
@@ -99,9 +99,10 @@ Die anfängliche Entwicklung wurde mit PyCharm und CLion durchgeführt, da diese
 Jedoch sind diese Umgebungen sehr ressourcenintensiv, was die gleichzeitige Ausführung erheblich verlangsamt.
 
 Aus diesem Grund wurde später eine Entwicklungsumgebung mit LSP-Unterstützung, in diesem Fall Lapce, verwendet.
-Dazu wurden dem Container die benötigten LSP-Server hinzugefügt und konfiguriert, um diese mit Lapce nutzen zu können.
+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.
-Dabei wird auch der Ressourcenverbrauch gesenkt, da nur ein einziger Editor benötigt wird.
+Durch diese Maßnahme wird der Ressourcenverbrauch gesenkt, da nur ein einziger Editor benötigt wird.
 
 \begin{figure}
 \includegraphics[width=\textwidth]{img/MA-Umsetzung-Lapce}
@@ -487,9 +488,9 @@ Um dies zu erreichen, können im Plugin bestimmte Interfaces mit entsprechenden
 Diese Funktionen werden später in der Simulation aufgerufen.
 Folgende Funktionen werden von Gazebo unterstützt:
 \begin{description}
- \item[Configure] wird aufgerufen, sobald das Plugin geladen wurde.
+ \item[Configure] wird aufgerufen, sobald das Plugin geladen wird.
  Alle benötigten Informationen über dessen Umgebung werden als Parameter übergeben.
- Darunter fallen die Entity, zu der das Plugin als Component hinzugefügt wurde.
+ Als ersten Parameter wird die Entity übergeben, an welcher das Plugin als Component hinzugefügt wurde.
  Außerdem wird eine Referenz auf die Konfiguration des Plugins in der geladenen Welt übergeben.
  Für den Zugriff auf die Simulationsumgebung werden zuletzt noch eine aktuelle Instanz des EntityComponentManagers und EventManagers von Gazebo übergeben.
  \item[PreUpdate] wird verwendet, um den nächsten Update-Schritt vorzubereiten.

tex/5_Evaluation_und_Diskussion.tex

@@ -1,9 +1,22 @@
 \chapter{Evaluation und Diskussion}
 
+\section{Auswahl einer geeigneten Umgebung}
+Die Auswahl einer geeigneten Umgebung für die gewünschte Simulation erfolgte in mehreren Auswahlschritten.
+Hierfür wurden mehrere Komponenten einzeln verglichen und ausgewählt.
+Folgende Komponenten wurden für die Umgebung ausgewählt:
+\begin{itemize}
+ \item ROS2 als Dienstumgebung
+ \item Gazebo Ignition als Simulationssoftware
+ \item BehaviorTree.CPP als Beschreibungssprache
+\end{itemize}
+
+Alle Komponenten können miteinander kommunizieren, was den Aufbau einer Simulationsumgebung erlaubt.
+
 \section{Nutzung der Virtualisierungsumgebung}
 Die auf Docker basierende Virtualisierungsumgebung stellt eine vollständige ROS2-Installation dar.
 In dieser Umgebung sind alle für die Arbeit benötigten Pakete enthalten.
-Der Start der Umgebung erfolgt über das mitgelieferte \code{start.sh}-Shellskript, welches ohne Parameter ausgeführt wird.
+Der Start der Umgebung erfolgt über das mitgelieferte \code{start.sh}-Shellskript.
+Dieses Skript wird ohne Parameter ausgeführt.
 
 Falls die Umgebung noch nicht genutzt wurde, wird eine neue Containervorlage erstellt.
 Dieser Prozess kann, je nach Internetverbindung des ausführenden Rechners, mehrere Minuten in Anspruch nehmen.
@@ -11,7 +24,7 @@ Der Start der Umgebung wird mit der Ausgabe \code{ros-ros-1  | Ready to connect.
 Während der Nutzung der Umgebung muss das Terminal weiter geöffnet bleiben.
 Nach dem Senden eines Terminiersignals durch das Schließen des Terminals oder die Tastenkombination \code{Ctrl+C} wird die Containerumgebung beendet.
 
-\begin{figure}[h]
+\begin{figure}
 \includegraphics[width=\textwidth]{img/MA-Docker-Started}
 \centering
 \caption{Konsole mit ausgeführter Virtualisierungsumgebung}
@@ -22,9 +35,9 @@ Die Verbindung in die ROS-Umgebung erfolgt über SSH in einer separaten Konsole.
 In der so aufgebauten Session kann die Hardwarebeschleunigung des Hostsystems automatisch genutzt werden.
 Dies wurde in Abbildung \ref{console-docker-passthrough} durch die Ausführung von \code{glxgears}, einer OpenGL-Anwendung zum Testen der Grafikpipeline, demonstriert.
 
-Das entworfene Containersystem ist mit deiser Funktionalität für den Einsatz geeignet.
+Das entworfene Containersystem ist mit der bereitgestellten Funktionalität eine Grundlage für die weitere Implementation.
 
-\begin{figure}[h]
+\begin{figure}
 \includegraphics[width=\textwidth]{img/MA-Docker-Passthrough}
 \centering
 \caption{Konsole in der virtuellen Umgebung mit Grafiktests}
@@ -42,7 +55,7 @@ Dieser muss in folgendem Format verwendet werden:
 Als Standard wird die Option \code{Coex} genutzt, falls der \code{scene}-Parameter nicht spezifiziert wird.
 
 Nach dem Start der Simulationsumgebung ist der Raum vollständig geladen und einsatzbereit (Abbildung \ref{sim-room}).
-Der Roboter befindet sich in der Ausgangsposition, siehe Abbildung \ref{robot-still}
+Der Roboter befindet sich nach dem Start in der Ausgangsposition, siehe Abbildung \ref{robot-still}.
 
 \begin{figure}
 \begin{minipage}{.45\textwidth}
@@ -60,10 +73,51 @@ Der Roboter befindet sich in der Ausgangsposition, siehe Abbildung \ref{robot-st
 \end{minipage}
 \end{figure}
 
+\section{Erstellung der benötigten Modelle}
+
 \section{Steuerung des Menschen}
 
+Durch den Start der Simulation wird selbstständig das erstellte ActorPlugin geladen.
+Der Start des für diese Arbeit implementierten ActorServers erfolgt zeitgleich, um die Anbindung an ROS zu gewährleisten.
+Beide Anwendungen zusammen erlauben das Ausführen von Bewegungen und Animationen zur Laufzeit in der Simulation.
+
+Alle für die Simulation des Menschen erstellten Animationen werden automatisch geladen, sobald diese durch das Plugin verwendet werden.
+Dies kann durch die erstellten BehaviorTree-Nodes erfolgen, aber auch durch das Verwenden von Terminalbefehlen zu Testzwecken.
+
+
+\section{Definition von Verhalten mit einer Beschreibungssprache}
+
+Die Definition von verschiedenen Verhaltensweisen über eine Beschreibungssprache wurde durch die Erstellung neuer Nodes erreicht.
+Für die Bewegung und Animation des Menschen sind die Nodes ActorMovement und ActorAnimation verfügbar.
+Die Steuerung des Roboters erfolgt durch die RobotMove- und SetRobotVelocity-Node.
+Beide Nodes zur Kontrolle des Roboters starten eine neue Bewegung mit den neuen Parametern.
+Im Falle einer laufenden Bewegung wird diese gestoppt und mit den neuen Parametern gestartet.
+
+Um Bewegungen in Zonen zu ermöglichen, kann die GenerateXYPose-Node zufällige Positionen in einer Zone generieren.
+Die InAreaTest-Node erlaubt eine Auskunft über die Position von Objekten.
+Eine Redefinition von bestehenden Parametern der generierten Pose ist über die OffsetPose-Node möglich.
+
+Eine Wiederaufnahme von unvollständigen Aktionen ist durch die implementierte Interruptable\-Sequence-Node möglich.
+
+Die Entscheidung über die Ausführung von einer aus mehreren Aktionen ist durch die WeightedRandom-Node realisiert.
+Um Fehler simulieren zu können, ist der Abbruch von Aktionen nötig.
+Dies wird durch die RandomFailure-Node erreicht.
+
+Eine Kombination aus diesen neu implementieren und den bereits verfügbaren Nodes kann alle benötigten Verhalten darstellen.
+
 \section{Umsetzung der Szenarien}
-\subsection{Koexistenzszenario}
+
+Alle beschriebenen Szenarien sind als Behavior Trees umgesetzt, welche nach dem Start einer Simulation ausgeführt werden.
+
+\subsubsection{Koexistenzszenario}
+
+Im Koexistenzszenario interagieren Roboter und Mensch nur im Ausnahmefall.
+Der Roboter simuliert einen Entladevorgang, bei welchem Objekte vom linken Tisch auf den rechten Tisch bewegt werden.
+Die für diesen Zweck implementierten Bewegungsnodes werden in späteren Szenarien weiter verwendet.
+Um den Menschen nicht zu gefährden, wird die Verfahrgeschwindigkeit automatisch and die Aufenthaltszone des Menschen angepasst.
+
+Der Arbeitsvorgang des Menschen besteht aus dem Arbeiten an einer Werkbank und dem Verbringen von Material in das Regal.
+In diesem Szenario begibt sich der Mensch nur mit einer Wahrscheinlichkeit von 5\% nach jedem Arbeitsvorgang zum Roboter.
 
 \begin{figure}
 \begin{minipage}{.45\textwidth}
@@ -81,7 +135,13 @@ Der Roboter befindet sich in der Ausgangsposition, siehe Abbildung \ref{robot-st
 \end{minipage}
 \end{figure}
 
-\subsection{Kooperationsszenario}
+\subsubsection{Kooperationsszenario}
+
+Eine Ausweitung der Interaktion erfolgt im Kooperationsszenario.
+In diesem werden durch den Roboter Objekte entweder weitergereicht oder aussortiert.
+Nach jedem aussortierten Objekt wird der Mensch gerufen.
+Der Mensch holt den Ausschuss dann nach dem erledigen seiner aktuellen Aufgabe ab.
+Diese Interaktion und das in diesem Szenario hinzugefügte Fließband sind in Abbildung \ref{coop-human} dargestellt.
 
 \begin{figure}
 \includegraphics[width=\textwidth]{img/MA-Sim-Human-Coop}
@@ -90,7 +150,7 @@ Der Roboter befindet sich in der Ausgangsposition, siehe Abbildung \ref{robot-st
 \label{coop-human}
 \end{figure}
 
-\subsection{Kollaborationsszenario}
+\subsubsection{Kollaborationsszenario}
 
 \begin{figure}
 \begin{minipage}{.45\textwidth}
@@ -108,28 +168,6 @@ Der Roboter befindet sich in der Ausgangsposition, siehe Abbildung \ref{robot-st
 \end{minipage}
 \end{figure}
 
-
-
-
-\section{Simulation des Menschen}
--Animationen und Bewegungen funktionieren
-
--Kollisionen möglich, aber mit Animationen schwer zu synchronisieren
-\section{Bewegung des Roboters}
--Roboter kann sich bewegen
-
--Kollisionen verfügbar
-
--Interaktion technisch möglich, nicht implementiert. (Kooperation MoveIt/Gazebo nötig)
-\section{BehaviorTrees}
-\subsection{Nodes}
--Nodes für implementierte Funktionen verfügbar
-
--Einige andere, technisch relevante Nodes auch implementiert
-\subsection{Kombinieren von Nodes zu einer Request}
--MoveIt Planung benötigt mehrere Parameter, sollen aber in einzelnen Nodes gesetzt werden
-
--Kombination nötig, Beschreibung hier
 \section{Lessons Learned bei der Umsetzung}
 -Viele kleine Unannehmlichkeiten, kombiniert ein großes Problemen
 
@@ -144,25 +182,25 @@ Der Roboter befindet sich in der Ausgangsposition, siehe Abbildung \ref{robot-st
 
 -Fehler durch fehlerhafte Config (Mal nachsehen, was das genau war)
 \subsection{Gazebo}
-\subsubsection{Upgrade auf Ignition}
-Gazebo ist zu diesem Zeitpunkt in mehreren, teilweise gleichnamigen Versionen verfügbar, die sich jedoch grundlegend unterscheiden.
-Ein altes Projekt mit dem früheren Namen Gazebo, dass nun in Gazebo Classic umbenannt wurde,
-die Neuimplementation der Simulationssoftware mit dem Namen Gazebo Ignition und
-die nächste Version, die nur noch den Namen Gazebo tragen soll.
-Dies ist darauf zurückzuführen, dass Gazebo Classic und Ignition eine Zeit lang gleichzeitig existierten, jedoch unterschiedliche Funktionen und interne Schnittstellen besitzen.
+%\subsubsection{Upgrade auf Ignition}
+%Gazebo ist zu diesem Zeitpunkt in mehreren, teilweise gleichnamigen Versionen verfügbar, die sich jedoch grundlegend unterscheiden.
+%Ein altes Projekt mit dem früheren Namen Gazebo, dass nun in Gazebo Classic umbenannt wurde,
+%die Neuimplementation der Simulationssoftware mit dem Namen Gazebo Ignition und
+%die nächste Version, die nur noch den Namen Gazebo tragen soll.
+%Dies ist darauf zurückzuführen, dass Gazebo Classic und Ignition eine Zeit lang gleichzeitig existierten, jedoch unterschiedliche Funktionen und interne Schnittstellen besitzen.
 
-Das Upgrade von Gazebo Classic auf Gazebo Ignition gestaltete sich aus mehreren Gründen schwierig.
-Dies ist am leichtesten an der geänderten Nutzeroberfläche sichtbar, die in Ignition nun modular ausgeführt ist.
-Um dieses neue modulare System nutzen zu können, wurde das Dateiformat für die Simulationen angepasst.
-In diesem werden die benötigten Physikparameter, Nutzeroberflächen, Plugins und die Simulationswelt definiert.
+%Das Upgrade von Gazebo Classic auf Gazebo Ignition gestaltete sich aus mehreren Gründen schwierig.
+%Dies ist am leichtesten an der geänderten Nutzeroberfläche sichtbar, die in Ignition nun modular ausgeführt ist.
+%Um dieses neue modulare System nutzen zu können, wurde das Dateiformat für die Simulationen angepasst.
+%In diesem werden die benötigten Physikparameter, Nutzeroberflächen, Plugins und die Simulationswelt definiert.
 
-Um alte Simulationsdateien zu migieren, empfiehlt sich die Erstellung einer neuen, leeren Welt in Gazebo Ignition,
-sodass alle benötigten Physik, Nuteroberflächen und Pluginreferenzen erstellt werden.
-Danach kann die Welt Stück für Stück in das neue Format übertragen werden, wobei nach jedem Eintrag ein Test zur Funktionsfähigkeit gemacht werden sollte, da sich bestimmte Parameterdeklarationen geändert haben.
-Die Arbeit in kleine Stücke aufzuteilen ist hierbei hilfreich, da Fehler während des Ladevorgangs im Log nicht weiter beschrieben werden.
+%Um alte Simulationsdateien zu migieren, empfiehlt sich die Erstellung einer neuen, leeren Welt in Gazebo Ignition,
+%sodass alle benötigten Physik, Nutzeroberflächen und Pluginreferenzen erstellt werden.
+%Danach kann die Welt Stück für Stück in das neue Format übertragen werden, wobei nach jedem Eintrag ein Test zur Funktionsfähigkeit gemacht werden sollte, da sich bestimmte Parameterdeklarationen geändert haben.
+%Die Arbeit in kleine Stücke aufzuteilen ist hierbei hilfreich, da Fehler während des Ladevorgangs im Log nicht weiter beschrieben werden.
 
-Auch das alte Plugin musste auf das neue System angepasst werden, was auch hier zu einer kompletten Neuimplementation führte, da die internen Systeme zu große Unterschiede aufwiesen.
-Darunter fallen eine grundlegende Strukturänderung der unterliegenden Engine, die auf ein Entity-Component-System umstellte, aber auch Veränderungen an den verwendeten Objekten innerhalb dieses Systems.
+%Auch das alte Plugin musste auf das neue System angepasst werden, was auch hier zu einer kompletten Neuimplementation führte, da die internen Systeme zu große Unterschiede aufwiesen.
+%Darunter fallen eine grundlegende Strukturänderung der unterliegenden Engine, die auf ein Entity-Component-System umstellte, aber auch Veränderungen an den verwendeten Objekten innerhalb dieses Systems.
 \subsubsection{Pluginarchitektur}
 Die von Gazebo verwendete Plugininfrastruktur ist ideal, um schnell neue Funktionen in Gazebo zu entwickeln.
 Jedoch existiert damit jedes Plugin im selben Prozess, was bei der Nutzung von Bibliotheken, die nicht für die mehrfache Nutzung im selben Prozess entsprechend ausgelegt wurden, zu Problemen führen kann.
@@ -193,19 +231,7 @@ Natürlich ist die Einführung eines weiteren Nachrichtendienstes ein Bruch der
 \subsection{ROS2}
 \subsubsection{Nachrichten und deren Echtzeitfähigkeit}
 -TCP und UDP verfügbar, jedoch nicht sofort kompatibel
-\subsubsection{Änderung der Compilertoolchain}
--Änderung des Buildsystems von rosbuild auf catkin
-
--Benötigte Änderungen in CMakeFile und package
 \subsection{MoveIt2}
-\subsubsection{Upgrade auf MoveIt2}
--Unterschiede in der Deklaration des Roboters selbst
-
--Änderungen der Deklaration der ros\_control Anbindung
-
--Vorerst kein Setup, manuelle Migration erforderlich
-
-->Lesson learned: Projekte häufig auf Updates prüfen
 \subsubsection{Fehlerhafte Generierung der Roboter}
 -Einige Aspekte der Generierung nicht erforderlich oder falsch
 \subsubsection{Controller}

tex/6_Ausblick.tex

@@ -0,0 +1,58 @@
+\chapter{Ausblick}
+\section{Umsetzung in anderem Simulator}
+Die Umsetzung des gleichen Problems in einem anderen Simulator bietet die Möglichkeit, weitere Simulationsplatformen zu testen und miteinander zu vergleichen.
+Hierbei ist vor allem die Anbindung an ROS interessant, welche mit Gazebo mit nur einem Plugin gleichzeitig funktioniert.
+
+Eine verbesserte Anbindung an ROS würde die schnellere Entwicklung von Komponenten und Szenarien erlauben.
+Da diese für viele andere Simulatoren erst geschaffen werden muss, kann von Anfang an ein Fokus auf Erweiterbarkeit gelegt werden.
+
+Je nach gewählter Umgebung ist es potentiell nötig, bestimmte Basisfunktionen neu zu implementieren, falls diese noch nicht unterstützt werden.
+Moderne Gameengines sind für diesen Einsatzzweck geeignet, da diese viele Bestandteile einer Simulationsplatform bereits enthalten.
+Außerdem ist die hohe Verfügbarkeit von Tutorials und Dokumentation für diese weitläufig eingesetzten Engines vorteilhaft.
+
+Mitgelieferte Werkzeuge bekannter Engines wie Unity, Unreal Engine und Godot beinhalten ausgereifte Physik- und Animationssysteme.
+Diese können für Roboterbewegungen und Menschensimulation verwendet werden.
+\subsection{Simulation bewegter Objekte}
+-Aufgrund von Komplexität des Prozesses nicht integriert
+\subsection{Ergänzung von Umgebungserkennung}
+-MoveIt hat Unterstützung
+
+-Daten aus Gazebo extrahieren und in MoveIt einbinden
+
+-Person in OctoMap\cite{octomap} erkennen
+\section{Vereinigung von ActorPlugin und ActorServer}
+-Mechanismus für Datenaustausch zwischen ROS und Gazebo überdenken/überarbeiten
+
+-Geteilte ROS Instanz zwischen Plugins? Wie?
+
+-Potentielle Integration von ROS als Messagedients in Gazebo
+
+\section{Migration auf die neuste ROS-Version}
+Die neuste ROS-Version bietet keine expliziten Vorteile der Umgebung selbst, jedoch sind in dieser mehr Pakete verfügbar.
+In der für das Projekt genutzten Umgebung befinden sich mehrere Pakete, die so auf eine neuere Version gebracht werden könnten.
+Jedoch ist der Aufwand einer Migration nur schwer abschätzbar.
+Dies führte zu der Entscheidung, diesen Prozesses in dieser Arbeit nicht durchzuführen.
+
+Ein Vorteil dieser Maßnahme ist die Möglichkeit, das Paket \code{gz_ros2_control} aus einer offiziellen Paketquelle zu beziehen.
+Dieses Paket stellt das Gazebo-Plugin für den Roboter bereit und muss so nicht manuell auf dem neusten Stand gehalten werden.
+
+\section{Verbesserung der Behavior Trees}
+Eine weitere mögliche Verbesserung ist der Ausbau der Implementation der Behavior Trees.
+
+Ein Update auf die neuste Version, die während der Entwicklung diese Projektes erschienen ist, würde die verbesserte Nutzung von asynchronen Nodes erlauben.
+Die Integration von Pre- und Post-Conditions erlaubt die Ausführung von Events vor und nach dem Ausführen einer Node.
+Weitere universelle Node-Parameter vereinfachen den Aufbau von Bäumen durch die Vereinfachung von Schleifen und Bedingungen.
+
+Ein Nachteil der Migration wäre jedoch das Wegfallen einiger Funktionen des Editors, welcher in dieser Version unter einer neuen Lizenz vertrieben wird.
+Die Analyse von Logdateien nach der Ausführung und die Überwachung von Bäumen zur Laufzeit sind ohne kostenpflichtige Lizenz nicht mehr möglich.
+
+Eine weitere Alternative ist die Nutzung von MoveIt Studio, welches auch mit Behavior Trees arbeitet.
+Die direkte Integration mit MoveIt vereinfacht die Anbindung an den Roboter, da wichtige Funktionen bereits implementiert sind.
+Jedoch ist die Unterstützung für eigene Befehle nur schlecht dokumentiert.
+Diese werden aber für die Steuerung des Menschen benötigt, was dieses Alternative nur für die Robotersteuerung attraktiv macht.
+
+Die Anpassung der aktuellen Implementation für größere Projekte ist eine weitere Option.
+Um die Übersichtlichkeit des Projekts zu erhöhen, werden häufig separate Module verwendet.
+Diese können einzelne Funktionen bereitstellen, die separat von anderen Modulen agieren.
+Alle Module müssen aktuell im Buildfile deklariert und mit in das Programm kompilliert werden.
+Bei einer großen Anzahl an Modulen erschwert dieser Umstand die Übersicht über benötigte Module für spezifische Trees.