-         
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 14

Thema: SLAM auf dem ESP32?

  1. #1
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    07.04.2015
    Beiträge
    782

    SLAM auf dem ESP32?

    Anzeige

    Ich hab hier ein ESP32-S2 Wrover Devboard (Saola V1.2 mit 2MB PSRAM) herumliegen (konnte beim Shoppen nicht widerstehen). Nominal sollte damit nichts gegen einen abgespeckten Lidarroboter mit kleinem Gridslam sprechen(?):
    - Frontend über Websocket
    - Aufnahme der Eingangsdaten (Odometrie und Lidarmessungen) über serielle Schnittstelle (für den Anfang aus einem Simulator).

    Hat das schon mal jemand hier mit dem ESP32 versucht?

  2. #2
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.619
    Blog-Einträge
    29
    Ich habe noch gar nichts mit dem ESP32 versucht. Das liegt da dran, dass ESP32 nicht so gut unterstützt (Arduino-IDE) wird, wie ESP8266; ist jedenfalls das, was ich mal gelesen habe. Ob das inzwischen anders ist, weiß ich nicht. Auch nicht, ob LittleFS inzwischen für den ESP32 verfügbar ist.
    Von der Leistung müsste der ESP32 doch ausreichen, mit >=140MHz Taktrate und zwei Kernen?

    Freundlichen Gruß

  3. #3
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    07.04.2015
    Beiträge
    782
    Ob es reicht? Versuch macht kluch!

    So, ich habe mittlerweile:
    - die passende Unterstützung für meine Arduino IDE(1.8.16) installiert (https://blog.espressif.com/arduino-f...g-f36d79967eb8). Mittlerweile gibt es das ESP-Package in der Version 2.01
    - das erste Beispiel (https://randomnerdtutorials.com/esp3...erver-arduino/) mit Installation der Bibliotheken für den WebSocket-Server angetestet. Das funktioniert auch mit dem neueren ESP32-S2.

    Der Plan wäre nun, das Grundgerüst des Projektes zu erstellen. Ich denke mal, mit drei wesentlichen Komponenten komme ich erst einmal hin.
    - HWCom: (Serielle Schnittstelle mit telegrammbasiertem Protokoll)
    - Slam: Die eigentliche Algorithmusrechnerei
    - Drawing: IO und Handling des Websocket-Servers

  4. #4
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    07.04.2015
    Beiträge
    782
    Erste Versuche, eine Preview!

    Klicke auf die Grafik für eine größere Ansicht

Name:	ESPSlamPreview.png
Hits:	9
Größe:	71,5 KB
ID:	35671

    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
    Klicke auf die Grafik für eine größere Ansicht

Name:	LidarData.png
Hits:	7
Größe:	118,6 KB
ID:	35670

    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

    Code:
    RANDOM INITIALIZED
    -> Oh, es geht schon los. Wenn die Meldung fehlt, steckt das Patchkabel an den falschen Pins.

    Code:
    Simulation end
    -> 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.
    Geändert von Holomino (16.12.2021 um 13:05 Uhr)

  5. #5
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.619
    Blog-Einträge
    29
    Reicht denn die Rechenleistung für sinnvolle Nutzung aus?

  6. #6
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    07.04.2015
    Beiträge
    782
    Das ist nicht ganz einfach zu beantworten. Ich versuche es mal:
    Die simulierte Umgebung hat eine Grundfläche von ca. 3000*2000 Einheiten (ob Inch, cm oder mm ist nicht festgelegt). Die Auflösung der Karte wird durch SLAM_RASTER (hier 25) bestimmt. Ein Feld auf der Karte ist also 25x25 Einheiten groß.

    Wäre die simulierte Umgebung z.B. eine reale Wohnung mit der Grundfläche 12x8m, würde sich als Einheit 4mm ergeben. Damit hättest Du eine Feldauflösung von 10x10cm. Wenn Dir diese Auflösung zum Navigieren reicht, kannst Du mit einer Bearbeitungszeit von 500ms/Scan bei 120 Messungen/Scan für den SLAM rechnen.

    Pragmatischer Ansatz, wenn Du noch keinen ESP32 zum Testen hast - ich stelle es gerade für Dich um und lasse es laufen:

    Bei SLAM_RASTER = 12,5 (bezogen auf obiges Beispiel also 5x5cm für ein Feld auf der Karte) zeigt mir meine Messung Durchlaufzeiten von bis zu 850ms.

    Bei SLAM_RASTER = 50 (bezogen auf obiges Beispiel also 20x20cm für ein Feld auf der Karte) zeigt mir meine Messung Durchlaufzeiten von etwa 420ms.

    (Man merkt schon: Die Anzahl der Fließkommaoperationen sinkt durch die Änderung der Auflösung nicht. Die ergibt sich aus "Anzahl Variationen * Messungen pro Scan". Was sich proportional zur Auflösung ändert, ist die Anzahl der Ganzzahloperationen (der Bresenham-Line Algorithmus), die gehen aber auch bei 240MHz recht fix.)

    Also grob geschätzt: Typische Wohnung = 500ms Zykluszeit für den SLAM - es fehlen noch Pathfinder, Pathfollower und die intellektuelle Aufgabe, die Karte in Bahnen für einen Staubsauger zu unterteilen oder zeitgesteuert Überwaschungsrouten abzufahren. Das wären sinnvolle Anwendungen, bei denen der Aktualisierungszyklus irgendwo im Sekundenbereich liegen muss

    Nicht sinnvoll wäre es, eine Katze damit spielen zu lassen.

  7. #7
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.619
    Blog-Einträge
    29
    Bresenham ist bei mir Ewigkeiten her, habe ich ganz kurz in den 90gern mal was mit gemacht. Nur zur Verwendung mit Grafikkarte. Habe das dann nie wieder benötigt.

    500ms scheint mir schon recht viel. Die 1s pro Zyklus, sind auch nur relativ zur Geschwindigkeit zu sehen oder nicht? Wie dem auch sei, habe ich nur eine begrenzte Vorstellung von dem, was da so im Programm passieren muss, weil ich mich noch nie damit beschäftigt habe. Frage ist, ob ein Roboter bei normaler Geschwindigkeit mit der Rechenleistung auskäme. Oder ob das wirklich nur Sinn macht, wenn der dann entsprechend langsam fährt.

    Trotzdem, erstmal schöne Sache!

    Gruß
    Moppi

  8. #8
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    07.04.2015
    Beiträge
    782
    Zitat Zitat von Moppi Beitrag anzeigen
    500ms scheint mir schon recht viel. Die 1s pro Zyklus, sind auch nur relativ zur Geschwindigkeit zu sehen oder nicht?
    Ich hatte in der Simulation die Robotergeschwindigkeit auf 1Einheit/ Beam (ein Beam=eine Abstandsmessung des Lidars) gesetzt. Mit 120 Beams/Scan sind das also 120 Einheiten, die das Teil sich max. pro Scan fortbewegt. Auf obiges Beispiel mit der Wohnung bezogen (4mm/Einheit) wären das bei Fullspeed (der Roboter rennt wirklich geradeaus) knapp 50cm/Scan.

    Auch zeigt mir der "Scan integration report" nach Durchlauf der Simulationsdatei 235 ermittelte Scans an. Bei 1s/Scan hätten die beiden Rundläufe durch die Wohnung etwa 4min gedauert.

    Sag Du mir, ob das langsam ist?


    Nachtrag:
    Ich habe mir gerade einmal eine Wegmessung eingebaut...
    In Slam.h:
    Code:
    class Slam
      {
      public:
        float Way=0;
    ...und am Ende der Funktion Slam::IntegrateScan() unter dem Kommentar "// Report to client" die Sache etwas aufgebohrt.
    Code:
      // Report to client
      Scans++; 
      Way+=max.Distance();
      unsigned long end = millis();
      
      snprintf(Report, sizeof(Report),"{\"MsgID\":3, \"Text\":\"Nr %d, %d Beams | Pose X:%.1f, Y:%.1f, O:%.2f, Way:%.2f, Weight:%.2f| Time:%d ms, Idle:%d ms, Heap: %d bytes\"}\0", Scans, scanLen, PsObj->X, PsObj->Y, PsObj->Orientation, Way, maxWeight, end-start, start-lastEnd, ESP.getFreeHeap());
      lastEnd= end;
      PoseUpdated = true;
      ReportUpdated = true;
    Ergebnis der Sache: Am Ende der Simulation ist der Way-Zähler auf etwa 24000 hochgelaufen. Das entspräche dann etwa 100m Netto-Fahrstrecke.
    Geändert von Holomino (17.12.2021 um 17:51 Uhr)

  9. #9
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    18.03.2018
    Beiträge
    2.619
    Blog-Einträge
    29
    Ich kenne das Konzept nicht, auch keinen Ablaufplan. Daher weiß ich nicht, wie schnell was ist, bzw. ob es ausreichend schnell ist. Ausreichend schnell, für Dein Konzept. Das interessierte mich, deswegen fragte ich.

    Bei Bewegungsabläufen, bei denen auch Reaktionen auf Ereignisse stattfinden, spielen Latenzen immer eine nicht unerhebliche Rolle, auf Systemen, die eine überschaubar geringe Leistung haben. Für drinnen ist meine Schätzung maximal 50cm pro Sekunde. Steuert die Umgebungsauswertung direkt die Fahrt, bedeutet das, dass in einer halben Sekunde 25cm zurückgelegt sind, in denen womöglich nichts passiert. Wenn die Fahrt aber generell anders gesteuert wird, mit anderen Sensoren, und die Umgebungserfassung nur zur groben Richtungsbestimmung dient (im Grunde so, wie bei Autofahren durch einen Menschen, der nebenbei ein Navi benutzt), spielt da eine Verzögerung im Sekundenbereich keine große Rolle. Zur Not hält so ein Roboter dann an und wartet, bis ein Ergebnis vorliegt, das er zum Weiterfahren benötigt. Wenn die Umgebungserkennung und Kartierung eingesetzt wird, um überhaupt nur einen Grundriss zu erstellen, mit Hindernissen, und ein Reinungsroboter (bspw.) würde dann aber nur aufgrund der fertigen Karte im Speicher fahren (ohne auf Echtzeitscans angewiesen zu sein), ist das auch wieder eine andere Sache.

    Du hast so eine Kartierung ja schon ein paar mal gemacht / umgesetzt. Ich dachte, wegen dem Thementitel, dass auch eine Einschätzung am Ende steht, wie man so einen SLAM-Algorythmus auf -- jetzt -- einem ESP sinnvoll einsetzt. Was geht, was nicht, in Bezug auf Steuerungskonzepte (oder auch nur Dein Steuerungskonzept).

    Lieben Gruß
    Moppi

  10. #10
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    07.04.2015
    Beiträge
    782
    Zitat Zitat von Moppi Beitrag anzeigen
    Du hast so eine Kartierung ja schon ein paar mal gemacht / umgesetzt. Ich dachte, wegen dem Thementitel, dass auch eine Einschätzung am Ende steht, wie man so einen SLAM-Algorythmus auf -- jetzt -- einem ESP sinnvoll einsetzt. Was geht, was nicht, in Bezug auf Steuerungskonzepte (oder auch nur Dein Steuerungskonzept).
    Mal ganz allgemein: SLAM ist auch nur eine Teillösung. Ohne Pathfinder und Pathfollower ist es ein Gimmik (schön anzusehen). Diesbezüglich bin ich auch nicht "am Ende" angelangt. Ich muss es allerdings auch erst noch schreiben. Bislang ist es nur eine Preview.
    Nach 25 Jahren C++-Abstinenz und ohne wesentliche Vorkenntnisse über den ESP32, RTOS, Arduino, WebServer oder HTML finde ich allerdings schon, dass es vorangeht (aufgrund des Verbreitungsgrades kann man sich viele Dinge aus dem Netz ziehen).

    Bezüglich "Steuerungskonzept": Ich gehe jetzt nicht davon aus, dass die laufende Umrechnung von Radencoderwerten in eine Pose oder das Anschließen oder verdrahten von Motortreibern zum jetzigen Zeitpunkt projektrelevant sind. Dazu verwende ich eben die Simulation.
    Den einen Teil der Hardwareschnittstelle (das Lidartelegramm) habe ich bereits vorgestellt.
    Der Pathfinder hat keine Schnittstelle zur Hardware (nur zur UI) und der Pathfollower wird auch nur zyklisch eine aus der subjektiven Pose abgeleitete Koordinate ausgeben, die der Roboter über eine primitive Regelung ansteuern kann (maximal kann man während der Fahrt durch weitere Hindernissensoren den Pathfollower unterbrechen und am Pathfinder eine Neuberechnung antriggern).

    Kurz: Die beiden Telegramme kann ich über die serielle Schnittstelle lösen, die Gegenstelle (Simulation) ist eh da, dann kann ich mich auf's Wesentliche konzentrieren.


    Zitat Zitat von Moppi Beitrag anzeigen
    Was geht, was nicht.
    Es werden einige komplexere Probleme (closed loop, kidnapped robot) wahrscheinlich nicht gehen. Allerdings weiß ich auch nicht, ob die bei z.B. Staubsaugerrobotern gelöst werden, oder ob diese Geräte nicht gerade deshalb die "Verbindung nach Hause" suchen, damit die Softies beim Hersteller die Sache heilen.

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. SLAM für autonomen Roboter nötig?
    Von Moppi im Forum Software, Algorithmen und KI
    Antworten: 45
    Letzter Beitrag: 26.06.2020, 14:40
  2. Flaschenhals im Slam?
    Von Holomino im Forum Software, Algorithmen und KI
    Antworten: 6
    Letzter Beitrag: 01.06.2015, 17:31
  3. Roboter mit Neato Lidar und SLAM
    Von teamohnename im Forum Vorstellungen+Bilder von fertigen Projekten/Bots
    Antworten: 4
    Letzter Beitrag: 20.04.2015, 13:41
  4. 360° Laser-Scanner für 360€, SLAM
    Von Günter49 im Forum Sensoren / Sensorik
    Antworten: 12
    Letzter Beitrag: 16.11.2014, 19:19
  5. Angebot eines SLAM Kurses
    Von Magox im Forum Offtopic und Community Tratsch
    Antworten: 2
    Letzter Beitrag: 26.09.2014, 18:18

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •