abstract={Roll-Nick-Gier-Winkel, englisch roll-pitch-yaw angle, sind spezielle Eulerwinkel (Lagewinkel), die zur Beschreibung der Ausrichtung eines Fahrzeugs im dreidimensionalen Raum herangezogen werden. Diese Art der Richtungsmessung und -bestimmung durch Drehratensensoren wurde zur Navigation im Luftverkehr eingef{\"u}hrt und wird inzwischen neben Luftfahrzeugen auch f{\"u}r Raum-, Land- und Wasserfahrzeuge verwendet.},
@@ -48,7 +48,7 @@ Die Roboterbeschreibung ist Grundlage der Generierung valider Konfigurationsdate
\caption{Visualisierung der Verzeichnisstruktur der Roboterbeschreibung und Konfiguration. Bezüglich der Übersichtlichkeit sind nur die Dateien gelistet, deren Modifikation in Hinsichtlich der Realisierung mehrerer robotischer Systeme relevant ist.}\label{fig:9}
\end{figure}
\begin{lstlisting}[language=JSON,firstnumber=1, caption={ Dual Setup Beispiel, in mit Modifikationen zur Übergabe der Roboterpositionen.}, label={lst:4}, captionpos=b]
\begin{lstlisting}[language=json,firstnumber=1, caption={ Dual Setup Beispiel, in mit Modifikationen zur Übergabe der Roboterpositionen.}, label={lst:4}, captionpos=b]
@@ -79,7 +79,7 @@ Die Roboterbeschreibung ist Grundlage der Generierung valider Konfigurationsdate
Eine Konfigurationsdatei konkretisiert ein robotisches System als Bewegungsgruppe 'MoveGroup', dessen Identität eindeutig durch ihr Namensattribut bestimmt ist. Demnach genügt dieses zur Instanziierung eines MoveGroup Objekts, welcher die Kommunikation zum gewählten Roboter initiiert. Eine duale Konfigurationsdatei ermöglicht analog das Instanziieren und Ansteuern zweier robotischer Systeme. Dabei ist eine Fehlfunktion dieser Instanzen während einer Operation observierbar, wobei die Planung und Exekution durch eine vermeintlich unbeabsichtigte Kollision zwischen Endeffektor und Primitiv detektiert wird, woraufhin die auszuführende Handlung negativ terminiert. Dies impliziert, dass die Funktionen des MoveGroup Interface hinsichtlich der Betrachtung mehrerer robotischer Systeme limitiert sind. Der \autoref{lst:5} zeigt einen Ansatz, der die Kollisionsdetektion definierter Kollisionsobjekte in der allowed kollision matrix 'AKM' deaktiviert, was Beispielsweise das Greifen, Halten und Abstellen eines Primitives in einem Dualen Setup ermöglicht.
\begin{lstlisting}[language=JSON,firstnumber=1, caption={Des Endeffektors rechter und linker Finger kollidieren unweigerlich während der Exekution mit dem Primitiv. Der illustrierte Quelltext Auszug stellt einen Ansatz zur Umgehung dar und ermöglicht eine erfolgreiche Terminierung des Vorgangs.}, label={lst:5}, captionpos=b]
\begin{lstlisting}[language=json,firstnumber=1, caption={Des Endeffektors rechter und linker Finger kollidieren unweigerlich während der Exekution mit dem Primitiv. Der illustrierte Quelltext Auszug stellt einen Ansatz zur Umgehung dar und ermöglicht eine erfolgreiche Terminierung des Vorgangs.}, label={lst:5}, captionpos=b]
Durch die Wahl des festen Abstands $a$ bezüglich der kubischen Diskretisierung und Definition der Vektoren $^{0}p \in P_{total}$ als Zentrum einer Sphäre, wird der Radius $r \in\R_{+}$ der Sphäre nach \autoref{eq:23} kalkuliert.
Zusätzlich empfiehlt sich die vollständige Auslagerung der Berechnungen auf performantere Rechner, um diese mit mehreren Rechenkernen zu operieren. Beispielsweise empfiehlt sich für diese Arbeit das Hochleistungsrechenzentrum der TU-Dresden. \autoref{lst:1} zeigt die Struktur der JSON-Datei, die als Artefakt der Berechnung in Gitlab entnommen werden. Die Felder 'resolution' und 'maxdistance' entstammen den Parametern der kubischen Diskretisierung und definieren den Namen der Datei. Das Feld 'pose' enthält die String-Repräsentation aller Endeffektor-Posen in einer Liste. Diese bestehen aus Position und Orientierung, wobei die Orientierung als Quaternion notiert ist, was dem Präfix q\_ zu entnehmen ist. Das Ergebnis der kinematischen Funktion aus \autoref{eq:7} als Informationen bezüglich der Erreichbarkeit der Pose ist als Wahrheitswert/bool in der Liste des Feldes 'value' dokumentiert.
\begin{lstlisting}[language=JSON,firstnumber=1, caption={Struktur der RM als Resultat der Arbeitsraumanalyse},captionpos=b, label={lst:1}]
\begin{lstlisting}[language=json,firstnumber=1, caption={Struktur der RM als Resultat der Arbeitsraumanalyse},captionpos=b, label={lst:1}]
{"name": "RM_\$(maxdistance)_\$(resolution)"
"resolution": float,
"max_distance": float,
...
...
@@ -152,7 +152,7 @@ Die Roboterbasis kann der Pose des ersten Festkörpers in Form der Transformatio
Die Metrik aus \autoref{eq:18} wird dabei zu den inversen Transformationen $^{0}T_{Base}$ portiert und als Menge $IRM$ in eine JSON Datei persistiert, dessen Struktur der \autoref{lst:2} zeigt, wobei die Felder 'pose' und 'value' nicht aus der zugrundeliegenden $RM$ übernommen wurden. Das Ergebnis dieses Algorithmus kann bei Formeln der Form \autoref{eq:20} Angewendet werden, um die Roboter Positionierung hinsichtlich der Definition einer spezifischen Aufgabe zu errechnen.
\begin{lstlisting}[language=JSON,firstnumber=1, caption={In 'value' werden alle kalkulierten Werte der Metrik persistiert, während 'pose' alle invertierten Endeffektor Posen enthält},captionpos=b, label={lst:2}]
\begin{lstlisting}[language=json,firstnumber=1, caption={In 'value' werden alle kalkulierten Werte der Metrik persistiert, während 'pose' alle invertierten Endeffektor Posen enthält},captionpos=b, label={lst:2}]
{"name": "IRM_\$(maxdistance)_\$(resolution)"
"resolution": float,
"max_distance": float,
...
...
@@ -165,7 +165,7 @@ Das Konzept zur Planung und Erstellung spezifischer Aufgaben, sowie deren Realis
Aktuell bietet MoveIt die Möglichkeit, beliebig Kollisionsobjekte in der Szene zu generieren und persistieren, aber keinen Algorithmus zur Aufgabenbeschreibung, welcher die Reihenfolge konkretisiert, in der die Kommunikation mit den robotischen Systemen stattfindet. Diese fehlende Funktion wird mittels eines Algorithmus ergänzt, welcher die Interaktionen, wie beispielsweise die Translation und Rotation eines Kollisionsobjektes, durch den Nutzer und der grafischen Bedienoberfläche realisiert und anhand zusätzliche Optionen die Dokumentation von Aufgaben ermöglicht. Dabei empfehlen sich Interaktive Marker durch ihren Funktionsumfang zur Repräsentation der Kollisionsobjekte, und bieten weitere Optionen zur Aufgabenbeschreibung in ihren Menüs.
Eine valide Aufgabenbeschreibung kann in JSON Dateien persistiert werden, dessen Struktur der \autoref{lst:3} veranschaulicht und zur Durchführung der Aufgabe durch robotische Systeme bedingt ist.
\begin{lstlisting}[language=JSON,firstnumber=1, caption={Der Nutzer hat die Möglichkeit, seine Aufgabe zu benennen. Das Feld 'position' ist eine Liste aller Aufgaben-Posen in Form einer Kette, die das jeweilige robotische System operieren muss.},captionpos=b, label={lst:3}]
\begin{lstlisting}[language=json,firstnumber=1, caption={Der Nutzer hat die Möglichkeit, seine Aufgabe zu benennen. Das Feld 'position' ist eine Liste aller Aufgaben-Posen in Form einer Kette, die das jeweilige robotische System operieren muss.},captionpos=b, label={lst:3}]
