diff --git a/CRE7038.tmp b/CRE7038.tmp
new file mode 100644
index 0000000000000000000000000000000000000000..899be26c8338eb3291a1a4fa1f78224080714aaf
--- /dev/null
+++ b/CRE7038.tmp
@@ -0,0 +1,175 @@
+% the following command is only required if the thesis is written in german
+\RequirePackage[ngerman=ngerman-x-latest]{hyphsubst}
+
+% change to english for english theses
+\documentclass[ngerman,BCOR=1.5cm,twoside]{tudscrreprt}
+
+\usepackage[T1]{fontenc}
+\usepackage[utf8]{inputenc}
+\usepackage[ngerman]{babel}
+\usepackage{isodate}
+\usepackage{amssymb}
+\usepackage{amsmath}
+
+\usepackage[
+    style=numeric-comp,
+    backend=biber,
+    url=false,
+    doi=true,
+    isbn=false,
+		hyperref,
+]{biblatex}
+\addbibresource{bibliography.bib}
+\AtEveryBibitem{%
+    \clearfield{note}%
+}
+
+\renewbibmacro*{doi+eprint+url}{%
+    \printfield{doi}%
+    \newunit\newblock%
+    \iftoggle{bbx:eprint}{%
+        \usebibmacro{eprint}%
+    }{}%
+    \newunit\newblock%
+    \iffieldundef{doi}{%
+        \usebibmacro{url+urldate}}%
+        {}%
+    }
+
+
+
+\usepackage[hidelinks]{hyperref} % makes all links clickable but hides ugly boxes
+\usepackage[capitalise,nameinlink,noabbrev]{cleveref} % automatically inserts Fig. X in the text with \cref{..}
+
+\usepackage[colorinlistoftodos,prependcaption,textsize=tiny]{todonotes}
+
+\usepackage{graphicx}
+\graphicspath{ {./images/} }
+
+% if you need mathy stuff
+\newtheorem{lem}{Lemma}
+\crefname{lem}{Lemma}{Lemmas}
+\newtheorem{thm}{Theorem}
+\crefname{thm}{Theorem}{Theorems}
+\newtheorem{defs}{Definition}
+\crefname{defs}{Def.}{Defs.}
+
+\usepackage{blindtext}
+
+%\usepackage{tudscrsupervisor} % if you want to copy the sources of the task description into the thesis
+
+\usepackage{csquotes}
+
+
+
+\usepackage{caption}
+\captionsetup{font=sf,labelfont=bf,labelsep=space}
+\usepackage{floatrow}
+\floatsetup{font=sf}
+\floatsetup[table]{style=plaintop}
+\captionsetup{singlelinecheck=off,format=hang,justification=raggedright}
+\DeclareCaptionSubType[alph]{figure}
+\DeclareCaptionSubType[alph]{table}
+\captionsetup[subfloat]{labelformat=brace,list=off}
+
+\usepackage{booktabs}
+\usepackage{array}
+\usepackage{tabularx}
+\usepackage{tabulary}
+\usepackage{tabu}
+\usepackage{longtable}
+
+\usepackage{quoting}
+
+\usepackage[babel]{microtype}
+
+\usepackage{xfrac}
+
+\usepackage{enumitem}
+\setlist[itemize]{noitemsep}
+
+\usepackage{ellipsis}
+\let\ellipsispunctuation\relax
+
+\input{lst.tex}
+\usepackage{tikz}
+
+\usetikzlibrary{positioning,arrows,calc,math,angles,quotes,chains,shapes}
+\newcommand{\R}{\mathbb{R}}
+\newcommand{\N}{\mathbb{N}}
+\usepackage{hyperref}
+\usepackage{mathtools}
+\usepackage{multirow}
+
+
+
+\usepackage{bera}% optional: just to have a nice mono-spaced font
+\usepackage{listings}
+\usepackage{xcolor}
+\usepackage{lstautogobble}
+\usepackage{dirtree}
+
+\begin{document}
+
+\faculty{Fakultät Informatik}
+\department{}
+\institute{Institut für Software- und Multimediatechnik}
+\chair{Lehrstuhl für Softwaretechnologie}
+\title{%
+    Automatisierte Konstruktion kollaborativer Multi-Roboter Arbeitsräume
+}
+
+%% for a bachelor thesis
+%\thesis{bachelor}
+%\graduation[B.Sc.]{Bachelor of Science}
+
+% for a master thesis
+\thesis{bachelor}
+\graduation[B.Sc.]{Bachelor of Science}
+
+% for a diploma thesis
+%\thesis{diploma}
+%\graduation[Dipl.Inf.]{Diplom-Informatiker}
+
+\author{Matteo Anedda}
+\emailaddress[]{matteo.anedda@mailbox.tu-dresden.de}
+\matriculationnumber{4732423}
+\matriculationyear{2017}
+\dateofbirth{17.09.1997}
+\placeofbirth{Riesa}
+%\discipline{Distributed Systems Engineering}
+
+\course{Bachelor Informatik}
+
+\supervisor{%
+	Dipl.-Inf. Sebastian Ebert
+    \and Dipl.-Inf. Johannes Mey%
+}
+
+\professor{Prof. Dr. rer. nat. habil. Uwe Aßmann}
+\date{01.12.2021}
+\maketitle
+\newpage
+
+\tableofcontents
+\listoffigures
+\listoftables
+
+\input{sections/einleitung}
+\input{sections/grundlagen.tex}
+\input{sections/sota.tex}
+\input{sections/konzept.tex}
+\input{sections/fallbeispiel.tex}
+\input{sections/implementierung.tex}
+\input{sections/evaluation.tex}
+\input{sections/zusammenfassung.tex}
+
+\nocite{*}
+\printbibliography[heading=bibintoc]\label{sec:bibliography}%
+
+%\appendix
+%\input{sections/appendix}
+
+\confirmation
+
+\end{document}
diff --git a/images/IM2.png b/images/IM2.png
index 6f29d9d5715f9333a8003759134981b964e601f0..83ace046f2b44e589f3746a1c7ec27b017af6ed0 100644
Binary files a/images/IM2.png and b/images/IM2.png differ
diff --git a/images/IMG_20211124_153815.jpg b/images/ceti.jpg
similarity index 100%
rename from images/IMG_20211124_153815.jpg
rename to images/ceti.jpg
diff --git a/images/sphere.png b/images/sphere.png
new file mode 100644
index 0000000000000000000000000000000000000000..c4cf4654b841b7b712583ec499a8df4b831af31f
Binary files /dev/null and b/images/sphere.png differ
diff --git a/lst.tex b/lst.tex
index 2543430b1879852aac81f52bd681097a90f78bb0..065b0059921f54bd11aa528e3c704c3b77156e38 100644
--- a/lst.tex
+++ b/lst.tex
@@ -15,10 +15,12 @@
 	backgroundcolor=\color{background},
 	autogobble=true,
   keywordstyle={\color{blue}\textbf}, % keywords are blue
-  commentstyle={\color{gray}},        % comments
-  aboveskip={0.1\baselineskip}
+  commentstyle={\color{gray}\textbf}, % comments
+  aboveskip={0.1\baselineskip},
+	stringstyle={\color{red}\textbf}
 }
 
+
 \colorlet{punct}{red!60!black}
 \definecolor{background}{HTML}{EEEEEE}
 \definecolor{delim}{RGB}{20,105,176}
@@ -39,8 +41,19 @@
 \lstdefinelanguage{AST}{
 	style=common-style,
 	morekeywords={abstract,rel},
-	otherkeywords={::=,->,<,>},
+	otherkeywords={},
 	morecomment=[l]{//}, morecomment=[s]{/*}{*/},
+	keywordstyle=\color{blue}\ttfamily,
+	commentstyle=\color{blue}\ttfamily,
+	morecomment=[l][\color{magenta}]{\#},
+		literate=
+			{Ö}{{\"O}}1
+			{Ä}{{\"A}}1
+			{Ü}{{\"U}}1
+			{ß}{{\ss}}1
+			{ü}{{\"u}}1
+			{ä}{{\"a}}1
+			{ö}{{\"o}}1,
 }
 
 \lstdefinelanguage{JSON}{
@@ -75,6 +88,7 @@
 			{ö}{{\"o}}1,
 }
 
+
 \lstdefinelanguage{JRAG}[]{java}{
 	style=common-style,
 	morekeywords={abstract,public,private,boolean,aspect,null,syn,inh,coll,eq,with,int,contributes,new,return,for,if,else,this,to,true,false},
@@ -97,17 +111,7 @@
 \lstdefinestyle{JSON} { language=JSON,style=common-style }
 
 
-\lstset{
-	language=C++,
-	breaklines=true,
-	frame=single,
-	basicstyle=\ttfamily,
-	keywordstyle=\color{blue}\ttfamily,
-	stringstyle=\color{red}\ttfamily,
-	commentstyle=\color{blue}\ttfamily,
-	morecomment=[l][\color{magenta}]{\#},
-	rulecolor=\color{black},
-}
+
 
 
 
diff --git a/sections/CRE9BCF.tmp b/sections/CRE9BCF.tmp
new file mode 100644
index 0000000000000000000000000000000000000000..b2b66640785496c8afd365b66cb62832a5819209
--- /dev/null
+++ b/sections/CRE9BCF.tmp
@@ -0,0 +1,169 @@
+\chapter{Implementierung}\label{ch:implementation}
+Die ausführliche Auseinandersetzung mit der Struktur des ROS spezifischen Arbeitsraums, dessen Pakete die Roboterbeschreibungen, Konfigurationsdateien und implementierte Algorithmen enthalten, ist Inhalt dieses Kapitels und in \autoref{fig:8} illustriert. Dabei initialisiert jede Quelldatei einen Node im ROS Kontext in der Programmiersprache C++. 
+
+\begin{figure}[h!]
+\centering
+	\begin{tikzpicture} [ >=stealth']
+		\node[rectangle, draw=black,  thick, minimum height=3em, align=center] (RD) {Roboterbeschreibung};
+		
+		\node[rectangle, draw=black,  thick, minimum height=3em, align=center] (DK) [above right = 1cm and 0.5cm of RD] {Dual Konfiguration};
+		\node[rectangle, draw=black,  thick, minimum height=3em, align=center] (MK) [below right = 1cm and 0.5cm of RD]{Mono Konfiguration};
+		\node[rectangle, draw=black,  thick, minimum height=3em, align=center] (I) [right= 5cm of RD]{Implementierung};
+		
+		\draw[-] (RD) -- (DK) -- (I);
+		\draw[-] (RD) -- (MK) -- (I);
+		
+		\node[rectangle, fill= white, draw=black,  thick, minimum height=1.5em, align=center] (ee) at (RD.south east)  {URDF};
+		\node[rectangle, fill= white, draw=black,  thick, minimum height=1.5em, align=center] (ew) at (DK.south east)  {SRDF}
+		\node[rectangle, fill= white, draw=black,  thick, minimum height=1.5em, align=center] (we) at (MK.south east)  {SRDF};
+
+
+	\end{tikzpicture}
+	\caption{Die Struktur des ROS Arbeitsraums ist durch dessen passive Pakete und aktive Pakete, sowie deren Beziehungen, illustriert. Diese Betrachtung partitioniert das Kapitel logisch in einen organisatorischen Teil, dessen Pakete die Prämisse des exekutiven Teils sind.} \label{fig:8}
+\end{figure}
+
+\section{Robotische Systeme und deren Konfiguration}
+Die Roboterbeschreibung ist Grundlage der Generierung valider Konfigurationsdateien, welche jeweils $n \in \N_{>0}$ robotische Systeme konkretisieren und somit die Kommunikation zwischen den $n$ Robotern durch Integration der \emph{move\_group} Schnittstelle ermöglichen. Diese ist ein Klon des öffentlich zugänglichen Pakets \emph{franka\_ ros} \cite{franka_ros} der Franka Emika GmbH von August 2020, welches der Lehrstuhl für Softwaretechnologie bereitstellt. Die enthaltenen Dateien definieren einzelne Festkörpergruppen sowie deren Vereinigung zu $n$ Robotergruppen. Beispielsweise ist der Struktur aus \autoref{fig:9} zu entnehmen, dass ein Manipulator aus Hand und Arm besteht, sowie dass die Instanziierung mehrerer Manipulatoren eine zusätzliche Datei bedingt. \autoref{fig:9} rechts zeigt die Struktur einer Konfigurationsdatei, welche im \emph{config} Verzeichnis alle Festkörper der Referenzbeschreibung anhand der \emph{controller.yaml} Datei als Kontrollelemente spezifiziert und somit die Interaktion ermöglicht. Das Beispiel einer Modifizierten Roboterbeschreibung eines dualen Setup zeigt \autoref{lst:4}, aus dem das Muster zur Generierung einer $n$ Roboter Datei zu entnehmen ist, indem dessen Inhalt für alle Identitäten $n$ mal iteriert wird. Analog kann die entsprechende $n$\_ Konfigurationsdatei aus dem \emph{MSA} erzeugt werden oder mittels einer Manipulation der \emph{config} und \emph{.launch} Dateien aus \autoref{fig:9} generiert werden.
+
+\begin{figure}
+\centering
+\begin{minipage}{.45\linewidth}
+\dirtree{%
+.1 Roboterbeschreibung.
+.2 ci.
+.2 meshes.
+.2 robots.
+.3 'panda\_arm.xacro'.
+.3 'hand.xacro'.
+.3 'panda\_arm\_hand.xacro'.
+.3 'dual\_panda\_example.xacro'.
+}
+\end{minipage}\hfill
+\begin{minipage}{.55\linewidth}
+\dirtree{%
+.1 MoveIt\_Konfiguration.
+.2 config.
+.3 'panda\_controller.yaml'.
+.3 'panda\_gripper\_controller.yaml'.
+.2 launch.
+.3 'move\_group.launch'.
+.3 'demo.launch'.
+.3 'planning\_context.launch'.
+}
+\end{minipage}\hfill
+\caption{Visualisierung der Verzeichnisstruktur der Roboterbeschreibung und Konfiguration. Bezüglich der Übersichtlichkeit sind nur die Dateien gelistet, deren Modifikation hinsichtlich der Realisierung mehrerer robotischer Systeme relevant ist.}\label{fig:9}
+\end{figure}
+
+\begin{lstlisting}[language=JSON,firstnumber=1, float, caption={ Dual Setup Beispiel mit Modifikationen zur Übergabe der Roboterpositionen.}, label={lst:4}, captionpos=t]
+{<robot xmlns:xacro="http://www.ros.org/wiki/xacro" name="panda">
+<!-- Einbindung der Roboter Komponenten-->
+<xacro:include filename="panda_arm.xacro"/>
+<xacro:include filename="hand.xacro"/>
+
+<!-- Deklaration der Namensattribute zu konkretisierender Roboter -->
+<xacro:arg name="arm_id_1" default="panda_1" />
+<xacro:arg name="arm_id_2" default="panda_2" />
+
+<!-- Deklarierung des Positionsattribute, welche aus der Kalkulation, ber die Konfigurationsdatei, in die Roboterbeschreibung bergeben wird-->
+<xacro:arg name="pos_1" default="0 0 0" />
+<xacro:arg name="pos_2" default="1 1 0" />
+
+<!-- Definition des eindeutigen World-Frames, als Referenz der Roboter -->
+<link name="world"/>
+
+<!-- Initialisierung der robotischen Systeme an ihrer spezifischen Position-->
+<xacro:panda_arm arm_id="$(arg arm_id_1)" connected_to="world"  xyz="$(arg pos_1)" /> 
+<xacro:hand ns="$(arg arm_id_1)" rpy="0 0 ${-pi/4}" connected_to="$(arg arm_id_1)_link8" />
+
+<xacro:panda_arm arm_id="$(arg arm_id_2)" connected_to="world"  xyz="$(arg pos_2)" /> 
+<xacro:hand ns="$(arg arm_id_2)" rpy="0 0 ${-pi/4}" connected_to="$(arg arm_id_2)_link8"/>
+<!-- Eine n-Roboterbeschreibung erfordert Namens- und Positions- Deklarationen sowie die Initialisierung aller n Manipulatoren -->  
+</robot>}
+\end{lstlisting}
+
+
+\subsection{MoveGroup Interface mit Dual Setup}
+Eine Konfigurationsdatei konkretisiert ein robotisches System als Bewegungsgruppe \emph{Move\_Group}, deren Identität eindeutig durch ihr Namensattribut bestimmt ist. Demnach genügt dieses zur Instanziierung eines \emph{Move\_Group} Objekts, welches die Kommunikation zum gewählten Roboter initiiert. Eine duale Konfigurationsdatei ermöglicht analog das Instanziieren und Ansteuern zweier robotischer Systeme durch deren Namensattribut. 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 der Schnittstelle hinsichtlich der Betrachtung mehrerer robotischer Systeme limitiert sind. Der \autoref{lst:5} zeigt einen Ansatz, der die Kollisionsdetektion definierter Kollisionsobjekte in der \emph{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, wodurch beispielsweise die Greifoperation fehlschlägt. Der illustrierte Quelltext behebt diesen Fehler, indem derartige Kollisionen erlaubt werden.}, label={lst:5}, float, captionpos=t]
+// Initialisierung der Szene
+planning_scene::PlanningScene ps(kinematic_model);
+
+// Generierung der Bewegungsgruppen anhand der festgelegten Namensattribute innerhalb der dualen Konfigurationsdatei
+std::vector<moveit::planning_interface::MoveGroupInterface>  robots;
+for(int i = 1; i <= 2; i++)
+	robots.push_back(std::move(moveit::planning_interface::MoveGroupInterface("panda_arm"+ std::to_string(i))))
+	
+// Modifikation der Kollisionsmatrix, welche die erlaubten Kollisionen der robotischen Systeme anhand deren Adjazenzen enthaelt 
+collision_detection::AllowedCollisionMatrix acm = ps.getAllowedCollisionMatrix();
+
+for(int i = 1; i <= 2; i++){
+	acm.setEntry("object" + std::to_string(i), "panda_" + std::to_string(i) + "_leftfinger", true);
+	acm.setEntry("object" + std::to_string(i), "panda_" + std::to_string(i) + "_rightfinger", true);
+}
+
+// Publikation der Aenderungen als Inhalt einer Planning Scene Nachricht
+moveit_msgs::PlanningScene pls;
+acm.getMessage(pls.allowed_collision_matrix);
+pls.is_diff = true;
+planning_scene_diff_publisher.publish(pls);
+\end{lstlisting}
+
+
+\section{Implementierung zur Positionsermittlung}
+Die tatsächliche Implementierung ist Inhalt des Reach Pakets, dessen Struktur die \autoref{fig:10} illustriert. An dieser ist ersichtlich, dass die Artefakte aus den kinematischen Berechnungen, beispielsweise der Arbeitsraumanalyse oder deren Inversion, in den zugehörigen Ordnern persistiert werden, während anderweitig generierte Dateien, wie der Aufgabenbeschreibung und Positionsbeschreibung, an anderer Stelle vorliegen. Das RViz Verzeichnis beinhaltet alle Konfigurationen der spezifischen Nodes im RViz Kontext, dessen Resultate anhand visueller Nachrichten publiziert werden. Dies impliziert, dass relevante Aspekte eines Nodes jederzeit durch das RViz Programm transparent observiert werden können.
+
+\begin{figure}[h!]
+\centering
+\begin{minipage}{.55\linewidth}
+\dirtree{%
+.1 Reach.
+.2 include.
+.2 launch.
+.2 maps.
+.3 inverse.
+.3 reach.
+.2 rviz.
+.2 src.
+.2 task.
+.2 position.
+}
+\end{minipage}\hfill
+\caption{Visualisierung aller Komponenten des Reach Verzeichnisses und deren Beziehung untereinander.}\label{fig:10}
+\end{figure}
+
+
+\subsection{Implementierung der Arbeitsraumanalyse}
+Der (Quelltext.6) der Header Datei beschreibt alle Funktionen, die den Algorithmus der Arbeitsraumanalyse implementieren. Dazu sind gemäß der Erörterungen im 'Konzept' Kapitel, neben der kubischen Diskretisierung zusätzliche sphärische Diskretisierungen formuliert. Die Planung des Endeffektors zu einer generierten Endeffektor Pose erfolgt über das MoveGroup Interface, angewandt auf der Konfigurationsdatei eines einzelnen robotischen Systems. Dabei ist eine Implementierung für performante Rechner enthalten, die Anhand der Aufteilung der Menge $T$ in die jeweiligen Rechenkerne alle kinematischen Berechnungen $f_{kin}$ parallel operiert.
+
+
+%\lstinputlisting[language=C++, caption ={Implementierung zur Generierung der RM}, label={lst:6}, captionpos=b ]{./images/publisher\_node.h}
+
+\subsection{Implementierung des Inversen Arbeitsraums}
+Der Algorithmus des inversen Arbeitsraums kalkuliert anhand der persistierten Informationen der Arbeitsraumanalyse die Metrik D. Die Inversion aller Transformationen anhand einer Iteration über den Arbeitsraum, erfolgt durch die in der Bibliothek \emph{tf2} implementierte Realisierung homogener Transformationen dessen Operationen $\in SE(3)$. Zusätzlich erfolgt die Portierung der Metrik und Persistenz der kalkulierten \emph{IRM}.
+
+\subsection{Der Algorithmus zur Positionsanalyse}
+Die Implementierung der Positionsanalyse erfolgt über deren Voxelisierung durch Integration der PCL Bibliothek. Diese ist in C++ vollumfänglich implementiert und ermöglicht performante Operationen auf 3 dimensionale Koordinaten. Dies differenzierte Voxelisierung generiert zunächst ein Gitter aus Vektoren $^{0}v \in \R^{3}$ ähnlich der kubischen Diskretisierung, und bildet jede Transformation $^{0}T_{Base_{TK/KG}} \in ^{0}T_{Base}$ eines Teilkettenglieds der Operationskette $KG_{i}\in TK \subset K$ anhand seiner räumlichen Position auf den Vektor $^{0}v$ ab. Die resultierende Struktur ist in \autoref{eq:30} gezeigt.
+
+\begin{equation}
+\begin{split}
+\label{eq:30}
+Task &= {(i, ^{0}T_{Base_{i}}) | g_{i} \in OK} \\
+Dictionary &= {(^{0}v, Task)}
+\end{split}
+\end{equation}
+
+Eine Teilkette $TK \subset K$ definiert nun anhand ihrer Glieder $g_{i}$ die Einträge, welche der Vektor $^{0}v$ mindestens enthalten muss, um eine potentielle Position des robotischen Systems zu sein, welche $TK$ operiert. Durch die Abbildung $D_{port}({0}T_{Base}) = D_{Reach}({0}T_{Base})$ ist analog die Struktur $Task_{Metrik}$ implementiert, welche die portierten Metriken aller Transformation $^{0}T_{Base_{i}}$ auf den Vektor $^{0}v$ abbildet.
+
+\begin{equation}
+\begin{split}
+\label{eq:31}
+Task_{Metrik} &= {(i, D_{port}(^{0}T_{Base_{i}})) | g_{i} \in K} \\
+Dictionary_{Metrik} &= {(^{0}v, Task_{Metrik})}
+\end{split}
+\end{equation}
+
+Die Ermittlung der optimalen Position $^{0}v$ für eine Teilkette $TK$ erfolgt, indem das arithmetische Mittel pro Kettenglied  $TK \in g_{i}$ kalkuliert wird und in Verhältnis zur Kardinalität $\vert TK \vert$ gesetzt wird. \par 
+Die resultierende Position pro $TK$ wird in einem eigenen Verzeichnis persistiert, um als Parameter der \emph{Pick and Place} Implementierung geladen zu werden und über jede Instanz, von der Konfigurationsdatei in die Roboterbeschreibung übergeben zu werden.  
+
diff --git a/sections/CREA219.tmp b/sections/CREA219.tmp
new file mode 100644
index 0000000000000000000000000000000000000000..b2b66640785496c8afd365b66cb62832a5819209
--- /dev/null
+++ b/sections/CREA219.tmp
@@ -0,0 +1,169 @@
+\chapter{Implementierung}\label{ch:implementation}
+Die ausführliche Auseinandersetzung mit der Struktur des ROS spezifischen Arbeitsraums, dessen Pakete die Roboterbeschreibungen, Konfigurationsdateien und implementierte Algorithmen enthalten, ist Inhalt dieses Kapitels und in \autoref{fig:8} illustriert. Dabei initialisiert jede Quelldatei einen Node im ROS Kontext in der Programmiersprache C++. 
+
+\begin{figure}[h!]
+\centering
+	\begin{tikzpicture} [ >=stealth']
+		\node[rectangle, draw=black,  thick, minimum height=3em, align=center] (RD) {Roboterbeschreibung};
+		
+		\node[rectangle, draw=black,  thick, minimum height=3em, align=center] (DK) [above right = 1cm and 0.5cm of RD] {Dual Konfiguration};
+		\node[rectangle, draw=black,  thick, minimum height=3em, align=center] (MK) [below right = 1cm and 0.5cm of RD]{Mono Konfiguration};
+		\node[rectangle, draw=black,  thick, minimum height=3em, align=center] (I) [right= 5cm of RD]{Implementierung};
+		
+		\draw[-] (RD) -- (DK) -- (I);
+		\draw[-] (RD) -- (MK) -- (I);
+		
+		\node[rectangle, fill= white, draw=black,  thick, minimum height=1.5em, align=center] (ee) at (RD.south east)  {URDF};
+		\node[rectangle, fill= white, draw=black,  thick, minimum height=1.5em, align=center] (ew) at (DK.south east)  {SRDF}
+		\node[rectangle, fill= white, draw=black,  thick, minimum height=1.5em, align=center] (we) at (MK.south east)  {SRDF};
+
+
+	\end{tikzpicture}
+	\caption{Die Struktur des ROS Arbeitsraums ist durch dessen passive Pakete und aktive Pakete, sowie deren Beziehungen, illustriert. Diese Betrachtung partitioniert das Kapitel logisch in einen organisatorischen Teil, dessen Pakete die Prämisse des exekutiven Teils sind.} \label{fig:8}
+\end{figure}
+
+\section{Robotische Systeme und deren Konfiguration}
+Die Roboterbeschreibung ist Grundlage der Generierung valider Konfigurationsdateien, welche jeweils $n \in \N_{>0}$ robotische Systeme konkretisieren und somit die Kommunikation zwischen den $n$ Robotern durch Integration der \emph{move\_group} Schnittstelle ermöglichen. Diese ist ein Klon des öffentlich zugänglichen Pakets \emph{franka\_ ros} \cite{franka_ros} der Franka Emika GmbH von August 2020, welches der Lehrstuhl für Softwaretechnologie bereitstellt. Die enthaltenen Dateien definieren einzelne Festkörpergruppen sowie deren Vereinigung zu $n$ Robotergruppen. Beispielsweise ist der Struktur aus \autoref{fig:9} zu entnehmen, dass ein Manipulator aus Hand und Arm besteht, sowie dass die Instanziierung mehrerer Manipulatoren eine zusätzliche Datei bedingt. \autoref{fig:9} rechts zeigt die Struktur einer Konfigurationsdatei, welche im \emph{config} Verzeichnis alle Festkörper der Referenzbeschreibung anhand der \emph{controller.yaml} Datei als Kontrollelemente spezifiziert und somit die Interaktion ermöglicht. Das Beispiel einer Modifizierten Roboterbeschreibung eines dualen Setup zeigt \autoref{lst:4}, aus dem das Muster zur Generierung einer $n$ Roboter Datei zu entnehmen ist, indem dessen Inhalt für alle Identitäten $n$ mal iteriert wird. Analog kann die entsprechende $n$\_ Konfigurationsdatei aus dem \emph{MSA} erzeugt werden oder mittels einer Manipulation der \emph{config} und \emph{.launch} Dateien aus \autoref{fig:9} generiert werden.
+
+\begin{figure}
+\centering
+\begin{minipage}{.45\linewidth}
+\dirtree{%
+.1 Roboterbeschreibung.
+.2 ci.
+.2 meshes.
+.2 robots.
+.3 'panda\_arm.xacro'.
+.3 'hand.xacro'.
+.3 'panda\_arm\_hand.xacro'.
+.3 'dual\_panda\_example.xacro'.
+}
+\end{minipage}\hfill
+\begin{minipage}{.55\linewidth}
+\dirtree{%
+.1 MoveIt\_Konfiguration.
+.2 config.
+.3 'panda\_controller.yaml'.
+.3 'panda\_gripper\_controller.yaml'.
+.2 launch.
+.3 'move\_group.launch'.
+.3 'demo.launch'.
+.3 'planning\_context.launch'.
+}
+\end{minipage}\hfill
+\caption{Visualisierung der Verzeichnisstruktur der Roboterbeschreibung und Konfiguration. Bezüglich der Übersichtlichkeit sind nur die Dateien gelistet, deren Modifikation hinsichtlich der Realisierung mehrerer robotischer Systeme relevant ist.}\label{fig:9}
+\end{figure}
+
+\begin{lstlisting}[language=JSON,firstnumber=1, float, caption={ Dual Setup Beispiel mit Modifikationen zur Übergabe der Roboterpositionen.}, label={lst:4}, captionpos=t]
+{<robot xmlns:xacro="http://www.ros.org/wiki/xacro" name="panda">
+<!-- Einbindung der Roboter Komponenten-->
+<xacro:include filename="panda_arm.xacro"/>
+<xacro:include filename="hand.xacro"/>
+
+<!-- Deklaration der Namensattribute zu konkretisierender Roboter -->
+<xacro:arg name="arm_id_1" default="panda_1" />
+<xacro:arg name="arm_id_2" default="panda_2" />
+
+<!-- Deklarierung des Positionsattribute, welche aus der Kalkulation, ber die Konfigurationsdatei, in die Roboterbeschreibung bergeben wird-->
+<xacro:arg name="pos_1" default="0 0 0" />
+<xacro:arg name="pos_2" default="1 1 0" />
+
+<!-- Definition des eindeutigen World-Frames, als Referenz der Roboter -->
+<link name="world"/>
+
+<!-- Initialisierung der robotischen Systeme an ihrer spezifischen Position-->
+<xacro:panda_arm arm_id="$(arg arm_id_1)" connected_to="world"  xyz="$(arg pos_1)" /> 
+<xacro:hand ns="$(arg arm_id_1)" rpy="0 0 ${-pi/4}" connected_to="$(arg arm_id_1)_link8" />
+
+<xacro:panda_arm arm_id="$(arg arm_id_2)" connected_to="world"  xyz="$(arg pos_2)" /> 
+<xacro:hand ns="$(arg arm_id_2)" rpy="0 0 ${-pi/4}" connected_to="$(arg arm_id_2)_link8"/>
+<!-- Eine n-Roboterbeschreibung erfordert Namens- und Positions- Deklarationen sowie die Initialisierung aller n Manipulatoren -->  
+</robot>}
+\end{lstlisting}
+
+
+\subsection{MoveGroup Interface mit Dual Setup}
+Eine Konfigurationsdatei konkretisiert ein robotisches System als Bewegungsgruppe \emph{Move\_Group}, deren Identität eindeutig durch ihr Namensattribut bestimmt ist. Demnach genügt dieses zur Instanziierung eines \emph{Move\_Group} Objekts, welches die Kommunikation zum gewählten Roboter initiiert. Eine duale Konfigurationsdatei ermöglicht analog das Instanziieren und Ansteuern zweier robotischer Systeme durch deren Namensattribut. 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 der Schnittstelle hinsichtlich der Betrachtung mehrerer robotischer Systeme limitiert sind. Der \autoref{lst:5} zeigt einen Ansatz, der die Kollisionsdetektion definierter Kollisionsobjekte in der \emph{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, wodurch beispielsweise die Greifoperation fehlschlägt. Der illustrierte Quelltext behebt diesen Fehler, indem derartige Kollisionen erlaubt werden.}, label={lst:5}, float, captionpos=t]
+// Initialisierung der Szene
+planning_scene::PlanningScene ps(kinematic_model);
+
+// Generierung der Bewegungsgruppen anhand der festgelegten Namensattribute innerhalb der dualen Konfigurationsdatei
+std::vector<moveit::planning_interface::MoveGroupInterface>  robots;
+for(int i = 1; i <= 2; i++)
+	robots.push_back(std::move(moveit::planning_interface::MoveGroupInterface("panda_arm"+ std::to_string(i))))
+	
+// Modifikation der Kollisionsmatrix, welche die erlaubten Kollisionen der robotischen Systeme anhand deren Adjazenzen enthaelt 
+collision_detection::AllowedCollisionMatrix acm = ps.getAllowedCollisionMatrix();
+
+for(int i = 1; i <= 2; i++){
+	acm.setEntry("object" + std::to_string(i), "panda_" + std::to_string(i) + "_leftfinger", true);
+	acm.setEntry("object" + std::to_string(i), "panda_" + std::to_string(i) + "_rightfinger", true);
+}
+
+// Publikation der Aenderungen als Inhalt einer Planning Scene Nachricht
+moveit_msgs::PlanningScene pls;
+acm.getMessage(pls.allowed_collision_matrix);
+pls.is_diff = true;
+planning_scene_diff_publisher.publish(pls);
+\end{lstlisting}
+
+
+\section{Implementierung zur Positionsermittlung}
+Die tatsächliche Implementierung ist Inhalt des Reach Pakets, dessen Struktur die \autoref{fig:10} illustriert. An dieser ist ersichtlich, dass die Artefakte aus den kinematischen Berechnungen, beispielsweise der Arbeitsraumanalyse oder deren Inversion, in den zugehörigen Ordnern persistiert werden, während anderweitig generierte Dateien, wie der Aufgabenbeschreibung und Positionsbeschreibung, an anderer Stelle vorliegen. Das RViz Verzeichnis beinhaltet alle Konfigurationen der spezifischen Nodes im RViz Kontext, dessen Resultate anhand visueller Nachrichten publiziert werden. Dies impliziert, dass relevante Aspekte eines Nodes jederzeit durch das RViz Programm transparent observiert werden können.
+
+\begin{figure}[h!]
+\centering
+\begin{minipage}{.55\linewidth}
+\dirtree{%
+.1 Reach.
+.2 include.
+.2 launch.
+.2 maps.
+.3 inverse.
+.3 reach.
+.2 rviz.
+.2 src.
+.2 task.
+.2 position.
+}
+\end{minipage}\hfill
+\caption{Visualisierung aller Komponenten des Reach Verzeichnisses und deren Beziehung untereinander.}\label{fig:10}
+\end{figure}
+
+
+\subsection{Implementierung der Arbeitsraumanalyse}
+Der (Quelltext.6) der Header Datei beschreibt alle Funktionen, die den Algorithmus der Arbeitsraumanalyse implementieren. Dazu sind gemäß der Erörterungen im 'Konzept' Kapitel, neben der kubischen Diskretisierung zusätzliche sphärische Diskretisierungen formuliert. Die Planung des Endeffektors zu einer generierten Endeffektor Pose erfolgt über das MoveGroup Interface, angewandt auf der Konfigurationsdatei eines einzelnen robotischen Systems. Dabei ist eine Implementierung für performante Rechner enthalten, die Anhand der Aufteilung der Menge $T$ in die jeweiligen Rechenkerne alle kinematischen Berechnungen $f_{kin}$ parallel operiert.
+
+
+%\lstinputlisting[language=C++, caption ={Implementierung zur Generierung der RM}, label={lst:6}, captionpos=b ]{./images/publisher\_node.h}
+
+\subsection{Implementierung des Inversen Arbeitsraums}
+Der Algorithmus des inversen Arbeitsraums kalkuliert anhand der persistierten Informationen der Arbeitsraumanalyse die Metrik D. Die Inversion aller Transformationen anhand einer Iteration über den Arbeitsraum, erfolgt durch die in der Bibliothek \emph{tf2} implementierte Realisierung homogener Transformationen dessen Operationen $\in SE(3)$. Zusätzlich erfolgt die Portierung der Metrik und Persistenz der kalkulierten \emph{IRM}.
+
+\subsection{Der Algorithmus zur Positionsanalyse}
+Die Implementierung der Positionsanalyse erfolgt über deren Voxelisierung durch Integration der PCL Bibliothek. Diese ist in C++ vollumfänglich implementiert und ermöglicht performante Operationen auf 3 dimensionale Koordinaten. Dies differenzierte Voxelisierung generiert zunächst ein Gitter aus Vektoren $^{0}v \in \R^{3}$ ähnlich der kubischen Diskretisierung, und bildet jede Transformation $^{0}T_{Base_{TK/KG}} \in ^{0}T_{Base}$ eines Teilkettenglieds der Operationskette $KG_{i}\in TK \subset K$ anhand seiner räumlichen Position auf den Vektor $^{0}v$ ab. Die resultierende Struktur ist in \autoref{eq:30} gezeigt.
+
+\begin{equation}
+\begin{split}
+\label{eq:30}
+Task &= {(i, ^{0}T_{Base_{i}}) | g_{i} \in OK} \\
+Dictionary &= {(^{0}v, Task)}
+\end{split}
+\end{equation}
+
+Eine Teilkette $TK \subset K$ definiert nun anhand ihrer Glieder $g_{i}$ die Einträge, welche der Vektor $^{0}v$ mindestens enthalten muss, um eine potentielle Position des robotischen Systems zu sein, welche $TK$ operiert. Durch die Abbildung $D_{port}({0}T_{Base}) = D_{Reach}({0}T_{Base})$ ist analog die Struktur $Task_{Metrik}$ implementiert, welche die portierten Metriken aller Transformation $^{0}T_{Base_{i}}$ auf den Vektor $^{0}v$ abbildet.
+
+\begin{equation}
+\begin{split}
+\label{eq:31}
+Task_{Metrik} &= {(i, D_{port}(^{0}T_{Base_{i}})) | g_{i} \in K} \\
+Dictionary_{Metrik} &= {(^{0}v, Task_{Metrik})}
+\end{split}
+\end{equation}
+
+Die Ermittlung der optimalen Position $^{0}v$ für eine Teilkette $TK$ erfolgt, indem das arithmetische Mittel pro Kettenglied  $TK \in g_{i}$ kalkuliert wird und in Verhältnis zur Kardinalität $\vert TK \vert$ gesetzt wird. \par 
+Die resultierende Position pro $TK$ wird in einem eigenen Verzeichnis persistiert, um als Parameter der \emph{Pick and Place} Implementierung geladen zu werden und über jede Instanz, von der Konfigurationsdatei in die Roboterbeschreibung übergeben zu werden.  
+
diff --git a/sections/einleitung.tex b/sections/einleitung.tex
index f2196f004e434d17ac7292a85ea46c6d925eda2c..000498652ca23911b8c21bb4a801493cdd5ccd54 100644
--- a/sections/einleitung.tex
+++ b/sections/einleitung.tex
@@ -1,6 +1,16 @@
 \chapter{Einleitung}\label{ch:introduction}
 'Kollaborative Multi-Roboter Arbeitsräume' beschreiben ein Gebiet der Robotik, dessen Inhalt die Kooperation mehrerer robotischer Systeme hinsichtlich der Lösung einer spezifischen Aufgabe innerhalb einer räumlichen Domäne ist. Die zugrundeliegenden Algorithmen ermöglichen dabei die Bewältigung der Aufgaben ohne Kollisionen untereinander, sowie mit Hindernissen in der Umgebung. \par
-Die Planung der Abläufe ist abhängig von der Beschaffenheit des Roboters, denn die Basis eines Roboters kann beweglich oder fest sein. Beispielsweise sind Roboterarme fest auf einer Platte montiert und somit fester Bestandteil der Umgebung. Ein Wechsel ihrer Position würde bedeuten, eine andere Stelle auf der Platte für die Montage zu präparieren, den Roboterarm zu demontieren und an anderer Stelle zu platzieren, was einen enormen Aufwand darstellt und den Erfolg der Handlung nicht garantiert. Daraus ist ersichtlich, dass die Positionierung unflexibler Roboter ein Problem aufweist, dessen Lösung direkten Einfluss hinsichtlich der zeitlicher Komponente, sowie der Bewältigung der spezifischen Aufgabe hat. Die Absolvierung dieser Aufgabe wird demzufolge durch effizientere Nutzung der Arbeitsumgebung besser umgesetzt, aufwändige Montagearbeiten während der Bearbeitung werden reduziert und der dadurch erschlossene Raum sowie die resultierende Zeit kann gewinnbringender genutzt werden. Im Anbetracht der stetig wachsenden Industrie und der sich daraus ergebenden Nachfrage nach effizienten automatisierten Produktionsverfahren, die den limitierten Arbeitsraum einer Produktionsstätte optimal nutzen, ist die Platzierung der Roboter ein entscheidender erster Schritt zur Optimierung des gesamten Arbeitsprozesses. 
+Die Planung der Abläufe ist abhängig von der Beschaffenheit des Roboters, denn die Basis eines Roboters kann beweglich oder fest sein. Beispielsweise sind Roboterarme fest auf einer Platte montiert und somit fester Bestandteil der Umgebung. Ein Wechsel ihrer Position würde bedeuten, eine andere Stelle auf der Platte für die Montage zu präparieren, den Roboterarm zu demontieren und an anderer Stelle zu platzieren, was einen enormen Aufwand darstellt und den Erfolg der Handlung nicht garantiert. Daraus ist ersichtlich, dass die Positionierung unflexibler Roboter ein Problem aufweist, dessen Lösung direkten Einfluss hinsichtlich der zeitlicher Komponente, sowie der Bewältigung der spezifischen Aufgabe hat. Die Absolvierung dieser Aufgabe wird demzufolge durch effizientere Nutzung der Arbeitsumgebung besser umgesetzt, aufwändige Montagearbeiten während der Bearbeitung werden reduziert und der dadurch erschlossene Raum sowie die resultierende Zeit kann gewinnbringender genutzt werden. Ein praktisches Beispiel wird im Exzellenzcluster \emph{Center for Tactile internet with human-in-the-loop} CeTi angewandt, welches Arbeitsräume in Form von Tischen konstruiert. Diese Tische können beliebig verschoben und angepasst werden, um Multi- Roboter Arbeitsräume zu erzeugen. Dieser Tisch ist in \autoref{fig:ceti} abgebildet.
+
+\begin{figure}[h!]
+\includegraphics[width = 9cm, height = 8cm]{images/ceti.jpg}
+\caption{CeTi Tisch mit Franka Emika Panda}
+\label{fig:ceti}
+\end{figure}
+ 
+Im Anbetracht der stetig wachsenden Industrie und der sich daraus ergebenden Nachfrage nach effizienten automatisierten Produktionsverfahren, die den limitierten Arbeitsraum einer Produktionsstätte optimal nutzen, ist die Platzierung der Roboter ein entscheidender erster Schritt zur Optimierung des gesamten Arbeitsprozesses. 
+
+
 
 \section{Zielsetzung der wissenschaftlichen Arbeit}
 \label{sec:Zielsetzung}
diff --git a/sections/evaluation.tex b/sections/evaluation.tex
index 8fd74969559d5e29e0a17c1f78cc6d17f62f3863..795efe71769297459dbeb4482bc4589fd218c7f8 100644
--- a/sections/evaluation.tex
+++ b/sections/evaluation.tex
@@ -1,5 +1,5 @@
 \chapter{Evaluierung}\label{ch:evaluateion}
-Nach der konzeptuellen Ausarbeitung und Demonstration der Implementierung des in \autoref{sec:diffVoxel} beschriebenen Algorithmus zur automatischen Konstruktion Multi-Roboter Arbeitsräume anhand eines Fallbeispiels, erfolgt in diesem Kapitel die Evaluation bezüglich der Anforderungen, welche \autoref{sec:anforderungen} zu entnommen sind.
+Nach der konzeptuellen Ausarbeitung und Demonstration der Implementierung des in \autoref{sec:diffVoxel} beschriebenen Algorithmus zur automatischen Konstruktion Multi-Roboter Arbeitsräume anhand eines Fallbeispiels, erfolgt in diesem Kapitel die Evaluation bezüglich der Anforderungen, welche \autoref{sec:anforderungen} zu entnehmen sind.
 
 \section{Quantitative Auswertung}
 Die Leistung und Effizienz von Multi-Roboter, analog zu Single-Roboter Arbeitsräumen, ist anhand spezifischer zeitlicher Kriterien bemessen. Zu diesen Kriterien gehören:
@@ -18,7 +18,7 @@ Der Hauptaspekt dieser wissenschaftlichen Arbeit ist die automatisierte Konstruk
 \end{enumerate}
 
 \subsection{Skalierbarkeit der Arbeitsräume}
-Marvel et al. \cite{Marvel2018} dokumentieren in ihrer Publikation zur Evaluierung robotischer Arbeitsräume, dass die Effizienz und Leistung eines Multi-Roboter Arbeitsraums anhand des Vergleichs mit dem eines einzelnen robotischen Systems gemessen werden kann. Dieser Vergleich erfordert eine Aufgabenbeschreibung, die für beide Arbeitsräume realisierbar ist, wodurch kooperative Aufgaben ausgeschlossen sind, da diese mehrere Roboter bedingen. \autoref{lst:eval1} visualisiert eine für diesen Vergleich angemessene Aufgabenbeschreibung \texttt{eval1}, während \autoref{fig:eval1} die Aufgabe schematisiert. Die Färbung der Pfeile ist für den Arbeitsraum mit bestehend aus einem robotischen System irrelevant.    
+Marvel et al. \cite{Marvel2018} dokumentieren in ihrer Publikation zur Evaluierung robotischer Arbeitsräume, dass die Effizienz und Leistung eines Multi-Roboter Arbeitsraums anhand des Vergleichs mit dem eines einzelnen robotischen Systems gemessen werden kann. Dieser Vergleich erfordert eine Aufgabenbeschreibung, die für beide Arbeitsräume realisierbar ist, wodurch kooperative Aufgaben ausgeschlossen sind, da diese mehrere Roboter benötigen. \autoref{lst:eval1} visualisiert eine für diesen Vergleich angemessene Aufgabenbeschreibung, während \autoref{fig:eval1} die Aufgabe schematisiert. Die Färbung der Pfeile ist für den Arbeitsraum bestehend aus einem robotischen System irrelevant, sonder bezieht sich auf den Multi-Roboter Arbeitsraum.    
 
 \begin{lstlisting}[language=JSON,firstnumber=1, float, caption={Aufgabenbeschreibung von \texttt{eval1}},captionpos=t, label={lst:eval1}]
 Name_der_Aufgabe: eval1
@@ -45,8 +45,8 @@ Aufgabenbeschreibung:
 \label{fig:eval1}
 \end{figure}
 
-Arbeitsräume können anhand der Dauer einer Exekution, der maximalen/minimalen und durchschnittlichen Ausführzeit, sowie der Standartabweichung \footnote{\url{https://mathworld.wolfram.com/StandardDeviation.html}} einer Aufgabe evaluiert werden. Um diese Daten zu erheben, erfolgen 15 Versuche anhand der Aufgabenbeschreibung von \texttt{eval1} für die betrachteten Arbeitsräume.
-Aus den Messungen in \autoref{tab:eval1solo} und \autoref{tab:eval1multi} ergeben sich in \autoref{tab:ergebnis}
+Arbeitsräume können anhand der Dauer einer Exekution, der maximalen/minimalen und durchschnittlichen Ausführzeit, sowie der Standardabweichung \footnote{\url{https://mathworld.wolfram.com/StandardDeviation.html}} einer Aufgabe evaluiert werden. Um diese Daten zu erheben, erfolgen 15 Versuche anhand der Aufgabenbeschreibung für die betrachteten Arbeitsräume.
+
 \begin{table}[h!]
 \begin{tabulary}{\textwidth}{@{}CCCCC@{}}
 \toprule
@@ -71,7 +71,7 @@ OK &
 2.0335s
 \tabularnewline\bottomrule
 \end{tabulary}
-\caption{Metriken des Arbeitsraums mit einem einzelnen robotischen System.}\label{tab:ergebnis1}
+\caption{Metriken des Arbeitsraums mit einem einzelnen robotischen System}\label{tab:ergebnis1}
 \end{table}
 
 \begin{table}[h!]
@@ -98,14 +98,39 @@ OK &
 4.0533s
 \tabularnewline\bottomrule
 \end{tabulary}
-\caption{Metriken des Multi-Roboter Arbeitsraums.}\label{tab:ergebnis2}
+\caption{Metriken des Multi-Roboter Arbeitsraums}\label{tab:ergebnis2}
+\end{table}
+
+\begin{table}[h!]
+\begin{tabulary}{\textwidth}{@{}CCCCC@{}}
+\toprule
+\textbf{Ketten} & \textbf{Minimum} & \textbf{Maximum} & \textbf{arithmetisches Mittel} & \textbf{Standardabweichung}
+\tabularnewline\midrule
+OK  &
+15.93s &
+25.00s &
+20.13s &
+3.11s 
+\tabularnewline\bottomrule
+\end{tabulary}
+\caption{Metriken des Multi-Roboter Arbeitsraums bei paralleler Exekution}\label{tab:ergebnis3}
 \end{table}
 
-\autoref{tab:eval1solo} dokumentiert die Messung der Zeit in Sekunden, welche ein einzelnes robotisches System zur Exekution der Teilketten, sowie der gesamten Operationskette von Aufgabe \texttt{eval1} beansprucht. Leere Zeilen implizieren das Versagen des robotischen Systems, indem es beispielsweise entweder keinen Pfad zum nächsten Kettenglied kalkuliert hat, oder eine Kollision mit der Szene detektiert wurde.  
+Aus den Messungen in \autoref{tab:eval1} ergeben sich \autoref{tab:ergebnis1} beziehungsweise \autoref{tab:ergebnis2}. Dabei werden alle fehlerhaften Messungen durch den jeweiligen maximalen Wert ersetzt. \emph{MoveIt!} limitiert die Planung und Exekution von Aufgaben, indem diese nur sequentiell erfolgen, obwohl Schnittaufgaben in Multi-Roboter Arbeitsräumen vollständig parallel ausgeführt werden können. Die in \autoref{tab:ergebnis3} kalkulierten Werte entstammen \autoref{tab:eval1}, indem die Zeit zur Ausführung der Operationskette dem Maximum der Teilketten 1 und 2 $max(1. TK, 2. TK)$ entspricht. Diese Werte sind nicht repräsentativ, denn es könnten beispielsweise öfter Fehler auftreten oder die Pfadberechnung würden mehr Zeit in Anspruch nehmen. 
+Aus 
+
+\autoref{tab:eval1} dokumentiert die Messung der Zeit, welche ein einzelnes robotisches System beziehungsweise zwei robotische Systeme in einem Multi-Roboter Arbeitsraum zur Exekution der Teilketten, sowie der gesamten Operationskette der Aufgabe beanspruchen. Leere Zeilen implizieren das Versagen des robotischen Systems, indem es beispielsweise entweder keinen Pfad zum nächsten Kettenglied kalkuliert hat oder eine Kollision mit der Szene detektiert wurde. 
+Aus \autoref{tab:ergebnis1} beziehungsweise \autoref{tab:ergebnis2} ist zu entnehmen, dass ein einzelnes robotisches System eine Schnittaufgabe in allen Aspekten schneller exekutiert, als ein Multi-Roboter System. Durch die Simulation einer parallelen Ausführung in \autoref{tab:ergebnis3}, führt der Multi-Roboter Arbeitsraum die Aufgabe durchschnittlich schneller aus, als ein einzelnes robotisches System.
 
-\begin{table}
+\begin{table}[h!]
+\parbox{.45\linewidth}{
+\centering
 \begin{tabulary}{\textwidth}{@{}RRR@{}}
 \toprule
+&
+Single-Roboter&
+
+\tabularnewline\midrule
 \textbf{1. TK} & \textbf{2. TK} & \textbf{OK} 
 \tabularnewline\midrule
 10.0327s&
@@ -169,14 +194,16 @@ OK &
 27.0866s
 \tabularnewline\bottomrule
 \end{tabulary}
-\caption{Dokumentation erfassten Messungen für ein einzelnes robotisches System in Sekunden}\label{tab:eval1solo}
-\end{table}
-
-\autoref{tab:eval1multi} dokumentiert analog zu \autoref{tab:eval1solo} die Messung der Zeit in Sekunden, welche ein Multi-Roboter Arbeitsraum zur Exekution der Aufgabe \texttt{eval1} in 15 Versuchen benötigt. 
-
-\begin{table}
+}
+\quad
+\parbox{.45\linewidth}{
+\centering
 \begin{tabulary}{\textwidth}{@{}RRR@{}}
 \toprule
+&
+Multi-Roboter&
+
+\tabularnewline\midrule
 \textbf{1. TK} & \textbf{2. TK} & \textbf{OK} 
 \tabularnewline\midrule
 16.2703s&
@@ -240,13 +267,28 @@ OK &
 34.5407s
 \tabularnewline\bottomrule
 \end{tabulary}
-\caption{Dokumentation erfassten Messungen für ein einzelnes robotisches System in Sekunden}\label{tab:eval1multi}
+\caption{Erfasste Messungen für robotische Arbeitsräume}\label{tab:eval1}
+}
 \end{table}
 
+\subsubsection{Das amdahlsche Gesetz}
+Die Beschleunigung (Speedup) eines Prozesses durch Parallelisierung wird anhand des amdahlschen Gesetzes \cite{Karmani} bemessen. Dazu erfolgt zunächst die Spaltung des Algorithmus in einen parallelisierbaren und sequentiellen Teil \emph{f}, wobei die Anzahl der operierenden Rechenkerne \emph{p} den parallelen Anteil beeinflusst, während sequentielle Aspekte des Verfahrens fest bleiben. Angewendet auf die Exekution einer Aufgabe in Multi-Roboter Arbeitsräumen, kann die Beschleunigung nach \autoref{eq:amdahl}
+kalkuliert werden. Dabei beträgt der sequentielle Anteil dieser \emph{Pick and Place} Aufgabe 8.34 Sekunden und beinhaltet das Lesen der Aufgabenbeschreibung sowie das Generieren aller Primitive und Auflageflächen der Szene, was \autoref{sec:Konstruktion} zu entnehmen ist. Die Gesamtzeit der Exekution nach \autoref{tab:ergebnis1} beträgt demnach 33.63 Sekunden, wovon \emph{f} der 24.8 prozentige sequentielle Anteil ist. Das Resultat zeigt, dass die Ausführung der Aufgabe durch 2 robotische Systeme um den Faktor 1.6, relative zur Exekution durch einen einzelnen Roboter, beschleunigt werden kann.
+
+\begin{equation*}
+\begin{split}
+Speedup &= \frac{1}{f + \frac{1-f}{p}} \\
+&= \frac{1}{0.248 + \frac{1-0.248}{2}} \\
+&= 1.6
+\end{split}
+\label{eq:amdahl}
+\end{equation*}
+
+
 \subsection{Skalierbarkeit der Positionsanalyse}
-Die Analyse und Kalkulation valider Basispositionen nach dem in \autoref{sec:diffVoxel} beschriebenen Algorithmus ist abhängig von der Anzahl aller Kettenglieder und Teilketten der dokumentierten Aufgabenbeschreibung. Um die Skalierbarkeit zu evaluieren, wird die Kalkulationszeit der Operationskette, die Anzahl kalkulierter Basispositionen pro Roboter dokumentiert. 
+Die Analyse und Kalkulation valider Basispositionen nach dem in \autoref{sec:diffVoxel} beschriebenen Algorithmus ist abhängig von der Anzahl aller Kettenglieder und Teilketten der dokumentierten Aufgabenbeschreibung. Um die Skalierbarkeit zu evaluieren, wird die Kalkulationszeit der Operationskette und die Anzahl kalkulierter Basispositionen pro Roboter dokumentiert. \autoref{tab:posi} zeigt diese Messung, wobei in \texttt{eval1} zunächst 4 Kettenglieder gleichmäßig auf 2 Teilketten aufgeteilt sind, während in \texttt{eval2} und \texttt{eval3} 6 Kettenglieder auf 2 beziehungsweise 3 Teilketten verteilt werde. Dieses Verhältnis ist in der \texttt{Aufteilung der Kettenglieder} Spalte durch die /-Notation repräsentiert. Die Zeit bis zur Termination des Algorithmus ist in Spalte \texttt{Kalkulationszeit} erfasst, während eine Aufteilung der Basispositionen einer Teilkette in der \texttt{Lösungsmenge} Spalte ebenfalls in /-Notation dokumentiert sind..
 
-\begin{table}
+\begin{table}[h!]
 \begin{tabulary}{\textwidth}{@{}CCCCC@{}}
 \toprule
 \textbf{Name} & \textbf{Anzahl der Teilketten} & \textbf{Aufteilung der Kettenglieder} & \textbf{Kalkulationszeit} & \textbf{Lösungsmenge}
@@ -273,4 +315,29 @@ eval3 &
 \caption{Dokumentation erfasster Informationen einer Aufgabenbeschreibung}\label{tab:posi}
 \end{table}
 
-\autoref{tab:posi} ist zu entnehmen, dass die Anzahl der Kettenglieder die \texttt{Kalkulationszeit} beeinflusst, während sich deren Aufteilung auf die Teilketten beziehungsweise die robotischen Systeme auf das Lösungsspektrum auswirkt. Die Anzahl der Kettenglieder ist bei Aufgabenbeschreibung \texttt{eval2} und \texttt{eval3}identisch, wodurch die \texttt{Kalkulationszeit} ähnlich ist. Dies ist damit zu begründen, dass jedes Kettenglied anhand der \autoref{eq:28} eine Menge $P_{Base}$ generiert, dessen Inhalt in einer separaten Datenstruktur bezüglich der zugrundeliegenden Teilkette analysiert wird. Die Aufgaben \texttt{eval1} und \texttt{eval2} haben die gleiche Anzahl an Teilketten, wobei die \texttt{Lösungsmengen} unterscheiden. Dies ist implizit durch die 
\ No newline at end of file
+Dabei ist \autoref{tab:posi} zu entnehmen, dass die Anzahl der Kettenglieder die \texttt{Kalkulationszeit} beeinflusst, während sich deren Aufteilung auf die Teilketten beziehungsweise die robotischen Systeme auf das Lösungsspektrum auswirkt. Die Anzahl der Kettenglieder ist bei Aufgabenbeschreibung \texttt{eval2} und \texttt{eval3} identisch, wodurch die \texttt{Kalkulationszeit} ähnlich ist. Dies ist damit zu begründen, dass jedes Kettenglied anhand der \autoref{eq:28} eine Menge $P_{Base}$ generiert, deren Inhalt in einer separaten Datenstruktur bezüglich der zugrundeliegenden Teilkette analysiert wird. Der in \autoref{sec:diffVoxel} dokumentierte Algorithmus implementiert einen Filter, welcher alle Voxel nach der Herkunft seiner Basispositionen filtert. Die daraus resultierende Schnittmenge der Basispositionen einer Teilkette wird geringer, je mehr Kettenglieder sie besitzt. Dadurch haben die Aufgaben \texttt{eval1} und \texttt{eval2} zwar die gleiche Anzahl an Teilketten, jedoch sich die \texttt{Lösungsmengen} unterschiedlich, wenn eine Teilkette aus vielen Kettengliedern besteht.  
+
+\section{Qualitative Auswertung}
+Das Verhältnis terminierender Aufgaben ist nach Marvel et al. \cite{Marvel2018} ein Kriterium, um die Qualität eines Multi-Roboter Arbeitsraumes zu messen. \autoref{tab:eval1} zeigt, dass das Ausführen dieser Aufgabe von 2 robotischen Systemen in einem Verhältnis von 14 zu 15 erfolgreich terminiert. In 5 von 8 weiteren Testverfahren überwiegt die erfolgreiche Termination, wobei die Kalkulation für Teilketten, dessen Kettenglieder 0.5 bis 1 Meter voneinander distanziert sind, zufriedenstellende Basispositionen kalkuliert, während relativ nah definierte Kettenglieder invalide Basispositionen kalkulieren.\par
+Fehlerhafte Basispositionen sind: 
+
+\begin{enumerate}
+    \item Positionen zu nah am Primitv  \label{enumi:fehler1}
+    \item Basisposition zu nah aneinander \label{enumi:fehler2}
+\end{enumerate}
+
+Aus \autoref{enumi:fehler1} resultiert eine Kollision mit der Auflagefläche oder das exekutierende robotische System steht in Eigenkollision. \autoref{enumi:fehler2} resultiert aus Aufgabenbeschreibungen, deren Operationskette nur ein robotisches System benötigt. 
+%Die Auflösung des Algorithmus aus \autoref{sec:ground}, welcher valide Vektoren auf die XY-Ebene projiziert   
+
+\subsection{Vergleich mit verwandten wissenschaftlichen Arbeiten}
+Die Nachteile, welche das Verfahren der Voxelisierung aus \autoref{sec:voxel} gegenüber dem in dieser wissenschaftlichen Arbeit implementierten Algorithmus hat, wurden in \autoref{sec:diffVoxel} beschrieben, daher erfolgt die Betrachtung der Algorithmen zur Kalkulation valider Basispositionen, welche \autoref{sec:Verwandte} zu entnehmen sind.
+Diese definieren den Arbeitsraum eines Roboters anhand der Entfernung zur Basisposition. Vorteile aus dieser Betrachtung sind:
+
+\begin{enumerate}
+    \item weniger Komplexität \label{enumi:vorteil1}
+    \item vollständige Charakterisierung des Arbeitsraums \label{enumi:vorteil2}
+\end{enumerate}
+
+\autoref{enumi:vorteil1} bezieht sich auf die Komplexität der Kalkulation aus \autoref{eq:27}, welche die kinematischen Berechnungen der Arbeitsraumanalyse spezifiziert, als auch auf den Algorithmus zur Voxelisierung in \autoref{sec:diffVoxel}. Die Arbeitsraumanalyse ist zugleich die Grundlage aller späteren Berechnungen und impliziert \autoref{enumi:vorteil2}, denn eine resultierende mangelhafte reachability map mit wenigen Einträgen charakterisiert das Umfeld des robotischen Systems nicht vollständig, was die Lösungsmenge aller Basispositionen beeinflusst. Die von Forstenhausler et al. \cite{Forstenhausler} definierte Sphäre um den Roboter hat für alle Vektoren innerhalb der Sphäre eine Bewertung, außer der Vektor liegt im Bereich der Eigenkollision, wodurch ein größeres Lösungsspektrum entsteht.
+Nachteil dieser Betrachtung ist, dass diese Bewertung des Arbeitsraums ungenau ist, da die Erreichbarkeit eines Vektors in der Sphäre angenommen wird, statt diese zu messen. 
+
diff --git a/sections/fallbeispiel.tex b/sections/fallbeispiel.tex
index fa6badd926f8cdada5b123a8ddbc51f648098045..165ca6fb073c6b3b673f9a8611967794091e647c 100644
--- a/sections/fallbeispiel.tex
+++ b/sections/fallbeispiel.tex
@@ -1,8 +1,8 @@
 \chapter{Fallbeispiel}\label{ch:caseStudy}
-Inhalt dieses Kapitels ist die Demonstration der Funktionsweise einzelner Elemente der Implementierung und dessen Synergie mit \emph{MoveIt!} spezifischen Komponenten, sowie der Integration des franka\_ros Pakets \footnote{\url{http://wiki.ros.org/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. 
+Inhalt dieses Kapitels ist die Demonstration der Funktionsweise einzelner Elemente der Implementierung und dessen Synergie mit \emph{MoveIt!} spezifischen Komponenten, sowie der Integration des franka\_ros Pakets\footnote{\url{http://wiki.ros.org/franka_ros}} anhand eines Beispiels. Dieses Paket stellt hierbei sowohl die 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}
-\emph{MoveIt!} bietet über die \emph{move\_group} Schnittstelle eine Möglichkeit der Kommunikation mittels spezieller Nachrichten und somit der Planung und Exekution kinematischer Operationen durch den Roboter. Dies bedingt eine \emph{SRDF} Datei, 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. Wie \autoref{sec:Moveit} zu entnehmen ist, kann diese Konfigurationsdatei innerhalb eines ROS Pakets mit dem \emph{moveit setup assistant} aus einer validen Roboterbeschreibung generiert werden. Das resultierende Konfigurationspaket ist Ausgangspunkt aller operativen Aspekte des Fallbeispiels und daher sowohl für einen Roboter, als auch für mehrere robotische Systeme in der Implementierung enthalten. 
+\emph{MoveIt!} bietet über die \emph{move\_group} Schnittstelle eine Möglichkeit der Kommunikation mittels spezieller Nachrichten und somit der Planung und Exekution kinematischer Operationen durch den Roboter. Dies benötigt eine \emph{SRDF} Datei, 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. Wie \autoref{sec:Moveit} zu entnehmen ist, kann diese Konfigurationsdatei innerhalb eines ROS Pakets mit dem \emph{moveit setup assistant} aus einer validen Roboterbeschreibung generiert werden. Das resultierende Konfigurationspaket ist Ausgangspunkt aller operativen Aspekte des Fallbeispiels und daher sowohl für einen Roboter, als auch für mehrere robotische Systeme in der Implementierung enthalten. 
 
 \subsection{Modifikationen in der Beschreibung robotischer Systeme}
 \label{sec:Modifikationen}
@@ -13,7 +13,7 @@ Die Kalkulation valider Positionen für robotische Systeme erfordert die roboter
 
 \subsection{Aufgabenkonstruktion}
 \label{sec:Konstruktion}
-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 \emph{Support\_Surface}, welche dem robotischen System über spezifische Nachrichten kommuniziert wird und ohne dessen eine Exekution nicht erfolgt. Dieser redundante Aufwand wird im Algorithmus berücksichtigt und ist implizit durch die Position und Dimension des Primitives definiert. \autoref{fig:OPkette} illustriert eine Szene aus Kollisionsobjekten anhand des Beispiels in \autoref{fig:OK}. Die Aufgabe in Form einer Operationskette wird in \autoref{fig:OK1} mittels interaktiver Marker modelliert. \autoref{fig:OK2} zeigt die vollständig genierte Szene aus dem Primitiv und den Operationsoberflächen, auf denen es während des Vorgangs beispielsweise abgestellt oder von denen es gegriffen werden kann. 
+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 Auflagefläche \emph{Support\_Surface}, welche dem robotischen System über spezifische Nachrichten kommuniziert wird und ohne die eine Exekution nicht erfolgt. Dieser redundante Aufwand wird im Algorithmus berücksichtigt und ist implizit durch die Position und Dimension des Primitives definiert. \autoref{fig:OPkette} illustriert eine Szene aus Kollisionsobjekten anhand des Beispiels in \autoref{fig:OK}. Die Aufgabe in Form einer Operationskette wird in \autoref{fig:OK1} mittels interaktiver Marker modelliert. \autoref{fig:OK2} zeigt die vollständig generierte Szene bestehend aus dem Primitiv und den Auflageflächen, auf denen es während des Vorgangs beispielsweise abgestellt oder von denen es gegriffen werden kann. 
 
 \begin{figure}[h!]
 \ffigbox[\FBwidth]%
@@ -23,14 +23,13 @@ Die Aufgabenbeschreibung in Form einer Operationskette erfolgt über interaktive
       {\caption{Operationskette mit interaktiven Markern}\label{fig:OK1}}%
     \ffigbox[\FBwidth]%
       {\fbox{\includegraphics[width=0.47\textwidth, height = 6cm]{images/PS.png}}}%
-      {\caption{Generierte Primitive und Operationsoberflächen als Kollisionsobjekte} \label{fig:OK2}}
+      {\caption{Generierte Primitive und Auflageflächen als Kollisionsobjekte} \label{fig:OK2}}
   \end{subfloatrow}}
-  {\caption{Aufbau einer Szene mit Primitiven und Operationsoberflächen aus einer Aufgabenbeschreibung.}
+  {\caption[Generierung einer Szene]{Aufbau einer Szene mit Primitiven und Auflageflächen aus einer Aufgabenbeschreibung.}
 \label{fig:OPkette}}%
 \end{figure}
 
-
-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 Startglied, welcher durch seine Identität $id=0$ und der Farbe gekennzeichnet ist. Es ist stets möglich, ein weiteres Glied zu generieren, welches farblich und schriftlich gekennzeichnet ist. Dieser Vorgang wird in \autoref{fig:add} visualisiert.
+Ausgangspunkt einer Operationskette und dessen Teilketten ist das Startglied, welches durch seine Identität $id=0$ und der Farbe gekennzeichnet ist. Es ist stets möglich, ein weiteres Glied zu generieren, welches farblich und schriftlich gekennzeichnet ist. Dieser Vorgang wird in \autoref{fig:add} visualisiert.
 
 \begin{figure}[h!]
 \ffigbox[\FBwidth]%
@@ -40,13 +39,13 @@ Demzufolge ist beispielsweise eine Differenzierung der zu erzeugenden Kollisions
 			{\caption{Visualisierung der Option im Menü}}
     \ffigbox[\FBwidth]%
       {\fbox{\includegraphics[width=0.35\textwidth, height = 6cm]{images/nach_join.png}}}%
-			{\caption{Realisierung durch Generierung des blauen Glieds}}
+			{\caption{Generierung des blauen Glieds}}
   \end{subfloatrow}}
   {\caption{Generierung eines Kettenglieds}
 \label{fig:add}}%
 \end{figure}
 
-Die Schnittoption im Menü des Startknotens dupliziert diesen und ist ab einer Operationskette beziehungsweise Teilkette der Länge zwei möglich. Die Realisierung dieser Option wird in \autoref{fig:schnitt} veranschaulicht. Eine valide Aufgabenbeschreibung ist nur formulierbar und wird persistiert, wenn mindestens zwei Teilketten existieren die jeweils mindestens zwei Glieder 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. 
+Die Schnittoption im Menü des Startknotens dupliziert diesen und ist ab einer Operationskette beziehungsweise Teilkette der Länge zwei möglich. Die Realisierung dieser Option wird in \autoref{fig:schnitt} veranschaulicht. Eine valide Aufgabenbeschreibung ist nur formulierbar und wird persistiert, wenn mindestens zwei Teilketten existieren die jeweils mindestens zwei Glieder 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. 
 
 \begin{figure}[h!]
 \ffigbox[\FBwidth]%
@@ -62,7 +61,7 @@ Die Schnittoption im Menü des Startknotens dupliziert diesen und ist ab einer O
 \label{fig:schnitt}}%
 \end{figure}
 
-Anlog modifiziert die Kooperationsoption das jeweils letzte Glied der Operationskette beziehungsweise Teilkette und visualisiert diese Schnittmenge ebenfalls schriftlich und farblich, was \autoref{fig:koop} zeigt. Dies impliziert, dass eine Operationskette aus Schnitt- und Kooperationskomponenten bestehen kann, was für deren Anwendung auf $n \in \N_{>2}$ robotischen Systemen relevant ist.
+Anlog modifiziert die Kooperationsoption das jeweils letzte Glied der Operationskette beziehungsweise Teilkette und visualisiert diese Schnittmenge ebenfalls farblich, was \autoref{fig:koop} zeigt. Dies impliziert, dass eine Operationskette aus Schnitt- und Kooperationskomponenten bestehen kann, was für deren Anwendung auf $n \in \N_{>2}$ robotischen Systemen relevant ist.
 
 \begin{figure}[h!]
 \ffigbox[\FBwidth]%
@@ -74,7 +73,7 @@ Anlog modifiziert die Kooperationsoption das jeweils letzte Glied der Operations
       {\fbox{\includegraphics[width=0.35\textwidth, height = 6cm]{images/koop2.png}}}%
 			{\caption{Modifikation des letzten Kettenglieds als Startglied einer weiteren Teilkette}}
   \end{subfloatrow}}
-  {\caption{Realisierung eines kooperativen Glieds als Schnittmenge der ersten und zweiten Teilkette}
+  {\caption[Modellierung einer kooperativen Kette]{Realisierung eines kooperativen Glieds als Schnittmenge der ersten und zweiten Teilkette}
 \label{fig:koop}}%
 \end{figure}
 
@@ -91,7 +90,7 @@ Aufgabenbeschreibung:
 		- -0.625 0.957 0.173
 \end{lstlisting}
 
-Analog erfordert eine kooperative Aufgabenbeschreibung keine zusätzlichen Primitive, da diese beispielsweise an einer Stelle zwischen den robotisch Systemen übergeben werden. Diese Übergabeposition ist die Schnittmenge der definierten Teilketten und wird als solche in \autoref{lst:koop} durch ihre Wiederholung visualisiert.
+Analog erfordert eine kooperative Aufgabenbeschreibung keine zusätzlichen Primitive, da diese beispielsweise an einer Stelle zwischen den robotischen Systemen übergeben werden. Diese Übergabeposition ist die Schnittmenge der definierten Teilketten und wird als solche in \autoref{lst:koop} durch ihre Wiederholung visualisiert.
 
 \begin{lstlisting}[language=JSON,firstnumber=1, float, caption={Aufgabenbeschreibung einer zusammenhängenden Aufgabe},captionpos=t, label={lst:koop}]
 Name_der_Aufgabe: Kooperation
@@ -128,4 +127,4 @@ Basispositionen:
 \end{lstlisting}
 
 \section{Ausführung der Operationskette}
-Zur Ausführung der Operationskette ist ein weiterer Algorithmus implementiert, welcher die erforderlichen Modifikationen aus \autoref{sec:Modifikationen} anhand des \texttt{Basispositionen} Feldes einer Positionierungsdatei realisiert. Somit werden die Positionen der robotischen Systeme \texttt{panda\_arm1} und \texttt{panda\_arm2} für das Beispiel in \autoref{lst:Goalschnitt} aktualisiert, die Primitive und Operationsoberflächen nach \autoref{sec:Konstruktion} anhand der Kettenglieder innerhalb der \texttt{panda\_arm} Felder generiert. In der entstandenen Szene erfolgt anschließend die Exekution der Aufgabe.
\ No newline at end of file
+Zur Ausführung der Operationskette ist ein weiterer Algorithmus implementiert, welcher die erforderlichen Modifikationen aus \autoref{sec:Modifikationen} anhand des \texttt{Basispositionen} Feldes einer Positionierungsdatei realisiert. Somit werden die Positionen der robotischen Systeme \texttt{panda\_arm1} und \texttt{panda\_arm2} für das Beispiel in \autoref{lst:Goalschnitt} aktualisiert, die Primitive und Auflageflächen nach \autoref{sec:Konstruktion} anhand der Kettenglieder innerhalb der \texttt{panda\_arm} Felder generiert. In der entstandenen Szene erfolgt anschließend die Exekution der Aufgabe.
\ No newline at end of file
diff --git a/sections/grundlagen.tex b/sections/grundlagen.tex
index f578af521c579193fc794ed64ab61e2e226e2656..e758d7e00205aa3342cb2a1277d92f3e175b1ab9 100644
--- a/sections/grundlagen.tex
+++ b/sections/grundlagen.tex
@@ -37,8 +37,8 @@ Aus \autoref{eq:1} ist ersichtlich, dass die Elemente des Koordinatenursprungs v
 Eine Orientierung wird durch Rotationen $R$ dargestellt, die auf einen Körper angewendet werden können. Im Forschungsgebiet Robotik und der Computergrafik existieren verschiedene Ansätze zur mathematischen Beschreibung einer Rotation, welche sich konzeptuell unterscheiden. Beispielsweise kann eine Rotation durch Kompositionen aus Rotations-Matrizen oder der Anwendung komplexer Zahlen realisiert werden. Die spezielle RPY-Rotation\footnote{\url{https://de.wikipedia.org/w/index.php?title=Roll-Nick-Gier-Winkel&oldid=209197743}\label{RPY}}, welche auf den Rotationswinkeln eines Körpers hinsichtlich seiner Achsen basiert, wird in \autoref{fig:1} anhand eines Flugzeugs visualisiert und ist Bestandteil späterer Ausführungen.
 
 \begin{figure}[ht]
-\includegraphics[width = 4cm, height = 4cm]{images/RPY.png}
-\caption{Roll-Pitch-Yaw beziehungsweise Roll-, Nick- und Gier- Winkel an einem Flugzeug demonstriert.\footref{RPY}}
+\includegraphics[width = 5cm, height = 5cm]{images/RPY.png}
+\caption[RPY Rotation]{Roll-Pitch-Yaw beziehungsweise Roll-, Nick- und Gier- Winkel an einem Flugzeug demonstriert.\footref{RPY}}
 \label{fig:1}
 \end{figure}
 
@@ -120,7 +120,7 @@ Für die kinematische Kette eines robotischen Systems bestehenden aus $n \in \N$
 
 \begin{figure}[ht]
 \includegraphics[]{images/panda_chain.png}
-\caption{Visualisierung der kinematischen Kette eines Franka Emika 'Panda' Roboters anhand der Frames aller Festkörper.}
+\caption[Kinematische Kette des Franka Panda Roboters]{Visualisierung der kinematischen Kette eines Franka Emika 'Panda' Roboters anhand der Frames aller Festkörper.}
 \label{fig:PC}
 \end{figure}
 
@@ -139,7 +139,7 @@ Der Arbeitsbereich \emph{Workspace}, beschreibt die Kapazitäten eins robotische
       {\fbox{\includegraphics[width=0.47\textwidth, height =5.5cm]{images/panda_tv.png}}}%
       {\caption{Ansicht von oben}\label{fig:TV}}%
   \end{subfloatrow}}%
-  {\caption{Illustration des Arbeitsraums eines Panda Roboters der Franka Emika GmbH aus unterschiedlichen Perspektiven. Alle Angaben sind in Millimeter bemessen.}\label{fig:panda}}%
+  {\caption[Franka Panda Roboter aus mehreren Perspektiven]{Illustration des Arbeitsraums eines Panda Roboters der Franka Emika GmbH aus unterschiedlichen Perspektiven. Alle Angaben sind in Millimeter bemessen.}\label{fig:panda}}%
 
 \subsection{reachability map}
 Die reachability map ist eine Datenstruktur, welche die Erreichbarkeit eines Vektors $v$ anhand aller Orientierungen charakterisiert, die der Endeffektor einnehmen kann. Sie enthält eine Menge aus Tupeln, welche die Posen des Endeffektors sowie der Information bezüglich deren Erreichbarkeit in Form eines Wahrheitswertes spezifiziert. Diese Informationen können zusätzlich durch die Integration einer Metrik genutzt werden, um beispielsweise den Arbeitsbereich 3 dimensional darzustellen, oder mit den Posen weitere Berechnungen durchzuführen \cite{Zacharias2009}. Aufgrund des Aufbaus einer reachability map, eignet sich diese als Grundlage für spätere Verfahren und wird in dieser wissenschaftlichen Arbeit genutzt.
@@ -154,8 +154,8 @@ ROS \cite{Quigley} ist ein auf robotische Systeme spezialisiertes open-source Fr
 Während die textuelle Visualisierung primitiver Datentypen oder des Inhalts spezifischer Nachrichten über die Kommandozeile möglich sind, ermöglicht das \emph{publisher-subscriber} Prinzip die Implementierung separater Prozesse, welche Informationen anhand des Abonnierens einer topic visuell repräsentieren. Ein Beispiel hierfür ist \emph{RViz} als fester Bestandteil von ROS. RViz ist durch die Integration eigener Module erweiterbar und ermöglicht die 3 dimensionale Visualisierung von Frames, robotischer Systeme oder weiteren Objekten in Form von \emph{Meshes} \cite{Quigley}. \autoref{fig:RViz} zeigt eine leere Szene in RViz und dessen grafischer Benutzeroberfläche, wobei das dargestellte Gitters auf der horizontalen XY Ebene, dessen Kanten jeweils einen Meter voneinander distanziert sind, zur Orientierung innerhalb der Szene dient. 
 
 \begin{figure}[ht]
-\includegraphics[width = 7cm, height = 5cm]{images/RViz.png}
-\caption{Leere RViz Szene.}
+\includegraphics[width = 8cm, height = 7cm]{images/RViz.png}
+\caption{Leere RViz Szene}
 \label{fig:RViz}
 \end{figure}
 
@@ -187,7 +187,7 @@ Interaktive Marker erweitern die bereits präzisierten Marker um die Interaktion
       {\fbox{\includegraphics[width=0.47\textwidth, height =5.5cm]{images/IM2.png}}}%
       {\caption{Interaktiver Marker mit Kontrollelementen}}
   \end{subfloatrow}}%
-  {\caption{Darstellung eines interaktiven Markers mit visuellen Kontrollelementen und dessen Kommunikation mit der Server Instanz.}\label{fig:IM}}%
+  {\caption[Interaktive Marker und deren Server]{Darstellung eines interaktiven Markers mit visuellen Kontrollelementen und dessen Kommunikation mit der Server Instanz.}\label{fig:IM}}%
 \end{figure}
 
 \subsection{Kinematische Operationen in ROS}
diff --git a/sections/implementierung.tex b/sections/implementierung.tex
index 6ccc1f10dd06a7fa97fde5e79402161a7a084f0a..859f1a30a10bab250d37a8d743651ea601891d48 100644
--- a/sections/implementierung.tex
+++ b/sections/implementierung.tex
@@ -6,18 +6,24 @@ Die ausführliche Auseinandersetzung mit der Struktur des ROS spezifischen Arbei
 	\begin{tikzpicture} [ >=stealth']
 		\node[rectangle, draw=black,  thick, minimum height=3em, align=center] (RD) {Roboterbeschreibung};
 		\node[rectangle, draw=black,  thick, minimum height=3em, align=center] (DK) [above right = 1cm and 0.5cm of RD] {Dual Konfiguration};
-		\node[rectangle, draw=black,  thick, minimum height=3em, align=center] (MK) [below right = 1cm and 0.5cm of RD]{Mono Konfiguration};
+		\node[rectangle, draw=black,  thick, minimum height=3em, align=center] (MK) [below right = 1cm and 0.5cm of RD]{Single Konfiguration};
 		\node[rectangle, draw=black,  thick, minimum height=3em, align=center] (I) [right= 5cm of RD]{Implementierung};
 		
+		\node[rectangle, fill= white, draw=black,  thick, minimum height=1.5em, align=center] (qe) at (RD.south east)  {URDF};
+		\node[rectangle, fill= white, draw=black,  thick, minimum height=1.5em, align=center] (adsew) at (DK.south east)  {SRDF};
+		\node[rectangle, fill= white, draw=black,  thick, minimum height=1.5em, align=center] (wyxve) at (MK.south east)  {SRDF};
+
 		\draw[-] (RD) -- (DK) -- (I);
 		\draw[-] (RD) -- (MK) -- (I);
 
+
+
 	\end{tikzpicture}
-	\caption{Die Struktur des ROS Arbeitsraums ist durch dessen passive Pakete und aktive Pakete, sowie deren Beziehungen, illustriert. Diese Betrachtung partitioniert das Kapitel logisch in einen organisatorischen Teil, dessen Pakete die Prämisse des exekutiven Teils sind.} \label{fig:8}
+	\caption[ROS Pakete dieser Arbeit]{Die Struktur des ROS Arbeitsraums bestehend aus der Roboterbeschreibung mit URDF-Dateien und den MoveIt! Konfigurationspaketen mit SRDF-Dateien} \label{fig:8}
 \end{figure}
 
 \section{Robotische Systeme und deren Konfiguration}
-Die Roboterbeschreibung ist Grundlage der Generierung valider Konfigurationsdateien, welche jeweils $n \in \N_{>0}$ robotische Systeme konkretisieren und somit die Kommunikation zwischen den $n$ Robotern durch Integration der \emph{move\_group} Schnittstelle ermöglichen. Diese ist ein Klon des öffentlich zugänglichen Pakets \emph{franka\_ ros} \cite{franka_ros} der Franka Emika GmbH von August 2020, welches der Lehrstuhl für Softwaretechnologie bereitstellt. Die enthaltenen Dateien definieren einzelne Festkörpergruppen sowie deren Vereinigung zu $n$ Robotergruppen. Beispielsweise ist der Struktur aus \autoref{fig:9} zu entnehmen, dass ein Manipulator aus Hand und Arm besteht, sowie dass die Instanziierung mehrerer Manipulatoren eine zusätzliche Datei bedingt. \autoref{fig:9} rechts zeigt die Struktur einer Konfigurationsdatei, welche im \emph{config} Verzeichnis alle Festkörper der Referenzbeschreibung anhand der \emph{controller.yaml} Datei als Kontrollelemente spezifiziert und somit die Interaktion ermöglicht. Das Beispiel einer Modifizierten Roboterbeschreibung eines dualen Setup zeigt \autoref{lst:4}, aus dem das Muster zur Generierung einer $n$ Roboter Datei zu entnehmen ist, indem dessen Inhalt für alle Identitäten $n$ mal iteriert wird. Analog kann die entsprechende $n$\_ Konfigurationsdatei aus dem \emph{MSA} erzeugt werden oder mittels einer Manipulation der \emph{config} und \emph{.launch} Dateien aus \autoref{fig:9} generiert werden.
+Die Roboterbeschreibung ist Grundlage der Generierung valider MoveIt! Konfigurationspakete, welche jeweils $n \in \N_{>0}$ robotische Systeme konkretisieren und somit die Kommunikation zwischen den $n$ Robotern durch Integration der \emph{move\_group} Schnittstelle ermöglichen. Beispielsweise ist der Roboterbeschreibung aus \autoref{fig:9} links zu entnehmen, dass ein Manipulator aus Hand und Arm besteht, sowie dass die Instanziierung mehrerer Manipulatoren eine zusätzliche Datei benötigen. \autoref{fig:9} rechts zeigt das Konfigurationspaket, welches im \texttt{config} Verzeichnis die SRDF-Datei des robotischen Systems enthält. \autoref{lst:4} zeigt am Beispiel einer URDF-Datei für 2 robotische Systeme, welche Modifikationen aus \autoref{sec:Modifikationen} notwendig sind, um die Position des Roboters aus der Positionsdatei zu laden, dessen Struktur \autoref{lst:Goal} zu entnehmen ist.
 
 \begin{figure}
 \centering
@@ -29,67 +35,68 @@ Die Roboterbeschreibung ist Grundlage der Generierung valider Konfigurationsdate
 .2 robots.
 .3 'panda\_arm.xacro'.
 .3 'hand.xacro'.
-.3 'panda\_arm\_hand.xacro'.
-.3 'dual\_panda\_example.xacro'.
+.3 'panda\_arm\_hand.urdf.xacro'.
+.3 'dual\_panda\_example.urdf.xacro'.
 }
 \end{minipage}\hfill
 \begin{minipage}{.55\linewidth}
 \dirtree{%
 .1 MoveIt\_Konfiguration.
 .2 config.
-.3 'panda\_controller.yaml'.
-.3 'panda\_gripper\_controller.yaml'.
+.3 'panda.srdf'.
 .2 launch.
-.3 'move\_group.launch'.
-.3 'demo.launch'.
-.3 'planning\_context.launch'.
 }
 \end{minipage}\hfill
-\caption{Visualisierung der Verzeichnisstruktur der Roboterbeschreibung und Konfiguration. Bezüglich der Übersichtlichkeit sind nur die Dateien gelistet, deren Modifikation hinsichtlich der Realisierung mehrerer robotischer Systeme relevant ist.}\label{fig:9}
+\caption{Visualisierung der Verzeichnisstruktur von Roboterbeschreibung und Konfigurationspaketen}\label{fig:9}
 \end{figure}
 
-\begin{lstlisting}[language=JSON,firstnumber=1, float, caption={ Dual Setup Beispiel mit Modifikationen zur Übergabe der Roboterpositionen.}, label={lst:4}, captionpos=t]
-{<robot xmlns:xacro="http://www.ros.org/wiki/xacro" name="panda">
+\begin{lstlisting}[language=JSON,firstnumber=1, float, caption={Modifikationen in der URDF-Datei des robotischen Systems }, label={lst:4}, captionpos=t]
+<robot xmlns:xacro="http://www.ros.org/wiki/xacro" name="panda">
 <!-- Einbindung der Roboter Komponenten-->
 <xacro:include filename="panda_arm.xacro"/>
 <xacro:include filename="hand.xacro"/>
 
-<!-- Deklaration der Namensattribute zu konkretisierender Roboter -->
-<xacro:arg name="arm_id_1" default="panda_1" />
-<xacro:arg name="arm_id_2" default="panda_2" />
+<!-- Deklaration der Name der Positionsdatei -->
+<xacro:arg name="GOAL" default='Base_task'/>
 
-<!-- Deklarierung des Positionsattribute, welche aus der Kalkulation, ber die Konfigurationsdatei, in die Roboterbeschreibung bergeben wird-->
-<xacro:arg name="pos_1" default="0 0 0" />
-<xacro:arg name="pos_2" default="1 1 0" />
+<xacro:property name="yaml_file" value="$(find reachability)/Positionsanalyse/$(arg GOAL).yaml" />
+<xacro:property name="props" value="${load_yaml(yaml_file)}" />
+
+<!-- Laden der Positionen aus den Feldern der Datei-->
+<xacro:property name="pos_1" value="${props['Basispositionen']['panda_arm1']}" />
+<xacro:property name="pos_2" value="${props['Basispositionen']['panda_arm2']}" />
 
 <!-- Definition des eindeutigen World-Frames, als Referenz der Roboter -->
 <link name="world"/>
 
 <!-- Initialisierung der robotischen Systeme an ihrer spezifischen Position-->
-<xacro:panda_arm arm_id="$(arg arm_id_1)" connected_to="world"  xyz="$(arg pos_1)" /> 
+<xacro:panda_arm arm_id="$(arg arm_id_1)" connected_to="world"  xyz="${pos_1}" /> 
 <xacro:hand ns="$(arg arm_id_1)" rpy="0 0 ${-pi/4}" connected_to="$(arg arm_id_1)_link8" />
 
-<xacro:panda_arm arm_id="$(arg arm_id_2)" connected_to="world"  xyz="$(arg pos_2)" /> 
+<xacro:panda_arm arm_id="$(arg arm_id_2)" connected_to="world"  xyz="${pos_2}" /> 
 <xacro:hand ns="$(arg arm_id_2)" rpy="0 0 ${-pi/4}" connected_to="$(arg arm_id_2)_link8"/>
-<!-- Eine n-Roboterbeschreibung erfordert Namens- und Positions- Deklarationen sowie die Initialisierung aller n Manipulatoren -->  
-</robot>}
+</robot>$
 \end{lstlisting}
 
 
-\subsection{MoveGroup Interface mit Dual Setup}
-Eine Konfigurationsdatei konkretisiert ein robotisches System als Bewegungsgruppe \emph{Move\_Group}, deren Identität eindeutig durch ihr Namensattribut bestimmt ist. Demnach genügt dieses zur Instanziierung eines \emph{Move\_Group} Objekts, welches die Kommunikation zum gewählten Roboter initiiert. Eine duale Konfigurationsdatei ermöglicht analog das Instanziieren und Ansteuern zweier robotischer Systeme durch deren Namensattribut. 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 der Schnittstelle hinsichtlich der Betrachtung mehrerer robotischer Systeme limitiert sind. Der \autoref{lst:5} zeigt einen Ansatz, der die Kollisionsdetektion definierter Kollisionsobjekte in der \emph{allowed kollision matrix (AKM)} deaktiviert, was beispielsweise das Greifen, Halten und Abstellen eines Primitives in einem Dualen Setup ermöglicht. 
+\subsection{Move\_Group Schnittstelle für Multi-Roboter Arbeitsräume}
+Die SRDF-Datei des Konfigurationspakets konkretisiert ein robotisches System als Bewegungsgruppe \emph{Move\_Group}, deren Identität eindeutig durch ihr Namensattribut bestimmt ist. Demnach genügt dieses Attribut zur Instanziierung eines \emph{move\_group} Objekts, welches die Kommunikation zu dem spezifischen Roboter initiiert. Eine duales Konfigurationspaket ermöglicht analog das Instanziieren und Ansteuern zweier robotischer Systeme durch deren Namensattribute. Dabei ist eine Fehlfunktion dieser Instanzen während der Interaktion mit dem Primitiv einer Aufgabe observierbar. Der Versuch das Primitiv zu greifen, wird als Kollision detektiert, woraufhin die auszuführende Handlung fehlschlägt. Dies impliziert, dass die Funktionen hinsichtlich der Betrachtung mehrerer robotischer Systeme limitiert sind. Der \autoref{lst:5} zeigt einen Ansatz, welcher die Kollisionsdetektion definierter Kollisionsobjekte in der \emph{Allowed Kollision Matrix} (AKM) deaktiviert. Diese Modifikation ermöglicht das Greifen, Halten und Abstellen eines Primitives. 
+
 
+\begin{lstlisting}[language=AST,firstnumber=1, caption={Modifikation der Kollisionsmatrix}, label={lst:5}, float, captionpos=t]
+/*
+Des Endeffektors rechter und linker Finger kollidieren unweigerlich während der Exekution mit dem Primitiv, wodurch beispielsweise die Greifoperation fehlschlägt.
+*/
 
-\begin{lstlisting}[language=JSON,firstnumber=1, caption={Des Endeffektors rechter und linker Finger kollidieren unweigerlich während der Exekution mit dem Primitiv, wodurch beispielsweise die Greifoperation fehlschlägt. Der illustrierte Quelltext behebt diesen Fehler, indem derartige Kollisionen erlaubt werden.}, label={lst:5}, float, captionpos=t]
 // Initialisierung der Szene
 planning_scene::PlanningScene ps(kinematic_model);
 
-// Generierung der Bewegungsgruppen anhand der festgelegten Namensattribute innerhalb der dualen Konfigurationsdatei
+// Generierung der Bewegungsgruppen anhand der festgelegten Namensattribute innerhalb der SRDF
 std::vector<moveit::planning_interface::MoveGroupInterface>  robots;
 for(int i = 1; i <= 2; i++)
 	robots.push_back(std::move(moveit::planning_interface::MoveGroupInterface("panda_arm"+ std::to_string(i))))
 	
-// Modifikation der Kollisionsmatrix, welche die erlaubten Kollisionen der robotischen Systeme anhand deren Adjazenzen enthaelt 
+// Modifikation der Kollisionsmatrix, welche die erlaubten Kollisionen der robotischen Systeme anhand deren Adjazenzen enthält 
 collision_detection::AllowedCollisionMatrix acm = ps.getAllowedCollisionMatrix();
 
 for(int i = 1; i <= 2; i++){
@@ -104,49 +111,16 @@ pls.is_diff = true;
 planning_scene_diff_publisher.publish(pls);
 \end{lstlisting}
 
-
-\section{Implementierung zur Positionsermittlung}
-Die tatsächliche Implementierung ist Inhalt des Reach Pakets, dessen Struktur die \autoref{fig:10} illustriert. An dieser ist ersichtlich, dass die Artefakte aus den kinematischen Berechnungen, beispielsweise der Arbeitsraumanalyse oder deren Inversion, in den zugehörigen Ordnern persistiert werden, während anderweitig generierte Dateien, wie der Aufgabenbeschreibung und Positionsbeschreibung, an anderer Stelle vorliegen. Das RViz Verzeichnis beinhaltet alle Konfigurationen der spezifischen Nodes im RViz Kontext, dessen Resultate anhand visueller Nachrichten publiziert werden. Dies impliziert, dass relevante Aspekte eines Nodes jederzeit durch das RViz Programm transparent observiert werden können.
-
-\begin{figure}[h!]
-\centering
-\begin{minipage}{.55\linewidth}
-\dirtree{%
-.1 Reach.
-.2 include.
-.2 launch.
-.2 maps.
-.3 inverse.
-.3 reach.
-.2 rviz.
-.2 src.
-.2 task.
-.2 position.
-}
-\end{minipage}\hfill
-\caption{Visualisierung aller Komponenten des Reach Verzeichnisses und deren Beziehung untereinander.}\label{fig:10}
-\end{figure}
-
-
 \subsection{Implementierung der Arbeitsraumanalyse}
-Der (Quelltext.6) der Header Datei beschreibt alle Funktionen, die den Algorithmus der Arbeitsraumanalyse implementieren. Dazu sind gemäß der Erörterungen im 'Konzept' Kapitel, neben der kubischen Diskretisierung zusätzliche sphärische Diskretisierungen formuliert. Die Planung des Endeffektors zu einer generierten Endeffektor Pose erfolgt über das MoveGroup Interface, angewandt auf der Konfigurationsdatei eines einzelnen robotischen Systems. Dabei ist eine Implementierung für performante Rechner enthalten, die Anhand der Aufteilung der Menge $T$ in die jeweiligen Rechenkerne alle kinematischen Berechnungen $f_{kin}$ parallel operiert.
-
-
-%\lstinputlisting[language=C++, caption ={Implementierung zur Generierung der RM}, label={lst:6}, captionpos=b ]{./images/publisher\_node.h}
+\autoref{sec:Aanal} ist zu entnehmen, dass während der Arbeitsraumanalyse die Menge aller Positionen $P_{total}$ sowie deren Orientastionen $OR_{total}$ generiert werden, um diese als Grundlage der kinematischen Berechnungen zu nutzen. Dazu sind neben der kubischen Diskretisierung zusätzliche sphärische Diskretisierungen formuliert, unter anderem der von Deserno \autoref{Deserno2015} illustrierte Algorithmus zur gleichmäßigen sphärischen Diskretisierung. Eine Implementierung für performante Rechner ist wird durch Hilfsfunktionen implementiert, welche die Menge aller Endeffektor-Posen $T$ in $n \in \N>0$ Teilmengen spaltet. Diese disjunkten Teilmengen können parallel von $n$Thread bearbeitet werden.
 
 \subsection{Implementierung des Inversen Arbeitsraums}
-Der Algorithmus des inversen Arbeitsraums kalkuliert anhand der persistierten Informationen der Arbeitsraumanalyse die Metrik D. Die Inversion aller Transformationen anhand einer Iteration über den Arbeitsraum, erfolgt durch die in der Bibliothek \emph{tf2} implementierte Realisierung homogener Transformationen dessen Operationen $\in SE(3)$. Zusätzlich erfolgt die Portierung der Metrik und Persistenz der kalkulierten \emph{IRM}.
+Der Algorithmus des inversen Arbeitsraums kalkuliert anhand persistierter Informationen der Arbeitsraumanalyse die Bewertung einer Position, welche in \autoref{eq:18} dokumentiert ist. Die Inversion aller Transformationen anhand einer Iteration über die \emph{reachability map}, erfolgt durch die in der Bibliothek \emph{tf2}\footnote{\url{http://wiki.ros.org/tf2}} implementierte Realisierung homogener Transformationen und deren Operationen. Zusätzlich erfolgt die Portierung der Metrik und Persistenz der kalkulierten inverse reachability map.
 
-\subsection{Der Algorithmus zur Positionsanalyse}
-Die Implementierung der Positionsanalyse erfolgt über deren Voxelisierung durch Integration der PCL Bibliothek. Diese ist in C++ vollumfänglich implementiert und ermöglicht performante Operationen auf 3 dimensionale Koordinaten. Dies differenzierte Voxelisierung generiert zunächst ein Gitter aus Vektoren $^{0}v \in \R^{3}$ ähnlich der kubischen Diskretisierung, und bildet jede Transformation $^{0}T_{Base_{TK/KG}} \in ^{0}T_{Base}$ eines Teilkettenglieds der Operationskette $KG_{i}\in TK \subset K$ anhand seiner räumlichen Position auf den Vektor $^{0}v$ ab. Die resultierende Struktur ist in \autoref{eq:30} gezeigt.
+\section{Der Algorithmus zur Positionsanalyse}
+Die Implementierung der Positionsanalyse erfolgt über deren Voxelisierung durch Integration der PCL Bibliothek \footnote{\url{http://wiki.ros.org/pcl_ros}}. Diese ist in C++ vollumfänglich implementiert und ermöglicht performante Operationen auf 3-dimensionale Koordinaten. Wie \autoref{sec:diffVoxel} zu entnehmen ist, erfolgt zunächst eine Voxelisierung nach \autoref{sec:partitionierung} für jedes Kettenglied einer Teilkette durch das \texttt{Octree} Objekt der PCL Bibliothek. Alle kalkulierten Basispositionen $P_{Base}$ nach \autoref{eq:28} des betrachteten Kettenglied werden in dieses Objekt integriert, wodurch jede Position $p_{Base} \in P_{Base}$ einem Voxel zugeordnet wird. Anschließend erfolgt eine Abtastung anhand der \texttt{VoxelSearch()} Funktion, welche die enthaltenen Basispositionen $p_{Base}$ eines Voxels übergibt, sofern er abgetastet wird. \par
+Die Abtastung erfolgt anhand einer kubisch Diskretisierten Struktur, welche bezüglich des \texttt{Octree} Objektes eine identische Auflösung hat. Im Anschluss erfolgt eine Filter-Funktion auf dies Struktur, welche die Schnittmenge der Voxel pro Teilkette errechnet.
 
-\begin{equation}
-\begin{split}
-\label{eq:30}
-Task &= {(i, ^{0}T_{Base_{i}}) | g_{i} \in OK} \\
-Dictionary &= {(^{0}v, Task)}
-\end{split}
-\end{equation}
 
 Eine Teilkette $TK \subset K$ definiert nun anhand ihrer Glieder $g_{i}$ die Einträge, welche der Vektor $^{0}v$ mindestens enthalten muss, um eine potentielle Position des robotischen Systems zu sein, welche $TK$ operiert. Durch die Abbildung $D_{port}({0}T_{Base}) = D_{Reach}({0}T_{Base})$ ist analog die Struktur $Task_{Metrik}$ implementiert, welche die portierten Metriken aller Transformation $^{0}T_{Base_{i}}$ auf den Vektor $^{0}v$ abbildet.
 
diff --git a/sections/konzept.tex b/sections/konzept.tex
index 01af0e59feb675ce6da36d0c723e57db92c9c08e..7a5ffdd961bdfa5498ce0184810eb02d6904a982 100644
--- a/sections/konzept.tex
+++ b/sections/konzept.tex
@@ -1,40 +1,9 @@
 \chapter{Konzept zur Realisierung Multi-Roboter Arbeitsräume}\label{ch:concept}
 Wie im vorherigen Kapitel beschrieben, charakterisieren wissenschaftliche Arbeiten die Analyse des Arbeitsraums einzelner Roboter, sowie die Kenntnis bezüglich auszuführender Aufgaben als notwendige Voraussetzungen, um anhand dieser Informationen sukzessiv die optimale Position des Roboters zu bestimmen. Dieses Kapitel dokumentiert die konzeptuellen Entscheidungen bezüglich gewählten Verfahren dieser Bachelorarbeit, basierend auf den zuvor beschriebenen Methodiken zur Arbeitsraumanalyse, dessen Invertierung und anschließender Auswertung. Das Konzept zur Definition spezifischer Aufgaben, sowie deren intuitive Generierung und Darstellung mittels grafischer Programme ist ebenfalls dokumentiert und vervollständigt somit den Algorithmus zur Kalkulation valider Roboterbasen. Die grundlegende Struktur persistierter Daten im YAML Format sind ebenfalls Bestandteil des Kapitels. Anhand dieser Realisierung erfolgt eine Erweiterung der Erkenntnisse vorangegangener wissenschaftlicher Arbeiten um die Anwendung auf mehrere robotische Systeme sowie der Konkretisierung spezifischer Aufgaben. Diese Erweiterung ermöglicht die automatisiert Konstruktion kollaborative Multi-Roboter Arbeitsräume.
 
-\newcommand\pgfmathsinandcos[3]{%
-  \pgfmathsetmacro#1{sin(#3)}%
-  \pgfmathsetmacro#2{cos(#3)}%
-}
-\newcommand\LongitudePlane[3][current plane]{%
-  \pgfmathsinandcos\sinEl\cosEl{#2} % elevation
-  \pgfmathsinandcos\sint\cost{#3} % azimuth
-  \tikzset{#1/.style={cm={\cost,\sint*\sinEl,0,\cosEl,(0,0)}}}
-}
-\newcommand\LatitudePlane[3][current plane]{%
-  \pgfmathsinandcos\sinEl\cosEl{#2} % elevation
-  \pgfmathsinandcos\sint\cost{#3} % latitude
-  \pgfmathsetmacro\yshift{\cosEl*\sint}
-  \tikzset{#1/.style={cm={\cost,0,0,\cost*\sinEl,(0,\yshift)}}} %
-}
-\newcommand\DrawLongitudeCircle[2][1]{
-  \LongitudePlane{\angEl}{#2}
-  \tikzset{current plane/.prefix style={scale=#1}}
-   % angle of "visibility"
-  \pgfmathsetmacro\angVis{atan(sin(#2)*cos(\angEl)/sin(\angEl))} %
-  \draw[current plane] (\angVis:1) arc (\angVis:\angVis+180:1);
-  \draw[current plane,dashed] (\angVis-180:1) arc (\angVis-180:\angVis:1);
-}
-\newcommand\DrawLatitudeCircle[2][2]{
-  \LatitudePlane{\angEl}{#2}
-  \tikzset{current plane/.prefix style={scale=#1}}
-  \pgfmathsetmacro\sinVis{sin(#2)/cos(#2)*sin(\angEl)/cos(\angEl)}
-  % angle of "visibility"
-  \pgfmathsetmacro\angVis{asin(min(1,max(\sinVis,-1)))}
-  \draw[current plane] (\angVis:1) arc (\angVis:-\angVis-180:1);
-  \draw[current plane,dashed] (180-\angVis:1) arc (180-\angVis:\angVis:1);
-}
 
 \section{Arbeitsraumanalyse robotischer Systeme}
+\label{sec:Aanal}
 Das Generieren valider Transformationen $^{0}T_{Endeff}$, welche Resultat der Vereinigung aus $OR_{total}$ und $P_{total}$ sind, ist Bestandteil der Arbeitsraumanalyse. Dabei ist den Formulierungen zur Generierung aller Orientierungen $OR_{total}$ zu entnehmen, dass diese auf den Polarkoordinaten $^{0}s \in S^{2}$ einer Sphäre basieren, welche durch ihren Ursprung und Radius definiert ist. Der implementiere Algorithmus zur Ermittlung aller Transformationen $^{0}T_{Endeff}$ kombiniert diese Mengen, indem jeder Vektor $^{0}p \in P_{total}$ den Ursprung einer Sphäre darstellt, und demzufolge Ausgangspunkt der Kalkulation seiner Orientierungen ist. 
 
 \subsection{Erfassung der Orientierungen und Positionen}
@@ -125,19 +94,13 @@ Aus vorangegangenen Kapiteln ist bekannt, dass die sphärische Diskretisierung d
 
 \begin{figure}
 \centering
-\begin{tikzpicture} % "THE GLOBE" showcase
-\def\R{2.5} % sphere radius
-\def\angEl{35} % elevation angle
-\filldraw[ball color=white] (0,0) circle (\R);
-\foreach \t in {-80,-60,...,80} { \DrawLatitudeCircle[\R]{\t} }
-\foreach \t in {-5,-35,...,-175} { \DrawLongitudeCircle[\R]{\t} }
-\end{tikzpicture}
-\caption{Gitter aus nicht äquidistanten Vektoren einer sphärischen Diskretisierung. Die Distanz zwischen Vektoren an den Polen ist vernachlässigbar gering.}
+\includegraphics[width = 6cm, height = 6.5cm]{images/sphere.png}
+\caption[Sphärische ungleichmäßige Diskretisierung]{Gitter aus nicht äquidistanten Vektoren einer sphärischen Diskretisierung. Die Distanz zwischen Vektoren an den Polen ist vernachlässigbar gering.}
 \label{fig:7}
 \end{figure}
 
 \subsubsection{Gleichmäßige Verteilung}
-Methoden wie die Fibonacci- oder Spiral- Verteilungen bieten minimale Abweichungen, empfehlen sich daher für die Orientierungsgenerierung und bilden eine im Kontext dieser wissenschaftlichen Arbeit angemessene Repräsentation der Erreichbarkeit des Vektors $^{0}p_{Endeff}$. Sie gehören neben der ungleichmäßigen Diskretisierung zu den von Mikhal et al. angewendeten Methoden zur Arbeitsraumanalyse eines robotischen Systems \cite{Makhal2018}. Deserno \cite{Deserno2004} illustriert in seiner Arbeit zur äquidistanten sphärischen Diskretisierung einen Algorithmus zur gleichmäßigen Verteilung vor, welche bisher nicht zum Zweck der Roboterplatzierung genutzt wurde. Der dokumentierte Algorithmus wurde für diese wissenschaftliche Arbeit übernommen.
+Methoden wie die Fibonacci- oder Spiral- Verteilungen bieten minimale Abweichungen, empfehlen sich daher für die Orientierungsgenerierung und bilden eine im Kontext dieser wissenschaftlichen Arbeit angemessene Repräsentation der Erreichbarkeit des Vektors $^{0}p_{Endeff}$. Sie gehören neben der ungleichmäßigen Diskretisierung zu den von Mikhal et al. angewendeten Methoden zur Arbeitsraumanalyse eines robotischen Systems \cite{Makhal2018}. Die Deserno \cite{Deserno2004} illustrierte äquidistante sphärische Diskretisierung einen wurde bisher nicht zum Zweck der Roboterplatzierung genutzt wurde. Der dokumentierte Algorithmus wurde für diese wissenschaftliche Arbeit übernommen.
 
 \section{Invertierte Arbeitsräume}
 \label{sec:IA}
@@ -147,19 +110,19 @@ Eine persistierte reachability map beinhaltet eine Liste aller Vektoren $v \in P
 
 Die Roboterbasis kann der Pose des ersten Festkörpers in Form der Transformation $^{0}T_{Base}$ eines robotischen Systems entnommen werden, wie die Umformungen in \autoref{eq:28} sukzessiv zeigen. Zum besseren Verständnis erfolgt diese Berechnung für eine kinematische Kette aus $n = 8$ Gliedern. Dabei ist in diesem Beispiel die Transformation von $Frame_{0}$ zu $Frame_{1} = Frame_{Base}$ die Identität 1, da der Roboter keine Erhöhung durch einen Standfuß aufweist, sondern seine Basis $^{0}T_{Base}$ auf dem fixen $Frame_{0}$ des kinematischen Baumes liegt. Sollte dem nicht so sein, ist eine zusätzliche Berechnung erforderlich.
 
-\begin{equation*}
-\label{eq:28}
+\begin{equation}
 \begin{aligned}
 ^{0}T_{Base} &= t \times ^{0}T_{Endeff} \\
-^{0}T_{Base} &= t \times (\prescript{0}{}{T}_{1} \times \prescript{1}{}{T}_{2} \times \prescript{2}{}{T}_{3} \times \prescript{3}{}{T}_{4} \times \prescript{4}{}{T}_{5} \times \prescript{5}{}{T}_{6} \times \prescript{6}{}{T}_{7} \times \prescript{7}{}{T}_{Endeff}) &\text{\autoref{eq:6}} \\
-^{0}T_{Base} &= \prescript{0}{}{T}_{Endeff} \times (\prescript{0}{}{T}_{1} \times \prescript{1}{}{T}_{2} \times \prescript{2}{}{T}_{3} \times \prescript{3}{}{T}_{4} \times \prescript{4}{}{T}_{5} \times \prescript{5}{}{T}_{6} \times \prescript{6}{}{T}_{7} \times \prescript{7}{}{T}_{Endeff})^{-1} &\text{t = $\prescript{0}{}{T}_{Endeff}$}\\
-^{0}T_{Base} &= \prescript{0}{}{T}_{Endeff} \times (\prescript{Endeff}{}{T}_{7} \times \prescript{7}{}{T}_{6} \times \prescript{6}{}{T}_{5} \times \prescript{5}{}{T}_{4} \times \prescript{4}{}{T}_{3} \times \prescript{3}{}{T}_{2} \times \prescript{2}{}{T}_{1} \times \prescript{1}{}{T}_{0})  &\text{\autoref{eq:SE}}\\
-^{0}T_{Base} &= \prescript{0}{}{T}_{Endeff} \times (\prescript{Endeff}{}{T}_{7} \times \prescript{7}{}{T}_{6} \times \prescript{6}{}{T}_{5} \times \prescript{5}{}{T}_{4} \times \prescript{4}{}{T}_{3} \times \prescript{3}{}{T}_{2} \times \prescript{2}{}{T}_{Base} \times 1) &\text{\autoref{sec:IA}}\\
-^{0}T_{Base} &= \prescript{0}{}{T}_{Endeff} \times (\prescript{Endeff}{}{T}_{7} \times \prescript{7}{}{T}_{6} \times \prescript{6}{}{T}_{5} \times \prescript{5}{}{T}_{4} \times \prescript{4}{}{T}_{3} \times \prescript{3}{}{T}_{2} \times \prescript{2}{}{T}_{Base}) \\
-^{0}T_{Base} &= \prescript{0}{}{T}_{Endeff} \times ^{Endeff}T_{Base} &\text{\autoref{eq:5}} \\
-^{0}T_{Base} &= ^{0}T_{Base} &\text{\autoref{eq:5}}
+ &= t \times (\prescript{0}{}{T}_{1} \times \prescript{1}{}{T}_{2} \times \prescript{2}{}{T}_{3} \times \prescript{3}{}{T}_{4} \times \prescript{4}{}{T}_{5} \times \prescript{5}{}{T}_{6} \times \prescript{6}{}{T}_{7} \times \prescript{7}{}{T}_{Endeff}) &\text{\autoref{eq:6}} \\
+ &= \prescript{0}{}{T}_{Endeff} \times (\prescript{0}{}{T}_{1} \times \prescript{1}{}{T}_{2} \times \prescript{2}{}{T}_{3} \times \prescript{3}{}{T}_{4} \times \prescript{4}{}{T}_{5} \times \prescript{5}{}{T}_{6} \times \prescript{6}{}{T}_{7} \times \prescript{7}{}{T}_{Endeff})^{-1} &\text{t = $\prescript{0}{}{T}_{Endeff}$}\\
+ &= \prescript{0}{}{T}_{Endeff} \times (\prescript{Endeff}{}{T}_{7} \times \prescript{7}{}{T}_{6} \times \prescript{6}{}{T}_{5} \times \prescript{5}{}{T}_{4} \times \prescript{4}{}{T}_{3} \times \prescript{3}{}{T}_{2} \times \prescript{2}{}{T}_{1} \times \prescript{1}{}{T}_{0})  &\text{\autoref{eq:SE}}\\
+ &= \prescript{0}{}{T}_{Endeff} \times (\prescript{Endeff}{}{T}_{7} \times \prescript{7}{}{T}_{6} \times \prescript{6}{}{T}_{5} \times \prescript{5}{}{T}_{4} \times \prescript{4}{}{T}_{3} \times \prescript{3}{}{T}_{2} \times \prescript{2}{}{T}_{Base} \times 1) &\text{\autoref{sec:IA}}\\
+ &= \prescript{0}{}{T}_{Endeff} \times (\prescript{Endeff}{}{T}_{7} \times \prescript{7}{}{T}_{6} \times \prescript{6}{}{T}_{5} \times \prescript{5}{}{T}_{4} \times \prescript{4}{}{T}_{3} \times \prescript{3}{}{T}_{2} \times \prescript{2}{}{T}_{Base}) \\
+ &= \prescript{0}{}{T}_{Endeff} \times ^{Endeff}T_{Base} &\text{\autoref{eq:5}} \\
+ &= ^{0}T_{Base} &\text{\autoref{eq:5}}
 \end{aligned}
-\end{equation*}
+\label{eq:28}
+\end{equation}
  
 Dazu wird die Menge $IRM$ aus \autoref{eq:19} in eine YAML Datei persistiert, dessen Struktur der \autoref{lst:2} schematisch zeigt, wobei die Felder \texttt{Basis\_Pose} und \texttt{Metrik} aus der zugrundeliegenden reachability map kalkuliert werden. Die Felder \texttt{Referenzsystem}, \texttt{Aufloesung} und \texttt{Intervall} werden aus der reachability map übernommen, und bilden analog den Namen \texttt{Map\_Name} der Datei. \texttt{Zeit} dokumentiert die Zeit zur Kalkulation aller Posen $^{Endeff}T_{0}$. 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.
 
diff --git a/sections/sota.tex b/sections/sota.tex
index 22ef41c9413414b96c368d3cee26815044aa78f2..ef0708da2e63dae01076c9d44ad6b4a130d859d6 100644
--- a/sections/sota.tex
+++ b/sections/sota.tex
@@ -9,7 +9,7 @@ Den Anforderungen aus \autoref{sec:anforderungen} ist zu entnehmen, dass die Pla
 		\node[rounded corners, draw=black,  thick, minimum height=3em, align=center, on chain, join=by {->}, right = of RM] (IRM) {Arbeitsrauminversion};
 		\node[rounded corners, draw=black,  thick, minimum height=3em, align=center, on chain, join=by {->}, right = of IRM] (Base) {Positionsanalyse};
 	\end{tikzpicture}
-	\caption{Darstellung des Algorithmus zur sukzessiven Ermittlung einer Roboterposition. Die Kommunikation zwischen den Etappen erfolgt mittels Persistenz der Teilergebnisse.
+	\caption[Algorithmus zur Ermittlung einer Roboterposition]{Darstellung des Algorithmus zur sukzessiven Ermittlung einer Roboterposition. Die Kommunikation zwischen den Etappen erfolgt mittels Persistenz der Teilergebnisse.
 } \label{fig:4}
 \end{figure}
 
@@ -45,7 +45,7 @@ RM:= \{(t , f_{kin}(t)) | t \in T \}
       {\fbox{\includegraphics[width=0.47\textwidth, height =5.5cm]{images/OR_total.png}}}%
       {\caption{Menge aller Orientierungen $\protect OR_{total}$} \label{fig:OR}}
   \end{subfloatrow}}%
-  {\caption{ Darstellung der Mengen $\protect P_{total}$ und $\protect OR_{total}$. Ein roter Marker repräsentiert den Vektoren, den der Endeffektor einnimmt. Ein grüner Pfeil zeigt in die Richtung des Endeffektors.}
+  {\caption[Darstellung der Orientierungen und Positionen]{ Darstellung der Mengen $\protect P_{total}$ und $\protect OR_{total}$. Ein roter Marker repräsentiert den Vektoren, den der Endeffektor einnimmt. Ein grüner Pfeil zeigt in die Richtung des Endeffektors.}
 \label{fig:5}}%
 \end{figure}
 
@@ -115,7 +115,7 @@ Die Menge $^{0}OR_{total}$ beschreibt alle möglichen Orientierungen, die für j
 		\pic [draw = blue,fill=blue!50,fill opacity=.5, text=orange] {angle = x--origin--phi};
 		\pic [draw = orange,fill=orange!50,fill opacity=.5, text=orange] {angle = s--origin--z};
 	\end{tikzpicture}
-	\caption{Visualisierung der Winkel Azimut (blau) $\protect \theta$ und Colatitude (orange) $\protect \phi$, dabei ist $\protect \overline{sp}$ die Strecke zwischen Zentrum p und einer Koordinate $\protect s \in S^{2}$ auf der Sphäre.}\label{fig:6}
+	\caption[Visualisierung von Polarkoordinaten]{Visualisierung der Winkel Azimut (blau) $\protect \theta$ und Colatitude (orange) $\protect \phi$, dabei ist $\protect \overline{sp}$ die Strecke zwischen Zentrum p und einer Koordinate $\protect s \in S^{2}$ auf der Sphäre.}\label{fig:6}
 \end{figure}
 
 \begin{equation}
@@ -141,7 +141,8 @@ Das Abtasten der Winkelintervalle von $\theta$ und $\phi$ hinsichtlich fester Au
 \end{equation}
 
 \subsubsection{gleichmäßige sphärische Diskretisierung}
-Die äquidistante Verteilung einer festen Zahl $n \in \N$ Vektoren auf einer Sphäre ist ein mathematisches Problem, dessen Lösung eine umfassende Bedeutung für Forschungsfelder der Biologie, Chemie und Physik aufweist. Beispielsweise basieren das Tammes Problem oder hard-spheres Problem auf dieser Problemstellung, bezogen auf der Modellierung fluider Partikel \cite{Saff1997}. Algorithmen zu diesem Kontext approximieren dieses Ziel, wobei die Distanzen auf der Sphäre  minimalen Abweichungen unterliegen und in Spezialfällen die Anforderung einer äquidistanten Verteilung erfüllen. Die Kardinalität $\vert S^{2} \vert$ ist analog zu \autoref{eq:kadi} durch $n$ gegeben.
+Die äquidistante Verteilung einer festen Zahl $n \in \N$ Vektoren auf einer Sphäre ist ein mathematisches Problem, dessen Lösung eine umfassende Bedeutung für Forschungsfelder der Biologie, Chemie und Physik aufweist. Beispielsweise basieren das Tammes Problem oder hard-spheres Problem auf dieser Problemstellung, bezogen auf der Modellierung fluider Partikel \cite{Saff1997}. Algorithmen zu diesem Kontext approximieren dieses Ziel, wobei die Distanzen auf der Sphäre minimalen Abweichungen unterliegen und in Spezialfällen die Anforderung einer äquidistanten Verteilung erfüllen. Beispielsweise illustriert Deserno \cite{Deserno2004} in seiner Arbeit zur äquidistanten sphärischen Diskretisierung einen Algorithmus zur gleichmäßigen Verteilung von sphärischen Vektoren. 
+Die Kardinalität $\vert S^{2} \vert$ ist analog zu \autoref{eq:kadi} durch $n$ gegeben.
 
 \subsection{Arbeitsraumcharakterisierung}
 \autoref{eq:18} formuliert die Erreichbarkeitsmetrik $D_{Reach}$ zur Bewertung der Erreichbarkeit eines Vektors $^{0}v_{Endeff}$ durch den Endeffektor. Hierzu erfolgt eine Gegenüberstellung der Menge $OR_{v}$ aller Orientierungen $R$, die der Endeffektor für den Vektor $^{0}v_{Endeff}$ während der Berechnungen erfolgreich einnehmen kann, gegenüber der Menge $OR_{total}$ aller generierten und bearbeiteten Orientierungen für $^{0}v_{Endeff}$ \cite{Porges2015}. Demnach impliziert ein geringer Wert $D_{Reach}$ für einen Vektor, dass dieser vom Koordinatenursprung des Frames $Frame_{0}$ weniger erreichbar ist als ein Vektor mit höherer Bewertung.  
@@ -160,7 +161,7 @@ D_{Reach}(v) &= \frac{\vert OR_{v} \vert}{\vert OR_{total} \vert}
 \end{equation}
 
 \section{Arbeitsrauminversion}
-Der invertierte Arbeitsraum beschreibt nach Vahrenkamp et al. alle Posen relativ zum Endeffektor, sphärisch um den Ursprung des $Frame_{0}$ verteilt, von denen aus das robotische System den Ursprung Frames erreicht \cite{Vahrenkamp2013}. Dazu beschreibt dieser Prozess die Invertierung aller persistierten Transformationen $^{0}T_{Endeff}$ der $reachability map$ und Portierung der zugehörigen Metrik $D_{Reach}(^{0}v_{Endeff})$. Die resultierende Menge enthält nach \autoref{eq:5} Transformationen der Form $^{Endeff}T_{0}$, welche dessen Basispose beschreiben. Diese Informationen werden als \emph{inverse reachability map (IRM)} persistiert, welche durch die \autoref{eq:19} definiert ist. 
+Der invertierte Arbeitsraum beschreibt nach Vahrenkamp et al. alle Posen relativ zum Endeffektor, sphärisch um den Ursprung des $Frame_{0}$ verteilt, von denen aus das robotische System den Ursprung Frames erreicht \cite{Vahrenkamp2013}. Dazu beschreibt dieser Prozess die Invertierung aller persistierten Transformationen $^{0}T_{Endeff}$ der $reachability map$ und Portierung der zugehörigen Metrik $D_{Reach}(^{0}v_{Endeff})$. Die resultierende Menge enthält nach \autoref{eq:5} Transformationen der Form $^{Endeff}T_{0}$, welche dessen Basispose beschreiben. Diese Informationen werden als \emph{inverse reachability map} (IRM) persistiert, welche durch die \autoref{eq:19} definiert ist. 
 
 \begin{equation}
 \label{eq:19}
@@ -181,6 +182,7 @@ P_{Base} &:= \{(t \times T, d) | (T, d) \in IRM , t \subset A \} \\
 \end{equation}
 
 \subsection{Charakterisierung eines Voxels}
+\label{sec:voxel}
 Makhal et al. \cite{Makhal2018} beschreibt einen Algorithmus, welcher alle $k$ Voxel charakterisiert und anhand deren Vektoren $^{0}p_{Base} \in TP$ bestimmt, welches Voxel sich bevorzugt für die Platzierung des robotischen Systems eignet. Dies erfolgt durch eine weitere Metrik $D_{voxel}$ in \autoref{eq:22}, die sich aus dem arithmetischen Mittel  $D_{Reach}^{mittel}$ eines Voxels und dem Verhältnis von dessen Kardinalität zum maximalen Voxel $TP_{max}$ ergibt. $TP_{max}$ ist das Resultat einer Iteration über alle $k$ Voxel, welche im Anschluss an die Voxelisierung erfolgt. Demnach lässt ein Voxel mit hoher Kardinalität darauf schließen, dass Posen verschiedener Aufgaben von ihm erreichbar sind.
 
 \begin{equation}
@@ -196,15 +198,17 @@ Die Metrik $D_{voxel}$ bewertet demnach ein Voxel anhand dessen Inhalts und Kard
 
 \begin{equation}
 \begin{split}
-\label{eq:21}
 D_{voxel}^{mittel}:V & \to [0,1] \\
 D_{voxel}^{mittel}(TP)&= \frac{\displaystyle\sum_{i=0}^{\vert TP \vert } D_{Reach}(p_{i})}{\vert TP \vert}
 \end{split}
+\label{eq:21}
 \end{equation}
 
 \section{Verwandte wissenschaftliche Arbeiten}
-Forstenhausler et al. \cite{Forstenhausler} dokumentieren in deren Publikation eine Methodik zur Kalkulation der Basisposition eines robotisch Systems anhand einer Aufgabe, ohne den schematisch illustrierten Algorithmus in \autoref{fig:4} zu nutzen. Der betrachtete Ansatz basiert auf der Spaltung des Arbeitsraums in verschiedene Dimensionen, ähnlich der in \autoref{fig:panda} dargestellten Perspektiven. Diese definieren einen sphärischen Körper um den Roboter, welche seinen welcher den Arbeitsraum anhand der Distanz charakterisiert. Eigenkollisionen treten häufiger auf, je näher die definierte Aufgabe an der Basis des robotischen Systems ist. Diese Erkenntnis wird durch eine zweite Sphäre integriert, die diesen fehleranfälligen Bereich aus dem tatsächlich Arbeitsraum entfernt. Sofern eine Aufgabe definiert ist, werden diese Sphären auf die Aufgabenpositionen projiziert. Die Kalkulation der Roboterbasis erfolgt anhand eines Algorithmus, welcher den Arbeitsraum des Roboters verschiebt, bis die Ausgabenpositionen in der vom Arbeitsraum definierten Sphäre liegen. \par
-Tao et al. \cite{Tao} zeigt in seiner wissenschaftlichen Arbeit einen ähnlichen Ansatz, welcher den Arbeitsraum eins Roboters analog zu \autoref{Forstenhausler} anhand von Sphären beschreibt. In seinem Beispiel besteht der 
+\autoref{sec:Verwandte}
+Tao \cite{Tao} zeigt in seiner wissenschaftlichen Arbeit eine Methodik zur Kalkulation der Basisposition eines robotisch Systems anhand einer Aufgabe, ohne den schematisch illustrierten Algorithmus in \autoref{fig:4} zu nutzen. Diese basiert auf der Spaltung des Arbeitsraums in verschiedene Dimensionen, ähnlich der in \autoref{fig:panda} dargestellten Perspektiven und definieren ihn als sphärischen Körper im Umfeld des robotischen Systems. Eigenkollisionen treten häufiger auf, je näher die Aufgabe an der Basis des Roboters definiert ist, dies impliziert die Notwendigkeit einer zweiten Sphäre, die diesen fehleranfälligen Bereich aus dem tatsächlich Arbeitsraum entfernt. Das Referenzsystem seines Beispiels ist ein aus zwei Festkörpern bestehender Roboterarm, wobei der innerer Radius bis zum zweiten Festkörper definiert ist, während der äußere Radius die Gesamtlänge des Roboterarms beträgt. In diesem Multi-Roboter Arbeitsraum besteht die Aufgabe darin, einen zylinderförmigen Tank zu bearbeiten, wobei über dessen Rotationsachse und Radius die Positionen der Roboter ermittelt wird. \par
+Forstenhausler et al. \cite{Forstenhausler} dokumentiert in seiner Publikation einen Algorithmus zur Generierung valider Roboter Positionen, welcher analog zu \cite{Tao} den Arbeitsraum des Roboters durch Sphären repräsentiert. Diese implementieren ein Feld, indem ein Vektor innerhalb der Sphäre anhand seiner Distanz zum Zentrum charakterisiert wird. Die Aufgabe ist anhand von Aufgabenpositionen definiert, welche das robotische System erreichen muss. Die Kalkulation der Roboterbasis erfolgt anhand eines Algorithmus, welcher den Arbeitsraum des Roboters verschiebt, bis die Aufgabenpositionen in der vom Arbeitsraum definierten Sphäre liegen. 
+
 
 
 
diff --git a/sections/zusammenfassung.tex b/sections/zusammenfassung.tex
index b735b66bd3680347816e7ab61f38fa09a079da2f..83e1647683481c0eca02b531f451eb06659e2f38 100644
--- a/sections/zusammenfassung.tex
+++ b/sections/zusammenfassung.tex
@@ -1,3 +1,4 @@
 \chapter{Zusammenfassung und Ausblick}\label{ch:conclusion}
-
-\blindtext
+In dieser wissenschaftlichen Arbeit zur automatischen Konstruktion eines Multi-Roboter Arbeitsraums wurde die Software \emph{MoveIt!} innerhalb von ROS verwendet. Hauptaspekt ist die Kalkulation robotischer Basispositionen, um anhand dieser die Roboter zu platzieren, welche eine \emph{pick and place} Aufgabe realisieren sollen. Die auszuführende Aufgabe wird mittels interaktiver Marker im \emph{RViz} Prozess modelliert. Die daraus resultierenden Aufgabenbeschreibung dokumentiert die Reihenfolge und Position, an der ein Objekt gegriffen beziehungsweise abgestellt werden soll und welcher Roboter diese Aktionen ausführt.\par
+Anhand der Auseinandersetzung mit bekannten Verfahren zur Kalkulation valider Roboterbasen durch Aufgabenbeschreibungen, wurde ein Konzept erarbeitet, welches die dazu notwendigen Algorithmen sukzessiv beschreibt. Zunächst erfolgt die Arbeitsraumanalyse, welche das Umfeld eines Roboters abtastet und daraus Informationen bezüglich der Erreichbarkeit in eine \emph{reachability map} persistiert. Diese Informationen werden im folgenden Prozess der Arbeitsrauminversion ausgewertet, bearbeitet und ebenfalls als Datenstruktur persistiert. Abschließend werden diese Informationen mit der Aufgabenbeschreibung kombiniert, was für jede definierte Aufgabenposition eine Basismenge generiert. Die Basismenge wird anhand der konkretisierten Reihenfolge analysiert und auf die XY-Ebene projiziert, wodurch jedem Roboter eine Basisposition und Sequenz zugeteilt wird, welche er schlussendlich exekutiert, womit der Multi-Roboter Arbeitsraum automatisch konstruiert wurde.\par 
+Zusammenfassend realisiert der beschriebene Algorithmus die automatische Positionierung robotischer Systeme für konkretisierte Aufgaben, wobei diese bei zu nah definierten Greif- und Abstellpositionen weniger zufriedenstellende Ergebnisse erzielen. Multi-Roboter Arbeitsräume profitieren von der Agilität und der Möglichkeit, Aufgaben parallel auszuführen. Eine hohe Variabilität der ausführbaren Aufgaben ist beispielsweise durch die Verschiebung und Anordnung der Tische gegeben. Durch Parallelität kann die Zeit zur Exekution einer Aufgabe auf ihren sequentiellen Anteil reduziert werden, was in der Industrie in eine erhöhte Produktion resultiert. Jedoch ist die Integration eines Multi-Roboter Arbeitsraums hinfällig, wenn dieser mehr Zeit zur Exekution einer Aufgabe benötigt, als ein einzelnes robotisches System. Daher ist weitere Entwicklung an der open-source Software \emph{MoveIt!} erforderlich, um Parallelität zu gewährleisten und somit das Potential der Mulit-Roboter Arbeitsräume für die Öffentlichkeit zu erweitern. Dies würde einen großen Beitrag zum Forschungsgebiet der Robotik beitragen.    
\ No newline at end of file
diff --git a/thesis.tex b/thesis.tex
index f0406c47891f58f594f6b5485eadf45c4cd41d2c..775e660a5ff23f50c02e196c4c59d98c18e3d8ee 100644
--- a/thesis.tex
+++ b/thesis.tex
@@ -154,6 +154,7 @@
 \tableofcontents
 \listoffigures
 \listoftables
+\lstlistoflistings
 
 \input{sections/einleitung}
 \input{sections/grundlagen.tex}
@@ -162,7 +163,7 @@
 \input{sections/fallbeispiel.tex}
 \input{sections/implementierung.tex}
 \input{sections/evaluation.tex}
-% \input{sections/zusammenfassung.tex}
+\input{sections/zusammenfassung.tex}
 
 \nocite{*}
 \printbibliography[heading=bibintoc]\label{sec:bibliography}%