diff --git a/lst.tex b/lst.tex
index e3371c070bc589de8432db6526c97cdecfd7109c..e329da3814c5af3db77af2bf55ef99b268f7ffac 100644
--- a/lst.tex
+++ b/lst.tex
@@ -2,24 +2,24 @@
 \usepackage{inconsolata}
 
 \lstdefinestyle{common-style}{
-  basicstyle=\scriptsize\ttfamily,  % the size of the fonts that are used for the code
-  showspaces=false,                   % show spaces adding particular underscores
-  showstringspaces=false,             % underline spaces within strings
-  showtabs=false,                     % show tabs within strings adding particular underscores
-%  frame=tlrb,                         % adds a frame around the code
-  framexleftmargin=1em,               % space between left part of frame and listing
-  tabsize=2,                          % sets default tabsize to 2 spaces
-  breaklines=true,                    % sets automatic line breaking
-  breakatwhitespace=true,             % sets if automatic breaks should only happen at whitespace
+	basicstyle=\ttfamily,
+	morecomment=[s]{<!--}{-->},
+	commentstyle={\color{gray}},  
+	numbers=left,
+	numberstyle=\ttfamily,
+	stepnumber=1,
+	numbersep=5pt,
+	xleftmargin=2em,
+	framexleftmargin=2em,
+	showstringspaces=false,
+	breaklines=true,
+	frame=lines,
+	backgroundcolor=\color{background},
+	autogobble=true,
   keywordstyle={\color{blue}\textbf}, % keywords are blue
   commentstyle={\color{gray}},        % comments
-  literate={\$}{{{\$}}}1,
-  basewidth=0.5em,
-  breakindent=40pt,
-  breakautoindent=true,
-  escapechar=\&,
   aboveskip={0.1\baselineskip}
-	}
+}
 
 \colorlet{punct}{red!60!black}
 \definecolor{background}{HTML}{EEEEEE}
@@ -45,21 +45,10 @@
 	morecomment=[l]{//}, morecomment=[s]{/*}{*/},
 }
 
-\lstdefinelanguage{json}{
-    basicstyle=\ttfamily,
-    numbers=left,
-    numberstyle=\ttfamily,
-		numbersep=5pt,
-		xleftmargin=2em,
-		framexleftmargin=2em,
-    stepnumber=1,
-    numbersep=8pt,
-    showstringspaces=false,
-    breaklines=true,
-    frame=lines,
-    backgroundcolor=\color{background},
-		autogobble=true,
-    literate=
+\lstdefinelanguage{JSON}{
+	style=common-style,
+	morecomment=[s]{<!--}{-->},
+	literate=
      *{0}{{{\color{numb}0}}}{1}
       {1}{{{\color{numb}1}}}{1}
       {2}{{{\color{numb}2}}}{1}
@@ -78,7 +67,6 @@
       {]}{{{\color{delim}{]}}}}{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},
@@ -98,6 +86,7 @@
 \lstdefinestyle{AST} { language=AST,style=common-style } 
 \lstdefinestyle{JRAG} { language=JRAG,style=common-style }
 \lstdefinestyle{Java} { language=Java,style=common-style }
+\lstdefinestyle{JSON} { language=JSON,style=common-style }
 
 
 \lstset{
diff --git a/sections/implementierung.tex b/sections/implementierung.tex
index f116b3f46c4b9e3e79bba8b99d444300b5642b68..d8ee3c39e5e47c1bd742deb985819ee369f179a2 100644
--- a/sections/implementierung.tex
+++ b/sections/implementierung.tex
@@ -17,38 +17,11 @@ Die ausführliche Auseinandersetzung mit der Struktur des ROS spezifischen Arbei
 \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 MoveGroup Schnittstelle ermöglichen. Diese ist ein Klon des öffentlich zugänglichen Pakets 'franka\_ ros' \cite{franka_ros} der Franka Emika GmbH zum 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} b zeigt die Struktur einer Konfigurationsdatei, welche im 'config' Verzeichnis alle Festkörper der Referenzbeschreibung anhand der '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 MSA erzeugt, oder mittels einer Manipulation der 'config' und 'launch' Dateien aus \autoref{fig:9} generiert werden.
+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 MoveGroup Schnittstelle ermöglichen. Diese ist ein Klon des öffentlich zugänglichen Pakets 'franka\_ ros' \cite{franka_ros} der Franka Emika GmbH zum 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  zu entnehmen, dass ein Manipulator aus Hand und Arm besteht, sowie dass die Instanziierung mehrerer Manipulatoren eine zusätzliche Datei bedingt.  b zeigt die Struktur einer Konfigurationsdatei, welche im 'config' Verzeichnis alle Festkörper der Referenzbeschreibung anhand der '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 MSA erzeugt, oder mittels einer Manipulation der 'config' und 'launch' Dateien aus  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 in Hinsichtlich der Realisierung mehrerer robotischer Systeme relevant ist.}\label{fig:9}
-\end{figure}
 
-\begin{lstlisting}[language=json,firstnumber=1, caption={ Dual Setup Beispiel, in mit Modifikationen zur Übergabe der Roboterpositionen.}, label={lst:4}, captionpos=b]
+\begin{lstlisting}[language=JSON,firstnumber=1, caption={ Dual Setup Beispiel, in mit Modifikationen zur Übergabe der Roboterpositionen.}, label={lst:4}, captionpos=b]
 {<robot xmlns:xacro="http://www.ros.org/wiki/xacro" name="panda">
 <!-- Einbindung der Roboter Komponenten-->
 <xacro:include filename="panda_arm.xacro"/>
@@ -79,7 +52,7 @@ Die Roboterbeschreibung ist Grundlage der Generierung valider Konfigurationsdate
 Eine Konfigurationsdatei konkretisiert ein robotisches System als Bewegungsgruppe 'MoveGroup', dessen Identität eindeutig durch ihr Namensattribut bestimmt ist. Demnach genügt dieses zur Instanziierung eines MoveGroup Objekts, welcher die Kommunikation zum gewählten Roboter initiiert. Eine duale Konfigurationsdatei ermöglicht analog das Instanziieren und Ansteuern zweier robotischer Systeme. Dabei ist eine Fehlfunktion dieser Instanzen während einer Operation observierbar, wobei die Planung und Exekution durch eine vermeintlich unbeabsichtigte Kollision zwischen Endeffektor und Primitiv detektiert wird, woraufhin die auszuführende Handlung negativ terminiert. Dies impliziert, dass die Funktionen des MoveGroup Interface hinsichtlich der Betrachtung mehrerer robotischer Systeme limitiert sind. Der \autoref{lst:5} zeigt einen Ansatz, der die Kollisionsdetektion definierter Kollisionsobjekte in der allowed kollision matrix 'AKM' deaktiviert, was Beispielsweise das Greifen, Halten und Abstellen eines Primitives in einem Dualen Setup ermöglicht. 
 
 
-\begin{lstlisting}[language=json,firstnumber=1, caption={Des Endeffektors rechter und linker Finger kollidieren unweigerlich während der Exekution mit dem Primitiv. Der illustrierte Quelltext Auszug stellt einen Ansatz zur Umgehung dar und ermöglicht eine erfolgreiche Terminierung des Vorgangs.}, label={lst:5}, captionpos=b]
+\begin{lstlisting}[language=JSON,firstnumber=1, caption={Des Endeffektors rechter und linker Finger kollidieren unweigerlich während der Exekution mit dem Primitiv. Der illustrierte Quelltext Auszug stellt einen Ansatz zur Umgehung dar und ermöglicht eine erfolgreiche Terminierung des Vorgangs.}, label={lst:5}, captionpos=b]
 // Initialisierung der Szene
 planning_scene::PlanningScene ps(kinematic_model);
 
@@ -105,26 +78,9 @@ planning_scene_diff_publisher.publish(pls);
 
 
 \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 dessen 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.
+Die tatsächliche Implementierung ist Inhalt des Reach Pakets, dessen Struktur die  illustriert. An dieser ist ersichtlich, dass die Artefakte aus den kinematischen Berechnungen, beispielsweise der Arbeitsraumanalyse oder dessen 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}
diff --git a/sections/konzept.tex b/sections/konzept.tex
index f99bbbfd5cd4fa720fb1c25a5d96cf95e93795f7..20af25bbba9a67f5c1b02c0ef8840d59a9b981c3 100644
--- a/sections/konzept.tex
+++ b/sections/konzept.tex
@@ -49,7 +49,7 @@ r = \frac {a}{2}
 Durch die Wahl des festen Abstands $a$ bezüglich der kubischen Diskretisierung und Definition der Vektoren $^{0}p \in P_{total}$ als Zentrum einer Sphäre, wird der Radius $r \in \R_{+}$ der Sphäre nach \autoref{eq:23} kalkuliert. 
 Zusätzlich empfiehlt sich die vollständige Auslagerung der Berechnungen auf performantere Rechner, um diese mit mehreren Rechenkernen zu operieren. Beispielsweise empfiehlt sich für diese Arbeit das Hochleistungsrechenzentrum der TU-Dresden. \autoref{lst:1} zeigt die Struktur der JSON-Datei, die als Artefakt der Berechnung in Gitlab entnommen werden. Die Felder 'resolution' und 'maxdistance' entstammen den Parametern der kubischen Diskretisierung und definieren den Namen der Datei. Das Feld 'pose' enthält die String-Repräsentation aller Endeffektor-Posen in einer Liste. Diese bestehen aus Position und Orientierung, wobei die Orientierung als Quaternion notiert ist, was dem Präfix q\_ zu entnehmen ist. Das Ergebnis der kinematischen Funktion aus \autoref{eq:7} als Informationen bezüglich der Erreichbarkeit der Pose ist als Wahrheitswert/bool in der Liste des Feldes 'value' dokumentiert.
 
-\begin{lstlisting}[language=json,firstnumber=1, caption={Struktur der RM als Resultat der Arbeitsraumanalyse},captionpos=b, label={lst:1}]
+\begin{lstlisting}[language=JSON,firstnumber=1, caption={Struktur der RM als Resultat der Arbeitsraumanalyse},captionpos=b, label={lst:1}]
 {"name": "RM_\$(maxdistance)_\$(resolution)"
  "resolution": float,
  "max_distance": float,
@@ -165,7 +165,7 @@ Das Konzept zur Planung und Erstellung spezifischer Aufgaben, sowie deren Realis
 Aktuell bietet MoveIt die Möglichkeit, beliebig Kollisionsobjekte in der Szene zu generieren und persistieren, aber keinen Algorithmus zur Aufgabenbeschreibung, welcher die Reihenfolge konkretisiert, in der die Kommunikation mit den robotischen Systemen stattfindet. Diese fehlende Funktion wird mittels eines Algorithmus ergänzt, welcher die Interaktionen, wie beispielsweise die Translation und Rotation eines Kollisionsobjektes, durch den Nutzer und der grafischen Bedienoberfläche realisiert und anhand zusätzliche Optionen die Dokumentation von Aufgaben ermöglicht. Dabei empfehlen sich Interaktive Marker durch ihren Funktionsumfang zur Repräsentation der Kollisionsobjekte, und bieten weitere Optionen zur Aufgabenbeschreibung in ihren Menüs.
 Eine valide Aufgabenbeschreibung kann in JSON Dateien persistiert werden, dessen Struktur der \autoref{lst:3} veranschaulicht und zur Durchführung der Aufgabe durch robotische Systeme bedingt ist.
 
-\begin{lstlisting}[language=json,firstnumber=1, caption={Der Nutzer hat die Möglichkeit, seine Aufgabe zu benennen. Das Feld 'position' ist eine Liste aller Aufgaben-Posen in Form einer Kette, die das jeweilige robotische System operieren muss.},captionpos=b, label={lst:3}]
+\begin{lstlisting}[language=JSON,firstnumber=1, caption={Der Nutzer hat die Möglichkeit, seine Aufgabe zu benennen. Das Feld 'position' ist eine Liste aller Aufgaben-Posen in Form einer Kette, die das jeweilige robotische System operieren muss.},captionpos=b, label={lst:3}]
 {"name": "TASK_"
  "position": [ "x y z q_x q_y q_z q_w"],
 }
diff --git a/thesis.tex b/thesis.tex
index ecb5d0b2c50755e32a25c2e836142927047499ca..d6dc2c7bbe62b75e8ce7b880bdc55d107c2fbc89 100644
--- a/thesis.tex
+++ b/thesis.tex
@@ -127,7 +127,7 @@
 }
 
 \professor{Prof. Dr. rer. nat. habil. Uwe Aßmann}
-\date{1.12.2021}
+\date{01.12.2021}
 \maketitle
 \newpage