Changes up 29.06
This commit is contained in:
parent
6c0668f2fd
commit
8b0b1ac02b
16
main.bib
16
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},
|
||||
}
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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?
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user