diff --git a/bibliography.bib b/bibliography.bib index bf220a03f7351df84a764ef668f73e128215947e..6d89c7e00baced7ccf1329995de6078e9a866391 100644 --- a/bibliography.bib +++ b/bibliography.bib @@ -579,5 +579,20 @@ institution={DIN Deutsches Institut für Normung e. V.}, } +@techreport{ISO_10218, + type={Norm}, + title={ISO 10218 Robotis and robotic devices - Safety requirements for industrial robots}, + month={Juli}, + year={2011}, + institution={Internationale Organisation für Normung}, +} + +@misc{eu-2006-42-EC, + author={{Council of European Union}}, + title={DIRECTIVE 2006/42/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on machinery, and amending Directive 95/16/EC }, + year={2006}, + note={\newline\url{https://eur-lex.europa.eu/eli/dir/2006/42/oj}}, +} + diff --git a/images/Orientation_eval.png b/images/Orientation_eval.png index faa9f64cf9d0af50489cb6b21607cdfe72249797..1e2a6ab2dd221d429a7de487382658e8bc3ae227 100644 Binary files a/images/Orientation_eval.png and b/images/Orientation_eval.png differ diff --git a/images/Safezone_eval.png b/images/Safezone_eval.png index a46debc696e6da14929129e48725334cf72bff9a..57bb974a06aefca1dccf49f52f01205b8ad7d44d 100644 Binary files a/images/Safezone_eval.png and b/images/Safezone_eval.png differ diff --git a/images/velocity_eval.png b/images/velocity_eval.png index b439e65b9bedba303306dfab2c60aef915dce040..8db4a5757db4d410a7c9cf5424a2977bbd56711d 100644 Binary files a/images/velocity_eval.png and b/images/velocity_eval.png differ diff --git a/sections/ausblick.tex b/sections/ausblick.tex index 6d7ced17dd22b7d6356e1425fa31f25654edae60..dbd0e2e97fbd97556d28f80402db86f2d3b94c3a 100644 --- a/sections/ausblick.tex +++ b/sections/ausblick.tex @@ -45,7 +45,9 @@ In der Taxonomie wäre das als Definition eines Teilpfades einzuordnen: Die Erweiterung der Fallstudie um diese Constraints kann auf verschiedene Weisen erfolgen. Constraints, die abhängig vom aktuellen Zustand angewandt und entfernt werden sollen, können anlog zu den Beschleunigungs- und Geschwindigkeits-Constraints realisiert werden, indem sie ebenfalls die abstrakte Klasse \textit{Constraints} implementieren (siehe \Cref{ch:constraint_impl}). Wird der Workflow beschränkt, müsste dieser Constraint Teil des \textit{CobotController}s werden, da dieser in der Fallstudie für den Handlungsablauf verantwortlich ist (siehe \Cref{ch:cobot_impl}). \section{Zukünftige Arbeiten} -Die gleichzeitige Simulation der beiden Roboter geschieht in der Fallstudie, aufgrund technischer Limitierungen der Gazebo Simulationsumgebung, nicht. Für einfache Anwendungsfälle, wie den vorliegenden, mag das kein Problem sein, insbesondere jedoch für Demonstrierungen direkter Kollaboration mehrerer Roboter, ist eine parallele Simulation unumgänglich. Um eine dahingehende Erweiterung zu ermöglichen, könnten sich zukünftige Arbeiten mit einer Erweiterung der Simulationsumgebung befassen. +Die gleichzeitige Simulation der beiden Roboter geschieht in der Fallstudie, aufgrund technischer Limitierungen der Gazebo Simulationsumgebung, nicht. Für einfache Anwendungsfälle, wie den vorliegenden, mag das kein Problem sein, insbesondere jedoch für Untersuchung direkter Kollaboration mehrerer Roboter, ist eine parallele Simulation unumgänglich. Um eine dahingehende Erweiterung zu ermöglichen, könnten sich zukünftige Arbeiten mit einer Erweiterung der Simulationsumgebung befassen. + +Maschinen mit Bewegungsabläufen unterliegen in der EU der Maschinenrichtlinie 2006/42/EG~\cite{eu-2006-42-EC} und der zugehörigen Norm~\cite{ISO_10218}, um die Sicherheit der Anwender zu gewährleisten. Der Hersteller der Roboter muss die Einhaltung dieser Richtlinien für den einzelnen Roboter garantieren. Nach der Integration in ein Gesamtsystem, ist diese Garantie nicht mehr gegeben, weshalb eine neue Risikobewertung notwendig wäre. 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. diff --git a/sections/eval.tex b/sections/eval.tex index 79c1d5825930fba5838dd6e3d7a996207b153354..8d370430776f4aea8442c989a6d0e04343f9f945 100644 --- a/sections/eval.tex +++ b/sections/eval.tex @@ -82,7 +82,7 @@ Die Initialisierung der Simulationsumgebung geschieht in einem Zuge mit dem Hinz \label{fig:cobot_2_sim} \end{figure} -Um die Einhaltung der Constraints zu validieren, wurde die Beschleunigung, die Geschwindigkeit, die Orientierung des Endeffektors und der Abstand zur Sicherheitszone zur Laufzeit der Simulation aufgezeichnet und in einem Graphen dargestellt. Dabei wurde lediglich Cobot 1 betrachtet, da die Handlungen und Constraints des zweiten Cobots eine Teilmenge des ersten Cobots sind. In Abbildung~\ref{fig:velocity_eval} ist zu sehen, dass die Beschleunigung, während der Handhabung von gefüllten Behältern, geringer ist, als während der Handlungen in denen das nicht der Fall ist. Die Bereiche, in denen die Beschleunigung beschränkt ist, sind farblich markiert. Die hohe Geschwindigkeit, während der Bewegung des Glases zwischen Sekunde 33 und 36, ist auf die große zurückgelegte Distanz und der damit verbundenen langen Beschleunigungszeit zurückzuführen. Abbildung~\ref{fig:orientation_eval} zeigt die Orientierung des Endeffektors, relativ zur Welt. Es ist ersichtlich, dass die Orientierung, während der Handhabung von Objekten, nur minimal um einen konstanten Wert schwanken. Diese Bereiche sind ebenfalls farblich unterlegt. Durch eine Verschärfung der Toleranzgrenzen wäre ein noch stabileres Ergebnis möglich. Allerdings würde dies mit einer deutlichen Steigerung der Planungszeit einhergehen. Abbildung~\ref{fig:safezone_eval} zeigt den Abstand aller Glieder des Roboters zur Sicherheitszone. Diese wird erst beim Platzieren des Glases und nach erfolgreicher Anfrage an den \textit{SafezoneController} geschnitten. Link 0 und Link 1 sind nicht zu erkennen, da sie ebenfalls einen konstanten Abstand halten und von der Kurve von Link 2 überdeckt werden. Die einzelnen Handlungen ordnen sich in allen drei Abbildungen grob den in Tabelle~\ref{tab:action_time} dargestellten Zeitfenstern zu. +Um die Einhaltung der Constraints zu validieren, wurde die Beschleunigung, die Geschwindigkeit, die Orientierung des Endeffektors und der Abstand zur Sicherheitszone zur Laufzeit der Simulation aufgezeichnet und in einem Graphen dargestellt. Dabei wurde lediglich Cobot 1 betrachtet, da die Handlungen und Constraints des zweiten Cobots eine Teilmenge des ersten Cobots sind. Die einzelnen Handlungen ordnen sich grob den in Tabelle~\ref{tab:action_time} dargestellten Zeitfenstern zu und werden im nachfolgenden Abschnitt genauer betrachtet. \begin{center} \begin{table} @@ -107,28 +107,7 @@ Um die Einhaltung der Constraints zu validieren, wurde die Beschleunigung, die G \end{center} -\begin{figure}[!h] - \centering - \includegraphics[height=\textheight, width=\textwidth, keepaspectratio]{images/velocity_eval.png} - \caption{Geschwindigkeit und Beschleunigung des Endeffektors relativ zur Welt} - \label{fig:velocity_eval} -\end{figure} - -\begin{figure}[!h] - \centering - \includegraphics[height=\textheight, width=\textwidth, keepaspectratio]{images/Orientation_eval.png} - \caption{Orientierung des Endeffektors relativ zur Welt} - \label{fig:orientation_eval} -\end{figure} - -\begin{figure}[!h] - \centering - \includegraphics[height=\textheight, width=\textwidth, keepaspectratio]{images/Safezone_eval.png} - \caption{Entfernungen aller Glieder zur Sicherheitszone} - \label{fig:safezone_eval} -\end{figure} -\newpage \section{Constraints} 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} @@ -148,10 +127,17 @@ Die Handlungen der beiden Roboter folgt einem strikten Ablaufplan. Ihre Handlung \paragraph{Orientierung} Bei der Handhabung und Manipulation von mit Flüssigkeit befüllten Behältern, müssen die Roboter diesen aufrecht relativ zum Boden halten. Dies geschieht beim Aufnehmen der Flasche, der Bewegung der Flasche an das Glas hinan, beim Abstellen der Flasche, bei der Aufnahme des Glases, bei der Bewegung des Glases und beim Abstellen des Glases. Dieser Constraint wird bereits bei der Pfadplanung berücksichtigt und ist aufgrund der Art des bewegten Werkstücks notwendig. Die Einschränkung der Orientierung entspricht dem von MoveIt bereitgestellten Orientation Constraint und kann daher problemlos in MoveIt umgesetzt werden. In die Taxonomie einordnen lässt sich dieser Constraint unter: - \begin{center} Robotische Constraints → Pfad → Orientierung des Endeffektors → Bewegtes Werkstück \end{center} +Abbildung~\ref{fig:orientation_eval} zeigt die Orientierung des Endeffektors, relativ zur Welt. Es ist ersichtlich, dass die Orientierung, während der Handhabung von Objekten, nur minimal um einen konstanten Wert schwanken. Diese Bereiche sind ebenfalls farblich unterlegt. Durch eine Verschärfung der Toleranzgrenzen wäre ein noch stabileres Ergebnis möglich. Allerdings würde dies mit einer deutlichen Steigerung der Planungszeit einhergehen. + +\begin{figure}[!h] + \centering + \includegraphics[height=\textheight, width=\textwidth, keepaspectratio]{images/Orientation_eval.png} + \caption[Orientierung des Endeffektors relativ zur Welt]{Die Orientierung des Endeffektors relativ zur Welt ist während der Bewegung von Flasche und Glas konstant zu halten. Lediglich zwischen den Handlungen und während der Füllbewegung ist eine Rotation erlaubt.} + \label{fig:orientation_eval} +\end{figure} \paragraph{Beschleunigung} Neben der Orientierung, muss beim Arbeiten mit Flüssigkeiten auch die Beschleunigung beschränkt werden, um ein Überschwappen zu verhindern. Berücksichtigt wird die Beschleunigungsskalierung von der Move Group erst bei Ausführung des geplanten Pfads, indem die maximale Beschleunigung jedes Gelenks reduziert wird. Die Beschränkung der Beschleunigung im Planungsschritt ist in der verwendeten MoveIt Version nicht möglich. In die Taxonomie wird der Beschleunigungs-Constraint wie folgt eingeordnet: @@ -159,11 +145,21 @@ Neben der Orientierung, muss beim Arbeiten mit Flüssigkeiten auch die Beschleun Robotische Constraints → Bewegung → Beschleunigung → Bewegtes Werkstück \end{center} +\begin{figure}[!h] + \centering + \includegraphics[height=\textheight, width=\textwidth, keepaspectratio]{images/velocity_eval.png} + \caption[Geschwindigkeit und Beschleunigung des Endeffektors relativ zur Welt]{Die Beschleunigung des Endeffektors relativ zur Welt ist während der Handhabung der Behälter beschränkt.} + \label{fig:velocity_eval} +\end{figure} + \paragraph{Geschwindigkeit} Das Umfüllen der Flüssigkeit aus den ersten in den zweiten Behälter erforderte eine zusätzliche Beschränkung der Geschwindigkeit. Eine zu schnelle Rotation des Endeffektors könnte ebenfalls zu einem Überschwappen führen. Analog zur Einschränkung der Beschleunigung, kann eine die Geschwindigkeit nicht beim Motion Planning berücksichtigt werden. Eingeordnet wird der Constraint unter: \begin{center} Robotische Constraints → Bewegung → Geschwindigkeit → Bewegtes Werkstück \end{center} +In Abbildung~\ref{fig:velocity_eval} ist zu sehen, dass die Beschleunigung, während der Handhabung von gefüllten Behältern, geringer ist, als während der Handlungen in denen das nicht der Fall ist. Die Bereiche, in denen die Beschleunigung beschränkt ist, sind farblich markiert. Die hohe Geschwindigkeit, während der Bewegung des Glases zwischen Sekunde 33 und 36, ist auf die große zurückgelegte Distanz und der damit verbundenen langen Beschleunigungszeit zurückzuführen. + + \paragraph{Sicherheitszone und Hindernisse} Um eine Kollision der Roboter in dem sich überschneidenden Arbeitsbereich zu verhindern, ist es immer nur einem Roboter möglich die Sicherheitszone zu betreten. Da das Betreten nicht mit einer Änderung des Verhaltens einhergeht, sondern ohne weiteres gar nicht möglich ist, handelt es sich eigentlich um verbotene Zone. Das Konzept von Sicherheitszonen und verbotenen Zonen gibt es in MoveIt nicht. Realisiert werden kann eine verbotene Zone allerdings zum Beispiel durch das Hinzufügen eines Hindernisses in die Planning Scene oder durch Verwendung des Position Constraints. In der Fallstudie wurde erstere Option verwendet. Dadurch ergeben sich zwei Möglichkeiten den Constraint in die Taxonomie einzuordnen: @@ -173,14 +169,21 @@ Um eine Kollision der Roboter in dem sich überschneidenden Arbeitsbereich zu ve \begin{center} Robotische Constraints → Pfad → Hindernisse \end{center} +Abbildung~\ref{fig:safezone_eval} zeigt den Abstand aller Glieder des Roboters zur Sicherheitszone. Diese wird erst beim Platzieren des Glases und nach erfolgreicher Anfrage an den \textit{SafezoneController} geschnitten. Link 0 und Link 1 sind nicht zu erkennen, da sie ebenfalls einen konstanten Abstand halten und von der Kurve von Link 2 überdeckt werden. + +\begin{figure}[!h] + \centering + \includegraphics[height=\textheight, width=\textwidth, keepaspectratio]{images/Safezone_eval.png} + \caption[Entfernungen aller Glieder zur Sicherheitszone]{Die Entfernungen aller Glieder zur Sicherheitszone ist größer als Null, solange der Roboter kein Zutrittsrecht erhalten hat, um das Glas auf dem Übergabeort abzustellen.} + \label{fig:safezone_eval} +\end{figure} \paragraph{Angehängtes Objekt} -Nach der Aufnahme des Glases oder der Flasche wird das Kollisionsobjekt dem kinematischen Modell des Roboters hinzugefügt und dadurch automatisch beim Motion Planning berücksichtigt. In der Taxonomie lässt sich dieser Constraint ebenfalls einordnen: +Nach der Aufnahme des Glases oder der Flasche wird das Kollisionsobjekt dem kinematischen Modell des Roboters hinzugefügt und dadurch automatisch beim Motion Planning berücksichtigt. \begin{center} Robotische Constraints → Pfad → Angehängte Objekte \end{center} - \begin{figure} \centering \includegraphics[height=\textheight, width=\textwidth, keepaspectratio]{images/Taxonomie_moveit.pdf} diff --git a/sections/implementierung.tex b/sections/implementierung.tex index 70e1b55f0831d3bc9e87dee37fd6e6cffa1d0442..42092da179f5ab35185e0ee3c72f45f8a42b52ec 100644 --- a/sections/implementierung.tex +++ b/sections/implementierung.tex @@ -155,14 +155,29 @@ Die Drucksensoren veröffentlichen ihren Zustand auf einem Topic, welches von de \section{Implementierung} -Implementiert wurde die Demo in \textit{C++} und der ROS Distribution ROS Melodic Morenia auf einem Ubuntu 18.04 System. Zur Kapselung von Verantwortlichkeiten und für eine bessere Wiederverwendbarkeit, ist die Implementierung in mehrere Packages aufgeteilt, die über CMake miteinander gelinkt werden. In den folgenden Abschnitten wird auf die zentralen Packages einzeln eingegangen. +Implementiert wurde die Fallstudie in \textit{C++} und der ROS Distribution ROS Melodic Morenia auf einem Ubuntu 18.04 System. Zur Kapselung von Verantwortlichkeiten und für eine bessere Wiederverwendbarkeit, ist die Implementierung in mehrere Packages aufgeteilt, die über CMake miteinander gelinkt werden. In den folgenden Abschnitten wird auf die zentralen Packages einzeln eingegangen. \subsection{Cobot}\label{ch:cobot_impl} Die Packages \textit{cobot\_1} und \textit{cobot\_2} enthalten jeweils die Implementierungen 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 vom Cobot 1 das Topic \glqq pressure\_1\grqq{} und vom Cobot 2 das Topic \glqq pressure\_2\grqq{} abonniert, um informiert zu werden, sobald das Glas auf dem 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. Eine Implementierung einer solchen Aufgabe ist im Codebeispiel~\ref{lst:pick_bottle} dargestellt. -\lstinputlisting[firstline=29,lastline=41, label={lst:pick_bottle}, caption={Beispielimplementierung einer Cobot-Aufgabe}]{../cobot_ws/src/cobot_1/src/Cobot.cpp} + +\begin{lstlisting}[label={lst:pick_bottle}, caption={Beispielimplementierung einer Cobot-Aufgabe}] + bool Cobot::pickBottle(moveit::planning_interface::MoveGroupInterface &group, moveit_msgs::CollisionObject bottle) { + ROS_INFO("Picking up the bottle..."); + + if(PickPlace::pick_x(group, bottle) == moveit_msgs::MoveItErrorCodes::FAILURE) return false; + + // hold bottle upright + this->orientationConstraint.apply(group); + + // lower acceleration to prevent spilling + this->accelerationConstraint.apply(group); + + return true; + } +\end{lstlisting} 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. @@ -176,17 +191,68 @@ Das Package \textit{constraints} enthält die Definition der abstrakten \textit{ Der Orientierungs-Constraint (Codebeispiel~\ref{lst:orientation_constraint}) wird realisiert, indem eine\newline \verb|moveit_msgs::OrientationConstraint|-Nachricht erstellt wird, die die aktuelle Orientierung des Endeffektors festsetzt. Diese Nachricht wird dann der Move Group als Pfad-Constraint hinzugefügt. Entfernt wird das Constraint durch das Leeren der Liste \verb|path_constraints.orientation_constraints|. -\lstinputlisting[firstline=11,lastline=26, label={lst:orientation_constraint}, caption={Implementierung des Orientierungs-Constraint}]{../cobot_ws/src/constraints/src/OrientationConstraint.cpp} + +\begin{lstlisting}[label={lst:orientation_constraint}, caption={Implementierung des Orientierungs-Constraint}] + void OrientationConstraint::apply(moveit::planning_interface::MoveGroupInterface &group) { + // Define an orientation constraint + moveit_msgs::OrientationConstraint ocm; + ocm.link_name = "panda_link7"; + ocm.header.frame_id = "panda_link0"; + ocm.orientation = group.getCurrentPose().pose.orientation; + ocm.absolute_x_axis_tolerance = 0.1; + ocm.absolute_y_axis_tolerance = 0.1; + ocm.absolute_z_axis_tolerance = 0.3; + ocm.weight = 1.0; + + // Add it as a path constraint for the group + moveit_msgs::Constraints path_constraints = group.getPathConstraints(); + path_constraints.orientation_constraints.push_back(ocm); + group.setPathConstraints(path_constraints); + } + +\end{lstlisting} Die Beschleunigung und Geschwindigkeit wird beschränkt und wieder freigegeben, indem die Geschwindigkeits- beziehungsweise Beschleunigungsskalierung der Move Group angepasst wird. Die Sicherheitszone, um den zweiten Drucksensor herum, wird durch das Hinzufügen eines weiteren Objekts zur Planning Scene realisiert, ohne dass dieses auch in der Simulationsumgebung erzeugt wird (siehe Codebeispiel~\ref{lst:safezone_constraint}). Das Erstellen des Kollisionsobjekts geschieht über den \textit{ObjectCreator} (Abschnitt~\ref{ch:objectCreator}). Darf der Roboter die Sicherheitszone betreten, wird das Safezone-Objekt entfernt, indem ein weiteres Objekt mit der selben ID und der \verb|REMOVE| Operation auf die Planning Scene angewandt wird. -\lstinputlisting[firstline=12,lastline=26, label={lst:safezone_constraint}, caption={Implementierung des Safezone-Constraint}]{../cobot_ws/src/constraints/src/SafeZoneConstraint.cpp} +\begin{lstlisting}[label={lst:safezone_constraint}, caption={Implementierung des Safezone-Constraint}] + void SafeZoneConstraint::apply(moveit::planning_interface::MoveGroupInterface &group) { + ObjectCreator(this->planning_scene_interface).createBox( + this->config, // ObjectConfig defines dimensions and position + this->id, // Unique ID that identifies the object + false // Will not be added to the simulation + ); + } + + void SafeZoneConstraint::remove(moveit::planning_interface::MoveGroupInterface &group) { + moveit_msgs::CollisionObject zone; + zone.id = this->id; + zone.header.frame_id = "panda_link0"; + zone.operation = zone.REMOVE; + this->planning_scene_interface.applyCollisionObject(zone); + } +\end{lstlisting} \subsection{SafezoneController} Der \textit{SafezoneController}-Node stellt einen einfachen ROS Service unter dem Namen \verb|safe_zone_controller| zur Verfügung. Der Zustand der Sicherheitszone (frei/belegt) wird in einer globalen Variable gespeichert. Jede Anfrage an den Service wird von der Callback Funktion in Codebeispiel~\ref{lst:safezone_controller} verarbeitet. Wenn die Sicherheitszone frei ist, sind Anfragen immer erfolgreich, unabhängig davon, ob sie mit \verb|req.occupy == false| erneut freigegeben oder mit \verb|req.occupy == true| belegt werden soll. Ist die Zone bereits belegt, schlägt eine weitere Belegungsanfrage fehl, während das Freigeben der belegten Zone erfolgreich ist. Auf eine Überprüfung des Senders, dass nur der Akteur, der aktuell die Zone belegt, sie auch wieder freigeben kann, wurde an dieser Stelle verzichtet. -\lstinputlisting[firstline=17,lastline=32, label={lst:safezone_controller}, caption={Callback Funktion des SafezoneController}]{../cobot_ws/src/safe_zone_controller/src/SafeZoneController.cpp} +\begin{lstlisting}[label={lst:safezone_controller}, caption={Callback Funktion des SafezoneController}] + bool occupy(cooperation_msgs::SafeZone::Request & req, cooperation_msgs::SafeZone::Response &res){ + if(safe_zone_is_free) { + safe_zone_is_free = !req.occupy; + res.success = true; + } + else if (req.occupy) { + res.success = false; + } + else { + // req.occupy == flase -> unblock the safe zone + safe_zone_is_free = true; + res.success = true; + } + return true; + } +\end{lstlisting} \subsection{ObjectCreator}\label{ch:objectCreator} 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.