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\footnote{\url{https://ifr.org/ifr-press-releases/news/robot-investment-reaches-record-16.5-billion-usd}}. 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}.
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\footnote{\url{https://ifr.org/ifr-press-releases/news/robot-investment-reaches-record-16.5-billion-usd}}. 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.
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.
@@ -28,14 +28,14 @@ Zusätzlich sind noch weitere handlungsunabhängige Anforderungen zu berücksich
...
@@ -28,14 +28,14 @@ Zusätzlich sind noch weitere handlungsunabhängige Anforderungen zu berücksich
\begin{enumerate}
\begin{enumerate}
\item[A1] Constraints sollen aufgabenspezifisch angewandt und entfernt werden können.
\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[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[A3] Zur Implementation soll das Robot Operating System (ROS) und das Motion Planning Framework MoveIt verwendet werden.
\end{enumerate}
\end{enumerate}
\section{Entwurf}
\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.
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}
\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.
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.
\paragraph{Node}
\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. 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.
...
@@ -62,19 +62,19 @@ Unter anderen wird die Beschreibung des Roboters in Form des Unified Robot Descr
...
@@ -62,19 +62,19 @@ Unter anderen wird die Beschreibung des Roboters in Form des Unified Robot Descr
\paragraph{Package}
\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.
\subsection{MoveIt!}
\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}\footnote{\url{https://moveit.ros.org/documentation/concepts/}} dargestellt und werden nachfolgend, auf Grundlage des Referenzbuchs von Anis Koubaa~\cite{koubaa_anis_2016} und der MoveIt! Dokumentation\footnote{\url{https://moveit.ros.org/documentation/concepts/}} kurz erklärt.
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\footnote{\url{https://moveit.ros.org/documentation/concepts/}} kurz erklärt.
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.
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}
\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 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}:
...
@@ -120,34 +120,52 @@ Die Sicherheitszone zwischen den Robotern - einschließlich des Übergabeorts -
...
@@ -120,34 +120,52 @@ Die Sicherheitszone zwischen den Robotern - einschließlich des Übergabeorts -
\caption{Entwurfsklassendiagramm eines Cobots \textcolor{blue}{Vertikal anordnen}}
\label{fig:klassendiagramm}
\label{fig:klassendiagramm}
\end{figure}
\end{figure}
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. Ein Drucksensor stellt die Information über seinen Druckzustand zur Verfügung.
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.
Da ein Cobot nicht weiß, wann und in welcher Reihenfolge er seine Handlungen ausführen soll, wird er von einem CobotController gesteuert. Dieser implementiert eins der Ablaufdiagramme aus Abbildung~\ref{fig:ablaufdiagramm} und ist außerdem zuständig für die Kommunikation mit SafeZoneController und PressureSensor und dem Hinzufügen von Objekten in die PlanningScene. Entsprechend Anforderung A2 sollen diese Objekte konfigurierbar sein. Die drei Einheiten CobotController, SafeZoneController und 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.
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).
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.
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).
\section{Implementierung}
\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}
\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}
Implementiert wurde die Demo in \textit{C++} und der ROS Distribution ROS Melodic Morenia\footnote{\url{http://wiki.ros.org/melodic}} auf einem Ubuntu 18.04 System.
Implementiert wurde die Demo in \textit{C++} und der ROS Distribution ROS Melodic Morenia auf einem Ubuntu 18.04 System.
\subsection{Cobot}
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.
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.