Think Modular

[Holomino]

Es fehlt immer noch was - der Braincomputer:
Nachdem wir nun wissen, das wir laufend von Navigations- und Hindernissensorik, Bewegungsmodul und Powermodul mit Daten bombardiert werden, wir auch noch Fahranweisungen und Steuerkommandos zurückschicken müssen, wird es Zeit, sich über den Umfang dieser Aufgabe klarzuwerden.

Zur Anbindung:
Ich hatte ja schon im Eingangsthread den Vorschlag gemacht, Bluetooth als Schnittstelle zur Hardware zu verwenden. Dann kann man z.B. auch das ausgediente Smartphone als Brain nutzen oder zur Entwicklungszeit die typischen 10m Reichweite dazu verwenden, komfortabel am PC oder Notebook zu entwickeln. Für den autarken Betrieb braucht man noch einen Versorgungsstecker. Brains ohne eigenen Akku, z.B. Raspberrys, quittieren eine Notabschaltung ohne geordnetes Herunterfahren im schlimmsten Fall mit einer kaputt geschriebenen SD-Karte. Das sollte man im Powermodul durch eine Ausschaltverzögerung berücksichtigen.

Zur Aufgabe:
SLAM baut eine Umgebungskarte und verbessert die Pose des Roboters darin. Die Funktion lässt sich am besten durch einen Stitch-Assistenten verdeutlichen, der laufend Teilbilder aus der Navigationssensorik möglichst passend übereinanderlegt und so über die vorgenommene Verschiebung eines eingefügten Teilbildes auf die tatsächliche Pose des Roboters rückschließt.

Sicher wird ein Roboter die Umgebungskarte für seine Fahrten nutzen, das Generieren der Bahnen ist allerdings nicht direkter Bestandteil von SLAM. Ein Pathfinder sucht auf der Umgebungskarte den kürzesten Weg von A nach B, ein Pathfollower führt die Fahrt durch senden von Steuerbefehlen an den Antrieb aus. Tritt im Verlauf der Fahrt ein Fehler (ein neues Hindernis) auf, muss der Pathfinder neu berechnen.
Ein Aufgabenplaner plant Abfolgen (z.B.: Fahre von A über B nach C und zurück nach A). Bei einem Überwachungsroboter z.B. werden so eine Reihe von anzufahrenden Wegpunkten und eine Uhrzeit für die Ausführung vorgegeben. Beim Saugroboter generiert der Aufgabenplaner die Wegpunkte in einem Raster, um die gesamte Bodenfläche abzudecken.

Das alles wollen wir überwachen und auch steuern. Dazu brauchen wir eine lesbare Darstellung der Umgebungskarte, der aktuellen Roboterpose und auch Eingriff in die Aufgabenplanung. Das bitteschön aber nicht am Gerät, sondern bequem vor einem Monitor - sonst müssten wir ja hinterherrennen.

Mal ein Fallbeispiel: Eine 10mx10m=100qm-Wohnung und ein Lidar

Die Umgebung lässt sich theoretisch in einem Occupancy-Grid (2D-Array, in dem je ein Wert eine x-y-Rasterfeld als frei, belegt oder unbekannt beschreibt) von 100x100=10000 Bytes mit den Abmessungen 10x10cm darstellen.
- Praktisch wissen wir nicht, wo und in welchem Winkel zu den Grundabmessunen wir starten. Das vergrößert das Grid ohne weiteres Speichermanagement um den Faktor (2*Wurzel(2))²=8 (Wir starten in der Mitte des OccupancyGrids und lassen in allen vier Himmelsrichtungen Platz für die Diagonale der 10*10m-Wohnung).
- Wir müssen unterscheiden zwischen Umgebung für den Stitch-Assistenten und Hindernisdetektion (was das Lidar nicht sieht, kann es nicht wiedererkennen). In eine zusätzliche Liste werden Hindernisse eingetragen (das Datenaufkommen ist wahrscheinlch niedrig).
- Die Umbewertung eines Feldes von "frei (>0)" auf "belegt (<0)" ist im worst case relativ träge (von 127 auf -1). Lidars haben die Eigenschaft, zwischen zwei Einzelmessungen eine Lücke aufzuweisen. So sieht man Stuhl- oder Tischbeine erst bei Annäherung. Man kann das Lidar aber selber als Hindernissensor interpretieren, also z.B. den letzten Scan in die Hindernisliste schreiben. Über die logische Oder-Verknüpfung von Occupancy-Grid des Lidars und Hindernisliste ergibt sich dann, ob ein Feld belegt ist.
- Die Abmessungen des Roboters und die Auflösung des Grids bestimmen, ob Felder in der Nachbarschaft eines belegten Feldes befahrbar sind. Ein Roboter mit 30cm Umfang stößt bereits auf dem Nachbarfeld eines als belegt markierten Feldes an das Hindernis an. Also muss man im Pathfinder auch diese Nachbarfelder ausschließen. Das kann man tun, indem man in einem neuen Grid (NavigationGrid) einfach die Hindernisse entsprechend der Abmessungen des Roboters vergrößert und im Pathfinder die Position des Roboters weiterhin als Punkt betrachtet.

Zusammen braucht man so LidarGrid, Hindernisliste und NavigationGrid. Zusätzlich braucht man noch einmal Speicher in der Größenordnung des NavigationGrid für den Pathfinder.
Ob das Raster so passt, erfährt man erst, wenn man in der Wohnung die schmalsten Wege (zwischen Sofa und Tisch?) sucht. Es ist zwar naheliegend, einen 30cm-Robbi auf einer 30x30cm aufgelösten Karte fahren zu lassen, aber 30cm Auflösung heißt auch nur, dass auf einer Kachel von 30x30cm irgendwo ein Hindernis liegt- vielleicht liegt es am Rand. Dann ist das Befahren des Nachbarfeldes in der Diagonale schon nicht mehr möglich.

Tröstlich: mit einem persistenten Speicher (SD-Karte,...) benötigt man weniger RAM. Änderungen in Lidar- und NavigationGrid könnnen nur in Sensorreichweite auftreten. Außerhalb der Reichweite liegende Kartenteile können also weggespeichert und bei Bedarf wieder hervorgeholt werden. Beim Pathfinder allerdings spart man ohne Vorberechnungen nix (der braucht zur Berechnung eines Pfades die gesamte Karte).

Fazit: Das klingt nicht nach einer Aufgabe für einen Microcontroller (die Funktion des "Stitch-Assistenten" habe ich noch gar nicht aufgezählt), zumal man beim Entwickeln ohne die grafische Darstellung kaum die Arbeit des SLAMs verifizieren kann. Die ganze Sache vielleicht noch per Wifi ins lokale Netz bringen zu wollen, macht es nicht unbedingt einfacher oder kleiner. Die Hardware über Bluetooth anzubinden erlaubt erst einmal den Start auf dem größtmöglichen Brain (das Entwickeln am PC). Herunterstrippen kann man später immer noch.