Erste Versuche, eine Preview!
Da ich mal annehme, dass ein Simulator auf Windows-Basis weder als exe (wer startet schon fremde Software auf dem eigenen Rechner) noch als Code (wer hat schon ein Visual Studio) breite Akzeptanz findet, habe ich etwas umdisponiert und als Demo einfach eine sim-Datei aus meinem Simulator erzeugt, die sich auf das SPIFFS-Datenlaufwerk des ESP laden lässt.
Um trotzdem die heilige Dreifaltigkeit "Kommunikation (HWCom)", "Algorithmus (Slam)" und "Ausgabe (Drawing)" des Programmes zu erhalten, wird der Inhalt der Sim-Datei physikalisch über die UART geschickt (man kann ja einfach RxD und TxD brücken).
Der Inhalt der Sim-Datei: Ein Roboter mit Odometrie (Radencoder) fährt durch eine simulierte Umgebung und misst dabei mit einem sich drehenden Lidar die Abstände zu Wänden und Gegenständen (Hindernissen). Als Information bekommt der ESP für jede Messung ein Telegramm mit folgendem Aufbau:
Code:
typedef struct
{
uint8_t CmdID; //Telegram ID
float X; //subjective Pose X
float Y; //subjective Pose Y
float Orientation; //subjective Pose Angle
float LidarX; //measurement offset X (relative to robot Pose)
float LidarY; //measurement offset Y (relative to robot Pose)
}__attribute__ ((packed)) LidarData_t; //Length 21
X,Y und Orientation geben die Pose (Punkt und Ausrichtung nach Odometrieberechnung) an. LidarX/Y drücken das Ergebnis der Abstandsmessung relativ zur aktuellen Pose aus.
Ein Rundumscan (360°) aus der Bewegung heraus ist im unteren Teil des Bildes dargestellt, wobei real wesentlich mehr Messungen pro Umdrehung von einem Lidar zu erwarten sind. Hier in der Simulationsdatei sind es z.B. 120 Messungen pro Umdrehung, die aus der Bewegung heraus jeweils mit der entsprechenden Pose geliefert werden.
Gleichzeitig zeigt dieser Bildteil, wie der Slam die Daten aufbereitet: Die Messungen werden solange gepuffert, bis ein 360°-Rundumscan vollständig von der seriellen Schnittstelle empfangen wurde. Danach werden alle Messungen auf die Pose der letzten Messung im Scan umgerechnet (die Pfeile in Magenta). So erhalten wir für einen Scan eine einzelne subjektive (von der Odometrie gemessene) Pose mit vielen Messungen.
Der eigentliche Algorithmus hat nun folgenden Ablauf:
1. Er errechnet eine Posendifferenz (PoseChange) aus der subjektiven Pose des aktuellen und des letzten Scans
2. Diese Posendifferenz schlägt er im Rahmen des Testes mit leichten Variationen (Zufallsgenerator) auf die letzte objektive (vom Slam generierte) Pose auf. Entsprechend werden dabei die Messungen des Lidars umgerechnet und auf Korrelation in der Map getestet.
3. Das beste Ergebnis des Testes bestimmt einerseits, wo sich der Roboter befindet (jetzt kann die variierte Posendifferenz auf die objektive Pose aufgeschlagen werden) und darauf basierend, wo die Hindernisse in der Karte einzutragen sind.
Voraussetzungen für das Beispiel:
=======================
- ESP32-/ESP32-S2 Devboard (z.B. https://www.reichelt.de/nodemcu-esp3...2-p219897.html) (https://www.reichelt.de/de/de/entwic...r-p311737.html)
- Arduino IDE (1.8.16 ?)
Board-Package für den ESP32 (Erstinstallation: https://blog.espressif.com/arduino-f...g-f36d79967eb8 , Update über Boardverwalter)
- Bibliotheken AsyncTCP/ESPAsyncWebServer (Anweisunge/Download: https://randomnerdtutorials.com/esp3...erver-arduino/)
- Arduino PlugIn SPIFFS Uploader (für den S2: https://github.com/lorol/arduino-esp...lugin/releases)
- Dieses Projekt (Unter https://c.gmx.net/@31902611639422705...SkGUZEDN7AmUzQ die Datei V0.5.zip)
- Ein Patchkabel 2 x feminin, um RxD/TxD einer UART an den Stiftleisten zu brücken
Step by step
============
- Nach Installation der Bibliotheken AsyncTCP/ESPAsyncWebServer die Datei "AsyncWebSocket.h" suchen, mit einem Texteditor öffnen und die Konstante WS_MAX_QUEUED_MESSAGES auf 8 setzen.
- Das Spiffs PlugIn nach Anleitung installieren
- Das Projekt entpacken und mit der Arduino-IDE laden
- Hier muss ggf. für den S2 das ESP-Package im Boardverwalter aktualisiert werden (aktuell Version 2.0.1)
- Wie in so jedem Web-Beispiel üblich, die Konstanten SSID/PWD an den eigenen Router anpassen. (in Common.h DRAWING_WIFI_SSID/ DRAWING_WIFI_PWD)
- Den ESP per USB an den Entwicklungsrechner anschließen, die entsprechenden Einstellungen im Werkzeugmenü vornehmen.
- Entscheidung mit/ ohne PSRAM (Wrover oder Wroom). Wenn mit PSRAM, dann "Werkzeuge->UsePSRAM" aktivieren UND ggf. Kommentarzeichen vor der Konstante SLAM_USE_PSRAM aus Common.h löschen.
- RxD und TxD an den Stiftleisten brücken. Beim ESP32 bietet sich UART2 an, beim ESP32-S2 UART1, In Common.h lässt sich die Sache über die Konstanten HWCOM_UART, HWCOM_RXGPIO und HWCOM_TXGPIO konfigurieren. (HWCOM_RXGPIO/HWCOM_TXGPIO berücksichtigen die Möglichkeit des Portmultiplexing. Man kann sie auskommentieren)
- Das Projekt auf den ESP hochladen (Strg+U).
- Anschließend die Dateien aus dem data-Verzeichnis per "Werkzeuge->ESP Sketch Data Upload" auf den ESP laden
Im seriellen Monitor der Arduino IDE sollten nun nach den üblichen Bootmeldungen des ESP folgende Zeilen erscheinen:
Code:
WS_MAX_QUEUED_MESSAGES from AsyncWebSocket.h:8
->gibt den Erfolg der Patchaktion in AsyncWebSocket.h an. Diese Einstellung ist heikel, weil die Nachrichtenschlange damit nur in der Anzahl der Telegramme begrenzt ist. dabei allerdings die Größe der Telegramme nicht berücksichtigt.
Code:
SPIFFS: 1378241 total, 1027594 used
Listing directory: /
FILE: Data1.sim SIZE: 361914
...
->auch die Dateien sind angekommen
Code:
Connecting to WiFi..
192.168.137.136
-> Die hier angegebene IP einfach mal als URL im Browser eingeben
-> Oh, es geht schon los. Wenn die Meldung fehlt, steckt das Patchkabel an den falschen Pins.
-> Schon fertig? Nochmal! Also: Reset-Taster am ESP drücken, Browser durch F5 aktualisieren.
Versuche:
=========
Ok, irgendwann hat man sich sicher satt gesehen. Vielleicht zuerst einmal schauen, ob die Sache nicht ein Fake ist? Um zu sehen, welche Daten der Simulator wirklich geliefert hat, kann der SLAM durch das Nullen der Variationsgrößen praktisch außer Gefecht gesetzt werden. Ändere dazu in Common.h folgende defines:
Code:
#define SLAM_ANGLEDEVIATION 0
#define SLAM_DISTANCEDEVIATION 0
Wird das Ergebnis besser/schlechter, wenn ich mehr oder weniger Variationen verwende?
Code:
#define SLAM_VARIATIONS 50
Kann ich die Karte gröber oder feiner auflösen?
Code:
#define SLAM_RASTER 25.0
Kann ich die Kacheln größer oder kleiner machen?
Code:
#define SLAM_TILESIZE 16
Kann ich die Sache beschleunigen?
Aus Common.h
Code:
#define HWCOM_SIMFILEPRESCALER 6
Sprich: Alle 6ms (nominal 6x 1ms Zykluszeit der HWCom-Task) wird ein Lidartelegramm versendet.
Tatsächlich aber gibt die HTML-Seite in der Debug-Sektion Auskunft.
Der "Scan integration report" gibt an, wie lange die Integration eines Scans dauert (Time) und wie lange der Algorithmus zwischen den Scans Päuschen macht (Idle).
Überraschend für mich: Auf dem ESP32-S2 (LX7, neuere Architektur, aber nur Single-Core) erreiche ich einen Verarbeitungszyklus von ca. 500ms/Scan. Der ältere ESP32(LX6, Dualcore) braucht dafür nur ca. 120ms. Da die Geschwindigkeit mehr als doppelt so hoch ist, bleibt für den S2 nur zu vermuten, dass sich hier der Overhead aller laufenden Tasks auf einem Kern negativ auswirkt oder (hoffentlich) kommende Package-Versionen die Sache noch etwas beschleunigen.
Berechtigungen
Zitieren
Lesezeichen