...

bibliography.bib

 % This file was created with Citavi 6.10.0.0
 
-@misc{.1172021,
- year = {11/7/2021},
- title = {urdf/Examples - ROS Wiki},
- url = {http://wiki.ros.org/urdf/Examples},
- urldate = {11/7/2021}
-}
-
-
 @article{Cheng2000,
  abstract = {Three-dimensional joint rotations in human movement analysis have been mainly described by Euler/Cardan angles. Due to sequence dependence, each combination of three Euler/Cardan angles defines a single pattern of joint rotation. When the rotation pattern is unknown, it needs to be considered using a particular sequence of Euler/Cardan angles to represent joint rotations. In this paper a spherical rotation coordinate system is developed for describing three-dimensional joint rotations using a method of rotation involving two steps: a long axis rotation and a pure axial rotation. Two angles of the classical spherical coordinate system--longitude and latitude--are used to describe long axis rotations in this newly proposed coordinate system. The spherical rotation coordinate system uses a radial rotation angle to describe pure axial rotation of a limb segment whereas the classical spherical coordinate system uses a radial displacement to describe motion of a point. An application of the spherical rotation coordinate system is given to define three-dimensional rotations of the glenohumeral joint. A mathematical proof shows that the long axis rotation and axial rotation are sequence independent. Two numerical examples are investigated which demonstrate that the spherical rotation angles can be uniquely determined in both forward and inverse kinematics without considering sequences rotations.},
  author = {Cheng, P. L.},
@@ -45,14 +37,6 @@
 }
 
 
-@misc{franka_ros,
- year = {11/4/2021},
- title = {franka{\_}ros - ROS Wiki},
- url = {http://wiki.ros.org/franka_ros},
- urldate = {11/4/2021}
-}
-
-
 @article{Hornung2013,
  abstract = {Three-dimensional models provide a volumetric representation of space which is important for a variety of robotic applications including flying robots and robots that are equipped with manipulators. In this paper, we present an open-source framework to generate volumetric 3D~environment models. Our mapping approach is based on octrees and uses probabilistic occupancy estimation. It explicitly represents not only occupied space, but also free and unknown areas. Furthermore, we propose an octree map compression method that keeps the 3D models compact. Our framework is available as an open-source C++ library and has already been successfully applied in several robotics projects. We present a series of experimental results carried out with real robots and on publicly available real-world datasets. The results demonstrate that our approach is able to update the representation efficiently and models the data consistently while keeping the memory requirement at a minimum.},
  author = {Hornung, Armin and Wurm, Kai M. and Bennewitz, Maren and Stachniss, Cyrill and Burgard, Wolfram},
@@ -169,66 +153,6 @@
 }
 
 
-@inproceedings{Tao.662011682011,
- author = {Tao, Long and Liu, Zhigang},
- title = {Optimization on multi-robot workcell layout in vertical plane},
- pages = {744--749},
- publisher = {IEEE},
- isbn = {978-1-4577-0268-6},
- booktitle = {2011 IEEE International Conference on Information and Automation},
- year = {6/6/2011 - 6/8/2011},
- doi = {10.1109/ICINFA.2011.5949092}
-}
-
-
-@misc{urdf_Examples_ros,
- year = {11/7/2021},
- title = {urdf/Examples - ROS Wiki},
- url = {http://wiki.ros.org/urdf/Examples},
- urldate = {11/7/2021}
-}
-
-
-@misc{urdf_ros,
- year = {11/7/2021},
- title = {urdf - ROS Wiki},
- url = {http://wiki.ros.org/urdf},
- urldate = {11/7/2021}
-}
-
-
-@inproceedings{Vahrenkamp2013,
- author = {Vahrenkamp, Nikolaus and Asfour, Tamim and Dillmann, Rudiger},
- title = {Robot placement based on reachability inversion},
- pages = {1970--1975},
- publisher = {IEEE},
- isbn = {978-1-4673-5643-5},
- booktitle = {2013 IEEE International Conference on Robotics and Automation},
- year = {5/6/2013 - 5/10/2013},
- doi = {10.1109/ICRA.2013.6630839}
-}
-
-
-@misc{Wikipedia2021,
- abstract = {Roll-Nick-Gier-Winkel, englisch roll-pitch-yaw angle, sind spezielle Eulerwinkel (Lagewinkel), die zur Beschreibung der Ausrichtung eines Fahrzeugs im dreidimensionalen Raum herangezogen werden. Diese Art der Richtungsmessung und -bestimmung durch Drehratensensoren wurde zur Navigation im Luftverkehr eingef{\"u}hrt und wird inzwischen neben Luftfahrzeugen auch f{\"u}r Raum-, Land- und Wasserfahrzeuge verwendet.},
- editor = {Wikipedia},
- year = {2021},
- title = {Roll-Nick-Gier-Winkel},
- url = {https://de.wikipedia.org/w/index.php?title=Roll-Nick-Gier-Winkel&oldid=209197743},
- urldate = {7/11/2021},
- doi = {Page},
- file = {Roll-Nick-Gier-Winkel:Attachments/Roll-Nick-Gier-Winkel.pdf:application/pdf}
-}
-
-
-@misc{xacro_ros,
- year = {11/7/2021},
- title = {xacro - ROS Wiki},
- url = {http://wiki.ros.org/xacro},
- urldate = {11/7/2021}
-}
-
-
 @inproceedings{Zacharias2007,
  author = {Zacharias, Franziska and Borst, Christoph and Hirzinger, Gerd},
  title = {Capturing robot workspace structure: representing robot capabilities},

sections/einleitung.tex

 \chapter{Einleitung}\label{ch:introduction}
-'Collaborative Multi-Robot Work-Cells' beschreibt 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. Zugrundeliegende 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 Operation 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. 
+'Collaborative Multi-Robot Work-Cells' beschreibt 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. 
 
 \section{Zielsetzung der wissenschaftlichen Arbeit}
-Ziel dieser Arbeit ist es, mittels Konzepten zur Charakterisierung der Kapazitäten eines Roboterarms, bezogen auf dessen Fähigkeit der Interaktion mit der Umgebung, kollaborative Multi-Roboter Arbeitsplätze zu definieren. Dazu ist die Auseinandersetzung mit wissenschaftlichen Publikationen erforderlich, um einen umfassenden Kenntnisstand hinsichtlich der Anforderungen bezüglich der Generierung eines solchen Arbeitsplatzes zu erlangen und als Grundlage der Evaluierung zu nutzen. Dabei ist die Elaboration einer Methodik zur Konkretisierung zu-operierender spezifischer Aufgaben, um auf Grundlage dessen automatisch einen kollaborativen Arbeitsplatz zu erzeugen, ebenfalls ein Aspekt dieser Arbeit. Anschließend ist die Anwendung der erarbeiteten Konzepte und dessen Implementierung innerhalb eines Fallbeispiels mit zwei oder mehr 'Panda' Roboterarmen der Franka Emika GmbH zu zeigen und dessen erzielter Resultate anhand der zuvor definierten Anforderungen zu evaluieren.
+Ziel dieser Arbeit ist es, mittels Konzepten zur Charakterisierung der Kapazitäten eines Roboterarms, bezogen auf dessen Fähigkeit der Interaktion mit der Umgebung, kollaborative Multi-Roboter Arbeitsräume zu definieren. Dazu ist die Auseinandersetzung mit wissenschaftlichen Publikationen erforderlich, um einen umfassenden Kenntnisstand hinsichtlich der Anforderungen bezüglich der Generierung eines solchen Arbeitsraums zu erlangen und Grundlage der Evaluierung. Dabei ist die Erarbeitung einer Methodik zur Konkretisierung zu operierender spezifischer Aufgaben, um auf Grundlage dessen automatisch einen kollaborativen Arbeitsraum zu erzeugen, ebenfalls ein Aspekt dieser Arbeit. Anschließend ist die Anwendung der erarbeiteten Konzepte und dessen Implementierung innerhalb eines Fallbeispiels mit zwei oder mehr 'Panda' Roboterarmen der Franka Emika GmbH zu zeigen und dessen erzielter Resultate anhand der zuvor definierten Anforderungen zu evaluieren.
 
 
 \section{Aufbau der wissenschaftlichen Arbeit}

sections/fallbeispiel.tex

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

sections/implementierung.tex

 \chapter{Implementierung}\label{ch:implementation}
-Die ausführliche Auseinandersetzung mit der Struktur des ROS spezifischen Arbeitsraums, dessen Pakete die nötigen Roboterbeschreibungen, Konfigurationsdateien und implementierte Algorithmen enthalten, um alle Aspekte der wissenschaftlichen Arbeit zu realisieren, ist Inhalt dieses Kapitels und in \autoref{fig:8} illustriert. Dabei initialisiert jede Quelldatei einen Node im ROS Kontext in der Programmiersprache C++. 
+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
@@ -17,7 +17,7 @@ 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 \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
@@ -45,22 +45,23 @@ Die Roboterbeschreibung ist Grundlage der Generierung valider Konfigurationsdate
 .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}
+\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, in mit Modifikationen zur Übergabe der Roboterpositionen.}, label={lst:4}, captionpos=b]
+\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 der zu konkretisierenden Roboter -->
+<!-- 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"/>
 
@@ -76,10 +77,10 @@ Die Roboterbeschreibung ist Grundlage der Generierung valider Konfigurationsdate
 
 
 \subsection{MoveGroup Interface mit Dual Setup}
-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. 
+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. 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, 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);
 
@@ -105,7 +106,7 @@ 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 \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
@@ -134,10 +135,10 @@ Der (Quelltext.6) der Header Datei beschreibt alle Funktionen, die den Algorithm
 %\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 eine Iteration über den Arbeitsraum, erfolgt durch das tf2 Objekt der gleichnamigen Bibliothek für Operationen auf homogene Transformationen. Zusätzlich erfolgt die Portierung der Metrik und Persistenz.
+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 dessen Voxelisierung durch Integration der PCL Bibliothek. Diese ist in C++ vollumfänglich Implementiert und ermöglicht performante Operationen auf 3 dimensionale Koordinaten. Ein bedeutender unterschied des Algorithmus zur Platzierung robotischer Systeme in Reuleaux \cite{Makhal2018} und dessen Implementierung in dieser Arbeit ist die differenzierte Voxelisierung. Diese Implementiert zunächst ein Gitter aus Vektoren $^{0}v \in \R^{3}$ ähnlich der kubischen Diskretisierung, und bildet jede Transformation $^{0}T_{Base_{i}} \in ^{0}T_{Base}$ eines Kettenglieds der Operationskette $g_{i} \in K$ anhand seiner räumlichen Position auf den Vektor $^{0}v$ ab. Die resultierende Struktur ist in \autoref{eq:30} gezeigt.
+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}
@@ -147,7 +148,7 @@ 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, welcher $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
+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}
@@ -158,5 +159,5 @@ Dictionary_{Metrik} &= {(^{0}v, Task_{Metrik})}
 \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 'Pick and Place' Implementierung geladen zu werden und über jede Instanz, über die Konfigurationsdatei der Roboterbeschreibung übergeben zu werden.  
+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.  
 

thesis.tex

@@ -14,9 +14,9 @@
 \usepackage[
     style=numeric-comp,
     backend=biber,
-    url=true,
+    url=false,
     doi=true,
-    isbn=true,
+    isbn=false,
     hyperref,
 ]{biblatex}
 \addbibresource{bibliography.bib}
@@ -24,6 +24,18 @@
     \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