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.

\section{Anforderungen}\label{ch:requirements}
Die in der Aufgabenstellung beschriebenen Handlungen der Roboter ergeben folgende Anforderungen:

\begin{enumerate}
	\item[H1] Ein Drucksensor soll das Vorhandensein eines Gefäßes signalisieren
	\item[H2] Beide Roboter sollen in der Lage sein die Gefäße aufzunehmen
	\item[H3] Beide Roboter sollen das gefüllte Gefäß bewegen können, ohne dessen Inhalt zu verschütten
	\item[H4] Der erste Roboter soll den Inhalt des einen Gefäßes in das andere umfüllen
	\item[H5] Es darf zu keinen Kollisionen zwischen den Robotern kommen
	
	
\end{enumerate}
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[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 [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, 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 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 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. 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. Wurde ein Topic abonniert, erfolgt der Datenaustausch allerdings direkt zwischen den Nodes und nicht über den Master.

\paragraph{Service}
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.