ich habe das grundsätzlich auch schon auf einem Arduino Due hingekriegt, wobei die Kartenfelder etwa so groß waren wie der Robot selber (denn er sollte ja auch auf einem Pfad, der 1 Feld breit ist, tatsächlich auch fahren können). Vorteil beim Due: er kann kooperatives Multithreading (Due Scheduler), das ist essentiell. Die aktuelle Position (float) wurde dann auf eine 100x100 Integer Karte projiziert.
Ein SAMD51 wäre noch leistungsfähiger, hier bin ich aber nicht sicher, ob MT Libs auf ihm laufen.
(edit: doch klar: z.B. ein Teensy 3.5/3.6 mit TeensyThread!!)
Einen ESP32 empfehle ich wegen der vielen Inkompatibilitäten und wackeligen Libs grundsätzlich nicht mehr.
Mein RaspberryPi2B hat aber ebenfalls für SLAM reibungslos gearbeitet (mit pthread MT).
Einziges Problem immer: die reproduzierbare Lokalisierung:
Odometrie alleine ist ungeeignet, Gyro hat unkompensiert zuviel Drift, Kompass und GPS aber nur für outdoors wirklich gut geeignet, Sensorfusion mit Kalman- und/oder Montecarlo-Filtern (am besten 2 parallel, je nach Untergrund wegen Schlupf), Baken zum Anpeilen sind an sich state of the art, und hier am besten dm-Wellen wie bei Pozyx (das war mir aber dann doch zu teuer um es selber zu benutzen). Um die ganzen Rechnereien parallel in Zeitscheiben nicht-blockierend und priorisiert durchzuführen, dazu genau wird das MT benötigt.
Zitieren
Lesezeichen