Crawlee soll so weit wie möglich auf ROS aufbauen. ROS ist eine Sammlung von Linux-Paketen, die als Zwischenschicht einige Services für Roboter anbietet. In der ROS-Welt gibt es eine beliebige Anzahl an Nodes (Achtung: Ab hier werde ich mich bestem Denglisch bedienen - ja, noch (viel) mehr als vorher…), die die eigentliche Arbeit erledigen. Diese können sich miteinander über so genannte Topics und Services unterhalten.

Dabei sind Topics eine Art Broadcasting-System. Ein Node kann Daten zu einem Topic publishen und alle Nodes, die sich für dieses Topic interessieren, können dieses Topic subscriben und erhalten von da an die Daten übermittelt. Services hingegen sind eine Art Remote-Procedure-Call-Verfahren (RPC) und ermöglichen es Befehle an Nodes zu übermitteln.
Intern gibt es sicher Unterschiede in der Implementierung, mit etwas Abstand verschwimmen die Einsatzgebiete für Topics und Services aber an vielen Stellen. Als Beispiel könnte man einen Node, der die Bewegung kontrolliert, nennen. Ist ein Bewegungsbefehl ein Topic oder doch ein Service des Nodes?
Ich werde zunächst einmal versuchen Services nur zur Kontrolle/Konfiguration der Nodes zu benutzen. Sprich um den Zustand/State des Nodes zu verändern. Für die Datenübermittelung (und Bewegungsbefehle sind imho keine State-Änderung) werde ich daher auf Topics zurückgreifen.

Natürlich kann man sich fragen, ob es nicht bereits ausreichend verschiedene Datentransfer und RPC-Mechanismen in Linux selbst gibt, und es eines ROS Aufsatzes wirklich bedarf… In meinen Augen gibt es auch da keine klare Antwort zu, aber der ROS Ansatz hat eine viel wichtigere Funktion, als das reine Angebot von Low-Level Services:

Standardisierung!

Der wirklich große Vorteil ist am Ende, dass man streng eingekapselte Module für ROS-Roboter bauen kann. Publizieren oder subscriben sie zu den richtigen Topics, kann man sie mit bestehenden Nodes zusammenarbeiten lassen, ohne irgendwelche zusätzlichen Interfaces zu programmieren, oder in den Code der bestehenden Nodes einzugreifen.

Um ROS nun auf meinen selbstgebauten Roboter anwenden zu können, benötige ich zunächst eine neue Zwischenschicht, zwischen der PR6 Hardware und dem Linux Betriebssystem. Das führt zu der folgenden Architektur.



Dabei werde ich in einem ersten Schritt zwei neue Softwares programmieren, die ich als Firmware (Software, die auf dem Atmega32 läuft und dabei unter keinem Betriebssystem) und Driver (ein Linux Programm, dass die FW Funktionen unter Linux/ROS zur Verfügung stellt) bezeichne. Der Driver wird dabei kein echter "Linux Treiber" werden, sondern ein reguläres Linux Programm im User-Space. Da ich auf keine HW Funktionen des EeePC zugreifen möchte, sondern lediglich über mein USB-2-UART kommunizieren mag, ist das ausreichend. Dazu aber ein anderes Mal mehr.