Roboter mit ROS - Murat Calis

Скачать книгу

so viel bedeutet wie, der Vorgang von Anfrage bis Antwort lässt keine parallelen Prozesse in dem aufrufenden Programm zu. Nehmen wir an, wir möchten zwei Arme gleichzeitig bewegen, dann würden wir eine Anfrage an den Service des einen Arms und eine weitere Anfrage in der nächsten Zeile unseres Nodes an den Service des anderen Arms senden. Der Node, aus dem wir beide Services aufrufen, wird allerdings zunächst die im Node erste Anfrage abarbeiten und erst wenn eine Antwort zurückgekommen oder der Vorgang abgeschlossen ist, wird der nächste Arm aufgerufen.

       Service blockiert

      Wenn man auf der Client-Seite ein Service anruft, um Berechnungen durchführen zu lassen, dann geht es auf der Client-Seite erst dann wieder weiter im Programm, wenn die Antwort zurückgekommen ist. Services arbeiten synchron, nicht asynchron. Deshalb sollten Services nur für kurzfristige Berechnungen oder Befehle verwendet werden. Für asynchrone Verarbeitung und langwierige Prozesse mit verzögerten Antwortzeiten kommen Actions ins Spiel – dazu später mehr.

      Informationen über ein Service erhält man mit dem Befehl rosservice. Genauso wie bei rostopic ist es mit rosservice möglich, alle aktuell gestarteten Services mit dem Befehl list auszugeben.

      rosservice list

      Die Ausgabe von rosservice info liefert Adresse, URI, den Datentyp und Argumente:

      rosservice info /move_base/clear_costmaps

      Node: /move_base

      URI: rosrpc://rosbox:34273

      Type: std_srvs/Empty

      Args:

      Nachrichtentyp für einen Service ausgeben:

      rosservice type /move_base/clear_costmaps

      Die Ausgabe eines Serviceformats liefert Anfrage- und Antwortbereich:

      rossrv show std_srvs/SetBool

      bool data

      ---

      bool success

      string message

      Mit rosservice haben wir Informationen über ein oder mehrere Service-Nodes erhalten. Jedoch verwenden wir den Befehl rossrv, um das Format einer Service-Definition auszugeben. Der Befehl rossrv ist vergleichbar mit rosmsg, den wir in Abschnitt 1.2.7 verwendet haben. Verwenden Sie doch mal rossrv list, um zu sehen, welche Serviceformate auf Ihrem Computer installiert sind.

      Wenn wir als Nächstes einen Service im Terminal aufrufen möchten, verwenden wir den Befehl call. Somit können wir ohne jegliche Programmierarbeit die Funktionalität und die Auswirkung eines Service testen. Mit dem folgenden Befehl rufen wir den Node move_base an und senden eine Nachricht im Format std_srvs/Empty an den Service clear_costmaps. Auch hier gilt: Wenn wir nicht wissen, wie man std_srvs/ Empty ausschreibt, zwingen wir die Konsole mit doppelten Tabulatortasteneingaben zur Autovervollständigung unserer Eingabe.

      rosservice call /move_base/clear_costmaps "{}"

image

      Abb. 1–8Service-Client und Service-Server

       1.2.9ROS-Actions

      Mit Services haben wir gelernt, kurzfristige Frage-Antwort-Techniken zu verwenden. Was aber, wenn wir langfristige Aufgaben zu bewältigen haben? »Gehe in die Küche, mache das Licht aus und komme wieder zurück«, ist eine typische Aufgabenstellung in der Robotik. Solche zeitintensiven Aufgaben lösen wir mit Actions. Dazu gibt es in ROS das actionlib-Paket. Die actionlib bietet eine standardisierte Schnittstelle, um mit präemptiven Aufgaben zu arbeiten.

      Ähnlich wie Services gibt es bei der Verwendung von Actions einen ActionServer und einen ActionClient. Eine Action-Definition wird in eine Datei mit der Endung .action geschrieben. Der Ordnername für Actions lautet action innerhalb eines ROS-Pakets. Action-Dateien sind in drei Bereiche gegliedert, die jeweils mit drei Bindestrichen voneinander abgetrennt werden. Die Reihenfolge innerhalb einer Action-Datei ist Goal, Result und zuletzt Feedback. Wer eigene .action-Dateien verwenden möchte, muss diese wie bei Services besprochen zunächst mit catkin_make in Klassendateien umwandeln lassen.

      Ein wichtiges Merkmal von Actions ist, dass sie weder den ActionClient-Node noch den ActionServer-Node blockieren, Stichwort »asynchron«! Man kann eine Action jederzeit stoppen, pausieren, neue Ziele eingeben und parallel andere Aufgaben erledigen.

       GoalEin ActionClient sendet ein Goal (deutsch Ziel) an einen ActionServer. Wenn wir mit Services vergleichen, wäre dieser Teil ein Request. Ein Goal könnte am Beispiel einer mobilen Basis eine Koordinate sein, die es zu erreichen gilt.

       ResultDas Ergebnis wird nach Beendigung der Action auf dem ActionServer nur einmal an den ActionClient zurückgegeben.

       FeedbackUnter Feedback kann man sich den Fortschritt der aktuellen Action vorstellen. Die Richtung ist von ActionServer zu ActionClient. Es obliegt der ActionServer-Programmiererin, eine geeignete Fortschrittsprozedur zu implementieren. Dies könnte zum Beispiel die aktuelle Koordinate des Roboters sein oder in Prozent ausgedrückt, der Anteil am zurückgelegten Weg. Der Fortschritt wird fortlaufend in der Frequenz des ActionServers zurückgegeben.

      Da die Zusammenhänge und die darunterliegende Technik sehr umfangreich sind, möchte ich an dieser Stelle auf die Wiki-Seiten von ROS verweisen, die eine exzellente Beschreibung der Technik und Vorgänge in Actions bieten. Die Startseite für actionlib finden wir unter http://wiki.ros.org/actionlib, eine detaillierte Beschreibung steht unter http://wiki.ros.org/actionlib/DetailedDescription.

      Schauen wir uns eine Action-Datei mit dem Befehl rosed etwas genauer an. Mit rosed können Dateien, die über die Pfadvariable $CMAKE_PREFIX_PATH erreichbar sind, editiert werden.

      rosed move_base_msgs MoveBase.action

      geometry_msgs/PoseStamped target_pose

      ---

      ---

      geometry_msgs/PoseStamped base_position

      Die Datei MoveBase.action enthält drei Bereiche, die durch jeweils drei Bindestriche getrennt sind. Der Bereich für Result wurde ausgelassen. Die hierbei verwendeten Messages, geometry_msgs/PoseStamped sehen wir detailliert mit dem Befehl rosmsg show geometry_msgs/PoseStamped.

       1.2.10ROS-Parameter

      Nehmen wir an, eine LED ist auf einem Mikrocontroller an Pin 13 befestigt. Die Konfiguration dazu schreibt man für gewöhnlich in den Programmcode noch vor dem Hauptprogramm. In ROS können wir diese Konfiguration auslagern, indem wir den Parameter-Server verwenden.

       Parameter-Server

      Ein Parameter-Server ist vergleichbar mit einem Verzeichnisdienst. Er ist über das Netzwerk erreichbar und kann Parameter speichern und Parameterwerte zurückgeben. Er eignet sich am besten für statische Parameter, die sich nie oder nur selten ändern. Andauernde Abfragen würden wegen dem Verbindungsaufbau mit dem Parameter-Server zu viel Zeit verbrauchen, um performant genug zu sein.

      Sollte

Скачать книгу