...

lst.tex

@@ -9,8 +9,6 @@
 	numberstyle=\ttfamily,
 	stepnumber=1,
 	numbersep=5pt,
-	xleftmargin=2em,
-	framexleftmargin=2em,
 	showstringspaces=false,
 	breaklines=true,
 	frame=lines,
@@ -64,7 +62,14 @@
       {\{}{{{\color{delim}{\{}}}}{1}
       {\}}{{{\color{delim}{\}}}}}{1}
       {[}{{{\color{delim}{[}}}}{1}
-      {]}{{{\color{delim}{]}}}}{1},
+      {]}{{{\color{delim}{]}}}}{1}
+			{Ö}{{\"O}}1
+			{Ä}{{\"A}}1
+			{Ü}{{\"U}}1
+			{ß}{{\ss}}1
+			{ü}{{\"u}}1
+			{ä}{{\"a}}1
+			{ö}{{\"o}}1,
 }
 
 \lstdefinelanguage{JRAG}[]{java}{

sections/fallbeispiel.tex

@@ -2,19 +2,19 @@
 Inhalt dieses Kapitels ist die Demonstration der Funktionsweise einzelner Elemente der Implementierung und dessen Synergie mit MoveIt spezifischen Komponenten, sowie der Integration des franka\_ros Pakets \cite{franka_ros} anhand eines Beispiels. Dieses Paket stellt hierbei die sowohl grafische, als auch funktionelle Beschreibung der Bestandteile des gleichnamigen robotischen Systems zur Verfügung, welches primär Objekt der Ausführung ist. 
 
 \section{Ausgangspunkt kinematischer Operationen}
-MoveIt bietet über das MoveGroup Interface eine Schnittstelle, welche die Kommunikation mittels spezieller Nachrichten und somit die Planung und Exekution kinematischer Operationen durch den Roboter ermöglicht. Dies bedingt eine Konfigurationsdatei, welche das robotische System konkretisiert, indem Beispielsweise Kontrollelemente wie Endeffektoren als Gruppen definiert oder Adjazenzen der einzelnen Festkörper in Form einer Kollisionsmatrix erfasst werden. Die Konfigurationsdatei stellt dadurch den Ausgangspunkt aller operativen Aspekte des Fallbeispiels dar und ist daher sowohl für einen Roboter, als auch für mehrere robotische Systeme in der Implementierung enthalten. Diese Konfigurationen können mittels moveit setup assistent 'MSA' generiert werden. 
+MoveIt bietet über die move\_group Schnittstelle eine Möglichkeit die Kommunikation mittels spezieller Nachrichten und somit der Planung und Exekution kinematischer Operationen durch den Roboter. Dies bedingt eine Konfigurationsdatei, welche das robotische System konkretisiert, indem Beispielsweise Kontrollelemente wie Endeffektoren als Gruppen definiert oder Adjazenzen der einzelnen Festkörper in Form einer Kollisionsmatrix erfasst werden oder weitere Nodes initialisiert werden. Die Konfigurationsdatei stellt dadurch den Ausgangspunkt aller operativen Aspekte des Fallbeispiels dar und ist daher sowohl für einen Roboter, als auch für mehrere robotische Systeme in der Implementierung enthalten. Diese Konfigurationen wurden mittels MSA generiert. 
 
 \subsection{Modifikationen in der Beschreibung robotischer Systeme}
-Das MoveGroup Interface bietet keine Möglichkeit zur Deklaration einer Roboterposition, da diese die Roboterbeschreibung festgelegt, welche Referenz der spezifischen Konfigurationsdatei ist. Dies impliziert die Notwendigkeit eine Modifikation, indem geforderte Positionen in Form von Variablen sukzessiv innerhalb der Instanzen einer Konfigurationsdatei bis zur letzten Instanz, der Roboterbeschreibung, kommuniziert werden. Hier UML wäre nice
+Die move\_group Schnittstelle bietet keine Möglichkeit zur Deklaration einer Roboterposition, da diese durch die Roboterbeschreibung festgelegt ist, welche Referenz der spezifischen Konfigurationsdatei ist. Dies impliziert die Notwendigkeit eine Modifikation, indem geforderte Positionen in Form von Variablen sukzessiv innerhalb der Instanzen einer Konfigurationsdatei bis zur letzten Instanz, der Roboterbeschreibung, kommuniziert werden.
 
 \section{Präparation des Fallbeispiels}
-Die Kalkulation valider Positionen für robotische Systeme erfordert die Roboter zentrierte Inspektion des Arbeitsraums und eine Aufgabenbeschreibung, welche für $i \in \N_{>0}$ Endsysteme mindestens $i$ Operationsketten aufweist. Die diesbezüglich vorzunehmende Arbeitsraumanalyse und dessen Inversion ist aufgaben unabhängig, erfolgt daher a priori und kann auf alle Aufgabenbeschreibung angewendet werden, die vom Ausgangssystem der Analyse, wie Beispielsweise dem 'Panda' der Franka Emika GmbH, operiert werden sollen. Die Aufgabenbeschreibung kann zum Ermittlungszeitpunkt vorgenommen werden oder schon persistiert vorliegen.
+Die Kalkulation valider Positionen für robotische Systeme erfordert die Roboter zentrierte Inspektion des Arbeitsraums und eine Aufgabenbeschreibung, welche für $i \in \N_{>0}$ Endsysteme mindestens $i$ Operationsketten aufweist. Die diesbezüglich vorzunehmende Arbeitsraumanalyse und dessen Inversion ist Aufgaben-Unabhängig, erfolgt daher a priori und kann auf alle Aufgabenbeschreibung angewendet werden, die vom Ausgangssystem der Analyse, wie Beispielsweise dem 'Panda' der Franka Emika GmbH, operiert werden sollen. Die Aufgabenbeschreibung kann zum Ermittlungszeitpunkt vorgenommen werden oder schon persistiert vorliegen.
 
 \subsection{Aufgabenkonstruktion}
-Die Aufgabenbeschreibung in Form einer Operationskette erfolgt über Interaktive Marker, die jeweils die Abstell- beziehungsweise Greifposition eines Primitives darstellen. Jede dieser Positionen erfordert ein zusätzliches Kollisionsobjekt als Operationsoberfläche 'Support\_Surface', welche dem robotischen System über das MoveGroup Interface kommuniziert und ohne dessen eine Operation nicht exekutiert wird. Dieser redundante Aufwand wird im Algorithmus berücksichtigt und ist implizit durch die Position und Dimension des Kettenglieds definiert. Demzufolge ist beispielsweise eine Differenzierung der zu erzeugenden Kollisionsobjekte, durch Platzierung zusätzlicher Abstelltische, kein Aspekt der Aufgabenbeschreibung. Ausgangspunkt einer Operationskette und dessen Teilketten ist der Startknoten, welcher durch seine Bezeichnung und der Farbe 'grün' gekennzeichnet ist. Es ist stets möglich, einen weiteren Knoten zu generieren, der als weiteres Kettenglied farblich und schriftlich gekennzeichnet ist. Die 'split' Option im Menü des Startknotens dupliziert diesen und ist ab einer Operationskette beziehungsweise Teilkette der Länge zwei möglich. Eine valide Aufgabenbeschreibung ist nur formulierbar und wird persistiert, wenn mindestens zwei Teilketten existieren, da dies die Notwendigkeit zweier robotischer Systeme impliziert. Die Wiederherstellung des Ausgangszustands ist ebenfalls durch einen zusätzlichen Menüpunkt möglich, dies eliminiert alle Glieder bis auf den Startknoten. Anlog dupliziert die 'coop' Option das jeweils letzte Glied der Operationskette beziehungsweise Teilkette und visualisiert diese Schnittmenge ebenfalls schriftlich und farblich. Dies impliziert, dass eine Operationskette aus 'split' und 'coop' Komponenten bestehen kann, was für die Anwendung auf $n \in \N_{>2}$ robotischen Systemen relevant ist. Hier Bilder Mashallah hübsch 
+Die Aufgabenbeschreibung in Form einer Operationskette erfolgt über Interaktive Marker, die jeweils die Abstell- beziehungsweise Greifposition eines Primitives darstellen. Jede dieser Positionen erfordert ein zusätzliches Kollisionsobjekt als Operationsoberfläche 'Support\_Surface', welche dem robotischen System über das spezifische Nachrichten kommuniziert und ohne dessen eine Operation nicht exekutiert wird. Dieser redundante Aufwand wird im Algorithmus berücksichtigt und ist implizit durch die Position und Dimension des Kettenglieds definiert. Demzufolge ist beispielsweise eine Differenzierung der zu erzeugenden Kollisionsobjekte, durch Platzierung zusätzlicher Abstelltische, kein Aspekt der Aufgabenbeschreibung. Ausgangspunkt einer Operationskette und dessen Teilketten ist der Startknoten, welcher durch seine Identität $id=0$ und der Farbe 'grün' gekennzeichnet ist. Es ist stets möglich, einen weiteren Knoten zu generieren, der als weiteres Kettenglied farblich blau und schriftlich gekennzeichnet ist. Die 'Schnitt' Option im Menü des Startknotens dupliziert diesen und ist ab einer Operationskette beziehungsweise Teilkette der Länge zwei möglich. Eine valide Aufgabenbeschreibung ist nur formulierbar und wird persistiert, wenn mindestens zwei Teilketten existieren die jeweils mindestens zwei Augabenposen enthalten, da dies die Notwendigkeit zweier robotischer Systeme und das Vorhandensein einer Greif und Abstellposition impliziert. Die Wiederherstellung des Ausgangszustands ist ebenfalls durch einen zusätzlichen Menüpunkt möglich, dies eliminiert alle Glieder bis auf den Startknoten. Anlog dupliziert die 'Kooperation' Option das jeweils letzte Glied der Operationskette beziehungsweise Teilkette und visualisiert diese Schnittmenge ebenfalls schriftlich und farblich durch die Farbe rot. Dies impliziert, dass eine Operationskette aus Schnitt- und Kooperationskomponenten bestehen kann, was für die Anwendung auf $n \in \N_{>2}$ robotischen Systemen relevant ist.
 
 \section{Positionsanalyse}
-Der Algorithmus zur Ermittlung von Positionen robotischer Systeme bezüglich einer Aufgabenbeschreibungen erfordert diese und zusätzlich den invertierten Arbeitsraum namentlich als Parameter. Über diese erfolgt der Zugriff auf die jeweiligen persistenten Dateien und die Berechnung auf Grundlage dessen beginnt. Alle Resultate sind Transparent über das graphische Programm RViz einsehbar, dabei kann der Umfang zu sehender Informationen über Checkboxen reguliert werden. Die Metrik $I(Voxel)(TK)$ aus \autoref{eq:29}, welche differenzierten Voxelisierung kalkuliert, visualisiert die Wertigkeit eines Voxels farblich. Analog zur Menge $P_{Base}$ jedes Kettenglieds und deren Differenzierung in die jeweilige Operationskette beziehungsweise Teilkette ist zusätzlich die Projektion dieser Werte auf die XY Ebene des kartesischen Koordinatensystems eine mögliche visuelle Modalität. Der maximale Index je Teilkette und Voxel ist ebenfalls einsehbar und wird mit zusätzlichen Informationen, wie dem Namen der Aufgabenbeschreibung, persistiert.
+Der Algorithmus zur Ermittlung von Positionen robotischer Systeme bezüglich einer Aufgabenbeschreibungen erfordert diese und zusätzlich den invertierten Arbeitsraum namentlich als Parameter. Über diese erfolgt der Zugriff auf die jeweiligen persistenten Dateien und die Berechnung auf Grundlage dessen beginnt. Alle Resultate sind Transparent über das graphische Programm RViz einsehbar, dabei kann der Umfang der visualisierten Informationen über Checkboxen reguliert werden. Die Metrik $D_{Reach}(Voxel)(TK)$ aus \autoref{eq:29}, welche differenzierten Voxelisierung kalkuliert, visualisiert die Wertigkeit eines Voxels farblich. Analog zur Menge $P_{Base}$ jedes Kettenglieds und deren Differenzierung in die jeweilige Operationskette beziehungsweise Teilkette ist zusätzlich die Projektion dieser Werte auf die XY Ebene des kartesischen Koordinatensystems eine mögliche visuelle Modalität. Der maximale Index je Teilkette und Voxel ist ebenfalls einsehbar und wird mit zusätzlichen Informationen, wie dem Namen der Aufgabenbeschreibung, persistiert.
 
 \section{Ausführung der Operationskette}
 Zur Ausführung der Operationskette ist ein weiterer Algorithmus implementiert, welcher die permutierten Informationen der Positionsanalyse Aufruft und die robotischen Systeme an den kalkulierten Positionen initialisiert, um jeweils die Teilketten zu operieren. 
\ No newline at end of file

sections/grundlagen.tex

@@ -41,14 +41,16 @@ Eine Orientierung wird durch Rotationen $R$ dargestellt, die auf einen Körper a
 \label{fig:1}
 \end{figure}
 
-Die Menge aller Rotations-Matrizen $R \in \R^{3 \times 3}$ bilden mit der Matrixmultiplikation die nicht kommutative Gruppe $SO(3) \subset \R^{3\times3}$ \cite[17f.]{Siciliano2016}, dessen Gruppenaxiome in \autoref{fig:2} abgebildet sind. Dies ist die spezielle orthogonale Gruppe $SO(3)$, wobei 1 die Matrix ist, dessen diagonale mit eins belegt ist, während alle anderen Werte null sind.
+Die Menge aller Rotations-Matrizen $R \in \R^{3 \times 3}$ bilden mit der Matrixmultiplikation die nicht kommutative Gruppe $SO(3) \subset \R^{3\times3}$ \cite[17f.]{Siciliano2016}, dessen Gruppenaxiome in \autoref{eq:SO} formuliert sind. Dies ist die spezielle orthogonale Gruppe $SO(3)$, wobei 1 die Matrix ist, dessen diagonale mit eins belegt ist, während alle anderen Werte null sind.
 
-\begin{align*} \label{fig:2}
-&Geschlossenheit: & 	\forall R_{1},R_{2} \in SO(3):  R_{1}R_{2} \in SO(3) \\
-&Identität: & \forall R \in SO(3): 1R = R1 = R\\
-&Inverse: & \forall R \in SO(3): RR^{T}= 1  \\
-&Assoziativität: & \forall R_{1},R_{2},R_{3} \in SO(3): (R_{1}R_{2})R_{3} = R_{1}(R_{2}R_{3})
-\end{align*}
+\begin{equation} \label{eq:SO}
+\begin{split}
+&Geschlossenheit:  	\forall R_{1},R_{2} \in SO(3):  R_{1}R_{2} \in SO(3) \\
+&Identität:  \forall R \in SO(3): 1R = R1 = R\\
+&Inverse:  \forall R \in SO(3): RR^{T}= 1  \\
+&Assoziativität:  \forall R_{1},R_{2},R_{3} \in SO(3): (R_{1}R_{2})R_{3} = R_{1}(R_{2}R_{3})
+\end{split}
+\end{equation}
 
 Die Komposition von Rotationen verschiedener Frames wird in Gleichung \autoref{eq:2} veranschaulicht. Dabei ist die Einhaltung der Reihenfolge bezüglich der Multiplikation, aufgrund der mangelnden Kommutativität der Gruppe SO(3), erforderlich. Durch dessen Eigenschaft der Geschlossenheit, ist das Resultat dieser Multiplikation ebenfalls $\in SO(3)$ \cite[11f.]{Siciliano2016}.
 
@@ -85,14 +87,16 @@ T  &= \begin{pmatrix}
 													\end{pmatrix}
 \end{equation}
 
-Transformationsmatrizen $T$ bilden mit der Matrixmultiplikation eine nicht kommutative Gruppe $SE(3)$, dessen Gruppenaxiome in \autoref{fig:3} dokumentiert sind, hierbei gilt analog zu \autoref{fig:2} die 1 Matrix $\in \R^{4\times4}$ als das neutrale Element der Gruppe \cite[17f.]{Siciliano2016}. 
+Transformationsmatrizen $T$ bilden mit der Matrixmultiplikation eine nicht kommutative Gruppe $SE(3)$, dessen Gruppenaxiome in \autoref{eq:SE} dokumentiert sind, hierbei gilt analog zu \autoref{eq:SO} die 1 Matrix $\in \R^{4\times4}$ als das neutrale Element der Gruppe \cite[17f.]{Siciliano2016}. 
 
-\begin{align*}\label{fig:3}
-&Geschlossenheit: & 	\forall T_{1},T_{2} \in SE(3):  T_{1}T_{2} \in SE(3) \\
-&Identität: & \forall T \in SE(3): 1T = T1 = T\\
-&Inverse: & \forall ^{j}T_{i} \in SE(3): (^{j}T_{i})(^{j}T_{i}^{-1}) = (^{j}T_{i})(^{i}T_{j}) = 1 \\
-&Assoziativität: & \forall T_{1},T_{2},T_{3} \in SE(3): (T_{1}T_{2})T_{3} = T_{1}(T_{2}T_{3})
-\end{align*}
+\begin{equation}\label{eq:SE}
+\begin{split}
+&Geschlossenheit:  	\forall T_{1},T_{2} \in SE(3):  T_{1}T_{2} \in SE(3) \\
+&Identität:  \forall T \in SE(3): 1T = T1 = T\\
+&Inverse:  \forall ^{j}T_{i} \in SE(3): (^{j}T_{i})(^{j}T_{i}^{-1}) = (^{j}T_{i})(^{i}T_{j}) = 1 \\
+&Assoziativität:  \forall T_{1},T_{2},T_{3} \in SE(3): (T_{1}T_{2})T_{3} = T_{1}(T_{2}T_{3})
+\end{split}
+\end{equation}
 
 Die Komposition aus Transformationen verschiedener Frames wird in Gleichung \autoref{fig:5} veranschaulicht. Dabei ist die Einhaltung der Reihenfolge bezüglich der Multiplikation, analog zur \autoref{eq:2} Gruppe $SO(3)$, erforderlich. Durch die Eigenschaft der Geschlossenheit der Gruppe SE(3), ist das Resultat dieser Multiplikation ebenfalls $\in SE(3)$ \cite[14f.]{Siciliano2016}.
 
@@ -100,13 +104,13 @@ Die Komposition aus Transformationen verschiedener Frames wird in Gleichung \aut
 ^{k}T_{i} = ^{k}T_{j} \times ^{j}T_{i}
 \end{equation}
 
-Für die kinematische Kette eines robotischen Systems bestehenden aus $n \in \N$ Festkörpern, wobei $Frame_{n} = Frame_{Endeff}$ das Frame des Endeffektors ist, gilt \autoref{eq:6}, welche ein Beispiel für $n=8$ zeigt. Im Kontext dieser Arbeit bedeutet diese Gleichung, dass für jede vom Roboter erreichbare Endeffektor-Pose relativ zu $Frame_{0}$ eine solche Kette aus Transformationen existiert, welche jeweils die Pose eines Festkörpers des Roboters repräsentieren \cite[26f.]{Siciliano2016}.
+Für die kinematische Kette eines robotischen Systems bestehenden aus $n \in \N$ Festkörpern, wobei $Frame_{n} = Frame_{Endeff}$ das Frame des Endeffektors ist, gilt \autoref{eq:6}, welche zusätzlich ein Beispiel für $n=8$ zeigt. Im Kontext dieser Arbeit bedeutet diese Gleichung, dass für jede vom Roboter erreichbare Endeffektor-Pose relativ zu $Frame_{0}$ eine solche Kette aus Transformationen existiert, welche jeweils die Pose eines Festkörpers des Roboters repräsentieren \cite[26f.]{Siciliano2016}.
 
 \begin{equation}
 \label{eq:6}
 \begin{split}
-^{n}T_{0} &= {\displaystyle \prod_{i=0}^{n}}^{n-i}T_{i} \\
- &= ^{0}T_{1} \times ^{1}T_{2} \times ^{2}T_{3} \times ^{3}T_{4} \times ^{4}T_{5} \times ^{5}T_{6} \times ^{6}T_{7} \times ^{7}T_{8} 
+^{0}T_{n} &= \prod_{i=0}^{n}{^{n-i}T_{i}} \\
+^{0}T_{8} &= ^{0}T_{1} \times ^{1}T_{2} \times ^{2}T_{3} \times ^{3}T_{4} \times ^{4}T_{5} \times ^{5}T_{6} \times ^{6}T_{7} \times ^{7}T_{8} 
 \end{split}
 \end{equation}
   
@@ -116,8 +120,8 @@ Der Arbeitsbereich 'Workspace', beschreibt die Kapazitäten eins robotische Syst
 In den Publikationen werden diese Darstellungen gleichgesetzt. Dieses Vorgehen hat auch Bestand in dieser wissenschaftlichen Arbeit, demnach werden fortan reachability maps betrachtet, welche zusätzliche Eigenschaften der capability map besitzt.
 
 \subsection{reachability map}
-Reachability maps visualisieren die Erreichbarkeit durch den Endeffektor, ohne weitere Angaben hinsichtlich der Qualität. Demnach ist beispielsweise ein Objekt erreichbar, was aber nicht eine erfolgreiche Exekution impliziert, da der Endeffektor Möglicherweise eine der definierten Greifposen nicht einnehmen kann. Demnach enthält eine reachability map die Information darüber, dass der Endeffektor die Objektposition erreicht, aber nicht welche Posen Operiert werden können
-Diese \autoref{fig:panda} zeigt eine solche Darstellung im Manual des Referenzroboters 'Panda' aus verschiedenen Perspektiven, um den Arbeitsbereich des Roboters in mehreren Dimensionen zu veranschaulichen.
+Reachability maps visualisieren die Erreichbarkeit durch den Endeffektor, ohne weitere Angaben hinsichtlich der Qualität. Demnach ist beispielsweise ein Objekt erreichbar, was aber nicht eine erfolgreiche Exekution impliziert, da der Endeffektor Möglicherweise eine der definierten Greifposen nicht einnehmen kann. Demnach enthält eine reachability map die Information darüber, dass der Endeffektor die Objektposition erreicht, aber nicht welche Posen Operiert werden können.
+Diese \autoref{fig:panda} zeigt eine solche Darstellung im Manual des Referenzroboters 'Panda' aus verschiedenen Perspektiven, um den Arbeitsbereich des Roboters in mehreren Dimensionen zu visualisieren.
 
 \ffigbox[\FBwidth]%
   {\begin{subfloatrow}%
@@ -136,16 +140,16 @@ In capability maps werden zusätzliche Informationen über die Erreichbarkeit de
 %\cite{Reuleaux} \cite{zacharias2008positioning}
 
 \section{ROS und das MoveIt}
-ROS ist ein der Öffentlichkeit frei zugängliches Framework, welches auf Anwendungen bezüglich robotischer Systeme spezialisiert ist. Es ermöglicht beispielsweise die Kommunikation zwischen Robotern, Erfassung sensorischer Daten und deren Visualisierung in zusätzlichen Programmen. Dies wird durch die Initialisierung von Nodes realisiert, welche nach dem Event Listener Prinzip Informationen hinsichtlich eines spezifischen Themas publizieren oder durch das Abonniere des Themas empfangen. Pakete innerhalb eines Arbeitsraums im ROS Kontext Koordinieren die zugrundeliegenden Quelltexte der Nodes und dienen der Abstraktion implementierter Algorithmen.
+ROS ist ein der Öffentlichkeit frei zugängliches Framework, welches auf Anwendungen bezüglich robotischer Systeme spezialisiert ist. Es ermöglicht beispielsweise die Kommunikation zwischen Robotern, Erfassung sensorischer Daten und deren Visualisierung in zusätzlichen Programmen. Dies wird durch die Initialisierung von Nodes realisiert, welche Informationen hinsichtlich eines spezifischen Themas publizieren oder durch das Abonniere des Themas empfangen. Pakete innerhalb eines Arbeitsraums im ROS Kontext Koordinieren die zugrundeliegenden Quelltexte der Nodes und dienen der Abstraktion implementierter Algorithmen.
 
 \subsection{Visualisierung in ROS}
-RViz ist eine ROS Node zur Visualisierung von Informationen im 3 dimensionalen Raum und wird in dieser Arbeit zur Illustration spezifischer Aspekte der Implementierung genutzt. Zur Orientierung auf der grafischen Benutzeroberfläche dienst ein Gitter auf der horizontalen XY Ebene, dessen Kanten jeweils einen Meter voneinander distanziert sind. 
+RViz ist ein ROS Node zur Visualisierung von Informationen im 3 dimensionalen Raum und wird in dieser Arbeit zur Illustration spezifischer Aspekte der Implementierung genutzt. Die Orientierung innerhalb der grafischen Benutzeroberfläche erfolgt anhand eines Gitters auf der horizontalen XY Ebene, dessen Kanten jeweils einen Meter voneinander distanziert sind. 
 
 \subsubsection{Marker Elemente}
-Primitive wie Würfel, Pfeile oder Sphären sind simple Marker Elemente, welche anhand Ihrer Position, Orientierung, Farbe und Dimension definiert sind und in RViz angezeigt werden können, um die Resultate der zugrundeliegenden Implementierung zu inspizieren.
+Primitive wie Würfel, Pfeile oder Sphären sind simple Marker Elemente, welche anhand deren Position, Orientierung, Farbe und Dimension definiert sind und in RViz durch das Abhören des zugrundeliegenden Themas visualisiert werden, um die Resultate der zugrundeliegenden Implementierung zu inspizieren beziehungsweise analysieren.
 
 \subsubsection{Interaktive Marker Elemente}
-Interaktive Marker Elemente erweitern die bereits präzisierten Marker um Interaktionsmöglichkeiten durch den Nutzer, wodurch Translationen und Rotationen auf beliebigen Achsen des Markers durch den Mauszeiger anwendbar sind. Zusätzlich kann jeder Marker ein eigenes Menü mit Untermenüs initialisieren. Diese Modifikationen werden durch zugrundeliegende visuelle Kontrollelemente des Markers und deren Kommunikation mit dem 'Interaktive Marker Server' realisiert. Jede Interaktion mit einer Instanz eines interaktiven Markers wird von RViz publiziert, der Server reagiert auf diese Nachricht mit der aktualisierten Position oder Orientierung des Markers. Zusätzlich ist die Implementierung weiterer Funktionen möglich, die als Reaktion auf über den Server kommuniziert werden sollen.
+Interaktive Marker Elemente erweitern die bereits präzisierten Marker um die Interaktionsmöglichkeit durch den Nutzer, wodurch Translationen und Rotationen auf beliebigen Achsen des Markers durch den Mauszeiger realisierbar sind. Zusätzlich kann jeder Marker ein eigenes Menü mit Untermenüs initialisieren, durch dessen Einträge zusätzliche anwendungsspezifische Algorithmen implementiert werden können. Diese Modifikationen werden durch zugrundeliegende visuelle Kontrollelemente des Markers und deren Kommunikation mit dem 'Interaktive Marker Server' realisiert. Jede Interaktion mit einer Instanz eines interaktiven Markers wird von RViz publiziert, der Server reagiert auf diese Nachricht mit der aktualisierten Position oder Orientierung des Markers. Zusätzlich ist die Implementierung weiterer Funktionen möglich, die als Reaktion über den Server kommuniziert werden sollen.
 
 \begin{figure}[ht]
 \includegraphics[width = 0.47\textwidth, height = 4cm]{images/IM.png}
@@ -154,7 +158,7 @@ Interaktive Marker Elemente erweitern die bereits präzisierten Marker um Intera
 \end{figure}
 
 \subsection{kinematische Operationen in ROS}
-
+In dieser wissenschaftlichen Arbeit erfolgen Berechnungen zur Kinematik, Kollision und Bewegungsplanung ausschließlich mit der ebenfalls öffentlich frei zugänglichen MoveIt Software. Diese definiert den 'move\_group' Node, welcher durch Integration zusätzlicher Nodes und Komponenten dessen vollständigen Funktionsumfang erhält. Beispielsweise werden diese zusätzlichen Nodes innerhalb einer Konfigurationsdatei initiiert, welche gleichermaßen die URDF Datei der zugrundeliegenden robotischen Systeme spezifiziert. Die Generation solcher Konfigurationsdateien erfolgt a priori über den Node des Moveit Assistenten 'MSA'. 
 
 \section{Anforderungen automatischer kollaborativer Multi-Roboter Arbeitsplätze}
 Marvel et al. adressieren die Skalierbarkeit, Synchronisierung der Roboter, Verteilung der spezifischen Aufgaben und Kollisionsvermeidung als grundlegende Aspekte der Planung eines Multi-Roboter Systems. Offensichtlich stehen diese Aspekte in Wechselwirkung zueinander, denn die Kollisionsdetektion ist beispielsweise vereinfacht, wenn die Exekution der Aufgaben sequentiell erfolgt und daher nur ein Roboter zeitgleich Bewegungen ausführt, dies impliziert zugleich eine weniger komplexe Aufgabenverteilung. Erfolgen die Handlungen der Roboter synchron, so ist die Verteilung der der Aufgaben essenziell für eine erfolgreiche Terminierung und dessen Ausführungszeit und bedingt eine komplexere Kollisionsdetektion. Änderungen der Szenerie, Beispielsweise durch die Hinzunahme oder Abnahme der Roboter, haben ebenfalls Auswirkungen auf die Ausführung beziehungsweise Kalkulationszeit, welche die Skalierbarkeit des Arbeitsraums konkretisiert.\cite{Marvel2018}. Diese Aspekte sind zusätzlich abhängig von der Platzierung in der Domäne, welche die Generierung automatischer Multi-Roboter Arbeitsplätze ermöglicht und daher der Hauptaspekt dieser wissenschaftlichen Arbeit ist. Also eigentlich kann ich hier alles aus Evaluation rein kopieren, das klingt zumindest besser.