@@ -28,51 +28,11 @@ Zusätzlich sind noch weitere handlungsunabhängige Anforderungen zu berücksich
\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, sollen die Positionen der Roboter und Objekte über eine Konfigurationsdatei anpassbar sein.
\item[A3] Zur Implementation soll das Robot Operating System (ROS) und das Motion Planning Framework MoveIt! verwendet werden.
\end{enumerate}
\section{Entwurf}
In diesem Abschnitt wird ein Entwurf vorgestellt, wie die gestellten Anforderungen aus Abschnitt~\ref{ch:requirements} technisch umgesetzt werden können.
\caption{Ablaufdiagramme für die Aufgaben der zwei Cobots.}
\label{fig:ablaufdiagramm}
\end{figure}
Die beiden Roboter der Fallstudie werden als separate Entitäten behandelt und sollen unabhängig voneinander agieren. Die in der Aufgabenstellung festgelegten Handlungen wurden im Ablaufdiagramm ~\ref{fig:ablaufdiagramm} visualisiert und dahingehend erweitert, dass das Fehlschlagen einer Greifaktion zur Rückkehr in einen sicheren Zustand resultiert. Pro Aufgabe werden folgende Constraints benötigt:
\begin{enumerate}
\item Startposition: Es sind keine Constraints benötigt, da keine Handlungen durchgeführt werden.
\item Flasche greifen: Die Orientierung des Endeffektors muss horizontal zum Boden sein, damit die Flasche seitlich gegriffen werden kann.
\item Glas füllen: Während der Bewegung vom Aufnahmeort der Flasche zum Glas, bleibt die Orientierung beschränkt, um ein Ausschütten zu verhindern. Ebenso wird die Beschleunigung beschränkt, um ein Überschwappen zu vermeiden. Zum Befüllen des Glases wird das Orientierungs-Constraint aufgehoben, um eine Rotation des Endeffektors zu erlauben.
\item Flasche abstellen: Die Orientierung muss wieder horizontal zum Boden sein, damit eventuelle Flüssigkeitsreste nicht verschüttet werden und ein korrektes Abstellen möglich ist. Eine Beschränkung der Beschleunigung ist nicht mehr notwendig und nachdem die Flasche abgestellt worden ist, muss auch die Orientierung nicht weiter beschränkt werden. Zusätzlich gilt es einen extra Sicherheitsabstand zur Tischplatte zu halten.
\item Glas greifen: Nach erfolgreichem Greifen des befüllten Glases, werden Orientierung und Beschleunigung erneut beschränkt, um ein Verschütten zu verhindern.
\item Safezone frei: Nachfolgende Handlungen können erst ausgeführt werden, wenn die Sicherheitszone zwischen den Robotern nicht vom anderen Roboter blockiert wird.
\item Glas abstellen: Die Orientierung und Beschleunigung bleiben beschränkt, bis das Glas abgestellt worden ist.
\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.
Zusammenfassend ergeben sich aus Entwurfssicht die im Entwurfsklassendiagramm~\ref{fig:klassendiagramm} dargestellten Entitäten.
\section{Implementierung}
Implementiert wird die Fallstudie unter Verwendung des Robot Operating System (ROS) Melodic Morenia \cite{quigley_ros_nodate} und des Motion Planning Framework MoveIt \cite{chitta_moveitros_2012}.
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}. 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.
...
...
@@ -120,7 +80,7 @@ Die Move Group ist der zentrale Knoten der MoveIt! Architektur. In ihm werden di
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}:
\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 Geometrische Primitive oder Netzmodelle: Eine Dreidimensionale Beschreibung von bekannten Objekten und Hindernissen
\end{enumerate}
...
...
@@ -130,7 +90,52 @@ Die Planning Pipeline verbindet Planning Request Adapters mit dem eigentlichen M
\paragraph{Controller}
Um die Trajektorie auf dem Roboter auszuführen, muss dieser ein \glqq FollowJointTrajectoryAction\grqq{} Interface implementiert haben, das von der Move Group angesteuert wird. In der Regel wird ein entsprechender Server vom Hersteller des Roboters bereitgestellt.
\caption{Ablaufdiagramme für die Aufgaben der zwei Cobots.}
\label{fig:ablaufdiagramm}
\end{figure}
\subsection{Objektorientierter Entwurf}
Die beiden Roboter der Fallstudie werden als separate Entitäten behandelt und sollen unabhängig voneinander agieren. Die in der Aufgabenstellung festgelegten Handlungen wurden im Ablaufdiagramm ~\ref{fig:ablaufdiagramm} visualisiert und dahingehend erweitert, dass das Fehlschlagen einer Greifaktion zur Rückkehr in einen sicheren Zustand resultiert. Pro Aufgabe werden folgende Constraints benötigt:
\begin{enumerate}
\item Startposition: Es sind keine Constraints benötigt, da keine Handlungen durchgeführt werden.
\item Flasche greifen: Die Orientierung des Endeffektors muss horizontal zum Boden sein, damit die Flasche seitlich gegriffen werden kann.
\item Glas füllen: Während der Bewegung vom Aufnahmeort der Flasche zum Glas, bleibt die Orientierung beschränkt, um ein Ausschütten zu verhindern. Ebenso wird die Beschleunigung beschränkt, um ein Überschwappen zu vermeiden. Zum Befüllen des Glases wird das Orientierungs-Constraint aufgehoben, um eine Rotation des Endeffektors zu erlauben.
\item Flasche abstellen: Die Orientierung muss wieder horizontal zum Boden sein, damit eventuelle Flüssigkeitsreste nicht verschüttet werden und ein korrektes Abstellen möglich ist. Eine Beschränkung der Beschleunigung ist nicht mehr notwendig und nachdem die Flasche abgestellt worden ist, muss auch die Orientierung nicht weiter beschränkt werden. Zusätzlich gilt es einen extra Sicherheitsabstand zur Tischplatte zu halten.
\item Glas greifen: Nach erfolgreichem Greifen des befüllten Glases, werden Orientierung und Beschleunigung erneut beschränkt, um ein Verschütten zu verhindern.
\item Safezone frei: Nachfolgende Handlungen können erst ausgeführt werden, wenn die Sicherheitszone zwischen den Robotern nicht vom anderen Roboter blockiert wird.
\item Glas abstellen: Die Orientierung und Beschleunigung bleiben beschränkt, bis das Glas abgestellt worden ist.
\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.
Zusammenfassend ergeben sich aus Entwurfssicht die im Entwurfsklassendiagramm~\ref{fig:klassendiagramm} dargestellten Entitäten. Ein 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. Der SafezoneController speichert den Zustand der Sicherheitszone und kann Zugang zu ihr entweder gewähren oder ablehnen.
Da ein Cobot nicht weiß, wann und in welcher Reihenfolge er seine Handlungen ausführen soll, wird er von einem CobotController gesteuert. Dieser ist außerdem zuständig für das Hinzufügen von Objekten in die PlanningScene und die Kommunikation mit SafeZoneController und PressureSensor. Diese drei Einheiten 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.
Die Drucksensoren veröffentlichen ihren Zustand auf einem Topic, welches von den Cobot Controllern abonniert wird (gekennzeichnet durch den durchgezogenen Pfeil). Für die Anfrage an den SafezoneController bietet eine Implementierung als ROS Service an (gekennzeichnet durch gestrichelte Pfeile).
\section{Implementierung}
\textcolor{blue}{Kurze Beschreibung, wie die im Entwurf beschriebene Architektur unter Nutzung von ROS implementiert wurde und wie die Constraints in MoveIt! umgesetzt worden sind. + Schwierigkeiten}
