Читать книгу Roboter mit ROS - Murat Calis - Страница 25

Ein erweitertes Kommunikationskonzept in ROS sind Services. Vergleichbar mit Diensten arbeiten sie im Gegensatz zu Messages bidirektional. Man hat es also nicht mit einem Datenstrom zu tun, der in nur eine Richtung fließt, vielmehr ist es ein Frage-Antwort-Mechanismus (engl. Request-Response). Ein Node übernimmt die Server-Funktion, also Service, und am anderen Ende nutzt ein Client verfügbare Service-Leistungen.

Services werden in .srv-Dateien definiert, ähnlich wie Messages, nur dass zusätzlich ein Bereich für die Antwort vom Service definiert werden muss. Der Antwortbereich ist durch drei Bindestriche vom Anfragebereich abgetrennt. Der Ordnername für Servicedateien lautet srv. Die verwendbaren Datentypen sind dieselben, die in Messages verwendet werden können. Im Internet finden wir diese Datentypen in einer tabellarischen Übersicht unter http://wiki.ros.org/msg.

Wer eigene .srv-Dateien verwenden möchte, muss diese zunächst mit catkin_make in Klassendateien umwandeln lassen. Erst dann können die Servicedefinitionen in eigene Programme als Header bzw. Bibliotheken eingebunden und verwendet werden. Insgesamt berührt man die Dateien CMakeLists.txt, package.xml und die .srv-Datei, bevor man eine eigene Servicedefinition überhaupt verwenden kann. Ein ROS-Tutorial beschreibt die benötigten Schritte auf folgender Website: http://wiki.ros.org/ROS/Tutorials/CreatingMsgAndSrv.

Services arbeiten blockierend, was 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 "{}"

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