Writing progress from 10.04

.kile/mechforsch.kilepr.gui

@@ -20,7 +20,7 @@ Highlighting=LaTeX
 Highlighting Set By User=false
 Indentation Mode=normal
 Mode=LaTeX
-Mode Set By User=false
+Mode Set By User=true
 
 [item:main.bib]
 open=true
@@ -35,17 +35,17 @@ open=false
 order=-1
 
 [view-settings,view=0,item:main.bib]
-CursorColumn=37
+CursorColumn=14
-CursorLine=112
+CursorLine=109
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"cb71bb47ec4a72f8446e70ca886b18c3c2c08129","ranges":[]}
+TextFolding={"checksum":"a7e42fe12fca343bb119c9438c9707efb60af457","ranges":[]}
 ViMarks=
 
 [view-settings,view=0,item:main.tex]
-CursorColumn=96
+CursorColumn=0
-CursorLine=11
+CursorLine=361
 Dynamic Word Wrap=false
 JumpList=
-TextFolding={"checksum":"f4caf9757786962cf6187282471f06ce0896d120","ranges":[]}
+TextFolding={"checksum":"9f78138bb44f610a790c5c58bc907bb95d19caa9","ranges":[]}
 ViMarks=

main.bib

@@ -24,7 +24,7 @@
 }
 
 @misc{gazeborosport,
-  title = {Port gazebo\_ros\_pkgs to ROS 2.0},
+  title = {Port gazebo_ros_pkgs to ROS 2.0},
   url = {https://github.com/ros-simulation/gazebo_ros_pkgs/issues/512},
   note = {letzter Zugriff: 13.4.2022},
 }
@@ -118,3 +118,27 @@
   url={https://colcon.readthedocs.io/en/released/},
   note = {letzter Zugriff: 02.04.2023},
 }
+
+@misc{moveitpipeline,
+  title = {moveit2_tutorials/moveit_pipeline.png at humble - ros-planning/moveit2_tutorials},
+  url = {https://github.com/ros-planning/moveit2_tutorials/blob/humble/_static/images/moveit_pipeline.png},
+  note = {letzter Zugriff: 02.04.2023},
+}
+
+@misc{moveitpython,
+  title = {MoveIt Commander with ROS2 - Issue \#337 - ros-planning/moveit2_tutorials},
+  url = {https://github.com/ros-planning/moveit2_tutorials/issues/337},
+  note = {letzter Zugriff: 10.04.2023},
+}
+
+@misc{rospackages,
+  title = {Packages - /ros2/ubuntu/pool/main/ :: Oregon State University Open Source Lab},
+  url = {http://packages.ros.org/ros2/ubuntu/pool/main/},
+  note = {letzter Zugriff: 10.04.2023},
+}
+
+@misc{unityroboticsofficial,
+  title = {Robotics Simulation | Unity},
+  url = {https://unity.com/solutions/automotive-transportation-manufacturing/robotics},
+  note = {letzter Zugriff: 10.04.2023},
+}

main.ist

@@ -1,31 +0,0 @@
-% makeindex style file created by the glossaries package
-% for document 'main' on 2022-4-3
-actual '?'
-encap '|'
-level '!'
-quote '"'
-keyword "\\glossaryentry"
-preamble "\\glossarysection[\\glossarytoctitle]{\\glossarytitle}\\glossarypreamble\n\\begin{theglossary}\\glossaryheader\n"
-postamble "\%\n\\end{theglossary}\\glossarypostamble\n"
-group_skip "\\glsgroupskip\n"
-item_0 "\%\n"
-item_1 "\%\n"
-item_2 "\%\n"
-item_01 "\%\n"
-item_x1 "\\relax \\glsresetentrylist\n"
-item_12 "\%\n"
-item_x2 "\\relax \\glsresetentrylist\n"
-delim_0 "\{\\glossaryentrynumbers\{\\relax "
-delim_1 "\{\\glossaryentrynumbers\{\\relax "
-delim_2 "\{\\glossaryentrynumbers\{\\relax "
-delim_t "\}\}"
-delim_n "\\delimN "
-delim_r "\\delimR "
-headings_flag 1
-heading_prefix "\\glsgroupheading\{"
-heading_suffix "\}\\relax \\glsresetentrylist "
-symhead_positive "glssymbols"
-numhead_positive "glsnumbers"
-page_compositor "."
-suffix_2p ""
-suffix_3p ""

main.tex

@@ -13,12 +13,14 @@ parskip=half,
 \usepackage{acro}
 \usepackage{listings}
 \usepackage[style=numeric,backend=biber]{biblatex}
+%\usepackage[style=numeric,backend=libbib]{biblatex}
 \usepackage{pdfpages}
 \usepackage{scrhack}
 \usepackage{xcolor}
 \usepackage{enumitem}
 \usepackage{hyperref}
 \usepackage{tabularray}
+\usepackage[strings]{underscore}
 
 \usepackage[letterspace=150]{microtype}
 \usepackage[onehalfspacing]{setspace}
@@ -26,7 +28,7 @@ parskip=half,
 \usepackage[automark,headsepline=.4pt,plainheadsepline]{scrlayer-scrpage}         % Erstellung von selbst definierten Kopfzeilen
 \clearpairofpagestyles%\clearscrheadfoot veraltet
 \renewcommand*{\chaptermarkformat}{
-  \chaptername~\thechapter\autodot\enskip
+  \chaptername~\thechapter\autodot\quad-\quad
 }
 
 \ihead*{\rightmark}
@@ -100,7 +102,7 @@ Aktuelle Arbeiten:
 
 -Planung von Interaktionen
 
--Parametervergrleiche von maschinellen und menschlichen Bewegungen
+-Parametervergleiche von maschinellen und menschlichen Bewegungen
 
 -Vermeidung von Kollisionen und Strategie
 
@@ -150,6 +152,7 @@ Cobot ist dabei ein Portemanteau aus Collaborative und Robot, was die besondere
 Er besitzt auch einen modifizierbaren Endeffektor, um unterschiedlichste Aufgaben erfüllen zu können.
 
 Um den Kuka iisy in der Simulation verwenden zu können, muss ein Modell des Roboterarms erstellt werden.
+Dieses Modell sollte die physikalischen Eigenschaften des Roboters möglichst gut wiederspiegeln.
 Anhand dieses Modells kann der Roboter dann in der Simulation dargestellt werden und mit anderen Objekten interagieren.
 
 -Beruhend auf echtem Roboter (Kuka iisy)
@@ -167,17 +170,56 @@ Um die spätere Steuerung des Menschen von außerhalb zu erleichtern, müssen di
 -Dynamische Ausführung von Befehlen
 -Erkennbare Bewegungsabläufe
 \section{Behavior Trees}
+Häufig wird Verhalten in State-Machines ausgedrückt, welche jedoch einige Nachteile besitzen.
+State-Machines werden ab einer gewissen Größe schnell unübersichtlich.
+Dies erschwert die schnelle Erfassung von Abfolgen und Zustandsübergängen, welche jedoch essentiell für den Betrieb einer Maschine sind.
+Ein BehaviorTree ist eine Struktur, um Verhalten als ein Baum zu beschreiben.
+Der Ablauf startet vom sogenannten Root, der Wurzel des Baums.
+Von dort an werden verschiedene Tree-Nodes in einer parent-child Struktur mit dem Root verbunden.
+Hierbei gibt es mehrere grundlegende Arten von Tree-Nodes.
+\begin{description}
+ \item[Aktions-Nodes]
+  beschreiben einzelne ausführbare Aktionen. Mit Hilfe von Parametern kann ihr Verhalten von anderen Nodes beeinflusst werden.
+ \item[Dekorations-Nodes]
+  können den Rückgabewert einer anderen Node modifizieren. Häufig existieren hier Negation, garantierter Erfolg und garantierter Fehler.
+ \item[Sequenz-Nodes]
+  beschreiben eine nacheinander ausgeführte Abfolge von anderen Nodes, welche mit spezifischen Randbedingungen weiter fortschreitet.
+ \item[Fallback-Nodes]
+  werden verwendet, um Verhalten zu definieren, welches nur bei Fehlern in vorherigen Nodes ausgeführt wird.
+\end{description}
+
 -Steuerung von Mensch und Roboter
 -Vermeidung der Nachteile von großen State-Machines
 \chapter{Komponenten-/Softwareauswahl}
 \section{Dienstumgebung (ROS2)}
 \subsection{Auswahl}
+Durch eine Dienstumgebung werden häufig benötigte Funktionen bereitgestellt, welche in Programmen genutzt werden können.
+Dabei ist es irrelevant, ob diese für simulierte, aber auch echte Hardware, genutzt werden.
+Bei einer Dienstumgebung für Roboter gehören zu den grundlegendn Aspekten die Nachrichtenübergabe zwischen einzelen interagierenden Programmen, um eine gemeinsame Basis für ein einfach erweiterbares System zu schaffen.
+
+In diesem Bereich sticht ROS als Dienstumgebung für Roboter hervor, da es sich um ein etabliertes, quelloffenes und häufig verwendetes System handelt.
+Es bietet die oben genannten Aspekte und einige weitere Verbesserungen, welche später näher beleuchtet werden.
+Die neuste Version ROS2 bietet dabei einige Verbesserungen im Vergleich zu früheren Version ROS1.
+Ein neues Nachrichtenformat mit Quality of Service kann zum Beispiel Nachrichten vorhalten und über sowohl TCP als auch UDP kommunizieren.
+Außerdem werden nun neben CMake auch andere Buildsysteme unterstützt, unter anderem auch Python.
+
+Generell existieren im Feld der Roboter-Dienstumgebungen keine Alternativen mit ähnlichem Funktionsumfang und gleicher Reichweite, jedoch sind andere Systeme mit anderen Nachrichtenformaten denkbar.
+Vor allem die unzähligen ROS-Bibliotheken, welche von Nutzern des Systems über die Jahre erstellt wurden, machen das System so populär.\cite{rospackages}
+
+-Alternative Ökosysteme mit gleichem Umfang wie ROS existieren nicht.
+-ROS2
+-Andere (nur) Messagingsysteme
+-LCM
+-ZeroMQ
 \subsection{Beschreibung}
 ROS2\cite{doi:10.1126/scirobotics.abm6074}, später auch einfach nur ROS genannt, beschreibt sich selbst als ``a meta operating system for robots''\cite{ros-git}.
 Hierbei ist ``operating system'' nicht in seiner herkömmlichen Bedeutung eines vollständigen Betriebssystems zu verstehen.
-Es handelt sich um eine gemeinsame Basis für Programme und Daten, welche durch ROS bereitgestellt wird.
+Es handelt sich dabei um eine gemeinsame Grundlage für Programme und Daten, welche durch ROS bereitgestellt wird.
-Einzelne Bestandteile sind dabei in Pakete gegliedert.
+
-Ein Paket kann dabei beliebig viele Daten und Programme beinhalten.
+Einzelne Bestandteile in der Umgebung sind dabei in Pakete gegliedert.
+Ein Paket kann beliebig viele Daten und Programme beinhalten, welche in zwei Dateien beschrieben werden.
+In CMakeLists.txt befinden sich Buildinstruktionen für den Compiler, falls sich Programme im Paket befinden.
+Außerdem können bestimmte Pfade aus dem Paket exportiert werden, sodass diese später im Workspace verfügbar sind.
 Programme, welche mit anderen Programmen in der Umgebung interagieren, werden in ROS ``Nodes'' genannt.
 
 Zu den Aufgaben von ROS gehören dabei:
@@ -188,8 +230,8 @@ Zu den Aufgaben von ROS gehören dabei:
 
  \item[Workspaceverwaltung]\hfill \\
   Pakete können in verschiedenen Verzeichnissen installiert werden und müssen für andere Pakete auffindbar sein.
-  ROS nutzt hierfür von colcon generierte Skripte, welche beim Erstellen eines Pakets mit angelegt werden.
+  ROS nutzt hierfür von colcon generierte Skripte, welche beim Erstellen eines Pakets und eines Workspaces mit angelegt werden.
-  Das Ausführen eines solchen Skripts fügt alle Pakete im Workspace der aktuellen Konsolenumgebung hinzu.
+  Das Skript des Pakets fügt nur dieses Paket der Umgebung hinzu, das Skript des Workspaces führt alle Skripte der enthaltenen Pakete aus, um diese der Umgebung hinzuzufügen.
 
  \item[Abhängigkeitsverwaltung]\hfill \\
   ROS kann durch die in den Paketen deklarierten Abhängigkeiten prüfen, ob diese in der aktuellen Umgebung verfügbar sind.
@@ -216,22 +258,24 @@ Diese Werkzeuge müssen hierfür auf ihre Tauglichkeit für die gesetzte Aufgabe
 Auch andere Aspekte sind hierbei zu betrachten, wie Lizenzen oder schwer bewertbare Aspekte wie Nutzerfreundlichkeit.
 Für die Auswahl kommen verschiedene Prgramme in Frage, welche im folgenden weiter beleuchtet werden.
 
-CoppeliaSim:
+CoppeliaSim, früher auch V-REP genannt, ist eine Robotersimulationsumgebung mit integriertem Editor und ROS-Unterstützung.
-Gute Robotersimulation
+Es unterstützt viele Sprachen (C/C++, Python, Java, Lua, Matlab oder Octave) zur Entwicklung von Erweiterungen des Simulators.
-Keine Simulation von Menschen
+Der Simulator selbst unterstützt Menschliche Aktoren, jedoch können diese nur Animationen abspielen oder zusammen mit Bewegungen abspielen.
-Library ist Open Source, jedoch nicht kostenfrei kommerziell einsetzbar.
+CoppeliaSim existiert in 3 Versionen, welche sich im Funktionsumfang unterscheiden, jedoch hat nur die professionelle Version Zugriff auf alle Funktionen und Verwendungsszenarien.
 
-Gazebo:
+Gazebo Ignition ist wie CoppeliaSim eine Robotersimulationsumgebung, jedoch ohne integrierten Editor und direkte ROS-Unterstützung.
-Gute Robotersimulation
+Gazebo setzt wie CoppeliaSim auf Erweiterungen, welche die gewünschten Funktionen einbinden können.
-Einfache Simulation von Menschen integriert, jedoch nicht für Aufgabe ausreichend.
+Zum Beispiel existiert auch eine ROS-Brücke, welche die Anbindung an ROS ermöglicht.
-Open Source, keine Beschränkungen
+Auch hier unterstützt der Simulator nur Animationen für menschliche Aktoren.
+Das Projekt ist Open Source, unter der Apache Lizenz (Version 2.0), was die Verwendung in jeglichen Szenarien erleichtert.
+
+Unity hingegen ist primär eine Grafikengine für Nutzung in Computerspielen.
+Es existieren mehrere Systeme zur Anbindung der Engine an ROS, vor allem das offizielle ``Robotics Simulation''-Paket und ZeroSim.
+Beide Systeme erlauben die Erweiterung der Gameengine um die Simulation von Robotern.
+Unity besitzt eine gute Dokumentation, die vor allem auf die Nutzung im Einsteigerbereich zurückzuführen ist.
+Auch die Optionen zur Menschensimulation sind gut, da diese häufig in Spielen verwendet werden.
+Ein großer Nachteil hingegen ist die Lizenz, welche nur für Einzelpersonen kostenlos ist.
 
-Unity:
-Offizielles Roboterframework und 3rd-Party Lösung verfügbar.
-Gute Dokumentation
-Gute Werkzeuge für Menschensimulation.
-Robotersimulation möglich, jedoch mit anderem Aufbau.
-Lizenzen einfach gestaltet, jedoch nicht offen.
 
 Unreal:
 3rd Party Lösung verfügbar
@@ -246,21 +290,75 @@ Gute Werkzeuge für Menschensimulation.
 Lizenz offen
 Keine explizite Robotersimulation, wäre nachzurüsten
 
-\section{Robotersimulation}
+\subsection{Robotersimulation}
--URDF-Dateiformat
+Für die Robotersimulation wird ein Modell des Roboters benötigt, in welchem dieser für die Siimulationsumgebung beschrieben wird.
+Gazebo nutzt hierfür .srdf-Dateien, welche auf xml basieren.
+In diesen werden die einzelnen Glieder des Arms und die verbindenden Gelenke beschrieben.
 
--Einteilung in Kollisions- und Anzeigemesh
+Jedes Glied des Modells besitzt eine Masse, einen Masseschwerpunkt und eine Trägheitsmatrix für die Physiksimulation in Gazebo.
-\section{Menschensimulation}
+Außerdem werden Modelle für die visuelle Repräsentation in Gazebo und die Kollisionserkennung in der Physiksimulation hinterlegt.
--Nur vorprogrammierte Bewegungen möglich
+Für beide existieren einfache Modelle wie Zylinder, Boxen und Kugeln.
+Da diese Formen nicht jeden Anwendungsfall abdecken und in der visuellen Repräsentation nicht ausreichen, können auch eigene Modelle hinterlegt werden.
 
--Nur einige vorgefertigte Animationen verfügbar
+Gelenke werden separat von den Gliedern definiert und verbinden jeweils zwei Glieder miteinander.
+Durch das Aneinanderreihen von mehreren Gliedern und Gelenken kann so jeder Roboteraufbau beschrieben werden.
+Jedes Gelenk besitzt eine Position und Rotation im Raum, um dessen Effekte je nach Typ des Gelenks berechnen zu können.
+Aspekte wie Reibung und Dämpfung können auch für die Physiksimulation angegeben werden.
+Folgende Typen von Gelenken können in urdf genutzt werden:
+\begin{description}
+ \item[freie Gelenke]
+  ermöglichen vollständige Bewegung in allen 6 Freiheitsgraden. Sie stellen den normalen Zustand der Gelenke zueinander dar.
+ \item[planare Gelenke]
+  erlauben Bewegungen senkrecht zur Achse des Gelenks. Sie werden für zum Beispiel Bodenkollisionen eingesetzt.
+ \item[feste Gelenke]
+  sperren alle 6 Freiheitsgrade und werden häufig zur Plazierung von Objekten in einer Szene genutzt.
+ \item[kontinuierliche Gelenke]
+  erlauben die beliebige Rotation um die Achse des Gelenks. Sie sind nur selten in rotierenden Gelenken mit Schleifkontakten zu finden.
+ \item[drehbare Gelenke]
+  verhalten sich wie kontinuerliche Verbindungen, haben jedoch minimale und maximale Auslenkungen. Sie sind die häufigste Art von Gelenken in Roboterarmen.
+ \item[prismatische Gelenke]
+  ermöglichen die Bewegung entlang der Achse des Gelenks. Denkbare Anwendungsfälle sind simulierte lineare Aktuatoren.
+\end{description}
+\subsection{Menschensimulation}
+Gazebo besitzt bereits ein einfaches Animationssystem für bewegliche Aktoren, welches auch für Menschen nutzbar ist.
+Es existiert bereits ein Modell eines Menschen mit mehreren Animationen, welche allein abgespielt, oder an Bewegungen gekoppelt werden können.
+Dadurch ist eine Laufanimation realisierbar, welche synchronisiert zur Bewegung abgespielt wird.
+
+Jedoch ist dies nur unter der Bedingung möglich, dass der gesamte Bewegungsablauf zum Simulationsstart bekannt ist.
+Dies ist auf die Definition der Pfade, welche die Bewegung auslösen, zurückzuführen.
+Diese können nur in der .sdf-Datei des Aktoren definiert werden, was Veränderungen zur Laufzeit ausschließt.
+Durch diesen Umstand ist der mögliche Simulationsumfang nicht ausreichend.
+
+Um diesen Umstand zu beheben, ist die Entwicklung eines eigenen Systems zum Bewegen und Animieren des Menschen unausweichlich.
+Dieses System muss, wie im Konzept beschrieben, Steuerbefehle von außen empfangen, umsetzen und Feedback liefern können.
 
 \section{Roboterumgebung (MoveIt2)}
--populärste Umgebung für Bewegungsplanung in ROS2
+MoveIt2 ist das empfohlene ROS2 Paket für Bewegungsplanung von Robotern.
+Das System besteht aus meheren Komponmenten, welche in ihrer Gesamtheit den Bereich der Bewegungsplanung abdecken.
+Der Nutzer kann mit MoveIt auf mehreren Wegen Steuerbefehle für den Roboter absenden.
 
--Integration mit ros\_control
+Die einfachste Art der Inbetriebnahme ist über das mitgelieferte RViz-Plugin und die demo-Launch-Files, welche durch den Setupassistenten für den Roboter generiert werden.
+Dort können Bewegungen durch das Bewegen von Markierungen oder  in der Simulation geplant und ausgeführt werden.
+
+Da sich ein solches System nur beschränkt zur Automatisierung durch Software eignet, existieren auch noch andere Schnitstellen.
+Für die Sprache Python existierte früher noch das moveit_commander Paket, welches den Zugriff auf MoveIt in Pyhon erlaubt, welches aber aktuell noch nicht portiert wurde. \cite{moveitpython}
+Die direkte Nutzung der C++-API ist aktuell die einzige offizielle Möglichkeit, mit MoveIt auf einer abstrakteren Ebene zu interagieren.
+Natürlich können die Befehle auch direkt an die entsprechenden Topics gesendet werden, was jedoch Erfahrung mit den verwendeten Datenstrukturen benötigt.
+
+Durch diese Schnittstelle erhält die sogenannte MoveGroup ihre Informationen über die gewünschte Bewegung.
+Diese Daten können durch eine OccupancyMap ergänzt werden, welche die Bereiche beschreibt, welche sich um den Roboter befinden.
+Eine solche Erweiterung erlaubt die Nutzung von Kollisionsvermeidung mit Objekten im Planungsbereich.
+
+Die Planung der Bewegung wird durch einen der zahlreichen implementierten Solver erledigt, welcher durch die MoveGroup aufgerufen wird.
+Um die generierte Bewegung umzusetzen, werden die gewünschten Gelenkpositionen als Abfolge an ros_control weitergegeben.
+Dabei können sowohl echte Hardwaretreiber, aber auch simulierte Roboter genutzt werden.
+Der Erfolg der gesamten Pipeline kann dabei durch einen Feedbackmechanismus überwacht werden.
+
+Im Falle von Gazebo wird ign_ros_control genutzt, welches die benötigten ros_control Controller in die Simulation einbindet.
+Diese können dann wie normale Controller von ros_control genutzt werden.
+
+Dieser Ablauf ist auch im Anhang unter Abbildung \ref{moveitpipeline} visualisiert.
 
--Integration von ros\_control in gazebo ignition möglich
 \chapter{Umsetzung}
 \section{Grundlegender Systemaufbau}
 -BehaviorTree -> ActorPluginServer -> ActorPluginServer
@@ -421,5 +519,10 @@ Darunter fallen eine grundlegende Strukturänderung der unterliegenden Engine, w
 -Person in OctoMap erkennen
 
 \printbibliography
-
+\markboth{Anhang}{Anhang}
+\begin{figure}[h]
+\includegraphics[width=14cm]{moveit_pipeline}
+\caption{Visualisierung der MoveIt Pipeline\cite{moveitpipeline}}
+\label{moveitpipeline}
+\end{figure}
 \end{document}