diff --git a/images/Aufgabenstellung.jpg b/images/Aufgabenstellung.jpg index 44315a550c0b1e7beb0308ee6e82aa97c164873d..765d37faaec6b9878ee7c6dea567a1415e7a199b 100644 Binary files a/images/Aufgabenstellung.jpg and b/images/Aufgabenstellung.jpg differ diff --git a/sections/einleitung.tex b/sections/einleitung.tex index fd72c582c18cd45d7ff56e5752119daf72bed530..468a1db9fe4a15e713fc21be5fa5e013bb91fd32 100644 --- a/sections/einleitung.tex +++ b/sections/einleitung.tex @@ -1,5 +1,5 @@ \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\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. @@ -19,8 +19,8 @@ ein Gefäß mit einer Flüssigkeit aus einem anderen Gefäß zu befüllen. Diese durch einen Menschen explizit eingeleitet. Der zweite Roboter nimmt das befüllte Gefäß entgegen und stellt es schließlich dem menschlichen Nutzer bereit. Dies geschieht wiederum automatisch. 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. +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. diff --git a/sections/implementierung.tex b/sections/implementierung.tex index 1d55e0369067ddbfce50b2b7d1a37097563ffc4a..d672c6d2ab35a49253b02d49fc86aa500a77eac1 100644 --- a/sections/implementierung.tex +++ b/sections/implementierung.tex @@ -28,14 +28,14 @@ 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, 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} \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} -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} 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 \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. -\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}. -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. +\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}. +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. \begin{figure} \centering \includegraphics[height=\textheight, width=\textwidth, keepaspectratio]{images/moveit_pipeline.png} - \caption{High Level Architektur von MoveIt!} + \caption{High Level Architektur von MoveIt} \label{fig:moveit_concepts} \end{figure} \paragraph{Move Group} -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} 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 - \label{fig:sequenzdiagramm} \end{figure} + \begin{figure} \centering - \includegraphics[height=\textheight, width=\textwidth, keepaspectratio]{images/Klassendiagramm Cobot.jpg} - \caption{Entwurfsklassendiagramm eines Cobots} + \begin{sideways} + \includegraphics[height=\textwidth, width=\textheight, keepaspectratio]{images/Klassendiagramm Cobot.jpg} . + \end{sideways} + \caption{Entwurfsklassendiagramm eines Cobots \textcolor{blue}{Vertikal anordnen}} \label{fig:klassendiagramm} \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. - -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. +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. -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. +\begin{figure} + \centering + \includegraphics[height=\textheight, width=\textwidth, keepaspectratio]{images/NodeCommunication.png} + \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). \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. + +Neben dem + +- Config +- Launch files + +\subsection{Constraints} + +\subsection{SafezoneController} + +\subsection{ObjectCreator} + +\subsection{PressureSensor} -\begin{figure} - \centering - \includegraphics[height=\textheight, width=\textwidth, keepaspectratio]{images/NodeCommunication.png} - \caption{Kommunikation zwischen den Nodes} - \label{fig:node_communication} -\end{figure} \section{Evaluation} \textcolor{blue}{ diff --git a/thesis.tex b/thesis.tex index 8048f0d1a9d98c5b421475c9237754cb2264be0e..50bf55ec2fe94e0f37f74c8c3778b4bac8e1f26b 100644 --- a/thesis.tex +++ b/thesis.tex @@ -113,7 +113,7 @@ \tableofcontents \listoffigures -\listoftables +%\listoftables \input{sections/einleitung} \input{sections/grundlagen.tex}