MasterarbeitLaTeX/tex/6_Ausblick.tex
2023-06-30 03:01:03 +02:00

76 lines
5.8 KiB
TeX

\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.
\section{Simulation bewegter Objekte}
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 mit dem Roboter ist möglich, da dieser aus mehreren Physikobjekten besteht.
Das Objekt kann somit an das Objekt des Endeffektors als Unterobjekt hinzugefügt werden.
Der daraus resultierende Übergang in lokale Koordinaten kann potentielle 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 diesen anzupassen.
Die unterschiedliche Anbindung von Roboter und Mensch erfordert mehrere Implementationen, welche Zustandsdaten über das Objekt austauschen müssen.
Um die Objekte mit
\section{Ergänzung von 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}
-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.