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

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 sich nun in Zukunft der Pin ändern, an dem die LED befestigt ist, müssen wir den Programmcode des Nodes weder anfassen noch kompilieren, da die nötigen Parameter extern gesetzt werden. Ein Node kann Parameter lesen, schreiben und löschen. Parameter können in YAML-Dateien ausgelagert werden. YAML steht für »YAML Ain’t Markup Language« und gehört in die Familie der Beschreibungssprachen. Im Gegensatz zu HTML und XML ist das YAML-Format für Menschen deutlich besser zu lesen, während HTML und XML von Computerprogrammen, genauer gesagt von Parsern, leichter verarbeitet werden. Der Speicherort ist ein Ordner namens config innerhalb eines ROS-Pakets. Der Dateiname hat die Endung .yaml.

Nodes können vor, während des Starts und im laufenden Zustand konfiguriert werden.

Der Parameter-Server läuft innerhalb des ROS-Masters und kann somit per XMLRPC abgefragt werden. Da das Abfragen der Parameterwerte die Nodes Zeit kostet, sind Parameter für nicht verändernde Konfigurationseinstellungen besser geeignet als sich ständig verändernde Parameterwerte. Erst wenn man den ROS-Master beendet, wird der Parameter-Server beendet und alle Parameter werden gelöscht. Ein Node, der private Parameter für sich oder globale Parameter für alle Nodes gesetzt hat, wird nicht automatisch die gesetzten Parameter löschen, sobald er beendet wird. Alle Parameter unterliegen der Obhut des Parameter-Servers und somit des ROS-Masters. Erst wenn man den ROS-Master beendet, werden alle Parameter gelöscht.

Einen Auszug der Parameter erhalten wir mit dem Befehl rosparam list. Anhand der Ausgabe erkennen wir eine gewisse Nomenklatur, die sich an die Namenskonvention von ROS hält. Unter dem Link http://wiki.ros.org/Names finden wir eine ausführliche Beschreibung dazu.

...

/move_base/base_global_planner

/move_base/base_local_planner

/move_base/global_costmap/footprint

/move_base/global_costmap/inflation_layer/enabled

/move_base/global_costmap/obstacle_layer/enabled

/joint_state_controller/publish_rate

/joint_state_controller/type

In der Beispielausgabe stehen die Namen der Nodes am Anfang, gefolgt von den Parametern. Angenommen, wir wollen die Parameter von move_base verifizieren, ob diese auch korrekt gesetzt wurden. Einen Parameterwert können wir mit dem Befehl rosparam get ausgeben. In der Beispielausgabe ist nur ein Bruchteil der Parameter von move_base aufgeführt. In Wirklichkeit sind es nach Ausführen des Befehls rosparam list | grep move_base | wc -l insgesamt 121. Anstatt alle Parameter einzeln mit rosparam get abzuarbeiten, ist es möglich, anhand des Node-Namen eine geordnete Liste der 121 Parameter und Parameterwerte auf der Konsole auszugeben.

rosparam get /move_base

Ist nur ein Teilbereich von /move_base für uns interessant, so geben wir den Namen nach einem Schrägstrich ein.

rosparam get /move_base/global_costmap

Parameterwerte werden mit dem Befehl rosparam set auf dem Parameter-Server gespeichert. Da diese Speicherung flüchtig ist und den nächsten Neustart des ROS-Masters nicht übersteht, empfiehlt es sich, eine eigene Parameter-Datei anzulegen, um diese beim Start mit rosparam load oder in einer launch-Datei zu laden. In ROS kommt zu diesem Zweck das YAML-Format zum Einsatz.

Nachfolgend sehen Sie einen Auszug aus einer Konfigurationsdatei im YAML-Format; das Raute-Symbol (#) leitet einen Kommentar ein und wird nicht als Konfiguration verarbeitet.

#abot:

# Publish all joint states

joint_state_controller:

type: joint_state_controller/JointStateController

publish_rate: 50

# Effort Controllers

leftWheel_effort_controller:

type: effort_controllers/JointEffortController

joint: left_wheel_motor

pid: {p: 100.0, i: 0.1, d: 10.0}

rightWheel_effort_controller:

type: effort_controllers/JointEffortController

joint: right_wheel_motor

pid: {p: 100.0, i: 0.1, d: 10.0}

Die Zeileneinrückung und Doppelpunkte in einer YAML-Datei bestimmen den hierarchischen Aufbau der Parameter, sobald diese auf dem Parameter-Server geladen werden. Im obigen Beispiel wird aus leftWheel_effort_controller: type: /leftWheel_effort_controller/type. Ein weiterer Speicherort für Parameter sind Launch-Dateien.