SLAM auf dem ESP32?

[Holomino]

Layout:
Der gefüllte Kreis mit Richtungszeiger in der HTML-Seite sah eh schon fast wie ein Pacman aus. Dann können wir die Sauerei mithilfe einer einfachen farblichen Konvertierung im TileConverter auch komplett machen.

Wifi reconnect:
Damit der Roboter sich nach Verbindungsverlust wiederverbindet.

Putzen einiger Magic-Numbers im Code:
Eine Aufgabe eher allgemeiner Natur.

Speicherauslastung/-fragmentierung im Scan-Report:
min Heap, max Heap block size, used PSRAM. Das gehört zum Langzeittest dazu (seit der letzten Version kann die Simulation auch mal eigenständig hundert virtuelle Kilometer abspulen).


Alles in allem also eher Konsolidierungsmaßnahmen, konzeptionell nichts Neues. Im Augenblick strecke ich die Fühler etwas in Richtung OpenSlam.org aus: zumindest sehen TinySlam und GridSlam oberflächlich so aus, als würden sie sich irgendwie zwischen Ausgabe, Simulator, Grid und Pathfinder auf den ESP quetschen lassen.

Wie immer:
Die V 0.10 liegt auf https://c.gmx.net/@31902611639422705...SkGUZEDN7AmUzQ

[Holomino]

tinySlam



Im Groben sind Aufbau und Struktur des tinySLAM identisch zum Bisherigen. Es wird über die Variation der Pose getestet und anschließend das beste Ergebnis in die Karte eingetragen. Augenscheinliche Unterschiede:

• Der Datentyp der Kartenfelder muss erweitert werden auf uint16_t
• Belegte und freie Felder unterscheiden sich in der Richtung (bisher wurden freie Felder dekrementiert, jetzt werden sie inkrementiert)
• Der Test erfolgt nur noch über den Vergleich der Endpunkte (schneller)
• Das Eintragen der Hindernisse erfolgt über einen Fangbereich (hole_width), wobei die Wertigkeit der betroffenen Felder per Tiefpass gesetzt wird.

Weniger augenscheinliche Unterschiede (Macken):
Messungen im spitzen Winkel (nah vor der Wand oder bei der Fahrt um eine Innenecke herum) reißen bisher geschlossene Umrissstrukturen wieder auf. Das kann man aber filtern. Aus Slam.cpp:

//Suppress small angle entries (rays disturbing walls)
    if (x<= 3*dxc/4 && oldVal <0x8000)
      return;

Wo einerseits hinzugefügt, aber offensichtlich auch abgetragen wird, muss mit einem Langzeitdrift gerechnet werden. D.h. die Karte läuft langsam unter den Absolutkoordinaten des Routenplaners weg.

Dagegen hilft eigentlich nur das Sperren der Lidarkarte.


Deutliche Vorteile gegenüber der bisherigen SLAM-Lösung beginnen sich abzuzeichnen, wenn man in sim.h die Reichweite des Lidars drastisch reduziert (z.B. #define SIM_LIDARRANGE 2500). Auch wenn die langfristige Lokalisierung nach Abschluss der Exploration noch nicht zuverlässig läuft (hier fehlt im Wesentlichen noch die Erweiterung der Variationsbereiche in Richtung der OutOfRange-Messungen), funktioniert die Exploration in der Regel so gut, dass man wirklich einmal über den Bau eines "Poor mans Lidar" nachdenken darf. Zumindest nominal kommt man hier schon recht nah an den realen Messbereich eines VL53L1X - frei nach Lou Ottens also: Wenn's kleiner, einfacher und günstiger ist, könnte es was werden...

Der aktuelle Spielkram befindet sich als V0.10TS.zip unter: https://c.gmx.net/@31902611639422705...SkGUZEDN7AmUzQ

Weitere Infos über tinySLAM:
www.OpenSLAM.org
https://www.researchgate.net/profile...-of-C-code.pdf