Nachdem ich unzählige Stunden mit micro-ros auf dem ESP32 verbracht habe, bin ich um einige Erkenntnisse reicher. Meine Idee war, viele Dinge direkt auf dem ESP32 erledigen zu lassen und einzelne Nachrichten an andere ROS 2 Nodes zu senden. Nach diversen Problemen mit dem Build System (gruselig) und nachdem ich endlich eigene Nachrichtendefinitionen ins micro-ros gebracht hatte, kam der nächste Rückschlag. Es werden im Standard nur sehr wenige publisher/subscriber ermöglicht (2). Man kann dies zwar in der Konfiguration des Build Systems anpassen, dies sind aber weitere Hürden, die nicht leicht zu erklären sind. Zudem ist die Dokumentation sehr lückenhaft und setzt viele Kenntnisse voraus, die mir fehlen.
Ich möchte die Arbeit aber nicht nur für mich erledigen. Ich möchte das ganze in einen Stand bringen, der auch andere in die Lage versetzt, den Ardumower als Turtlebot zu steuern. Dies aber bitte ohne tiefgehende Kenntnisse von micro-ros. Ich bin der Meinung, diese Hürde ist für viele zu groß und ich bin nicht in der Lage, dies aus einem einzigen Repository zu bedienen. Ich könnte nun mit Docker anfangen, mir fehlt aber die Lust, mich da auch noch rein zu finden.
Also zurück auf "LOS" und von vorne beginnen? Zum Glück nicht ganz. Dank der bisherigen Vorarbeiten in der Ardumower Turtlebot Firmware sowie der bisherigen Ardumower ROS 2 Nodes ist es recht einfach, verschiedene Szenarien abzudecken. Ich sehe diese Optionen und bin aktuell mit der Umsetzung dran:
1. alles läuft auf dem Mower. Ein RPI ist direkt per UART mit dem Ardumower verbunden
2. einige ROS 2 Nodes (Ardumower driver, base controller) auf dem Mower (RPI) und weitere Nodes (Path planning, opencv usw.) auf einem dedizierten stationären PC
3. Ardumower mit ESP32 per UART verbunden. micro-ros auf ESP32 überwacht UART und sendet/empfängt die Daten an ROS 2 mittels einer einfachen String message. Die weitere Verarbeitung findet dann auf einem stationären System statt
Anbei ein kleines Bildchen dazu
Der ROS 2 Node "Ardumower Driver" dient zur Übertragung der UART Daten (entweder durch direkte Anbindung oder über die String Messages auf Topic /ardumower_uart_rx/tx) in eigene Ardumower Nachrichten (Namespace ardumower_msgs).
Der ROS 2 Node "Base controller" hat eine Subscription zu einigen der Ardumower Messages und überträgt diese in Standard ROS 2 Nachrichten, etwa aus dem Namespace sensors_msgs oder nav_msgs. Außerdem übernimmt der Base Controller die tf Transformation für Odometrie und IMU.
Warum macht dies der Ardumower Driver nicht direkt? Ich denke über diesen Weg halte ich Möglichkeiten offen, die Rohdaten des Mowers in anderen Nodes weiterzuverarbeiten. Ob das erforderlich sein wird, kann ich aktuell nicht sagen. Der Weg ist aber vorhanden.
Eine weitere, tiefgreifende Entscheidung ist getroffen. Ursprünglich wollte ich so viel wie möglich aus der Firmware raus nehmen. So sollten auch das Perimeter Tracking, PID Controller und Kurskorrekturen Anhand der IMU und Odometrie Daten ins ROS 2 wandern. Dies geht aus meiner Sicht aber nur, wenn die Dinge entweder auf dem lokalen RPI im Mower oder im micro-ros erledigt werden. Die Latenz über WLAN ist einfach zu groß, besonders wenn die Abdeckung im Garten lückenhaft ist. Zudem hätte das alles neu implementiert werden müssen.
Glücklicherweise kann die Azurit Firmware das ja seit Jahren und sehr stabil. Also wandern diese Dinge wieder zurück in die Turtlebot Firmware. Die Häufigkeit der ROS 2 Nachrichten kann reduziert werden (Perimeter alle 50ms vs. alle 100ms) und der Aufwand in ROS 2 beschränkt sich "nur" auf SLAM (das Thema ist komplex genug).
Damit ROS 2 den Mower zum Perimeter Tracking bekommt, wird eine ROS 2 Action erstellt. ROS 2 sendet dann die Anforderung "Tracking" und Azurit legt los. Dank IMU, ODOM und Perimeterdaten alle 100ms kann eine Cost Map des Gartens erstellt werden, welche fürs path planning dient. Eine weitere Action stoppt das Tracking wieder.
Aktuell ist es auch so, dass /cmd_vel Nachrichten (lineare- und Winkelgeschwindigkeit) vom base controller in PWM Werte übersetzt werden. Hierüber ist aus meiner Sicht keine Kurskorrektur über Azurit möglich. Dies erfolgt nach meiner Erkenntnis bisher über die Ziel -RPM der Räder. Daher werde ich dies ändern und die Ziel Geschwindigkeiten an Azurit übergeben. Das Berechnen der PWM Werte erfolgt dann hier inkl. Beschleunigungsrampen, die ich zuvor in ROS2 hatte.
Das klingt vielleicht nicht sehr spannend, es bleibt ja vieles beim Alten. Ich bin aber froh, dies für mich sortiert zu haben und eine klare Trennung zwischen Azurit und ROS 2 zu haben. Bei der Recherche ist mir glücklicherweise aufgegangen, dass andere (Kobuki also der ursprüngliche Turtlebot, Roomba, Neato) das ebenfalls so handhaben. Es gibt immer einen MCU der MEHR als nur elementarste Operationen übernimmt und eine darauf aufsetzende Software, welche den Rest übernimmt. Die einschlägigen Tutorials zu ROS und ROS 2 greifen hier einfach zu kurz und führen (aus gutem Grund), nie über Teleoperation hinaus. Ich habe mich immer gewundert, warum SLAM, path planning etc. immer nur in der Simulation, nie am realen Robot gezeigt werden. Jetzt weiß ich es.