MasterarbeitLaTeX/tex/6_Ausblick.tex

\chapter{Ausblick}
\section{Umsetzung in anderem Simulator}
Die Umsetzung des gleichen Problems in einem anderen Simulator bietet die Möglichkeit, weitere Simulationsplattformen 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 der Fokus auf Erweiterbarkeit gelegt werden.

Je nach gewählter Umgebung ist es potenziell 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 Simulationsplattform 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.

\section{Simulation bewegter Objekte}\label{objectsim}
Die Simulation bewegter Objekte benötigt ein neues Gazebo-Plugin, welches mit den bereits entwickelten Komponenten der aktuellen Umgebung interagiert.
Um ein Objekt mit dem Roboter oder Menschen zu bewegen, muss dieses auf eine von zwei Arten bewegt werden.

Die Bewegung von Objekten mit dem Roboter ist möglich, da dieser mit der gegenwärtigen Implementation aus mehreren Physikobjekten besteht.
Das zu  bewegende Objekt kann somit dem Objekt des Endeffektors als Unterobjekt hinzugefügt werden.
Der daraus resultierende Übergang in lokale Koordinaten kann potenzielle Umrechnung anhand der Transformationen vorhergehender Armteile erfordern.

Eine Bewegung mit dem Menschen erfordert vor allem bei Animationen einen anderen Mechanismus.
Da der Mensch nicht aus einzelnen Physikobjekten besteht, ist die Anbringung als Unterobjekt nicht möglich.
Stattdessen muss die aktuelle Position des Armes anhand der Animationsdaten verfolgt werden, um die Position des Objektes an diese anzupassen.

Die unterschiedliche Anbindung von Roboter und Mensch erfordert mehrere Implementationen, welche Zustandsdaten über das Objekt austauschen müssen.
Um die Objekte zu steuern, muss eine weitere ROS-Anbindung in einem entsprechenden Gazebo-Plugin erfolgen.

Dieses Plugin unterliegt denselben Limitierungen, die auch schon im ActorPlugin beachtet werden mussten.
Eine weitere Nachrichtenübergabe als Zwischenschritt vor dem eigentlichen ROS-Server ist so unausweichlich.

Dieser Kommunikationsmechanismus muss das Erstellen, Entfernen und Bewegen von Objekten zwischen Roboter, Umgebung und Mensch unterstützen.
\section{Erweiterung um Umgebungserkennung}
Eine Ergänzung von simulierten Tiefenkameras zur Umgebungserkennung stellt eine weitere mögliche Ausbaustufe des Projekts dar.
Mit den Kameras kann eine Tiefenkarte erstellt werden, um die Verfahrgeschwindigkeit des Roboters zu kontrollieren.
MoveIt implementiert für diesen Verwendungszweck bereits sogenannte Octomaps.
Diese Octomaps repräsentieren die Belegung eines Raums durch Objekte mit gleichseitigen Würfeln.

Der Einsatz dieser Octomaps zum Ausweichen von Hindernissen ist bereits in der Bewegungsplanung implementiert.
Für die Reduktion der Verfahrgeschwindigkeit muss der erwartete Raum mit dem aktuellen Raum verglichen werden.
Daraus kann die Distanz zu einem unerwarteten Objekt berechnet werden, um die Verfahrgeschwindigkeit dementsprechend anzupassen.
\section{Zusammenführung von ActorPlugin und ActorServer}
Die aktuelle, separate Implementation von ActorServer und ActorPlugin kann durch eine Vereinigung der Implementation verbessert werden.
Folgende Versuche wurden bereits durchgeführt, führten aber zu keinem Erfolg:
\begin{itemize}
 \item{Die Ausführung in einem separaten Thread,}
 \item{eine Trennung vom Hauptprogramm mittels Fork und}
 \item{das Weglassen der Initialisierung von rclcpp, da diese später durch ign_ros2_control durchgeführt wird.}
\end{itemize}

\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 Prozess 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 dieses 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 \cite{moveItStudio}, welches ebenfalls mit Behavior Trees arbeitet.
Die direkte Integration mit MoveIt vereinfacht die Anbindung an den Roboter, da wichtige Funktionen bereits implementiert sind.
Jedoch ist die Unterstützung für eigene Befehle nur schlecht dokumentiert.
Diese werden aber für die Steuerung des Menschen benötigt, was dieses Alternative nur für die Robotersteuerung attraktiv macht.

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 kompiliert werden.
Bei einer großen Anzahl an Modulen erschwert dieser Umstand die Übersicht über benötigte Module für spezifische Trees.