final 2

bibliography.bib

@@ -89,14 +89,15 @@
 	file = {arXiv Fulltext PDF:C\:\\Users\\jimmo\\Zotero\\storage\\Q5VH3VCB\\Coleman et al. - 2014 - Reducing the Barrier to Entry of Complex Robotic S.pdf:application/pdf;arXiv.org Snapshot:C\:\\Users\\jimmo\\Zotero\\storage\\VNYII4CG\\1404.html:text/html},
 }
 
-@inproceedings{quigley_ros_nodate,
+
+@article{quigley_ros_nodate,
 	author = {Quigley, Morgan and Conley, Ken and Gerkey, Brian and Faust, Josh and Foote, Tully and Leibs, Jeremy and Wheeler, Rob and Ng, Andrew},
 	year = {2009},
 	month = {01},
-	pages = {},
 	title = {ROS: an open-source Robot Operating System},
 	volume = {3},
-	journal = {ICRA Workshop on Open Source Software}
+	pages = {1--6},
+	journal = {ICRA Workshop on Open Source Software},
 }
 
 @incollection{carbone_path_2015,
@@ -277,11 +278,14 @@
 	file = {IEEE Xplore Full Text PDF:C\:\\Users\\jimmo\\Zotero\\storage\\T3WDVR2T\\Matthias et al. - 2011 - Safety of collaborative industrial robots Certifi.pdf:application/pdf;IEEE Xplore Abstract Record:C\:\\Users\\jimmo\\Zotero\\storage\\FQHX6T4R\\5942307.html:text/html},
 }
 
-@article{berenson_constrained_nodate,
+@phdthesis{berenson_constrained_nodate,
+	type = {Dissertation},
 	title = {Constrained {Manipulation} {Planning}},
-	language = {en},
 	author = {Berenson, Dmitry},
-	pages = {186},
+	school = {Carnegie Mellon University},
+	url = {https://www.ri.cmu.edu/pub_files/2011/5/dmitry_thesis.pdf},
+	year = {2011},
+	pages = {17},
 }
 
 @incollection{hutchison_constraint-based_2007,
@@ -415,21 +419,14 @@
 }
 
 @article{canny_kinodynamic_nodate,
-	title = {Kinodynamic motion planning},
-	author = {{Bruce Donald} and {Patrick Xavier}, {John Canny}, {John Reif}},
-	abstract = {•	Kinodynamische Motion Planning versucht sowohl kinematische (zB. Hindernisse) als auch dynamische Constraints (v, a, f) zu berücksichtigen
-	•	Ziel: Zeit minimale/optimale Trajektorie von Startposition und -Geschwindigkeit zu Zielposition und -Geschwindigkeit und dabei Hindernisse inklusive eines Sicherheitsabstands zu vermeiden und Geschwindigkeit und Beschleunigungsconstraints einzuhalten
-	•	Eine exakte Lösung in 3D zu finden ist NP-Hart
-	•	Annäherungsalgorithmen, deren Lösung nah an optimal ist
-	•	Sicherheitsabstand ist eine Funktion abhängig von der Geschwindigkeit
-	•	Finden einer Lösung ist immer ein Tradeoff aus:
-	o	Ausführungszeit der Bewegung
-	o	Strenge der Einhaltung des Sicherheitsabstands
-	o	Genauigkeit beim Erreichen der Zielposition und Geschwindigkeit
-	•	(Hindernisse werden als Menge von überlappenden Polyedern repräsentiert)
-	•	Keine Garantie, dass die angenäherte optimale sichere Lösung in der Position optimal ist},
-	language = {en},
-	pages = {19},
+	author = {Donald, Bruce and Xavier, Patrick and Canny, John and Reif, John},
+	year = {1993},
+	month = {11},
+	pages = {1048-1066},
+	title = {Kinodynamic Motion Planning.},
+	volume = {40},
+	journal = {J. ACM},
+	doi = {10.1145/174147.174150}
 }
 
 @book{siciliano_springer_2008,
@@ -553,17 +550,9 @@
 @misc{noauthor_robot_nodate,
 	title = {{ROBOT} {\textbar} {Bedeutung} im {Cambridge} {Englisch} {Wörterbuch}},
 	url = {https://dictionary.cambridge.org/de/worterbuch/englisch/robot},
-	abstract = {robot Bedeutung, Definition robot: 1. a machine controlled by a computer that is used to perform jobs automatically:  2. someone who….},
-	language = {de},
 	urldate = {2020-12-09},
-	file = {Snapshot:C\:\\Users\\jimmo\\Zotero\\storage\\KIY7QGKE\\robot.html:text/html},
 	}
 
-@misc{moveit_concepts_nodate,
-	title = {Concepts {\textbar} {MoveIt}},
-	url = {https://moveit.ros.org/documentation/concepts/},
-	urldate = {2021-01-20},
-}
 
 @book{tactile_internet_ceti, 
 	title={Tactile Internet With Human-In-The-Loop}, 

sections/ausblick.tex

@@ -4,9 +4,9 @@
 In diesem Abschnitt werden verschiedene Erweiterungen der Fallstudie vorgestellt und daraus resultierende Constraints ebenfalls in die Taxonomie eingeordnet werden.
 
 \paragraph{Synchronisation der Roboter}
-Im momentanen Stand der Demo arbeiten beide Roboter unabhängig voneinander und ohne jegliche Informationen über den jeweils anderen. Vorstellbar wäre eine Kommunikation über TCP/IP oder UDP, wodurch  die Roboter ihre Workflows synchronisieren könnten. Das würde es ermöglichen alle Teilnehmer in einem einzelnen Ablaufplan zu modellieren, wie von Roman Froschauer und Rene Lindorfer~\cite{froschauer_roman_workflow-based_nodate} vorgeschlagen.
+Im momentanen Stand der Fallstudie arbeiten beide Roboter unabhängig voneinander und ohne jegliche Informationen über den jeweils anderen. Vorstellbar wäre eine Kommunikation über TCP/IP oder UDP, wodurch  die Roboter ihre Workflows synchronisieren könnten. Das würde es ermöglichen alle Teilnehmer in einem einzelnen Ablaufplan zu modellieren, wie von Roman Froschauer und Rene Lindorfer~\cite{froschauer_roman_workflow-based_nodate} vorgeschlagen.
  
-Für die Constraints des Roboters würde das eine Erweiterung der Handlungs-Constraints bedeuten, da die nächste mögliche Handlung nun nicht mehr nur von den eigenen vorherigen Zuständen abhängt, sondern auch von den Zuständen der anderen Teilnehmer. In die bestehende Taxonomie kann der Constraint wie folgt eingeordnet werden:
+Für die Constraints des Roboters würde das eine Erweiterung der Handlungs Constraints bedeuten, da die nächste mögliche Handlung nun nicht mehr nur von den eigenen vorherigen Zuständen abhängt, sondern auch von den Zuständen der anderen Teilnehmer. In die bestehende Taxonomie kann der Constraint wie folgt eingeordnet werden:
 
 \begin{center}
 	Robotische Constraints → Handlung → Endeffektorunspezifisch
@@ -33,7 +33,7 @@ Auch die Sicherheitszone kann erst durch eine aktive Überwachung sinnvoll reali
 \paragraph{Entfernen von Flüssigkeitsresten}
 Durch die Überwachung des Arbeitsbereichs per Kamera, wäre es möglich eventuell verschüttete Flüssigkeitsreste zu erkennen. Eine zusätzliche Aufgabe wäre diese Reste zu beseitigen.
 
-Dazu benötigt der Roboter ein Werkzeug oder auch einfach ein Tuch, was ebenfalls ein endeffektor-spezifischer Handlungs-Constraint ist. Zum Entfernen muss ein Pfad durch die Flüssigkeit gefolgt werden, ohne die Berührung zum Tisch zu verlieren. Dies erfolgt, indem ein Teilpfad entlang der Ebene des Tisches definiert wird, den der Roboter folgen muss. Alternativ lassen sich auch zwei Punkte auf gegenüberliegenden Seiten der Flüssigkeit definieren, zwischen denen ein Pfad mit kartesischer Pfadplanung berechnet wird. Dabei wird eine Trajektorie gesucht, die die Punkte in einer Geraden verbindet, was auf einem ebenen Tisch auch einen Pfad ohne Berührungsverlust erzeugen würde. 
+Dazu benötigt der Roboter ein Werkzeug oder ein einfaches Tuch, was ebenfalls ein endeffektor-spezifischer Handlungs-Constraint ist. Zum Entfernen muss ein Pfad durch die Flüssigkeit gefolgt werden, ohne die Berührung zum Tisch zu verlieren. Dies erfolgt, indem ein Teilpfad entlang der Ebene des Tisches definiert wird, den der Roboter folgen muss. Alternativ lassen sich auch zwei Punkte auf gegenüberliegenden Seiten der Flüssigkeit definieren, zwischen denen ein Pfad mit kartesischer Pfadplanung berechnet wird. Dabei wird eine Trajektorie gesucht, die die Punkte in einer Geraden verbindet, was auf einem ebenen Tisch auch einen Pfad ohne Berührungsverlust erzeugen würde. 
 
 In der Taxonomie wäre das als Definition eines Teilpfades einzuordnen:
 \begin{center}
@@ -41,14 +41,14 @@ In der Taxonomie wäre das als Definition eines Teilpfades einzuordnen:
 \end{center}
 
 \paragraph{}
-Die Erweiterung der Fallstudie um diese Constraints kann auf verschiedene Weisen erfolgen. Constraints, die abhängig vom aktuellen Zustand angewandt und entfernt werden sollen, können anlog zu den Beschleunigungs- und Geschwindigkeits-Constraints realisiert werden, indem sie ebenfalls die abstrakte Klasse \textit{Constraints} implementieren (siehe \Cref{ch:constraint_impl}). Wird der Workflow beschränkt, müsste dieser Constraint Teil des \textit{CobotController}s werden, da dieser in der Demo für den Handlungsablauf verantwortlich ist (siehe \Cref{ch:cobot_impl}).
+Die Erweiterung der Fallstudie um diese Constraints kann auf verschiedene Weisen erfolgen. Constraints, die abhängig vom aktuellen Zustand angewandt und entfernt werden sollen, können anlog zu den Beschleunigungs- und Geschwindigkeits-Constraints realisiert werden, indem sie ebenfalls die abstrakte Klasse \textit{Constraints} implementieren (siehe \Cref{ch:constraint_impl}). Wird der Workflow beschränkt, müsste dieser Constraint Teil des \textit{CobotController}s werden, da dieser in der Fallstudie für den Handlungsablauf verantwortlich ist (siehe \Cref{ch:cobot_impl}).
 
 \section{Zukünftige Arbeiten}
-Die Simulation der beiden Roboter geschieht in der Demo-Anwendung, aufgrund technischer Limitierungen der Gazebo Simulationsumgebung, nicht. Für einfache Anwendungsfälle, wie den vorliegenden, mag das kein Problem sein, insbesondere jedoch für Demonstrierungen direkter Kollaboration mehrerer Roboter, ist eine parallele Simulation unumgänglich. Um eine dahingehende Erweiterung zu ermöglichen, könnten sich zukünftige Arbeiten mit einer Erweiterung der Simulationsumgebung befassen.
+Die gleichzeitige Simulation der beiden Roboter geschieht in der Fallstudie, aufgrund technischer Limitierungen der Gazebo Simulationsumgebung, nicht. Für einfache Anwendungsfälle, wie den vorliegenden, mag das kein Problem sein, insbesondere jedoch für Demonstrierungen direkter Kollaboration mehrerer Roboter, ist eine parallele Simulation unumgänglich. Um eine dahingehende Erweiterung zu ermöglichen, könnten sich zukünftige Arbeiten mit einer Erweiterung der Simulationsumgebung befassen.
 
 Die präsentierte Taxonomie ist alleine auf Grundlage von Constraints industrieller Manipulatoren entstanden. Sie ist daher nur begrenzt auf andere Arten von Robotern übertragbar. Gerade mobile Roboter erfordern aufgrund ihrer holonomen Art weitere und andere Constraints. Eine Erweiterung der Taxonomie zur universelleren Abdeckung von robotischen Constraints wäre ein sinnvoller nächster Schritt.
 
-Die einzelnen Handlungen und Aufgaben in der Demo werden unabhängig voneinander geplant und ausgeführt, ohne Einschränkungen der folgenden Aufgaben zu berücksichtigen. Das Greifen der Flasche beispielsweise kann aus allen Richtungen und auch von oben erfolgreich sein. Das Umfüllen der Flüssigkeit im nächsten Schritt kann jedoch nur erfolgreich durchgeführt werden, wenn die Flasche seitlich gegriffen wurde und die Gelenklimits des Endeffektors die zusätzliche Drehung erlauben. In der Fallstudie wird dieses Problem umgangen, indem die Flasche grundsätzlich aus X-Richtung gegriffen wird. Vor Ausführung der Bewegung in Richtung Glas, werden wiederholt Trajektorien zu beiden Seiten des Glases geplant, bis der Zielzustand der Trajektorie noch einen ausreichenden Spielraum im Endeffektor-Gelenk hat, um eine Drehbewegung zu erlauben. Erst dann wird die Bewegung ausgeführt, um anschließend die Drehbewegung zu planen. Eine deutlich elegantere Lösung wäre die Vorabplanung aller Aufgaben. Michael Görner et al.~\cite{task_constructor_2019} präsentieren in ihrer Arbeit ein Framework, welches MoveIt um genau diese Funktionalität erweitert: Das Planen von robotischen Aktionen, die aus mehreren von einander abhängigen Unteraufgaben bestehen. Aufgaben werden dabei in Baumstrukturen beschrieben. Die Blätter repräsentieren primitive Planungsstufen, die von MoveIts integrierten Planern gelöst werden können. Die Ergebnisse jeder Stufe werden gebündelt und an die übergeordnete Ebene in Form einer MoveIt Planning Scene propagiert. Der MoveIt Task Constructor ist öffentlich als open source Projekt unter der BSD-3 Lizenz verfügbar\footnote{\url{https://github.com/ros-planning/moveit_task_constructor}}.
+Die einzelnen Handlungen und Aufgaben in der Fallstudie werden unabhängig voneinander geplant und ausgeführt, ohne Einschränkungen der folgenden Aufgaben zu berücksichtigen. Das Greifen der Flasche beispielsweise kann aus allen Richtungen und auch von oben erfolgreich sein. Das Umfüllen der Flüssigkeit im nächsten Schritt kann jedoch nur erfolgreich durchgeführt werden, wenn die Flasche seitlich gegriffen wurde und die Gelenklimits des Endeffektors die zusätzliche Drehung erlauben. In der Fallstudie wird dieses Problem umgangen, indem die Flasche grundsätzlich aus X-Richtung gegriffen wird. Vor Ausführung der Bewegung in Richtung Glas, werden wiederholt Trajektorien zu beiden Seiten des Glases geplant, bis der Zielzustand der Trajektorie noch einen ausreichenden Spielraum im Endeffektor-Gelenk hat, um eine Drehbewegung zu erlauben. Erst dann wird die Bewegung ausgeführt, um anschließend die Drehbewegung zu planen. Eine deutlich elegantere Lösung wäre die Vorabplanung aller Aufgaben. Michael Görner et al.~\cite{task_constructor_2019} präsentieren in ihrer Arbeit ein Framework, welches MoveIt um genau diese Funktionalität erweitert: Das Planen von robotischen Aktionen, die aus mehreren von einander abhängigen Unteraufgaben bestehen. Aufgaben werden dabei in Baumstrukturen beschrieben. Die Blätter repräsentieren primitive Planungsstufen, die von MoveIts integrierten Planern gelöst werden können. Die Ergebnisse jeder Stufe werden gebündelt und an die übergeordnete Ebene in Form einer MoveIt Planning Scene propagiert. Der MoveIt Task Constructor ist öffentlich als open source Projekt unter der BSD-3 Lizenz verfügbar\footnote{\url{https://github.com/ros-planning/moveit_task_constructor}}.
 
 Ein weiteres Ziel zukünftiger Arbeiten könnte sein, den Task Constructor zumindest für abhängige Unteraufgaben zu implementieren und so die Flexibilität und Zuverlässigkeit der Anwendung zu verbessern.
 

sections/einleitung.tex

 \newpage\null\newpage
 \chapter{Einleitung}\label{ch:introduction}
-Die Adaption von Robotern in der Industrie nimmt von Jahr zu Jahr zu. Die International Federation of Robotics meldet für 2018 einen Investitionsrekord von 16,5 Milliarden US Dollar in industrielle Robotik und erwartet bis 2022 ein durchschnittliches Wachstum von 12 Prozent pro Jahr~\cite{ifr_industrial_nodate}. Noch sind jedoch nicht alle Probleme besser von Robotern als von Menschen lösbar. Insbesondere die sensorischen Fähigkeiten des Roboters und die Entscheidungsfindung in unsicheren oder unbekannten Situationen sind den Fähigkeiten des Menschen noch unterlegen. Statt der Ersetzung des Menschen, scheint eine aktive Zusammenarbeit von Mensch und Roboter eine höhere Effizienz zu bieten. Das spiegelt sich auch in der zunehmenden Entwicklung von kollaborativen Robotern (Cobots) wider. Diese sind in der Regel kleiner, schwächer und günstiger als herkömmliche industrielle Roboter und sind in der Lage in Echtzeit auf ihre Umgebung zu reagieren und so - ohne die Notwendigkeit eines Sicherheitskäfigs - eine direkte Zusammenarbeit mit Menschen zu ermöglichen~\cite{tactile_internet_ceti}.
+Der Einsatz von Robotern in der Industrie nimmt von Jahr zu Jahr zu. Die International Federation of Robotics meldet für 2018 einen Investitionsrekord von 16,5 Milliarden US Dollar in industrielle Robotik und erwartet bis 2022 ein durchschnittliches Wachstum von 12 Prozent pro Jahr~\cite{ifr_industrial_nodate}. Noch sind jedoch nicht alle Probleme besser von Robotern als von Menschen lösbar. Insbesondere die sensorischen Fähigkeiten des Roboters und die Entscheidungsfindung in unsicheren oder unbekannten Situationen sind den Fähigkeiten des Menschen noch unterlegen. Statt der Ersetzung des Menschen, scheint eine aktive Zusammenarbeit von Mensch und Roboter eine höhere Effizienz zu bieten. Das spiegelt sich auch in der zunehmenden Entwicklung von kollaborativen Robotern (Cobots) wider. Diese sind in der Regel kleiner, schwächer und günstiger als herkömmliche industrielle Roboter und sind in der Lage in Echtzeit auf ihre Umgebung zu reagieren und so - ohne die Notwendigkeit eines Sicherheitskäfigs - eine direkte Zusammenarbeit mit Menschen zu ermöglichen~\cite{tactile_internet_ceti}.
 
 Gerade in unbekannten und sich ändernden Umgebungen ist es nicht praktikabel  Bewegungen und Handlungen des Roboters für alle Eventualitäten vorzudefinieren. Stattdessen soll er in der Lage sein, selbstständig sein Verhalten und seine Bewegungen neuen Situationen anzupassen. Um Sicherheitsanforderungen umzusetzen und die erwartete Ausführung von Aufgaben zu gewährleisten, können dem Roboter Einschränkungen (Constraints) auferlegt werden. Dadurch bleibt die lokale Planung Aufgabe des Planungsalgorithmus des Roboters. Die Menge an gültigen Lösungen wird aufgrund der Constraints jedoch soweit eingeschränkt, dass der Roboter ein erwartungsgemäßes Verhalten zeigt und an ihn gestellte Anforderungen erfüllt.
 
 \paragraph{}Das Ziel dieser Studienarbeit ist die Analyse und Anwendung robotischer Constraints, zur Einschränkung und Steuerung industrieller Manipulatoren.
-Die analysierten Constraints sollen in einer Taxonomie klassifiziert werden, die als Hilfestellung bei der Entwicklung neuer Robotikanwendungen dienen kann.
+Die analysierten Constraints werden in einer Taxonomie klassifiziert, die als Hilfestellung bei der Entwicklung neuer Robotikanwendungen dienen soll.
 
-\begin{figure}
+Die Evaluation der Anwendbarkeit der erstellten Taxonomie erfolgt anhand eines einfachen Anwendungsfalls, einer kollaborativer Mensch-Roboter-Interaktion, indem die auftretenden Einschränkungen wieder in die Taxonomie eingeordnet werden. In diesem Anwendungsfall werden zwei Roboter betrieben. Wie in Abbildung~\ref{fig:aufgabenstellung} dargestellt, ist der erste Roboter dafür verantwortlich ein leeres Gefäß mit einer Flüssigkeit aus einem anderen Gefäß zu befüllen, nachdem dieses von einem Menschen bereitgestellt wurde. Anschließend nimmt er das nun gefüllte Gefäß auf und stellt es an einem Übergabeort ab. Der zweite Roboter nimmt das befüllte Gefäß entgegen und stellt es dem menschlichen Nutzer bereit.
+Durch die Konzeption von Erweiterungen der Fallstudie wird zudem die Vollständigkeit der Taxonomie überprüft, indem dabei auftretende Einschränkungen ebenfalls in die Taxonomie eingeordnet werden. 
+
+\paragraph{} Die Arbeit besteht aus 6 Teilen. \Cref{ch:basics} erklärt grundlegende Begrifflichkeiten aus dem Umfeld der Robotik, die in späteren Kapiteln benötigt werden. In \Cref{ch:taxonomy} werden verschiedene Constraints von Arbeitsbereich, Bewegung und Handlung eines Roboters beschrieben und in eine allgemeine Taxonomie eingeordnet. \Cref{ch:implementation} dokumentiert den Entwurf und die Implementierung der Fallstudie. In \Cref{ch:eval} wird die Implementierung hinsichtlich der Einhaltung der Constraints überprüft und die angewandten Constraints nochmals in die Taxonomie eingeordnet. \Cref{ch:future_work} gibt einen Ausblick auf mögliche zukünftige Arbeiten und \Cref{ch:conclusion} fasst die Ergebnisse dieser Arbeit noch einmal zusammen.
+
+\begin{figure}[!h]
 	\centering	
-	\includegraphics[height=\textheight, width=\textwidth, 		  	keepaspectratio]{images/Aufgabenstellung.jpg}	
+	\includegraphics[height=0.65\textheight, width=\textwidth, keepaspectratio]{images/Aufgabenstellung.jpg}	
 	\caption{Aktivitätsdiagramm der Aufgabenstellung}
 	\label{fig:aufgabenstellung}
 \end{figure}
\ No newline at end of file
-
-Neben einer konzeptionellen Analyse der verschiedenen Einschränkungen erfolgt eine Evaluation anhand eines einfachen Anwendungsfalls einer kollaborativer Mensch-Roboter-Interaktion. In diesem Anwendungsfall werden zwei Roboter betrieben. Wie in Abbildung~\ref{fig:aufgabenstellung} dargestellt, ist der erste Roboter, dafür verantwortlich
-ein leeres Gefäß mit einer Flüssigkeit aus einem anderen Gefäß zu befüllen, nachdem dieses von einem Menschen bereitgestellt wurde. Anschließend nimmt er das nun gefüllte Gefäß auf und stellt es an einem Übergabeort ab. Der zweite Roboter nimmt das befüllte Gefäß entgegen und stellt es schließlich dem menschlichen Nutzer bereit.
-Beide Aktionen erfordern unter anderem die Einschränkung der Neigung des Endeffektors, des Arbeitsbereiches und der Geschwindigkeit. Die technische Basis für die Implementierung wird
-hierbei durch das Robot Operation System (ROS)\footnote{https://www.ros.org}, in Zusammenwirkung mit dem Planungs-
-Frameworks MoveIt\footnote{https://moveit.ros.org}, gebildet.
-
-Anhand des Anwendungsfalls wird die Anwendbarkeit der zuvor untersuchten Einschränkungen untersucht, wobei die in der Fallstudie identifizierten Einschränkungen in die erstellte Taxonomie eingeordnet werden. Um die Vollständigkeit der Taxonomie bezüglich kollaborativer Robotik-Anwendungen zu untersuchen, werden zudem mögliche Erweiterungen der Fallstudie konzipiert und daraus resultierende weitere benötigte Einschränkungen ebenfalls eingeordnet.
-
-\paragraph{} Die Arbeit besteht aus 6 Teilen. \Cref{ch:basics} erklärt grundlegende Begrifflichkeiten aus dem Umfeld der Robotik, die in späteren Kapiteln benötigt werden. In \Cref{ch:taxonomy} werden verschiedene Constraints von Arbeitsbereich, Bewegung und Handlung eines Roboters beschrieben und in eine allgemeine Taxonomie eingeordnet. \Cref{ch:implementation} dokumentiert den Entwurf und die Implementierung der Fallstudie. In \Cref{ch:eval} wird die Implementation hinsichtlich der Einhaltung der Constraints überprüft und die angewandten Constraints nochmals in die Taxonomie eingeordnet. \Cref{ch:future_work} gibt einen Ausblick auf mögliche zukünftige Arbeiten und \Cref{ch:conclusion} fasst die Ergebnisse dieser Arbeit noch einmal zusammen.
\ No newline at end of file

sections/eval.tex

+\newpage\null\newpage
 \chapter{Evaluation}\label{ch:eval}
 Ziel der Fallstudie war die Anwendung einiger der in der Taxonomie eingeordneten Constraints in einem realen Anwendungsfall. In diesem Kapitel wird die Implementierung hinsichtlich der Erfüllung der in Abschnitt~\ref{ch:requirements} gelisteten Anforderungen überprüft. Dazu werden beide Cobot-Anwendungsfälle in einer Gazebo Simulationsumgebung simuliert. Anschließend werden alle aufgetretenen Constraints in die in Kapitel~\ref{ch:taxonomy} präsentierte Taxonomie eingeordnet.
 
 
-
-
 \section{Simulation}
 Die Initialisierung der Simulationsumgebung geschieht in einem Zuge mit dem Hinzufügen der Objekte in die Planning Scene. Die Abläufe der Simulationen von Cobot 1 und Cobot 2 sind schrittweise in Abbildung~\ref{fig:cobot_1_sim} und Abbildung~\ref{fig:cobot_2_sim} dargestellt.
 
@@ -83,13 +82,13 @@ Die Initialisierung der Simulationsumgebung geschieht in einem Zuge mit dem Hinz
 	\label{fig:cobot_2_sim}
 \end{figure}
 
-Um die Einhaltung der Constraints zu validieren, wurde die Beschleunigung, die Geschwindigkeit, die Orientierung des Endeffektors und der Abstand zur Sicherheitszone zur Laufzeit der Simulation aufgezeichnet und in einem Graphen dargestellt. Dabei wurde lediglich Cobot 1 betrachtet, da die Handlungen und Constraints des zweiten Cobots eine Teilmenge des ersten Cobots sind. In Abbildung~\ref{fig:velocity_eval} ist zu sehen, dass die Beschleunigung, während der Handhabung von gefüllten Behältern, geringer ist, als während der Handlungen in denen das nicht der Fall ist. Abbildung~\ref{fig:orientation_eval} zeigt die Orientierung des Endeffektors, relativ zur Welt. Es ist ersichtlich, dass die Orientierung, während der Handhabung von Objekten, innerhalb der Toleranzgrenzen bleibt, die bei der Erstellung des Orientierungs-Constraints definiert wurden (siehe Quelltext~\ref{lst:orientation_constraint}). Abbildung~\ref{fig:safezone_eval} zeigt noch den Abstand aller Glieder des Roboters zur Sicherheitszone. Diese wird erst beim Platzieren des Glases und nach erfolgreicher Anfrage an den \textit{SafezoneController} geschnitten. Link 0 und Link 1 sind nicht zu erkennen, da sie ebenfalls einen konstanten Abstand halten und von der Kurve von Link 2 überdeckt werden. Die einzelnen Handlungen ordnen sich in allen drei Abbildungen grob den in Tabelle~\ref{tab:action_time} dargestellten Zeitfenstern zu.
+Um die Einhaltung der Constraints zu validieren, wurde die Beschleunigung, die Geschwindigkeit, die Orientierung des Endeffektors und der Abstand zur Sicherheitszone zur Laufzeit der Simulation aufgezeichnet und in einem Graphen dargestellt. Dabei wurde lediglich Cobot 1 betrachtet, da die Handlungen und Constraints des zweiten Cobots eine Teilmenge des ersten Cobots sind. In Abbildung~\ref{fig:velocity_eval} ist zu sehen, dass die Beschleunigung, während der Handhabung von gefüllten Behältern, geringer ist, als während der Handlungen in denen das nicht der Fall ist. Die Bereiche, in denen die Beschleunigung beschränkt ist, sind farblich markiert. Abbildung~\ref{fig:orientation_eval} zeigt die Orientierung des Endeffektors, relativ zur Welt. Es ist ersichtlich, dass die Orientierung, während der Handhabung von Objekten, nur minimal um einen konstanten Wert schwanken. Diese Bereiche sind ebenfalls farblich unterlegt. Abbildung~\ref{fig:safezone_eval} zeigt noch den Abstand aller Glieder des Roboters zur Sicherheitszone. Diese wird erst beim Platzieren des Glases und nach erfolgreicher Anfrage an den \textit{SafezoneController} geschnitten. Link 0 und Link 1 sind nicht zu erkennen, da sie ebenfalls einen konstanten Abstand halten und von der Kurve von Link 2 überdeckt werden. Die einzelnen Handlungen ordnen sich in allen drei Abbildungen grob den in Tabelle~\ref{tab:action_time} dargestellten Zeitfenstern zu.
 
 \begin{center}
 	\begin{table}
 		\caption{Zeitliche Zuordnung der Handlungen in der Evaluation}
 		\label{tab:action_time}
-		\begin{tabular}{l||c|c}
+		\begin{tabular}{l||S[table-format=1]|S[table-format=1]}
 			\textbf{Handlung} & \textbf{Beginn} & \textbf{Ende} \\
 			\hline
 			Startposition & 0s & 5s \\

sections/grundlagen.tex

-\newpage\null\newpage
 \chapter{Grundlagen}\label{ch:basics}
 Einige der wesentlichen Begriffe dieser Arbeit besitzen keine eindeutige Definition. Daher werden diese Begriffe zunächst kurz erklärt und eine für diese Arbeit geltende Definition festgelegt.
 
@@ -6,12 +5,12 @@ Einige der wesentlichen Begriffe dieser Arbeit besitzen keine eindeutige Definit
 
 Das Cambridge Dictionary definiert einen Roboter im Allgemeinen als \glqq eine von einem Computer gesteuerte Maschine, die zur automatischen Ausführung von Aufgaben genutzt wird\grqq{}~\cite{noauthor_robot_nodate}. 
 
-Diese Arbeit bezieht sich in erster Linie auf industrielle Roboter oder auch industrielle Manipulatoren. Die Bezeichnungen Roboter und Manipulator werden daher in dieser Arbeit synonym verwendet. Mechanisch sind sie als serielle Kette zu beschreiben, in der jedes Glied, bis auf das erste und letzte, mit einem anderen Glied über ein Gelenk verbunden ist~\cite{siciliano_springer_2008}. Typischer Weise besitzen solche Manipulatoren einen Endeffektor, der zur Handhabung, Montage und Bearbeitung von Werkstücken konzipiert ist und entsprechend der zu erledigenden Aufgabe zu wählen ist.
+Diese Arbeit bezieht sich in erster Linie auf industrielle Roboter oder auch industrielle Manipulatoren. Die Bezeichnungen Roboter und Manipulator werden daher in dieser Arbeit synonym verwendet. Mechanisch sind sie als serielle Kette zu beschreiben, in der jedes Glied, bis auf das erste und letzte, mit zwei weiteren Gliedern über jeweils ein Gelenk verbunden ist~\cite{siciliano_springer_2008}. Typischer Weise besitzen solche Manipulatoren einen Endeffektor, der zur Handhabung, Montage und Bearbeitung von Werkstücken konzipiert ist und entsprechend der zu erledigenden Aufgabe zu wählen ist.
 
 
 \section{Cobots}
 Roboter sind dem Menschen in vielen Bereichen deutlich überlegen. So sind sie durchgängig einsetzbar und arbeiten weitaus genauer, als es einem Menschen möglich wäre. Die Überwachung und Entscheidungsfindung obliegt jedoch oft noch dem Menschen. Gerade in Bereichen, die ein hohes Maß an individualisierten Arbeitsschritten enthalten, wie beim Zusammenbau von individualisierbaren Komponenten in der Automobilindustrie~\cite{michalos_design_2015}, ist es heute noch nicht praktikabel menschliche Arbeiter vollständig zu ersetzen. Um trotzdem auch die Vorteile des Einsatzes von Robotern auszunutzen, ist es wichtig eine Umgebung zu schaffen, in der Roboter und Menschen sich einen gemeinsamen Arbeitsbereich teilen~\cite{siciliano_springer_2008}.
-In solchen kollaborativen Zellen ist es notwendig, dass der Roboter eine Reihe von Sicherheitsbestimmungen gerecht wird~\cite{ISO_15066} und in der Lage ist, auf unerwartetes Verhalten des Menschen zu reagieren. Indem er sein eigenes Verhalten entsprechend anpasst und dadurch Verletzungen verhindert, kann eine stets sichere Arbeitsumgebung gewährleistet werden~\cite{tactile_internet_ceti}. Erfüllt ein Roboter diese Vorgaben und kann für kollaborative Arbeiten mit Menschen eingesetzt werden, spricht man von einem Cobot.
+In solchen kollaborativen Zellen ist es notwendig, dass der Roboter eine Reihe von Sicherheitsbestimmungen gerecht wird~\cite{ISO_15066} und in der Lage ist, auf unerwartetes Verhalten des Menschen zu reagieren. Indem er sein eigenes Verhalten entsprechend anpasst und dadurch Verletzungen verhindert, kann eine stets sichere Arbeitsumgebung gewährleistet werden~\cite{tactile_internet_ceti}. Erfüllt ein Roboter diese Vorgaben und kann für kollaborative Arbeiten mit Menschen eingesetzt werden, gilt er als Cobot.
 
 \section{Pose}
 Die Pose eines Roboters beschreibt seine Position und Orientierung im Raum~\cite{siciliano_springer_2008}. Im Raum definiert werden kann eine Pose im \glqq Joint Space\grqq{} und im \glqq Cartesian Space\grqq{}. Eine Definition im \glqq Joint Space\grqq{} ist vollständig, da in ihr der Wert jedes Gelenks definiert ist. In der Regel ist aber vor allem die Pose des Endeffektors von Interesse. Durch einer Vorwärtstransformation oder auch Vorwärtskinematik, kann diese Pose anhand der Gelenkwerte bestimmt werden. Eine Beschreibung im \glqq Cartesian Space\grqq{} ist nicht vollständig, da hier lediglich die Pose des Endeffektors, in Form von kartesischen Koordinaten, definiert ist~\cite{yu_chapter_2018}.
@@ -26,9 +25,7 @@ Der Pfad und die Trajektorie beschreiben eine Folge von Posen im Raum, die vom R
 \section{Motion Planning}\label{ch:motion_planning}
 Motion Planning beschreibt die Aufgabe eine kontinuierliche und kollisionsfreie Trajektorie von einem gegebenen Startzustand zu einem Zielzustand zu finden~\cite[Seite 109]{siciliano_springer_2008} \cite{sucan_open_2012}. 
 
-Das Finden einer optimalen Trajektorie ist PSPACE-vollständig und daher schwer zu implementieren und rechnerisch zu lösen. In der Praxis hat sich daher, für die meisten Anwendungsfälle, der alternativer Ansatz des Sampling-Based Planning durchgesetzt~\cite[Kapitel 5.1.3]{siciliano_springer_2008}. 
-
-Ein Sampling-Based Planner greift auf einen vorhandenen Algorithmus zur Kollisionserkennung zurück, der verwendet wird, um einzelne Konfigurationen des Roboters auf Kollisionsfreiheit zu überprüfen. Die Trajektorie entsteht aus einer Kette an kollisionsfreien Konfigurationen, beginnend an der Startkonfiguration und endend an der Zielkonfiguration. Die Schrittgröße zwischen den einzelnen Konfigurationen ist dabei möglichst klein zu wählen, damit davon ausgegangen werden kann, dass es während der Bewegung zwischen ihnen zu keinen Kollisionen kommt.
+Das Finden einer optimalen Trajektorie ist PSPACE-vollständig und daher schwer zu implementieren und rechnerisch zu lösen. In der Praxis hat sich daher, für die meisten Anwendungsfälle, der alternativer Ansatz des Sampling-Based Planning durchgesetzt. Dabei wird eine Menge an kollisionsfreien Konfigurationen im Arbeitsbereich erstellt und erweitert, bis eine Kette von Konfigurationen gefunden wird, die die Start- und Ziel-Pose miteinander verbindet. Zur Überprüfung der Kollisionsfreiheit, greift er auf einen vorhandenen Algorithmus zur Kollisionserkennung zurück. Die Schrittgröße zwischen den einzelnen Konfigurationen ist dabei möglichst klein zu wählen, da für die Bewegung zwischen den Konfigurationen keine weitere Kollisionserkennung erfolgt ~\cite[Kapitel 5.1.3]{siciliano_springer_2008}.
 Diese Art Planer ist auch in der Lage eine Lösung für Systeme mit mehr als drei Freiheitsgraden zu finden~\cite[Kapitel 5.2]{siciliano_springer_2008}. Existiert eine Lösung, so wird diese auch in endlicher Zeit gefunden, jedoch kann die Nicht-Existenz einer Lösung nicht festgestellt werden, wodurch eine Abbruchbedingung notwendig wird, die nach einer bestimmten Zeit die Suche nach einer Trajektorie beendet, um eine Blockierung zu verhindern~\cite{sucan_open_2012}.
 
 \section{Constraints}

sections/implementierung.tex

+\newpage\null\newpage
 \chapter{Fallstudie}\label{ch:implementation}
 Die Fallstudie soll eine Auswahl an Constraints in einem kollaborativen Anwendungsfall implementieren und untersuchen. Die Ausgangssituation bilden zwei Panda Roboterarme des Herstellers Franka Emika\footnote{https://www.franka.de/}. Der erste Roboter nimmt nach Initialisierung durch einen Menschen ein Gefäß auf und füllt dessen Inhalt in ein anderes Gefäß. Die Initialisierung erfolgt, indem ein leerer Behälter auf einem Drucksensor abgestellt wird. Nachdem das erste Gefäß wieder abgestellt wurde, wird das zweite Gefäß aufgenommen und auf einem zweiten Drucksensor in der Nähe des anderen Roboters gestellt. Dieser nimmt das Gefäß auf und stellt es dem menschlichen Nutzer bereit.
 
@@ -16,54 +17,67 @@ Die in der Aufgabenstellung beschriebenen Handlungen der Roboter ergeben folgend
 Um einen reibungslosen Ablauf zu gewährleisten und den gestellten Anforderungen gerecht zu werden, sind folgende Constraints zu implementieren:
 
 \begin{enumerate}
-	\item[C1] Orientierung des Endeffektors: Während der Handhabung von gefüllten Gefäßen, sollen diese stets orthogonal zum Boden orientiert sein.
+	\item[C1] Orientierung des Endeffektors: Während der Handhabung von gefüllten Gefäßen, sollen diese stets orthogonal zum Boden orientiert sein
 	
-	\item[C2] Beschleunigung und Geschwindigkeit: Gefüllte Gefäße müssen vorsichtig bewegt werden, um eine Überschwappen zu verhindern.
+	\item[C2] Beschleunigung und Geschwindigkeit: Gefüllte Gefäße müssen vorsichtig bewegt werden, um ein Überschwappen zu verhindern
 	
-	\item[C3] Arbeitsbereich: Um eine Kollision der beiden Roboter zu vermeiden, soll um die Übergabestelle eine Sicherheitszone eingerichtet werde, die immer nur von einem Roboter geschnitten werden darf.
+	\item[C3] Arbeitsbereich: Um eine Kollision der beiden Roboter zu vermeiden, soll um die Übergabestelle eine Sicherheitszone eingerichtet werde, die immer nur von einem Roboter geschnitten werden darf
 	
-	\item [C4] Handlung: Die Handlungen dürfen nur in der durch die Aufgabenstellung vorgeschriebenen Reihenfolge durchgeführt werden.
+	\item [C4] Handlung: Die Handlungen dürfen nur in der durch die Aufgabenstellung vorgeschriebenen Reihenfolge durchgeführt werden
 \end{enumerate}
 Zusätzlich sind noch weitere handlungsunabhängige Anforderungen zu berücksichtigen:
 \begin{enumerate}
-	\item[A1] Constraints sollen aufgabenspezifisch angewandt und entfernt werden können.
-	\item[A2] Für eine höhere Usability und einer einfacheren Integration in andere Projekte, solle die Größe und Position der Objekte über eine Konfigurationsdatei anpassbar sein.
-	\item[A3] Zur Implementation soll das Robot Operating System (ROS) und das Motion Planning Framework MoveIt verwendet werden.
+	\item[A1] Constraints sollen aufgabenspezifisch angewandt und entfernt werden können
+	\item[A2] Für eine höhere Usability und einer einfacheren Integration in andere Projekte, soll die Größe und Position der Objekte über eine Konfigurationsdatei anpassbar sein
+	\item[A3] Zur Implementierung soll das Robot Operating System (ROS) und das Motion Planning Framework MoveIt verwendet werden
 \end{enumerate}
 
 \section{Entwurf}
 In diesem Abschnitt wird, nach einer kurzen Einführung in ROS und MoveIt ein Entwurf vorgestellt, wie die gestellten Anforderungen aus Abschnitt~\ref{ch:requirements} technisch umgesetzt werden können.
 
 \subsection{Robot Operating System}
-Das Robot Operating System (ROS) ist ein mehrsprachiges open-source Framework zur flexiblen Realisierung komplexer Robotikanwendungen~\cite{quigley_ros_nodate}. In dieser Arbeit verwendet wird die Distribution \glqq ROS Melodic Morenia\grqq{}. Die Grundlage einer ROS Anwendung bilden sogenannte Nodes, die in einer Peer-to-Peer Architektur miteinander kommunizieren können. Im folgenden werden die grundlegenden Begriffe kurz erklärt.
+Das Robot Operating System (ROS) ist ein mehrsprachiges open-source Framework zur flexiblen Realisierung komplexer Robotikanwendungen~\cite{quigley_ros_nodate}. In dieser Arbeit verwendet wird die Distribution \glqq ROS Melodic Morenia\grqq{}. Die Grundlage einer ROS Anwendung bilden sogenannte Nodes, die in einer Peer-to-Peer Architektur miteinander kommunizieren können. Im Folgenden werden die grundlegenden Begriffe kurz erläutert.
 
 \paragraph{Node}
-Ein Node ist ein eigenständiges Softwaremodul und ein eigenständiger Prozess, der parallel zu anderen Nodes ausgeführt werden kann. Ein ROS-basiertes System sollte in der Regel möglichst feingranular aufgebaut und Funktionalitäten in einzelne Nodes gekapselt sein. Ein vollständiges System besteht dementsprechend aus einer Menge an Nodes, die über Messages und Services miteinander kommunizieren. Dies erlaubt eine klare Trennung von Verantwortlichkeiten innerhalb des Systems und reduziert die Code-Komplexität, da zur Ansteuerung anderer Nodes keine Implementierungsdetails bekannt sein müssen.
+Ein Node ist ein eigenständiges Softwaremodul und ein eigenständiger Prozess, der parallel zu anderen Nodes ausgeführt werden kann und verschiedenste Berechnungen und Befehle ausführt. Ein ROS-basiertes System sollte in der Regel möglichst feingranular aufgebaut und Funktionalitäten in einzelne Nodes gekapselt sein. Ein vollständiges System besteht dementsprechend aus einer Menge an Nodes, die über Messages und Services miteinander kommunizieren. Dies erlaubt eine klare Trennung von Verantwortlichkeiten innerhalb des Systems und reduziert die Code-Komplexität, da zur Ansteuerung anderer Nodes keine Implementierungsdetails bekannt sein müssen.
 
 
 \paragraph{Message}
-Eine Message wird in einer Textdatei definiert und beschreibt eine streng typisierte Datenstruktur. In ihr können sowohl primitive Datentypen als auch Arrays von primitiven Datentypen und auch anderen Messages verwendet werden. Dadurch können sich beliebig tiefe Datenstrukturen aufbauen.
+Eine Message wird in einer Textdatei definiert und beschreibt eine streng typisierte Datenstruktur. In ihr können sowohl primitive Datentypen als auch Arrays von primitiven Datentypen und auch anderen Messages verwendet werden. Dadurch können sich beliebig tiefe Datenstrukturen aufbauen. Als Beispiel ist in Quelltext~\ref{lst:msg_example} die Definition der von MoveIt bereitgestellten Orientierungs-Constraint Message dargestellt. Sie enthält einfache Datentypen und weitere Messages.
+
+\newpage
+\begin{lstlisting}[language=C++, caption=Beispieldefinition einer Orientierungs-Constraint Message, label=lst:msg_example]
+	std_msgs/Header header
+	geometry_msgs/Quaternion orientation
+	string link_name
+	float64 absolute_x_axis_tolerance
+	float64 absolute_y_axis_tolerance
+	float64 absolute_z_axis_tolerance
+	float64 weight
+	
+\end{lstlisting}
+
 
 \paragraph{Topic}
 Um eine Message zu senden, veröffentlicht ein Node diese Nachricht auf einem Topic. Definiert ist ein Topic durch einen namensgebenden String, wie zum Beispiel \glqq odometry\grqq{}. Interessiert sich ein Node für die veröffentlichten Informationen, kann er dieses Topic abonnieren und erhält dadurch stets die aktuellsten Daten, sobald diese veröffentlicht wurden.
 Jeder Node kann sowohl mehrere Topics abonnieren als auch auf mehreren Topics seine Nachrichten veröffentlichen. Ebenso können mehrere Nodes auf dem selben Topic veröffentlichen.
-Da Nodes in der Regel nichts über die Existenz der anderen Nodes wissen, werden alle Topics auf dem ROS Master inseriert, bei dem sich jeder Node über die verfügbaren Topics informieren kann.
+Da Nodes in der Regel nichts über die Existenz der anderen Nodes wissen, werden alle Topics auf dem ROS Master inseriert, bei dem sich jeder Node über die verfügbaren Topics informieren kann. Wurde ein Topic abonniert, erfolgt der Datenaustausch allerdings direkt zwischen den Nodes und nicht über den Master.
 
 \paragraph{Service}
-Services bilden einen zweiten Kommunikationsweg für synchrone Kommunikation zwischen zwei Nodes. Ein Service wird durch ein Paar von zwei Messages definiert: Einer Request und einer Response. Auch Services werden beim Master angemeldet. Anders als Topics darf ein Service allerdings nur von einem Node inseriert werden. Andere Nodes können einen Service aufrufen und erhalten eine exklusive Antwort zurück.
+Services bilden einen Kommunikationsweg für synchrone Kommunikation zwischen zwei Nodes. Ein Service wird durch ein Paar von zwei Messages definiert: Einer Request und einer Response. Auch Services werden beim Master angemeldet. Anders als Topics darf ein Service allerdings nur von einem Node inseriert werden. Andere Nodes können einen Service aufrufen und erhalten eine exklusive Antwort zurück.
 
 \paragraph{Master}
 Der ROS Master bietet einen Service zur Registrierung und Namensgebung für alle Nodes, Topics und Services. Er ist auf jedem ROS System vorhanden und wird von jedem Node gekannt. Dadurch ermöglicht er den anderen Nodes sich gegenseitig zu finden, um eine Peer-To-Peer Kommunikation aufzubauen.
 
 \paragraph{Parameter Server}
-Der Parameter Server läuft innerhalb des ROS Masters und dient Nodes um Parameter zu speichern und abzurufen. Diese sind in der Regel statische, nicht-binäre Daten wie Konfigurationsparameter.
+Der Parameter Server läuft innerhalb des ROS Masters und dient Nodes,Parameter zu speichern und abzurufen. Diese sind in der Regel statische, nicht-binäre Daten wie Konfigurationsparameter.
 Unter anderen wird die Beschreibung des Roboters in Form des Unified Robot Description Formats (URDF) oder des Semantic Robot Description Formats (SRDF) hier gespeichert. Diese Beschreibungen spezifizieren sowohl die kinematischen und dynamischen Eigenschaften, die visuelle Repräsentation und das Kollisionsmodell des Roboters~\cite{semantic_robot_description}.
 
 \paragraph{Package}
-Um in einem größeren System nicht alle Nodes manuell starten zu müssen, können sie in einem Package gebündelt und über eine Launch Datei gestartet werden. Die Launch Datei beschreibt die Startparameter der einzelnen Nodes und deren Abhängigkeit zu weiteren Nodes und Packages.
+Um in einem größeren System nicht alle Nodes manuell starten zu müssen, können sie in einem Package gebündelt und über eine Launch Datei gestartet werden. Die Launch Datei beschreibt die Startparameter der einzelnen Nodes und deren Abhängigkeit zu weiteren Nodes und Packages. Neben Nodes kann ein Package auch ROS-unabhängige Software, Konfigurationsdateien und Daten enthalten. Ziel von Packages ist die einfache Wiederverwendung von Softwaremodulen.
 
 \subsection{MoveIt}
-MoveIt\footnote{\url{https://moveit.ros.org/}} ist das primäre Motion-Planning Framework in ROS und bietet eine relativ niedrige Einstiegshürde. \cite{coleman_reducing_2014}. Die Kernfunktionalitäten sind aus austauschbaren Komponenten aufgebaut. Als Standard Motion Planning Plugin wird die Open Motion Planning Library (OMPL), zur Kollisionserkennung die Fast Collision Library (FCL) und für die kinematischen Berechnungen die OROCOS Kinematics and Dynamics Library (KDL) verwendet \cite{chitta_moveitros_2012}.
+MoveIt\footnote{\url{https://moveit.ros.org/}} ist das primäre Motion-Planning Framework in ROS und bietet eine relativ niedrige Einstiegshürde~\cite{coleman_reducing_2014}. Die Kernfunktionalitäten sind aus austauschbaren Komponenten aufgebaut. Als Standard Motion Planning Plugin wird die Open Motion Planning Library (OMPL), zur Kollisionserkennung die Fast Collision Library (FCL) und für die kinematischen Berechnungen die OROCOS Kinematics and Dynamics Library (KDL) verwendet \cite{chitta_moveitros_2012}.
 Die Grundbausteine der MoveIt Architektur sind in Abbildung~\ref{fig:moveit_concepts} dargestellt und werden nachfolgend, auf Grundlage des Referenzbuchs von Anis Koubaa~\cite{koubaa_anis_2016} und der MoveIt Dokumentation~\cite{moveit_concepts_nodate} kurz erklärt.
 
 \begin{figure}
@@ -77,9 +91,9 @@ Die Grundbausteine der MoveIt Architektur sind in Abbildung~\ref{fig:moveit_conc
 Die Move Group ist der zentrale Knoten der MoveIt Architektur. In ihm werden die anderen Komponenten zusammengeführt, um sie dem Nutzer gebündelt zur Verfügung stellen zu können. Zum Ausführen und Planen von Bewegungen, wird eine maschinenlesbare Beschreibung des Roboters benötigt. Diese kann von der Move Group als ROS Node vom ROS Parameter Server abgerufen werden.
 
 \paragraph{Planning Scene}
-Die Planning Scene repräsentiert den aktuellen Zustand des Roboters und dessen Umgebung und wird innerhalb der Move Group von einem Planning Scene Monitor gepflegt. Dieser überwacht drei Topics und sammelt darüber Informationen zum aktuellen Zustand des Roboters, zu Sensordaten und zu weiteren Geometrien beziehungsweise Objekten in der Welt. Durch die im Zustand des Roboters gespeicherten Gelenkwerte, kann die exakte Pose des Roboters festgestellt werden. Ein Objekt, das aufgenommen worden ist, wird fest mit dem virtuellen Modell des Roboters verbunden, sodass es in der weiteren Pfadplanung mit berücksichtigt werden kann. Die Umgebung kann sowohl mit Hilfe von externen Sensoren modelliert, als auch durch vom Nutzer erstellte Kollisionsobjekten beeinflusst werden. Das resultierende Modell der Umgebung kann anschließend auf zwei Arten repräsentiert werden~\cite{chitta_moveitros_2012}:
+Die Planning Scene repräsentiert den aktuellen Zustand des Roboters und dessen Umgebung und wird innerhalb der Move Group von einem Planning Scene Monitor gepflegt. Dieser überwacht jeweils ein Topic zum aktuellen Zustand des Roboters, zu Sensordaten und zu weiteren Geometrien beziehungsweise Objekten in der Welt. Durch die im Zustand des Roboters gespeicherten Gelenkwerte, kann die exakte Pose des Roboters festgestellt werden. Ein Objekt, das aufgenommen worden ist, wird fest mit dem virtuellen Modell des Roboters verbunden, sodass es in der weiteren Pfadplanung mit berücksichtigt werden kann. Die Umgebung kann sowohl mit Hilfe von externen Sensoren modelliert, als auch durch vom Nutzer erstellte Kollisionsobjekten beeinflusst werden. Das resultierende Modell der Umgebung kann anschließend auf zwei Arten repräsentiert werden~\cite{chitta_moveitros_2012}:
 \begin{enumerate}
-	\item Voxel: Die Welt wird in dreidimensionale Zellen aufgeteilt und der Zustand jeder Zelle kann entweder markiert, frei oder unbekannt sein\footnote{\url{http://wiki.ros.org/voxel\_grid}}
+	\item Voxel: Die Welt wird in dreidimensionale Zellen aufgeteilt und der Zustand jeder Zelle kann entweder belegt, frei oder unbekannt sein\footnote{\url{http://wiki.ros.org/voxel\_grid}}
 	
 	\item Geometrische Primitive oder Netzmodelle: Eine Dreidimensionale Beschreibung von bekannten Objekten und Hindernissen
 \end{enumerate}
@@ -92,7 +106,7 @@ Um die Trajektorie auf dem Roboter auszuführen, muss dieser ein \glqq FollowJoi
 
 \begin{figure}
 	\centering
-	\includegraphics[height=\textheight, width=\textwidth, keepaspectratio]{images/Ablaufdiagramm.jpg} 
+	\includegraphics[height=0.98\textheight, width=\textwidth, keepaspectratio]{images/Ablaufdiagramm.jpg} 
 	\caption{Ablaufdiagramme für die Aufgaben der zwei Cobots.}
 	\label{fig:ablaufdiagramm}
 \end{figure}
@@ -111,11 +125,11 @@ Die beiden Roboter der Fallstudie werden als separate Entitäten behandelt und s
 \end{enumerate}
 Die aufgelisteten Constraints gelten für beide Cobots.
 
-Die Sicherheitszone zwischen den Robotern - einschließlich des Übergabeorts - wird von einer weiteren Entität kontrolliert. Will ein Roboter die Sicherheitszone betreten, muss er dieses Recht bei dem Controller anfordern. Der Controller sorgt dafür, dass immer nur ein Roboter dieses Recht erhält. Erst nachdem sich der erste Roboter wieder abmeldet, darf der zweite die Sicherheitszone betreten. Dieser Vorgang (einschließlich der Aktivierung der Roboter durch die Drucksensoren) ist im Sequenzdiagramm ~\ref{fig:sequenzdiagramm} dargestellt.
+Die Sicherheitszone zwischen den Robotern - einschließlich des Übergabeorts - wird von einer weiteren Entität kontrolliert. Will ein Roboter die Sicherheitszone betreten, muss er dieses Recht bei dem Controller anfordern. Der Controller sorgt dafür, dass immer nur ein Roboter dieses Recht erhält. Ist die Zone bereits belegt, gibt er eine negative Antwort zurück. Der abgelehnte Roboter kann anschließend beliebig oft neue Anfragen senden. Erst nachdem sich der erste Roboter wieder abmeldet, darf der zweite die Sicherheitszone betreten. Dieser Vorgang (einschließlich der Aktivierung der Roboter durch die Drucksensoren) ist im Sequenzdiagramm~\ref{fig:sequenzdiagramm} dargestellt.
 
 \begin{figure}
 	\centering
-	\includegraphics[height=\textheight, width=\textwidth, keepaspectratio]{images/Sequenzdiagramm.jpg} 
+	\includegraphics[height=\textheight, width=\textwidth, keepaspectratio]{images/Sequenzdiagramm.png} 
 	\caption{Rechtevergabe für die Sicherheitszone zwischen den zwei Cobots.}
 	\label{fig:sequenzdiagramm}
 \end{figure}
@@ -123,54 +137,54 @@ Die Sicherheitszone zwischen den Robotern - einschließlich des Übergabeorts -
 
 \begin{figure}
 	\centering
-	\includegraphics[height=\textheight, width=\textwidth, keepaspectratio]{images/Klassendiagramm Cobot.jpg} .
-	\caption{Entwurfsklassendiagramm eines Cobots}
+	\includegraphics[height=0.95\textheight, width=\textwidth, keepaspectratio]{images/Klassendiagramm Cobot.jpg} .
+	\caption{Entwurfsklassendiagramm des ersten Cobots}
 	\label{fig:klassendiagramm}
 \end{figure}
 
-Zusammenfassend ergeben sich aus Entwurfssicht die im Entwurfsklassendiagramm~\ref{fig:klassendiagramm} dargestellten Entitäten. Ein \textit{Cobot} kennt seine Startposition, die gleichzeitig als sicherer Zustand dient, alle Handlungen, die er prinzipiell ausführen kann und eine beliebige Anzahl an Constraints, die individuell angewandt oder entfernt werden können. Um die Anwendung an dieser Stelle für weitere Constraints erweiterbar zu halten, muss jeder Constraint die abstrakte Klasse \textit{Constraint} implementieren. Der \textit{SafezoneController} speichert den Zustand der Sicherheitszone und kann Zugang zu ihr entweder gewähren oder ablehnen. Ein Drucksensor stellt die Information über seinen Druckzustand zur Verfügung.
+Aus der Entwurfssicht ergeben sich die im Entwurfsklassendiagramm in Abbildung~\ref{fig:klassendiagramm} dargestellten Entitäten. Das Klassendiagramm für den zweiten Cobot unterscheidet sich lediglich in der \textit{Cobot} Klasse, da dieser keine Handlungen mit der Flasche durchführt. Ein \textit{Cobot} kennt seine Startposition, die gleichzeitig als sicherer Zustand dient, alle Handlungen, die er prinzipiell ausführen kann und eine beliebige Anzahl an Constraints, die individuell angewandt oder entfernt werden können. Um die Anwendung an dieser Stelle für weitere Constraints erweiterbar zu halten, muss jeder Constraint die abstrakte Klasse \textit{Constraint} implementieren. Der \textit{SafezoneController} speichert den Zustand der Sicherheitszone und kann Zugang zu ihr entweder gewähren oder ablehnen. Ein Drucksensor stellt die Information über seinen Druckzustand zur Verfügung.
 
-Da ein Cobot nicht weiß, wann und in welcher Reihenfolge er seine Handlungen ausführen soll, wird er von einem \textit{CobotController} gesteuert. Dieser implementiert eins der Ablaufdiagramme aus Abbildung~\ref{fig:ablaufdiagramm} und ist außerdem zuständig für die Kommunikation mit \textit{SafeZoneController} und \textit{PressureSensor} und dem Hinzufügen von Objekten in die PlanningScene. Entsprechend Anforderung A2 sollen diese Objekte konfigurierbar sein. Die drei Einheiten \textit{CobotController}, \textit{SafeZoneController} und \textit{PressureSensor} laufen unabhängig voneinander und können in einem ROS System als eigenständige Nodes implementiert werden. Dadurch kann die Kommunikation dann entsprechend der Abbildung~\ref{fig:node_communication} realisiert werden. 
+Da ein Cobot nicht weiß, wann und in welcher Reihenfolge er seine Handlungen ausführen soll, wird er von einem \textit{CobotController} gesteuert. Dieser implementiert eins der Ablaufdiagramme aus Abbildung~\ref{fig:ablaufdiagramm} und ist außerdem zuständig für die Kommunikation mit \textit{SafeZoneController} und \textit{PressureSensor} und dem Hinzufügen von Objekten in die PlanningScene mit Hilfe des \textit{ObjectCreators}. Entsprechend Anforderung A2 sollen diese Objekte konfigurierbar sein. Die drei Einheiten \textit{CobotController}, \textit{SafeZoneController} und \textit{PressureSensor} laufen unabhängig voneinander und können in einem ROS System als eigenständige Nodes implementiert werden. Dadurch kann die Kommunikation entsprechend der Abbildung~\ref{fig:node_communication} realisiert werden. 
 \begin{figure}
 	\centering
-	\includegraphics[height=\textheight, width=\textwidth, keepaspectratio]{images/NodeCommunication.png} 
+	\includegraphics[height=0.95\textheight, width=\textwidth, keepaspectratio]{images/NodeCommunication.jpg} 
 	\caption{Kommunikation zwischen den Nodes}
 	\label{fig:node_communication}
 \end{figure}
-Die Drucksensoren veröffentlichen ihren Zustand auf einem Topic, welches von dem \textit{CobotController} abonniert wird (gekennzeichnet durch den durchgezogenen Pfeil). Für die Anfrage an den \textit{SafezoneController} bietet eine Implementierung als ROS Service an (gekennzeichnet durch gestrichelte Pfeile).
+Die Drucksensoren veröffentlichen ihren Zustand auf einem Topic, welches von dem \textit{CobotController} abonniert wird (gekennzeichnet durch den durchgezogenen Pfeil). Für die Anfrage an den \textit{SafezoneController} bietet eine Implementierung als ROS Service an (gekennzeichnet durch die gestrichelten Pfeile).
 
 
 \section{Implementierung}
-Implementiert wurde die Demo in \textit{C++} und der ROS Distribution ROS Melodic Morenia auf einem Ubuntu 18.04 System. Zur Kapselung von Verantwortlichkeiten und für eine bessere Wiederverwendbarkeit, ist die Implementation in mehrere Packages aufgeteilt, die über Cmake miteinander gelinkt werden. In den folgenden Abschnitten wird auf die zentralen Packages einzeln eingegangen.
+Implementiert wurde die Demo in \textit{C++} und der ROS Distribution ROS Melodic Morenia auf einem Ubuntu 18.04 System. Zur Kapselung von Verantwortlichkeiten und für eine bessere Wiederverwendbarkeit, ist die Implementierung in mehrere Packages aufgeteilt, die über CMake miteinander gelinkt werden. In den folgenden Abschnitten wird auf die zentralen Packages einzeln eingegangen.
 
 \subsection{Cobot}\label{ch:cobot_impl}
-Die Pakete \textit{cobot\_1} und \textit{cobot\_2} enthalten jeweils die Implementationen des \textit{CobotController} und der \textit{Cobot}-Klasse. Der \textit{CobotController} ist nicht als tatsächliche Klasse im Sinne der Objektorientierung implementiert, sondern als ROS Node. Das bedeutet er enthält eine Main Methode, die als Einstiegspunkt gilt, sobald er durch den ROS Master initialisiert wird. 
+Die Packages \textit{cobot\_1} und \textit{cobot\_2} enthalten jeweils die Implementierungen des \textit{CobotController} und der \textit{Cobot}-Klasse. Der \textit{CobotController} ist nicht als tatsächliche Klasse im Sinne der Objektorientierung implementiert, sondern als ROS Node. Das bedeutet er enthält eine Main Methode, die als Einstiegspunkt gilt, sobald er durch den ROS Master initialisiert wird. 
 
-Nach erfolgreicher Initialisierung, wird das Topic \glqq pressure\_1\grqq{} beziehungsweise \glqq pressure\_2\grqq{} abonniert, um informiert zu werden, sobald das Glas auf den Drucksensor abgestellt wird. Ein Service Client wird zum Stellen von Anfragen an den \textit{SafezoneController} erstellt und mit Hilfe des \textit{ObjectCreators} werden die Umgebungsobjekte, wie der Tisch, die Behälter und die Drucksensoren, zur Planning Scene hinzugefügt. Erst anschließend beginnt die Abarbeitung des Ablaufdiagramms~\ref{fig:ablaufdiagramm}. Die einzelnen Zustände beziehungsweise Aufgaben werden von einer \textit{Cobot}-Instanz ausgeführt, die für jede Aufgabe eine entsprechende Methode bereitstellt. Eine Implementation einer solchen Aufgabe ist im Codebeispiel~\ref{lst:pick_bottle} dargestellt.
+Nach erfolgreicher Initialisierung, wird vom Cobot 1 das Topic \glqq pressure\_1\grqq{} und vom Cobot 2 das Topic \glqq pressure\_2\grqq{} abonniert, um informiert zu werden, sobald das Glas auf dem Drucksensor abgestellt wird. Ein Service Client wird zum Stellen von Anfragen an den \textit{SafezoneController} erstellt und mit Hilfe des \textit{ObjectCreators} werden die Umgebungsobjekte, wie der Tisch, die Behälter und die Drucksensoren, zur Planning Scene hinzugefügt. Erst anschließend beginnt die Abarbeitung des Ablaufdiagramms~\ref{fig:ablaufdiagramm}. Die einzelnen Zustände beziehungsweise Aufgaben werden von einer \textit{Cobot}-Instanz ausgeführt, die für jede Aufgabe eine entsprechende Methode bereitstellt. Eine Implementierung einer solchen Aufgabe ist im Codebeispiel~\ref{lst:pick_bottle} dargestellt.
 
-\lstinputlisting[firstline=29,lastline=41, label={lst:pick_bottle}, caption={Beispielimplementation einer Cobot-Aufgabe}]{../cobot_ws/src/cobot_1/src/Cobot.cpp}
+\lstinputlisting[firstline=29,lastline=41, label={lst:pick_bottle}, caption={Beispielimplementierung einer Cobot-Aufgabe}]{../cobot_ws/src/cobot_1/src/Cobot.cpp}
 
-Alle Aufgaben erwarten eine Referenz zu einer Move Group, auf der die Bewegung ausgeführt werden soll. Beinhaltet die Aufgabe ein Objekt, wie die Flasche beim Aufnehmen der Flasche, wird zusätzlich noch eine \textit{CollisionObject}-Beschreibung dieses Objektes benötigt, da in ihr Größe und Position des Objektes definiert ist. Die tatsächliche Implementation, zum Aufnehmen und Platzieren von Objekten, ist in einem weiteren Package ausgelagert, damit beide Cobots auf diese Funktionalität zugreifen können und Codeduplikate vermieden werden. Nach Ausführung der Bewegung, werden die notwendigen Constraints angepasst und dem \textit{CobotController}, in Form eines booleschen Werts, den Erfolg der Ausführung zurückgegeben. Die Constraints werden im Konstruktor des \textit{Cobot}s als Klassenvariablen instanziiert und lassen sich so innerhalb der Handlungen anwenden und entfernen.
+Alle Aufgaben erwarten eine Referenz zu einer Move Group, auf der die Bewegung ausgeführt werden soll. Beinhaltet die Aufgabe ein Objekt, wie die Flasche beim Aufnehmen der Flasche, wird zusätzlich noch eine \textit{CollisionObject}-Beschreibung dieses Objektes benötigt, da in ihr Größe und Position des Objektes definiert ist. Die tatsächliche Implementierung, zum Aufnehmen und Platzieren von Objekten, ist in einem weiteren Package ausgelagert, damit beide Cobots auf diese Funktionalität zugreifen können und Codeduplikate vermieden werden. Nach Ausführung der Bewegung, werden die notwendigen Constraints angepasst und dem \textit{CobotController}, in Form eines booleschen Werts, den Erfolg der Ausführung zurückgegeben. Die Constraints werden im Konstruktor des \textit{Cobot}s als Klassenvariablen instanziiert und lassen sich so innerhalb der Handlungen anwenden und entfernen.
 
 Neben dem Programmcode enthält das Cobot Package auch noch eine Konfigurationsdatei, in der die vorhandenen Objekte und die Eigenschaften des Sensors beschrieben sind. Dadurch lässt sich die Ausgangssituation anpassen, ohne dass Änderungen am Programmcode notwendig sind, was die Nutzerfreundlichkeit erheblich steigert. Beim Start des Nodes werden die Parameter auf den Parameter Server veröffentlicht, wodurch sie auch von jedem anderen Node abgerufen werden können. Die Position der Flasche auf der X-Achse wird zum Beispiel durch den Parameter \verb|/object/bottle/x: 0.5| konfiguriert. Die Namensgebung der Parameter folgt dabei der ROS-Namenskonvention, um eine Überschneidung auf dem Parameter Server zu vermeiden.
 
-Über die Launch Datei des Packages startet neben dem \textit{CobotController} auch den \textit{SafezoneController}- und \textit{PressureSensor}-Node und eine Simulationsumgebung.
+Die Launch Datei des Packages startet neben dem \textit{CobotController} auch den \textit{SafezoneController}- und \textit{PressureSensor}-Node und eine Simulationsumgebung.
 
 \subsection{Constraints}\label{ch:constraint_impl}
-Das Package \textit{constraints} enthält die Definition der abstrakten \textit{Constraint}-Klasse und die vier konkreten Implementationen \textit{AccelerationConstraint}, \textit{OrientationConstraint}, \textit{SafezoneConstraint} und \textit{VelocityConstraint}.
+Das Package \textit{constraints} enthält die Definition der abstrakten \textit{Constraint}-Klasse und die vier konkreten Implementierungen \textit{AccelerationConstraint}, \textit{OrientationConstraint}, \textit{SafezoneConstraint} und \textit{VelocityConstraint}.
 
 Der Orientierungs-Constraint (Codebeispiel~\ref{lst:orientation_constraint}) wird realisiert, indem eine\newline
  \verb|moveit_msgs::OrientationConstraint|-Nachricht erstellt wird, die die aktuelle Orientierung des Endeffektors festsetzt. Diese Nachricht wird dann der Move Group als Pfad-Constraint hinzugefügt. Entfernt wird das Constraint durch das Leeren der Liste \verb|path_constraints.orientation_constraints|.
 
-\lstinputlisting[firstline=11,lastline=26, label={lst:orientation_constraint}, caption={Implementation des Orientierungs-Constraint}]{../cobot_ws/src/constraints/src/OrientationConstraint.cpp}
+\lstinputlisting[firstline=11,lastline=26, label={lst:orientation_constraint}, caption={Implementierung des Orientierungs-Constraint}]{../cobot_ws/src/constraints/src/OrientationConstraint.cpp}
 
 Die Beschleunigung und Geschwindigkeit wird beschränkt und wieder freigegeben, indem die Geschwindigkeits- beziehungsweise Beschleunigungsskalierung der Move Group angepasst wird.
 
 Die Sicherheitszone, um den zweiten Drucksensor herum, wird durch das Hinzufügen eines weiteren Objekts zur Planning Scene realisiert, ohne dass dieses auch in der Simulationsumgebung erzeugt wird (siehe Codebeispiel~\ref{lst:safezone_constraint}). Das Erstellen des Kollisionsobjekts geschieht über den \textit{ObjectCreator} (Abschnitt~\ref{ch:objectCreator}). Darf der Roboter die Sicherheitszone betreten, wird das Safezone-Objekt entfernt, indem ein weiteres Objekt mit der selben ID und der \verb|REMOVE| Operation auf die Planning Scene angewandt wird.
-\lstinputlisting[firstline=12,lastline=26, label={lst:safezone_constraint}, caption={Implementation des Safezone-Constraint}]{../cobot_ws/src/constraints/src/SafeZoneConstraint.cpp}
+\lstinputlisting[firstline=12,lastline=26, label={lst:safezone_constraint}, caption={Implementierung des Safezone-Constraint}]{../cobot_ws/src/constraints/src/SafeZoneConstraint.cpp}
 
 \subsection{SafezoneController}
-Der \textit{SafezoneController}-Node stellt einen einfachen ROS Service unter dem Namen \verb|safe_zone_controller| zur Verfügung. Der Zustand der Sicherheitszone (frei/belegt) wird in einer globalen Variable gespeichert. Jede Anfrage an den Service wird von der Callback Funktion in Codebeispiel~\ref{lst:safezone_controller} verarbeitet. Wenn die Sicherheitszone frei ist, sind Anfragen immer erfolgreich, unabhängig davon, ob sie mit \verb|req.occupy == false| erneut freigegeben oder mit \verb|req.occupy == true| belegt werden soll. Ist die Zone bereits belegt, schlägt eine weitere Belegungsanfrage fehl, während das Freigeben der belegten Zone erfolgreich ist. Auf eine Überprüfung des Senders, dass nur der Akteur, der aktuell die Zone belegt, sie auch wieder freigeben kann, wurde an dieser Stelle verzichtet. \textcolor{red}{Ist das bei ROS Services überhaupt möglich?}
+Der \textit{SafezoneController}-Node stellt einen einfachen ROS Service unter dem Namen \verb|safe_zone_controller| zur Verfügung. Der Zustand der Sicherheitszone (frei/belegt) wird in einer globalen Variable gespeichert. Jede Anfrage an den Service wird von der Callback Funktion in Codebeispiel~\ref{lst:safezone_controller} verarbeitet. Wenn die Sicherheitszone frei ist, sind Anfragen immer erfolgreich, unabhängig davon, ob sie mit \verb|req.occupy == false| erneut freigegeben oder mit \verb|req.occupy == true| belegt werden soll. Ist die Zone bereits belegt, schlägt eine weitere Belegungsanfrage fehl, während das Freigeben der belegten Zone erfolgreich ist. Auf eine Überprüfung des Senders, dass nur der Akteur, der aktuell die Zone belegt, sie auch wieder freigeben kann, wurde an dieser Stelle verzichtet.
 
 \lstinputlisting[firstline=17,lastline=32, label={lst:safezone_controller}, caption={Callback Funktion des SafezoneController}]{../cobot_ws/src/safe_zone_controller/src/SafeZoneController.cpp}
 
@@ -180,4 +194,4 @@ Das package \textit{object\_creator} enthält die Klassen \textit{ObjectCreator}
 Anhand dieses Objekts kann der \textit{ObjectCreator} entsprechende Kollisionsobjekte erstellen und diese zur Planning Scene hinzufügen. Optional kann das erstellte Objekt auch zur Simulationsumgebung hinzugefügt werden.
 
 \subsection{PressureSensor}
-Als Drucksensor wird die Tinkerforge Load\_Cell\_V2\footnote{\url{https://www.tinkerforge.com/de/doc/Hardware/Bricklets/Load_Cell_V2.html}} verwendet. Für den Sensor steht ein \textit{C/C++} API Binding zur Verfügung, welches mit im \textit{pressure\_sensor} Package liegt und vom \textit{PressureSensor}-Node eingebunden wird. Dieser inseriert das \verb|pressure| Topic beim ROS Master und lädt die Konfigurationsparameter des Drucksensors vom ROS Parameter Server. Die Parameter enthalten sowohl die Adresse des Sensors als auch den Grenzwert in Gramm, ab dem das Glas als vorhanden angesehen werden soll. Bei jeder Änderung in der Messung, wird das Gewicht neu ausgewertet und der Zustand auf dem Topic veröffentlicht. 
+Als Drucksensor wird die Tinkerforge Load\_Cell\_V2\footnote{\url{https://www.tinkerforge.com/de/doc/Hardware/Bricklets/Load_Cell_V2.html}} verwendet. Für den Sensor steht ein \textit{C/C++} API Binding zur Verfügung, welches Teil des \textit{pressure\_sensor} Packages ist und vom \textit{PressureSensor}-Node eingebunden wird. Dieser inseriert das \verb|pressure| Topic beim ROS Master und lädt die Konfigurationsparameter des Drucksensors vom ROS Parameter Server. Die Parameter enthalten sowohl die Adresse des Sensors als auch den Grenzwert in Gramm, ab dem das Glas als vorhanden angesehen werden soll. Bei jeder Änderung in der Messung, wird das Gewicht neu ausgewertet und der Zustand auf dem Topic veröffentlicht. 

sections/tax_einordnung.tex

@@ -11,7 +11,7 @@ Im folgenden werden mögliche Arten von Constraints für die Pfadgenerierung (Mo
 
 
 \section{Pfad-Constraints}
-Der Pfad resultiert aus einem erfolgreichen Motion Planning. Die Berechnung eines möglichen Pfads hängt sowohl vom Arbeitsbereich des Roboters ab, als auch von angehängten Objekten oder Teilpfaden beziehungsweise Wegpunkten, die abgefahren werden müssen.
+Der Pfad resultiert aus einem erfolgreichen Motion Planning. Die Berechnung eines möglichen Pfads hängt sowohl vom Arbeitsbereich des Roboters ab als auch von angehängten Objekten oder Teilpfaden beziehungsweise Wegpunkten, die abgefahren werden müssen.
 
 \subsection{Arbeitsbereich}
 Der Arbeitsbereich eines Roboters beschreibt alle vom Endeffektor erreichbaren Punkte im Raum~\cite{siciliano_springer_2008}. Dabei lässt er sich nochmals in einen primären und sekundären Arbeitsbereich unterteilen. Der primäre Bereich enthält alle Punkte, die vom Endeffektor aus jeder Richtung, mit beliebiger Orientierung erreicht werden können. Der sekundäre Bereich ist eine Obermenge des primären Bereichs und enthält alle überhaupt erreichbaren Punkte~\cite{gupta_nature_1986}.
@@ -24,14 +24,14 @@ Der Wirkungsbereich eines Roboters beschreibt seinen theoretisch maximalen Arbei
 \subsubsection{Kollaboration}
 Die Kollaboration mit Menschen oder anderen Robotern resultiert in weiteren Constraints, die sowohl beim Entwurf der Arbeitsumgebung, als auch beim Motion Planning berücksichtigt werden müssen. Eine sichere Kollaboration kann auf verschiedene Wege erreicht werden.
 
-\paragraph{Sicherheitszonen}Matthias et al.~\cite{matthias_safety_2011} beschreiben eine Arbeitsumgebung, in der sich Roboter und Mensch ohne weitere Sicherheitsmechanismen permanent einen Arbeitsbereich teilen und der Roboter zu jeder Zeit harmlos für den Menschen sein soll. Sie präsentieren ein Sicherheitskonzept, welches es ermöglicht die Pfadplanung und -ausführung durchzuführen, ohne dass der Arbeitsbereich durch weitere Sensoren überwacht werden muss. Dazu werden folgende Anforderungen an den Cobot gestellt:
+\paragraph{Sicherheitszonen}Matthias et al.~\cite{matthias_safety_2011} beschreiben eine Arbeitsumgebung, in der sich Roboter und Mensch ohne weitere Sicherheitsmechanismen permanent einen Arbeitsbereich teilen und der Roboter zu jeder Zeit harmlos für den Menschen ist. Sie präsentieren ein Sicherheitskonzept, welches es ermöglicht die Pfadplanung und -ausführung durchzuführen, ohne dass der Arbeitsbereich durch weitere Sensoren überwacht werden muss. Dazu werden folgende Anforderungen an den Cobot gestellt:
 \begin{enumerate}
 	\item Mechanische Maßnahmen / Soft Robotics
 	\begin{enumerate}
-		\item Leichtbauweise mit, der Nutzlast entsprechenden, Drehmomenten
+		\item Leichtbauweise mit der Nutzlast entsprechenden Drehmomenten
 		\item Glieder und Aktuatoren aus verformbaren Materialien~\cite{soft_robotics_2018}
 		\item Gepolsterte und abgerundete Oberflächen 
-		\item \glqq Back-drivability\grqq{} - die Möglichkeit den Roboter trotz aktiver Bremsen manuell bewegen zu können.
+		\item \glqq Back-drivability\grqq{} - die Möglichkeit den Roboter trotz aktiver Bremsen manuell bewegen zu können
 	\end{enumerate}
 	\item Kontrollmaßnahmen
 	\begin{enumerate}
@@ -44,13 +44,13 @@ Die Kollaboration mit Menschen oder anderen Robotern resultiert in weiteren Cons
 Können diese Anforderungen nicht erfüllt werden, ist es notwendig den Arbeitsbereich zu überwachen, um auf die Anwesenheit eines Menschen oder anderen Roboters reagieren zu können. Eine allgemeine Möglichkeit, zur Modellierung einer Roboter Applikation, ist aus allen verfügbaren Informationen ein Weltmodell zu erstellen, welches alle Entitäten in der Umgebung des Roboters und den Roboter selbst enthält und ein Bewegungsmodell, welches alle Bewegungen beschreibt~\cite{tactile_internet_ceti}. Für Anwendungen, in denen es zu einer Überschneidung der Arbeitsbereiche kommen kann, können innerhalb des Weltmodells Sicherheitszonen definiert werden, die das Verhalten und die Bewegungsplanung des Roboters beeinflussen~\cite{tactile_internet_ceti}. George Michalos et al.~\cite{michalos_design_2015} definieren vier Strategien, wie auf das Auftreten eines neuen Hindernisses in einer solchen Sicherheitszone reagiert werden kann:
 
 \begin{enumerate}
-	\item Die Geschwindigkeit und Kraft wird limitiert, um die Verletzungsgefahr zu minimieren. Auch Yamada et al.~\cite{yamada_human-robot_1997} zeigten in einer Untersuchung zur menschlichen Schmerztoleranz, dass Kollisionen mit einer Kontaktkraft von bis zu $50 N$ für Mensch-Roboter Interaktionen praktikabel sind.
+	\item Die Geschwindigkeit und Kraft wird limitiert, um die Verletzungsgefahr zu minimieren. Auch Yamada et al.~\cite{yamada_human-robot_1997} zeigten in einer Untersuchung zur menschlichen Schmerztoleranz, dass Kollisionen mit einer Kontaktkraft von bis zu $50 N$ für Mensch-Roboter Interaktionen praktikabel sind
 	
 	\item Alle Operationen und Bewegungen des Roboters werden gestoppt
 	
 	\item Eine Kollision wird vermieden, indem ein neuer, kollisionsfreier Pfad geplant wird
 	
-	\item Wurde eine Sicherheitszone außerhalb des aktiven Arbeitsbereichs definiert, kann der menschliche Arbeiter gewarnt werden, bevor dieser den Arbeitsbereich betritt und eine der ersten drei Reaktionen provoziert.
+	\item Wurde eine Sicherheitszone außerhalb des aktiven Arbeitsbereichs definiert, kann der menschliche Arbeiter gewarnt werden, bevor dieser den Arbeitsbereich betritt und eine der ersten drei Reaktionen provoziert
 \end{enumerate}
 
 
@@ -71,27 +71,28 @@ Im folgenden Abschnitt werden diese Möglichkeiten kurz erläutert.
 
 \begin{figure}
 	\centering	
-	\includegraphics[height=\textheight, width=\textwidth, 		  	keepaspectratio]{images/Hinderniss_Taxonomie.png}	
+	\includegraphics[height=\textheight, width=\textwidth, 		  	keepaspectratio]{images/Hinderniss_Taxonomie.jpg}	
 	\caption{Taxonomie der Vorgehensweisen zur Hindernisvermeidung nach~\cite[Kapitel 35.9]{siciliano_springer_2008}}
 	\label{fig:obstacle_tax}
 \end{figure}
 
 
 \subsubsection{Ein-Schritt-Methoden}
-Ein-Schritt-Methoden sind Techniken zur Hindernisvermeidung, die Sensordaten direkt zur Bewegungssteuerung verwenden, ohne weitere Zwischenberechnungen durchzuführen. Dazu zählen Methoden, die auf physikalischen Analogien basieren. Ein Beispiel für eine solche Analogie ist die Potentialfeldmethode, wo der Roboter als Partikel unter dem Einfluss eines Kräftefeldes angesehen wird. Die Zielposition übt eine anziehende Kraft auf das Partikel aus während es von Hindernissen abgestoßen wird. Die resultierende Bewegung ergibt sich aus der Summer der einwirkenden Kräfte. Heuristische Methoden sind von klassischen Planungsmethoden abgeleitet~\cite[Kapitel 35.9]{siciliano_springer_2008}. Ein Beispiel wäre das in Abschnitt~\ref{ch:motion_planning} erklärte Sampling-Based Planning.
+Ein-Schritt-Methoden sind Techniken zur Hindernisvermeidung, die Sensordaten direkt zur Bewegungssteuerung verwenden, ohne dass weitere Zwischenberechnungen notwendig sind. Dazu zählen Methoden, die auf physikalischen Analogien basieren. Ein Beispiel für eine solche Analogie ist die Potentialfeldmethode, wo der Roboter als Partikel unter dem Einfluss eines Kräftefeldes angesehen wird. Die Zielposition übt eine anziehende Kraft auf das Partikel aus während es von Hindernissen abgestoßen wird. Die resultierende Bewegung ergibt sich aus der Summer der einwirkenden Kräfte. Heuristische Methoden sind von klassischen Planungsmethoden abgeleitet~\cite[Kapitel 35.9]{siciliano_springer_2008}. Ein Beispiel wäre das in Abschnitt~\ref{ch:motion_planning} erklärte Sampling-Based Planning.
 
 
 \subsubsection{Mehr-Schritt-Methoden}
 Bei Mehr-Schritt-Methoden werden Zwischeninformationen berechnet, die verarbeitet werden müssen, um eine Bewegung zu erhalten. Diese Methoden sind zum einen solche, die eine Untermenge an Bewegungsrichtungen berechnen, wie das Vektor-Feld-Histogramm oder die Hindernis-Begrenzungs-Methode und solche, die eine Menge an Geschwindigkeitsreglungen berechnen, wie der dynamische Fensteransatz oder die Methode der Geschwindigkeitshindernisse. Nachfolgend werden die Grundkonzepte dieser Methoden kurz dargestellt.
 
 \paragraph{Vektor-Feld-Histogramm}
-Die Welt werden vom Roboter ausgehen in Sektoren aufgeteilt. Den Sektoren wird anschließend die Dichte an Hindernissen zugeteilt, sodass ein Polarhistogramm entsteht. Die Sektoren mit der kleinsten Dichte, die gleichzeitig am nächsten zu dem Sektor sind, der das Ziel enthält, werden als Kandidaten ausgewählt. Liegt das Ziel innerhalb eines der Sektoren, wird dieser als Richtung gewählt. Liegt das Ziel außerhalb, wird der Sektor mit der geringsten Dichte gewählt. Da Hindernisse durch Wahrscheinlichkeitsdichten repräsentiert sind, eignet sich diese Methode gut bei Verwendung von Sensoren mit höherer Unsicherheit, wie zum Beispiel Ultraschallsensoren~\cite[Seite 841]{siciliano_springer_2008}.
+Hindernisse werden durch Wahrscheinlichkeiten repräsentiert. Daher eignet sich diese Methode besonders gut bei Verwendung von Sensoren mit höherer Unsicherheit, wie Ultraschallsensoren.
+Die Welt wird vom Roboter ausgehen in Sektoren aufgeteilt. Den Sektoren wird anschließend die Wahrscheinlichkeitsdichte zugeteilt, dass sich in ihnen ein Hindernis befindet. Dadurch entsteht ein Polarhistogramm. Die Sektoren mit der kleinsten Dichte, die gleichzeitig am nächsten zu dem Sektor sind, der das Ziel enthält, werden als Kandidaten ausgewählt. Liegt das Ziel innerhalb eines der Sektoren, wird dieser als Richtung gewählt. Liegt das Ziel außerhalb, wird der Sektor mit der geringsten Dichte gewählt ~\cite[Seite 841]{siciliano_springer_2008}.
 
 \paragraph{Hindernis-Begrenzungs-Methode}
 Im ersten Schritt werden Zwischenziele definiert, wenn das eigentliche Ziel nicht auf direktem Wege erreichbar ist. Diese Zwischenziele liegen entweder zwischen Hindernissen oder auf der Kante eines Hindernisses. Das Zwischenziel mit dem geringsten Abstand zum Ziel wird als neues Ziel festgelegt. Für jedes Hindernis wird eine Menge an unerwünschten Richtungen berechnet, die für eine erfolgreiche Hindernisvermeidung ungeeignet wären. Im letzten Schritt wird ein Kompromiss berechnet, in dem aus den erlaubten Richtungen die ausgewählt wird, die sich dem Ziel annähert, gleichzeitig aber einen möglichst großen Abstand zu den Hindernissen hat. Da die Bewegungsgeschwindigkeit invers proportional zum Abstand zu den Hindernissen ist, wird diese dadurch ebenfalls optimiert. Als effektiv hat sich diese Methode vor allem in beengten Räumen gezeigt~\cite[Seite 842]{siciliano_springer_2008}.
 
 \paragraph{Dynamischer Fensteransatz}
-Die Menge an Kandidaten-Geschwindigkeitsregelungen ist eine Teilmenge aller Regelungen, die noch ein Abbremsen ermöglichen, bevor es zu einer Kollision kommt, und die ihren Zielwert in vorgegebener Zeit erreichen können. Im zweiten Schritt wird die Regelung gewählt, die eine gewichtete Summe aus der Näherung an das Ziel, den Abstand zu Hindernissen und die ausführbare Geschwindigkeit maximiert. Der Dynamische Fensteransatz eignet sich vor allem für Roboter mit langsamen dynamischen Reaktionsmöglichkeiten oder für die Arbeit mit hohen Geschwindigkeiten~\cite[Kapitel 35.9.4 ]{siciliano_springer_2008}.
+Im ersten Schritt wird eine Menge an Kandidaten Geschwindigkeitsregelungen, die noch ein Abbremsen ermöglichen, bevor es zu einer Kollision kommt, und die ihren Zielwert in vorgegebener Zeit erreichen können. Im zweiten Schritt wird die Regelung gewählt, die eine gewichtete Summe aus der Annäherung an das Ziel, den Abstand zu Hindernissen und die ausführbare Geschwindigkeit maximiert. Der Dynamische Fensteransatz eignet sich vor allem für Roboter mit langsamen dynamischen Reaktionsmöglichkeiten oder für die Arbeit mit hohen Geschwindigkeiten~\cite[Kapitel 35.9.4 ]{siciliano_springer_2008}.
 
 \paragraph{Geschwindigkeitshindernisse}
 Die Methode der Geschwindigkeitshindernisse folgt den selben Annahmen wie der dynamische Fensteransatz, mit dem Unterschied, dass auch die Geschwindigkeiten der Hindernisse berücksichtigt werden. Dadurch eignet sie sich besonders für dynamische Anwendungsfälle~\cite[Kapitel 35.9.5]{siciliano_springer_2008}.
@@ -103,15 +104,15 @@ Eine allgemein optimale  Methode lässt sich nicht festlegen. Diese hängt von d
 In einigen Anwendungsfällen, wie beispielsweise dem Schweißen, ist es notwendig, dass der Endeffektor des Roboters zwischen Start- und Zielposition einen vorgegebenen Pfad abfährt. Befindet sich der Teilpfad vollständig innerhalb des stationären Arbeitsbereichs, können seine Punkte einfach als Zwischenziele im Motion Planning berücksichtigt werden. Beim Einsatz von mobilen Manipulatoren kann der zu folgende Teilpfad auch außerhalb des aktuellen Arbeitsbereichs sein, da sich dieser durch die Bewegung im Raum verändert~\cite{oriolo_motion_2005}. 
 
 \subsection{Angefügte Objekte}
-Nimmt ein Roboter ein Objekt auf, vergrößert dieses die Geometrie beziehungsweise die Maße des Roboters. Wird das Objekt beim Motion Planning nicht berücksichtigt, kann dies bei den folgenden Bewegungen zu unerwarteten Kollisionen führen. Dazu kann die Geometrie des Objektes dem kinematischen Modell des Roboters angefügt werden, sodass das Objekt aus Sicht des Motion Planning Algorithmus ein Teil des Roboters wird~\cite{sucan_open_2012}. Aufgenommene Objekte beschränken daher ebenfalls die Menge an gültigen Trajektorien.
+Nimmt ein Roboter ein Objekt auf, vergrößert dieses Objekt die Geometrie beziehungsweise die Maße des Roboters. Wird das Objekt beim Motion Planning nicht berücksichtigt, kann dies bei den folgenden Bewegungen zu unerwarteten Kollisionen führen. Dazu kann die Geometrie des Objektes dem kinematischen Modell des Roboters angefügt werden, sodass das Objekt aus Sicht des Motion Planning Algorithmus ein Teil des Roboters wird~\cite{sucan_open_2012}. Aufgenommene Objekte beschränken daher ebenfalls die Menge der gültigen Trajektorien.
 
 \subsection{Abstand}
-In einem unbeschränkten Motion Planning gilt die Pfadplanung als erfolgreich, sobald diese ausführbar und kollisionsfrei ist. Gerade bei schnelleren Bewegungen kann es sinnvoll sein einen zusätzlichen Sicherheitsabstand zu anderen Objekten zu halten, da ansonsten schon kleine Ungenauigkeiten in der Beschreibung der Welt zu Kollisionen führen können~\cite{canny_kinodynamic_nodate}. Die Einhaltung dieses Abstandes kann auf zwei Arten realisiert werden.
+In einem unbeschränkten Motion Planning gilt die Pfadplanung als erfolgreich, sobald diese ausführbar und kollisionsfrei ist. Gerade bei schnelleren Bewegungen kann es sinnvoll sein einen zusätzlichen Sicherheitsabstand zu anderen Objekten zu halten, da ansonsten schon kleine Ungenauigkeiten in der Beschreibung der Welt zu Kollisionen führen können~\cite{canny_kinodynamic_nodate}. Die Einhaltung dieses Abstandes kann auf zwei Arten realisiert werden:
 
 \begin{enumerate}
 	\item Padding des Roboters: Ein Sicherheitsabstand wird zu allen Objekten gehalten.
 	
-	\item Padding der Objekte: Der Abstand zu einzelnen Objekten muss eingehalten werden. 
+	\item Padding der Objekte: Ein Abstand zu einzelnen Objekten muss eingehalten werden. 
 \end{enumerate}
 
 
@@ -125,9 +126,7 @@ Neben den physischen Bewegungen können auch die abstrakten Handlungen eines Rob
 Abhängig von dem ausgerüsteten Endeffektor, kann eventuell nur eine Teilmenge aller verfügbaren Handlungen ausgeführt werden. Ein Roboter mit einem Schweißgerät als Endeffektor kann beispielsweise keine Handlungen ausführen, die das Greifen eines Objekts beinhalten. 
 
 \paragraph{Endeffektor-unspezifische Constraints}
-Sobald Aufgaben nicht mehr unabhängig voneinander sind, muss die Handlungswahl des Roboters dahingehend eingeschränkt werden, dass die Kausalität der Handlungen eingehalten wird. So darf es einem Roboter erst möglich sein ein Objekt abzustellen, nachdem er es aufgenommen hat oder eine erfolgreich abgeschlossene Handlung erst zu kommunizieren, nachdem sie tatsächlich ausgeführt wurde.
-
-Roman Froschauer und Rene Lindorfer.~\cite{froschauer_roman_workflow-based_nodate} präsentieren einen Workflow-basierten Programmieransatz, in dem solche Vorbedingungen realisiert und visualisiert werden können. Neben den eigenen Handlungen, können dabei auch Handlungen anderer Akteure, wie die eines weiteren Roboter oder eines Menschen, als Vorbedingungen modelliert werden.
+Sobald Aufgaben nicht mehr unabhängig voneinander sind, muss die Handlungswahl des Roboters dahingehend eingeschränkt werden, dass die Kausalität der Handlungen eingehalten wird. So darf es einem Roboter erst möglich sein ein Objekt abzustellen, nachdem er es aufgenommen hat oder eine erfolgreich abgeschlossene Handlung erst zu kommunizieren, nachdem sie tatsächlich ausgeführt wurde. Roman Froschauer und Rene Lindorfer~\cite{froschauer_roman_workflow-based_nodate} präsentieren einen Workflow-basierten Programmieransatz, in dem solche Vorbedingungen realisiert und visualisiert werden können. Neben den eigenen Handlungen, können dabei auch Handlungen anderer Akteure, wie die eines weiteren Roboter oder eines Menschen, als Vorbedingungen modelliert werden.
 
 \section{Bewegungs-Constraints}
 Die dritte Untergruppe der Constraints sind Beschränkungen in der Bewegung des Roboters. In Abgrenzung zu den Pfad-Constraints, die den Pfad schon während des Planungsschrittes beschränken, schränken Bewegungs-Constraints die physische Bewegung beziehungsweise die Ausführung der Trajektorie ein. Dazu gehören die Beschränkung der Beschleunigung, der Geschwindigkeit, der Orientierung und der Kraft. Diese werden in den folgenden Abschnitten näher erläutert.
@@ -149,6 +148,6 @@ Neben der Begrenzung der Geschwindigkeit aus Sicherheitsgründen können auch au
 Das Bewegen von Objekten erfordert häufig auch die Einschränkung der Beschleunigung. Dies ist insbesondere beim Umgang mit Flüssigkeiten notwendig, um die Trägheit der Flüssigkeit berücksichtigen zu können und so ein unkontrolliertes Überschwappen zu vermeiden \cite{maderna_robotic_2018}.
 
 \subsection{Kraft}
-Die Beschränkung der Kraft kann auf zweierlei Weise erfolgen. Zum einen kann die Kraft beschränkt werden, mit der sich der Roboter bewegt und eventuell Objekte verschiebt und zum anderen kann die Kraft beschränkt werden, mit der der Endeffektor ein Objekt greift~\cite{force_control}. Letzteres ist vor allem bei nicht-soliden Objekten notwendig, die bei einer zu hohen Krafteinwirkung beschädigt werden oder sich verformen würden.
+Die Beschränkung der Kraft kann auf zweierlei Weise erfolgen. Zum einen kann die Kraft beschränkt werden, mit der sich der Roboter bewegt und eventuell Objekte verschiebt und zum anderen kann die Kraft beschränkt werden, mit der der Endeffektor ein Objekt greift~\cite{force_control}. Letzteres ist vor allem bei nicht-soliden Objekten notwendig, die bei einer zu hohen Krafteinwirkung beschädigt werden könnten.
 
-So wie die Geschwindigkeit limitiert wird, um die Auftrittskraft bei einer Kollision zu beschränken, kann auch die Kraft allgemein so weit beschränkt werden, dass die in der ISO 15066 gegebenen Grenzwerte nicht überschritten werden~\cite[Tabelle A.2]{ISO_15066}. Die niedrigste maximal zulässige Kraft ist dabei mit 65 Newton für das Gesicht angegeben.  
\ No newline at end of file
+So wie die Geschwindigkeit limitiert wird, um die Auftrittskraft bei einer Kollision zu beschränken, kann auch die Kraft allgemein so weit beschränkt werden, dass die in der ISO 15066 gegebenen Grenzwerte nicht überschritten werden~\cite[Tabelle A.2]{ISO_15066}.  
\ No newline at end of file

sections/zusammenfassung.tex

@@ -5,7 +5,7 @@ Ziel dieser Arbeit war es mögliche Arten von Constraints für industrielle Robo
 Die entstandene Taxonomie ist in Abbildung~\ref{fig:taxonomie} dargestellt. Sie liefert einen Überblick über anwendbare Constraints und soll als Hilfestellung bei der Erstellung neuer Robotikanwendungen dienen. Einen Anspruch auf Vollständigkeit erhebt sie dabei nicht, wenngleich verschiedene Konzepte zur Erweiterung der Fallstudie keine weiteren Constraints erforderlich gemacht haben, die nicht in der Taxonomie einsortierbar waren.
 
 Im Zuge der Fallstudie wurde ein kollaborativer Anwendungsfall zwischen zwei Robotern und einem Menschen untersucht. Dieser Anwendungsfall beinhaltete sowohl die Handhabung von mit Flüssigkeit befüllten Behältern, als auch das Umfüllen dieser Flüssigkeit und der Interaktion mit einem menschlichen Akteur. Dazu wurden dem Roboter abhängig von der aktuellen Aufgabe Constraints auf die Orientierung des Endeffektors, seine Geschwindigkeit und Beschleunigung und seines Arbeitsbereichs auferlegt.
-Die Implementierung erfolgte in \textit{C++} unter der Verwendung des Robot Operating Systems (ROS) und des Motion Planning Frameworks MoveIt. Um die Demo erweiterbar zu halten, wurde ein Interface erstellt, welches von weiteren Constraints implementiert werden kann. Die Positionen und Eigenschaften der Objekte in der Welt sind über eine Konfigurationsdatei definiert und können dadurch an eine neue Ausgangssituation angepasst werden. Die erfolgreiche Anwendung der in der Fallstudie benötigten Constraints wurde anhand einer Versuchsreihe nachgewiesen.
+Die Implementierung erfolgte in \textit{C++} unter der Verwendung des Robot Operating Systems (ROS) und des Motion Planning Frameworks MoveIt. Um die Fallstudie erweiterbar zu halten, wurde ein Interface erstellt, welches von weiteren Constraints implementiert werden kann. Die Positionen und Eigenschaften der Objekte in der Welt sind über eine Konfigurationsdatei definiert und können dadurch an eine neue Ausgangssituation angepasst werden. Die erfolgreiche Anwendung der in der Fallstudie benötigten Constraints wurde anhand einer Versuchsreihe nachgewiesen.
 
 
 

thesis.tex

@@ -10,6 +10,9 @@
 \usepackage{isodate}
 \usepackage{quoting}
 
+\usepackage{url}
+\def\UrlBreaks{\do\/\do-}
+
 \usepackage[style=numeric,backend=bibtex]{biblatex}
 
 \addbibresource{bibliography.bib}
@@ -84,6 +87,8 @@
 \usepackage{ellipsis}
 \let\ellipsispunctuation\relax
 
+\usepackage{siunitx}
+
 \input{lst.tex}
 
 \begin{document}