Stil Korrekturen

sections/ausblick.tex

@@ -49,7 +49,7 @@ Die gleichzeitige Simulation der beiden Roboter geschieht in der Fallstudie, auf
 
 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 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}}.
+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 voneinander 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}
-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}.
+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.
 

sections/eval.tex

@@ -130,10 +130,10 @@ Um die Einhaltung der Constraints zu validieren, wurde die Beschleunigung, die G
 
 \newpage
 \section{Constraints}
-In diesem Abschnitt wird für jedes verwendete Constraint untersucht, in wie fern es in MoveIt direkt umgesetzt werden konnte und in die Taxonomie eingeordnet. Eine vollständige Darstellung aller verwendeten Constraints und in MoveIt umsetzbaren Constraints ist in Abbildung~\ref{fig:taxonomie_moveit} gegeben. Standardmäßig unterstützt MoveIt folgende Constraints, für die bereits eigene ROS Messages existieren:
+In diesem Abschnitt wird für jedes verwendete Constraint untersucht, inwiefern es in MoveIt direkt umgesetzt werden konnte und in die Taxonomie eingeordnet. Eine vollständige Darstellung aller verwendeten Constraints und in MoveIt umsetzbaren Constraints ist in Abbildung~\ref{fig:taxonomie_moveit} gegeben. Standardmäßig unterstützt MoveIt folgende Constraints, für die bereits eigene ROS Messages existieren:
 \begin{enumerate}
 	\item \textbf{Joint Constraint:} Einzelne Drehwerte der Gelenke innerhalb eines Bereichs halten
-	\item \textbf{Position Constraint:} Einzelne Glieder innerhalb eines dreidimensionalen Volumen halten
+	\item \textbf{Position Constraint:} Einzelne Glieder innerhalb eines dreidimensionalen Volumens halten
 	\item \textbf{Orientation Constraint:} Die Orientierung eines Gliedes innerhalb einer Toleranz halten
 	\item \textbf{Visibility Constraint:} Sicherstellen, dass der Roboter sich nicht innerhalb des Sichtkegels eines Sensors bewegt. Soll ein Objekt stets für den Sensor sichtbar sein, muss zusätzlich ein Positions-Constraint angewandt werden.
 \end{enumerate}
@@ -142,7 +142,7 @@ In diesem Abschnitt wird für jedes verwendete Constraint untersucht, in wie fer
 Die Handlungen der beiden Roboter folgt einem strikten Ablaufplan. Ihre Handlungswahl ist dementsprechend beschränkt. Da MoveIt lediglich ein Motion Planning Framework ist, bietet es keine Möglichkeiten abstrakte Handlungen einzuschränken. In der Taxonomie wird ein solcher Constraint eingeordnet unter: 
 
 \begin{center}
-	Robotische Constraints → Handlung → Endeffektorunspezifisch
+	Robotische Constraints → Handlung → Endeffektor-unspezifisch
 \end{center}
 
 \paragraph{Orientierung}
@@ -181,9 +181,9 @@ Nach der Aufnahme des Glases oder der Flasche wird das Kollisionsobjekt dem kine
 \end{center}
 
 
-\begin{figure}[!h]
+\begin{figure}
 	\centering
 	\includegraphics[height=\textheight, width=\textwidth, keepaspectratio]{images/Taxonomie_moveit.pdf} 
 	\caption{In der Fallstudie angewandte Constraints (blau) und in MoveIt direkt umsetzbare Constraints (orange)}
 	\label{fig:taxonomie_moveit}
-\end{figure}
\ No newline at end of file
+\end{figure}

sections/grundlagen.tex

@@ -5,7 +5,7 @@ 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 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.
+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}. Typischerweise 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}
@@ -29,7 +29,7 @@ Das Finden einer optimalen Trajektorie ist PSPACE-vollständig und daher schwer
 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 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}
-Die physischen Eigenschaften des Roboters, resultieren in der realen Welt immer in Einschränkungen (Constraints) für seine Bewegung. Diese lassen sich in globale und lokale Constraints unterteilen. Während globale Constraints sich aus den Hindernissen in der Welt und möglichen Gelenklimits der Roboters ergeben, limitieren lokale Constraints die Geschwindigkeit und Beschleunigung, aufgrund der kinematischen und dynamischen Eigenschaften, wie die Erhaltung von Drehimpulsen~\cite{siciliano_springer_2008}.
+Die physischen Eigenschaften des Roboters resultieren in der realen Welt immer in Einschränkungen (Constraints) für seine Bewegung. Diese lassen sich in globale und lokale Constraints unterteilen. Während globale Constraints sich aus den Hindernissen in der Welt und möglichen Gelenklimits der Roboter ergeben, limitieren lokale Constraints die Geschwindigkeit und Beschleunigung, aufgrund der kinematischen und dynamischen Eigenschaften, wie die Erhaltung von Drehimpulsen~\cite{siciliano_springer_2008}.
 
 Neben den natürlich gegebenen Constraints, können dem Planer noch weitere Beschränkungen auferlegt werden. Dadurch ist es möglich das Verhalten und die Bewegung des Roboters an die aufgabenspezifischen Anforderungen anzupassen, die Aufgabe des Motion Planning aber weiterhin einem Algorithmus zu überlassen. 
 Häufig wird bei Constraints auch zwischen holonomen und nicht-holonomen Constraints unterschieden. Erstere können mathematisch alleine durch Gleichungen beschrieben werden, die lediglich von Positionen im Raum und optional auch der Zeit abhängig sind. Für nicht-holonomen Constraints ist mindestens eine Variable neben der Position von dessen zeitlicher Ableitung abhängig~\cite{berenson_constrained_nodate}. 

sections/implementierung.tex

 \newpage\null\newpage
 \chapter{Fallstudie}\label{ch:implementation}
-Die Fallstudie soll die Anwendbarkeit der in der Taxonomie beschriebenen Constraints zeigen und untersuchen, in wie fern diese Constraints vom Motion Planning Framework MoveIt\footnote{\url{https://moveit.ros.org/}} unterstützt werden. Dazu wird 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.
+Die Fallstudie soll die Anwendbarkeit der in der Taxonomie beschriebenen Constraints zeigen und untersuchen, inwiefern diese Constraints vom Motion Planning Framework MoveIt\footnote{\url{https://moveit.ros.org/}} unterstützt werden. Dazu wird 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.
 
 \section{Anforderungen}\label{ch:requirements}
 Die in der Aufgabenstellung beschriebenen Handlungen der Roboter ergeben folgende Anforderungen:
@@ -67,10 +67,10 @@ Da Nodes in der Regel nichts über die Existenz der anderen Nodes wissen, werden
 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.
+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,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}
@@ -91,7 +91,7 @@ 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 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}:
+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 belegt, frei oder unbekannt sein\footnote{\url{http://wiki.ros.org/voxel\_grid}}
 	
@@ -142,9 +142,9 @@ Die Sicherheitszone zwischen den Robotern - einschließlich des Übergabeorts -
 	\label{fig:klassendiagramm}
 \end{figure}
 
-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.
+Aus 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 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. 
+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 mithilfe 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=0.95\textheight, width=\textwidth, keepaspectratio]{images/NodeCommunication.pdf} 
@@ -166,7 +166,7 @@ Nach erfolgreicher Initialisierung, wird vom Cobot 1 das Topic \glqq pressure\_1
 
 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.
+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.
 
 Die Launch Datei des Packages startet neben dem \textit{CobotController} auch den \textit{SafezoneController}- und \textit{PressureSensor}-Node und eine Simulationsumgebung.
 
@@ -189,9 +189,9 @@ Der \textit{SafezoneController}-Node stellt einen einfachen ROS Service unter de
 \lstinputlisting[firstline=17,lastline=32, label={lst:safezone_controller}, caption={Callback Funktion des SafezoneController}]{../cobot_ws/src/safe_zone_controller/src/SafeZoneController.cpp}
 
 \subsection{ObjectCreator}\label{ch:objectCreator}
-Das package \textit{object\_creator} enthält die Klassen \textit{ObjectCreator} und \textit{ObjectConfig}. Mit Hilfe der Klasse \textit{ObjectConfig} wird ein Konfigurationsobjekt aus den Konfigurationsparametern erstellt, die über den ROS Parameter Server abgerufen werden. Dieses Objekt enthält anschließend die Maße, Position, Masse und ein Flag, welches festlegt, ob es in der Simulation statisch oder bewegbar sein soll.
+Das package \textit{object\_creator} enthält die Klassen \textit{ObjectCreator} und \textit{ObjectConfig}. Mithilfe der Klasse \textit{ObjectConfig} wird ein Konfigurationsobjekt aus den Konfigurationsparametern erstellt, die über den ROS Parameter Server abgerufen werden. Dieses Objekt enthält anschließend die Maße, Position, Masse und ein Flag, welches festlegt, ob es in der Simulation statisch oder bewegbar sein soll.
 
 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 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. 
+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

 \newpage\null\newpage
 \chapter{Taxonomische Einordnung von Constraints}\label{ch:taxonomy}
-Im folgenden werden mögliche Arten von Constraints für die Pfadgenerierung (Motion Planning), die Handlung und die Bewegung von Robotern analysiert, erläutert und in einer Taxonomie eingeordnet. Eine grafische Darstellung der Taxonomie ist in Abbildung~\ref{fig:taxonomie} zu sehen.
+Im Folgenden werden mögliche Arten von Constraints für die Pfadgenerierung (Motion Planning), die Handlung und die Bewegung von Robotern analysiert, erläutert und in einer Taxonomie eingeordnet. Eine grafische Darstellung der Taxonomie ist in Abbildung~\ref{fig:taxonomie} zu sehen.
 
 \begin{figure}
 	\centering	
@@ -41,7 +41,7 @@ Die Kollaboration mit Menschen oder anderen Robotern resultiert in weiteren Cons
 	\item Andere Maßnahmen wie die Berücksichtigung von weiteren Gefahrenquellen durch bestimmte Werkstücke und Werkzeuge
 
 \end{enumerate}
-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:
+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 Roboterapplikation, 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
@@ -65,7 +65,7 @@ Sind Überschneidungen der Arbeitsbereiche und Berührungen zwischen Mensch und
 Die einfachste aber auch ineffizienteste Strategie ist ein permanenter sicherer Betrieb, indem der komplette Arbeitsbereich als eine Sicherheitszone definiert wird, was eine dauerhafte Beschränkung von Geschwindigkeit und Kraft und permanente Kollisionsvermeidung erfordert.
 
 \subsection{Hindernisse}
-Da das Ziel des Motion Planning das Erstellen einer kollisionsfreie Trajektorie ist, beschränken Hindernisse innerhalb des Arbeitsbereich maßgeblich die gültigen Pfade.
+Da das Ziel des Motion Planning das Erstellen einer kollisionsfreie Trajektorie ist, beschränken Hindernisse innerhalb des Arbeitsbereichs maßgeblich die gültigen Pfade.
 Das Springer Handbook of Robotics~\cite[Kapitel 35.9]{siciliano_springer_2008} definiert eine Taxonomie der verschiedenen Darstellungsmöglichkeiten von Hindernissen und Algorithmen, diese zu vermeiden. Eine Visualisierung der Taxonomie ist in Abbildung~\ref{fig:obstacle_tax} dargestellt.
 Im folgenden Abschnitt werden diese Möglichkeiten kurz erläutert.
 
@@ -78,7 +78,7 @@ Im folgenden Abschnitt werden diese Möglichkeiten kurz erläutert.
 
 
 \subsubsection{Ein-Schritt-Methoden}
-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.
+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 Potenzialfeldmethode, 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}
@@ -92,7 +92,7 @@ Die Welt wird vom Roboter ausgehen in Sektoren aufgeteilt. Den Sektoren wird ans
 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}
-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}.
+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}.
@@ -126,7 +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 Roboters 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.

sections/zusammenfassung.tex

@@ -6,7 +6,3 @@ Die entstandene Taxonomie ist in Abbildung~\ref{fig:taxonomie} dargestellt. Sie
 
 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 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.
-
-
-
-