diff --git a/main.bib b/main.bib index 7dd721e..b10ad08 100644 --- a/main.bib +++ b/main.bib @@ -282,3 +282,19 @@ doi = {https://doi.org/10.1201/9780429489105} url = {http://design.ros2.org/articles/changes.html}, note = {letzter Zugriff 25.06.2023}, } + +@misc{lsp, + title = {Official page for Language Server Protocol}, + url = {https://microsoft.github.io/language-server-protocol/}, + note = {letzter Zugriff 29.06.2023}, +} +@misc{gazeboDebug, + title = {Ignition Gazebo: Debugging}, + url = {https://gazebosim.org/api/gazebo/2.10/debugging.html}, + note = {letzter Zugriff 29.06.2023}, +} +@misc{rosDebug, + title = {How can I run ROS2 nodes in a debugger (e.g. gdb)? - ROS Answers: Open Source Q\&A Forum}, + url = {https://answers.ros.org/question/267261/how-can-i-run-ros2-nodes-in-a-debugger-eg-gdb/}, + note = {letzter Zugriff 29.06.2023}, +} diff --git a/tex/3_Auswahl.tex b/tex/3_Auswahl.tex index 860366a..6b7f9d1 100644 --- a/tex/3_Auswahl.tex +++ b/tex/3_Auswahl.tex @@ -130,7 +130,7 @@ Eine solche Umgebung erlaubt die Zerlegung der geplanten Simulation in mehrere K Die daraus erfolgte Abgrenzung erhöht die Übersichtlichkeit der einzelnen Bestandteile. Dies vereinfacht die spätere Wartung des Projekts. -\section{Simulationsumgebung (Gazebo)} +\section{Simulationsumgebung} \subsection{Auswahl} Als Simulationsumgebung eignen sich verschiedenen Programme, die sich hinsichtlich ihres Funktionsumfangs stark unterscheiden. diff --git a/tex/4_Umsetzung.tex b/tex/4_Umsetzung.tex index 3d0063a..5c4f9f8 100644 --- a/tex/4_Umsetzung.tex +++ b/tex/4_Umsetzung.tex @@ -1,6 +1,6 @@ \chapter{Umsetzung} -Bei der Umsetzung des geplanten Systemaufbaus kam es zu mehreren Problemen, die den geplanten Systemaufbau, sowie dessen Komplexität, negativ beeinflussen. +Bei der Umsetzung des geplanten Systemaufbaus waren Anpassungen nötig, die den geplanten Systemaufbau, sowie dessen Komplexität, negativ beeinflussen. Die Kommunikation zwischen dem Actormodell und dem Behavior Tree musste in mehrere Komponenten aufgeteilt werden, um Konflikte innerhalb der Simulationssoftware zu vermeiden. @@ -8,7 +8,7 @@ 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. -Die hier genannten Änderungen erfordern eine Anpassung der Systemübersicht, deren neue Version in Abbildung \ref{umsetzung_overview} zu sehen ist. +Mit den genannten Änderungen ergibt sich die in Abbildung \ref{umsetzung_overview} gezeigte Übersicht des Systems. \begin{figure} \includegraphics[width=\textwidth]{img/MA-Umsetzung-Übersicht} @@ -19,7 +19,7 @@ Die hier genannten Änderungen erfordern eine Anpassung der Systemübersicht, de \section{Docker-Compose} Um Docker für die Verwaltung einer ROS-Installation verwenden zu können, müssen einige Anpassungen vorgenommen werden. -Da viele Anwendungen, unter anderem auch die Simulationsumgebung, eine Desktopumgebung benötigen, ist der Zugriffs auf eine solche Umgebung erforderlich. +Da viele Anwendungen, unter anderem auch die Simulationsumgebung, eine Desktopumgebung benötigen, musste der Zugriff auf eine solche Umgebung berücksichtigt werden. Diese Probleme können nicht durch Docker allein gelöst werden, da die Virtualisierungsumgebung eine Trennung der Systeme vorsieht. Die Isolation des Containers von der Benutzeroberfläche des Systemskann durch eine Kombination aus zwei Komponenten aufgehoben werden. @@ -30,8 +30,8 @@ Dieses Skript erstellt zuerst die benötigten Verzeichnisse für den Container, Danach werden die SSH-Keys des Hosts in den Container kopiert, um eine SSH-Verbindung zu ermöglichen. Dieser Umweg über SSH ist nötig, da die benötigten Umgebungsvariablen für ROS sonst nicht in allen Fällen gesetzt werden können. -Außerdem werden die benötigten Zugriffe auf den lokalen X-Server durch den Container anhand dessen Hostname erlaubt. -Diese Änderung erlaubt es dem Container, Fenster auf dem Desktop anzeigen zu können, solange die benötigten SysFS-Dateien hereingereicht werden. +Außerdem werden die benötigten Zugriffe auf den lokalen X-Server durch den Container mittels Hostname erlaubt. +Diese Änderung gestattet es dem Container, Fenster auf dem Desktop anzuzeigen, solange die benötigten SysFS-Dateien hereingereicht werden. Dies geschieht durch Einträge in der compose.yml-Datei, die diese als ``bind mount'' in den Container hereinreicht. Um Zugriff auf die Grafikbeschleunigung des Systems zu erhalten, muss deren Repräsentation im SysFS unter \code{/dev/dri} hineingereicht werden. @@ -39,7 +39,7 @@ Der Zugriff auf die Desktopumgebung, der im vorherigen Schritt entsperrt wurde, Dabei handelt es sich um den Unix-Socket des X11 Displayservers. 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. +Dieser führt die obengenannten Schritte aus und startet den Container. 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. @@ -59,10 +59,10 @@ popd || exit Dieses Skript nutzt \code{colcon}, um alle Pakete in \code{~/workspace}-Verzeichnis zu erstellen. Dabei wird auch eine \code{compile_commands.json}-Datei im build-Unterordner erstellt, die von Entwicklungsumgebungen zur Syntaxvervollständigung genutzt werden. -Um eine Nutzung in allen Umgebungen zu erlauben, wurde diese in das Hauptverzeichnis gelinkt, da einige Umgebung nur dort nach dieser Datei suchen. +Um eine Nutzung in allen Entwicklungsumgebungen zu erlauben, wurde diese zusätzlich in das Hauptverzeichnis des Workspaces gelinkt. +Dies ist dem Fakt geschuldet, dass einige Entwicklungsumgebungen nur dort nach dieser Datei suchen. - -Da der Kompiliervorgang parallel abläuft, erscheinen Informationen zu allen Paketen gleichzeitig, was das Finden eines Fehlers erschwert. +Da der Kompiliervorgang parallel abläuft, erscheinen Informationen zu allen Paketen gleichzeitig, was das Finden von Fehlern erschwert. 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. @@ -79,17 +79,17 @@ Dies geschieht meist auf eine von zwei unterschiedlichen Weisen. Die Entwicklungsumgebung kann eine interne Repräsentation des geschriebenen Codes generieren. Diese Repräsentation kann nun genutzt werden, um die implementierten Funktionen der Entwicklungsumgebung bereitzustellen. -Um dies zu erreichen, muss für jede unterstützte Sprache Code geschrieben werden, der in die Entwicklungsumgebung integriert werden muss. +Um dies zu erreichen, muss für jede unterstützte Sprache Code geschrieben werden, der in die Entwicklungsumgebung integriert wird. -Als Alternative existiert das Language Server Protocol, kurz LSP, dass eine Schnittstelle in Form eines JSON-RPC Protokolls zur Verfügung stellt, um Infomationen über den Code an die Entwicklungsumgebung zu übergeben. -Dies erlaubt einer Entwicklungsumgebung, nur noch den benötigten Server der Sprache zu starten, um Informationen über den Code in einem standartisierten Protokoll zu erhalten. +Als Alternative existiert das Language Server Protocol, kurz LSP\cite{lsp}, dass eine Schnittstelle in Form eines JSON-RPC Protokolls zur Verfügung stellt, um Infomationen über den Code an die Entwicklungsumgebung zu übergeben. +Dies erlaubt einer Entwicklungsumgebung, nur noch den benötigten Server der Sprache zu starten, um Informationen über den Code in einem standardisierten Protokoll zu erhalten. Der große Vorteil des LSP ist, dass eine Entwicklungsumgebung alle Funktionen der Programmiersprache vollständig unterstützt, solange das Protokoll vollständig implementiert wurde und ein entsprechender Server für die Sprache existiert. -Jedoch können bestimmte Funktionen, die beim Design des LSP nicht bedacht wurden, einfacher in interner Implementation umgesetzt werden. +Bestimmte Funktionen, die beim Design des LSP nicht bedacht wurden, können einfacher in einer interner Implementation umgesetzt werden. Deswegen besitzen Entwicklungsumgebungen mit interner Coderepräsentation häufig mehr Funktionen, spezialisieren sich jedoch auf bestimmte Sprachen. -In diesem Projekt wurden mehrere Entwicklungsumgebungen mit den jeweils unterschiedlichen Verfahren verwendet. +In diesem Projekt wurden mehrere Entwicklungsumgebungen mit den jeweils unterschiedlichen Verfahren eingesetzt. Um diese mit dem Docker-Container verwenden zu können, müssen diese Umgebungen die Entwicklung auf entfernten Systemen unterstützten, da der Container vom ausführenden System getrennt ist. Um dies zu ermöglichen, wird ein Teil der Entwicklungsumgebung im Container ausgeführt, um mit dem inneren Kontext der Maschine arbeiten zu können. @@ -112,7 +112,7 @@ Durch diese Maßnahme wird der Ressourcenverbrauch gesenkt, da nur ein einziger \end{figure} \section{Verwendete Datentypen} -In diesem Projekt werden viele unterschiedliche Datentypen verwendet. +In diesem Projekt werden viele unterschiedliche Datentypen für sowohl den Datenaustauch zwischen Nodes, aber auch in der internen Implementation der Nodes verwendet. Diese Datentypen sind größtenteils aus der Programmiersprache C++ bekannt, jedoch werden auch weitere Typen aus eigenem Code oder eingebundenen Bibliotheken verwendet. Um die Verständlichkeit der Dokumentation zu erleichtern, sind die in der Implementation verwendeten Datentypen hier zusammengefasst und beschrieben. \begin{description} @@ -157,7 +157,8 @@ Die Lagerstätte soll im Kooperationsszenario neben der Arbeit des Menschen auch Eine Nutzung im Kollaborationsszenario ist nicht 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. -Für das Kooperationsszenario wurde ein Förderband moddeliert, das nur in diesem Szenario dem Raum hinzugefügt wird. +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. Der so erstellte Raum wird in einer .sdf-Datei als Modell referenziert, um diesen später in die Simulation einbinden zu können. Das Förderband erhält ein eigenes Modell in einer weiteren Datei, die zur Laufzeit in die Simulation geladen wird. @@ -337,7 +338,12 @@ Da sich einige Knochen nur am Anfang der Animation in einer bestimmten Pose befi \end{figure} \subsection{Programmierung} + +Die von Gazebo verwendete Plugininfrastruktur ist ideal, um schnell neue Funktionen in Gazebo zu entwickeln. +Um dies zu ermöglichen werden beim Start der Simulation zusätzliche Programme in diese eingebunden. + \subsubsection{Message Queue} + Nach der ersten Implementation des ActorPlugins kam es zu Kollisionen mit \code{ros_control}, die beide \code{rclcpp} zur Kommunikation benutzen. Diese Kollisionen führt zu einem Crash, wenn beide Plugins in der Simulation geladen werden. Dies geschieht, da beide Plugins rclcpp, eine Bibliothek zur Kommunikation mit ROS-Topics, verwenden. @@ -350,7 +356,7 @@ Nach dem Debuggen des Crashes wurden einige Problemlösungen ausprobiert, jedoch Eine Anpassung beider Plugins auf die gemeinsame Nutzung einer Ressource ist möglich, erfordert jedoch potentiell weitreichende Neuimplementationen, die zeitlich nur schwer planbar sind. Die Nutzung eines separaten Nachrichtendienstes, der keinen globalen Kontext benötigt, ist die sicherste und schnellste Lösung des Problems. -Jedoch erfordert diese Implementation zusätziliche Logik, um die beiden Dienste ineinander übersetzen zu können. +Jedoch erfordert diese Implementation zusätzliche Logik, um die beiden Dienste ineinander übersetzen zu können. Die Auswahl eines Dienstes wurde dabei aus einer Reihe an unterschielichen Möglichkeiten getroffen. Webdienste, wie zum Beispiel REST-API's und Websockets werden von vielen Sprachen nativ untersützt, was sie zu guten Kanidaten für solche Kommunikation macht. @@ -591,7 +597,8 @@ Um diese Vielfalt an Daten standartisiert an andere Software in ROS weitergeben \subsection{Modellierung} Für den Kuka LBR iisy existiert kein Simulationsmodell für Gazebo und ROS, weswegen dieses Modell aus Herstellerdaten generiert wurden. Hierzu stand eine .stl-Datei des Herstellers zur Verfügung. -Aus dieser Datei wurden mit FreeCAD\cite{freecad} alle Glieder des Roboters als Collada-Dateien exportiert. +Diese Datei enthält eine geometrische Beschreibung des Roboters, zu sehen in Abbildung \ref{robot_raw}, welche nicht direkt im Simulator nutzbar ist. +Aus dieser Datei wurden mit FreeCAD\cite{freecad} alle Glieder des Roboters als separate Collada-Dateien exportiert. Dabei muss darauf geachtet werden, dass die exportierten Daten eine ausreichende Meshgröße haben. Diese kann vor dem Export in FreeCAD eingestellt werden. Durch diese Einstellung bleiben feine Strukturen erhalten, die später in Blender wieder reduziert werden können. @@ -817,6 +824,8 @@ In Abbildung \ref{tree_base_robot} wurde dies durch eine Wolke repräsentiert. \label{tree_base_robot} \end{figure} +\subsubsection{Koexistenz} + Im ersten Szenario, der Koexistenz zwischen Mensch und Roboter, soll eine Arbeitsaufgabe durch den Roboter allein simuliert werden. Hierfür soll der Roboter Objekte von der rechten auf die linke Tischseite transportieren. Alle Nodes werden einer ReactiveSequence untergeordnet, um bei Unterbrechungen durch den Mensch den Fortschritt der Aktion behalten zu können. @@ -834,6 +843,8 @@ Der vollständige Baum ist in Abbildung \ref{tree_robot_coex} zu sehen. \label{tree_robot_coex} \end{figure} +\subsubsection{Kooperation} + Im Kooperationsszenario wird der Ablauf des ersten Szenarios modifiziert. Nach der Bewegung zu einem Objekt auf der linken Tischseite wird eine zufällige Entscheidung getroffen. Mit einer Chance von 90\% ist das Objekt den Anforderungen gerecht, und kann durch den Roboter auf ein Förderband gelegt werden. @@ -849,6 +860,8 @@ Am Ende der übernommenen Sequenz wird eine SetCalledTo-Node ergänzt, die den M \label{tree_robot_coop} \end{figure} +\subsubsection{Kollaboration} + Für das dritte Szenario soll der Roboter mit dem Menschen kollaborieren. Um dieses Szenario umzusetzen, wird ein weiteres Mal das erste Szenario modifiziert. Hier soll der Roboter eine Palette ausladen, wobei es durch die Beschaffenheit der Objekte zu Fehlern kommen kann. @@ -867,6 +880,8 @@ Bei dieser handelt es sich um eine SetCalledTo-Node, welche den Menschen ruft. \subsection{Verhalten des Menschen} +\subsubsection{Koexistenz} + Im ersten Szenario soll der Mensch nur neben dem Roboter arbeiten. Um das Verhalten des Roboters trotzdem zu prüfen, soll der Mensch selten die Sicherheitszone betreten, um den Roboter zu überwachen. Dies wird durch eine WeightedRandom-Node erreicht, die mit 95 prozentiger Wahrscheinlichkeit den normalen Arbeitsvorgang ausführt. @@ -884,6 +899,8 @@ Diese enthält eine GenerateXYPose-Node, um ein Ziel in der Sicherheitszone ausz \label{tree_actor_coex} \end{figure} +\subsubsection{Kooperation} + Für das Kooperationsszenario wird diese Abfolge durch eine weitere, übergeordnete Sequence-Node ergänzt. Diese wurde ausgewählt, da ein Ruf durch den Roboter in diesem Szenario nicht zeitkritisch ist. Eine solche Implementation erlaubt das vollständige Ausführen der vorgehenden Aufgabe. @@ -906,6 +923,8 @@ Um das Objekt im Schrank zu verstauen, wird der bereits definierte Subtree ``Dep \label{tree_actor_coop} \end{figure} +\subsubsection{Kollaboration} + Für das letzte Szenario soll der Mensch dem Roboter beim Entladen einer Palette assistieren. Falls der Mensch nicht vom Roboter gerufen wird, soll dieser im Raum herumwandern. Für die festlegung einer Baumstruktur ist es wichtig, ob der Mensch sofort, oder erst nach vollenden seiner Arbeit dem Roboter zu Hilfe kommt. diff --git a/tex/5_Evaluation_und_Diskussion.tex b/tex/5_Evaluation_und_Diskussion.tex index b17d8b3..83e2ff1 100644 --- a/tex/5_Evaluation_und_Diskussion.tex +++ b/tex/5_Evaluation_und_Diskussion.tex @@ -1,6 +1,8 @@ \chapter{Evaluation und Diskussion} -\section{Auswahl einer geeigneten Umgebung} +\section{Grundlagen} + +\subsubsection{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: @@ -12,14 +14,13 @@ Folgende Komponenten wurden für die Umgebung ausgewählt: Alle Komponenten können miteinander kommunizieren, was den Aufbau einer Simulationsumgebung erlaubt. -\section{Nutzung der Virtualisierungsumgebung} +\subsubsection{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. +Der Start der Umgebung erfolgt über das im Projektverzeichnis befindliche \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. Der Start der Umgebung wird mit der Ausgabe \code{ros-ros-1 | Ready to connect.} abgeschlossen, die auch in Abbildung \ref{console-docker-started} sichtbar ist. 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. @@ -44,7 +45,39 @@ Das entworfene Containersystem ist mit der bereitgestellten Funktionalität eine \label{console-docker-passthrough} \end{figure} -\section{Starten der Simulation eines Szenarios} +\subsubsection{Erstellung der benötigten Modelle} + +\subsubsection{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. + + +\subsubsection{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{Simulation der Szenarien} Das Starten der Simulation erfolgt über ein Skript innerhalb des \code{ign_world}-Pakets. Dieses Skript wird durch den Befehl \code{ros2 launch ign_world gazebo_controller_launch.py} ausgeführt. In diesem Skript werden alle für die Simulation benötigten ROS2-Nodes gestartet und konfiguriert. @@ -73,50 +106,17 @@ Der Roboter befindet sich nach dem Start in der Ausgangsposition, siehe Abbildun \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} - -Alle beschriebenen Szenarien sind als Behavior Trees umgesetzt, welche nach dem Start einer Simulation ausgeführt werden. +Alle beschriebenen Szenarien sind mit Außnahme des Fließbandes aus dem Kooperationsszenario als Behavior Trees umgesetzt. +Diese werden nach dem Start einer Simulation ausgeführt und definieren das Verhalten von Roboter und Mensch. \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. +Der Roboter simuliert einen Entladevorgang, bei welchem Objekte vom linken Tisch auf den rechten Tisch bewegt werden (Abbildung \ref{coex-move}). 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. +Der Arbeitsvorgang des Menschen besteht aus dem Arbeiten an einer Werkbank und dem Verbringen von Material in das Regal (Abbildung \ref{coex-shelf}). In diesem Szenario begibt sich der Mensch nur mit einer Wahrscheinlichkeit von 5\% nach jedem Arbeitsvorgang zum Roboter. \begin{figure} @@ -152,94 +152,44 @@ Diese Interaktion und das in diesem Szenario hinzugefügte Fließband sind in Ab \subsubsection{Kollaborationsszenario} +Für das Kollaborationsszenario durchschreitet der Mensch den Raum, was die Kontrolle mehrerer Systeme simuliert. +Der Roboter bewegt in diesem Szenario Objekte vom linken auf den rechten Tisch, wobei Fehler auftreten können. +Bei einem Fehler beendet der Mensch seinen Kontrollgang und hebt ein Objekt auf, um es zum Roboter zurückzubringen (Abbildung \ref{colab-drop}). +Der Roboter bricht den fehlgeschlagenen Vorgang ab, und beginnt diesen mit dem nächsten Objekt von neuem. + \begin{figure} \begin{minipage}{.45\textwidth} \includegraphics[width=\textwidth]{img/MA-Sim-Human-Colab-Pickup} \centering -\caption{Mensch bei Aufheben eines Objektes} -\label{colab-pickup} \end{minipage} \hspace{.09\textwidth} \begin{minipage}{.45\textwidth} \includegraphics[width=\textwidth]{img/MA-Sim-Human-Colab-Drop} \centering -\caption{Mensch beim Ablegen eines Objektes} -\label{colab-drop} \end{minipage} +\caption{Mensch beim Aufhebevorgang} +\label{colab-drop} \end{figure} -\section{Lessons Learned bei der Umsetzung} --Viele kleine Unannehmlichkeiten, kombiniert ein großes Problemen +\section{Zusammenfassung} +Alle simulierten Szenarien sind in einer Beschreibungssprache abgebildet. +Es wurden entsprechende Austauschmechanismen für die Beschreibungsprache geschaffen, welche auch neue Szenarien darstellen können. +Die vollständige Kontrolle der Endeffektorposition des Roboters und der Bewegung des Menschen in der Simulation sind möglich. --Dokumentation für spätere Projekte -\subsection{Erstellung des Robotermodells} --Keine direkten technischen Daten zum Roboter von Kuka --Nur CAD-Dateien der Außenhülle +Eine dynamische Simulation von Objekten, welche durch Roboter und Mensch beeinflusst werden können, konnte nicht umgesetzt werden. --Schätzung von Spezifikationen anhand Marketingmaterial -\subsection{Erweiterung des Robotermodells mit MoveIt} --Fehler durch falsche Pfade des Setups +\section{Lessons Learned} --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. +Während der Entwicklung des Projekts wurden zahlreiche Erkenntnisse gesammelt, welche die Entwicklung weiterer Projekte mit dieser Plattform erleichtern können. -%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, 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. -\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. - -Zur Kommunikation des ActorPlugins mit dem ROS-ActionServer wurde die benötigte Funktionalität vorerst im Plugin selbst implementiert. -Da diese Funktionalität zuerst entwickelt wurde, konnte sie zu diesem Zeitpunkt nur alleinstehend getestet werden. -Diese Tests verliefen vorerst erfolgreich, jedoch scheiterten sie bei der Integration des Robotermodells, dass über die \code{ros_control}-Integration ebenfalls \code{rclcpp} nutzt. - -Um dieses Problem zu umgehen, sind mehrere Lösungsansätze denkbar. \begin{description} - \item[Separater Nachrichtendienst] - Ein solcher losgelöster Dienst kann die Nachrichten mit einem anderen Programm auszutauschen, dass die Kommunikation nach außen übernimmt. - \item[Nutzung der gleichen ROS-Instanz] - Um dem Problem zu begegnen, könnte auch eine globale ROS-Instanz von Gazebo verwaltet werden, die dann von den Plugins genutzt werden kann. - Dies könnte als ein Plugin realisiert werden, dass diese anderen Plugins zur Verfügung stellt, jedoch müssten die anderen Plugins zur Nutzung dieser Schnittstelle modifiziert werden. - \item[Gazebo-ROS-Brücke] - Die Gazebo-ROS-Brücke kann Nachrichten, die in beiden Formaten definiert wurden, ineinander umwandeln. - Dies ermöglicht die Kommunikation über die Brücke als Mittelmann. - Dabei müssten Anpassungen an der Architektur vorgenommen werden, da Gazebo kein Äquivalent zum ActionServer besitzt. + \item[Testen einzelner Komponenten]\hfill\\ + Alle ROS-Nachrichtentypen sind mit Kommandozeilenbefehlen versend- und empfangbar. + Um einzelne Teilsysteme zu testen, können so deren Zustände gesetzt und überwacht werden. + \item[Überprüfung auf Updates]\hfill\\ + Die regelmäßige Prüfung von verwendeten Bestandteilen auf Updates kann helfen, neue oder verbesserte Funktionen einzusetzen. + \item[Verwendung eines Debuggers]\hfill\\ + Viele Nodes in ROS können über Kommandozeilenparameter im Debugmodus ausgeführt werden.\cite{rosDebug} + Da Programme wie Gazebo aber über weitere Launch-Files eingebunden werden, ist dies hier nicht möglich. + Eine Lösung ist in diesem Fall der separate Start der Gazebo-Umgebung in einem Debugger.\cite{gazeboDebug} \end{description} -Die Entscheidung fiel auf einen separaten Nachrichtendienst, da dessen Implementation losgelöst von anderen Systemen funktioniert. -Natürlich ist die Einführung eines weiteren Nachrichtendienstes ein Bruch der Philosophie, jedoch die einzige Methode, die garantiert funktioniert, weswegen sie letztendlich implementiert wurde. - -\subsubsection{Fehlende Animationsgrundlagen} --Animationen werden als .col bereitgestellt - --Enthalten Textur, Mesh und Bones, jedoch nicht verbunden -> schlecht für Animation -\subsection{ROS2} -\subsubsection{Nachrichten und deren Echtzeitfähigkeit} --TCP und UDP verfügbar, jedoch nicht sofort kompatibel -\subsection{MoveIt2} -\subsubsection{Fehlerhafte Generierung der Roboter} --Einige Aspekte der Generierung nicht erforderlich oder falsch -\subsubsection{Controller} --Controller benötigte Anpassungen und manuelle Tests -\section{Lessons Learned bei den Szenarien} -\subsection{Debugging} --async tty Option - --gdb ist ein Muss - --``Aufhängen'' von trees diff --git a/tex/6_Ausblick.tex b/tex/6_Ausblick.tex index 7fca53a..85f5725 100644 --- a/tex/6_Ausblick.tex +++ b/tex/6_Ausblick.tex @@ -12,15 +12,32 @@ Außerdem ist die hohe Verfügbarkeit von Tutorials und Dokumentation für diese 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 +\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} --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?