Ja ist es, für eine kleine Wohnung reicht ein Raspberry Pi 3 (oder vergleichbar) gerade eben. Besser ist in jedem Fall schon ein Intel Core i5/7. Wobei man hier auch Einstellen kann. Eine Auflösung von 10cm/Feld benötigt natürlich weniger CPU-Zeit als 2.5cm/Feld.Zitat von Moppi
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.
Geändert von HaWe (26.06.2020 um 16:11 Uhr)
Ich habe mal letztens versucht, herauszubekommen, was denn nun in so einem käuflichen Lidar-Roomba an Prozessor/Speicher verbaut ist. Nach einer Stunde suchen war ich allerdings genauso klug wie vorher.
Kann hier vielleicht mal jemand sein Schätzchen aufschrauben?
Nachtrag. Hab doch noch was gefunden.
https://kaeni.de/hack-des-xiaomi-mi-...nte-einblicke/
Die Daten sehen einem Raspberry schon ziemlich ähnlich.
Wobei die Hardware wohl eher als abgestripptes Laufzeitsystem zu verstehen ist. Die Navigation wird wohl nicht auf dem Roboter selbst entwickelt worden sein.
Geändert von Holomino (24.06.2020 um 12:03 Uhr)
Interessant, und eine ganz schön mächtige Soft- und Hardware-Architektur!
- - - Aktualisiert - - -ARM Quadcore Prozessor mit 1,5 GHZ pro Kern, 512 MB RAM, 4 GB eMMC-Flash, ARM Cortex M3 STM32 MCU zur Steuerung der Sensoren). Der Roboter kommuniziert per Cloud-Protokoll ausschließlich über das Internet mit der Mi-Home Anwendung, nicht über das lokale Netzwerk.
doch, klar, ich bin immer über den Mittelpunkt eines jeden Rasterfeldes gefahren (berechnet und gemessen), mit IR Sensoren nach allen Seiten, um die Begrenzungen und zufällige, temporäre Hindernissen zu erfassen. Pathfinding über AStern und Bug2-Algorithmen. Außerdem war mein Robot knapp 40x40cm groß, und die Quadrate zB. 50x50. War aber bei mir kein Staubsauger-Robot.
PS, und ich behaupte ja nicht, dass es nie Probleme gibt, aber ohne Karte klappt es Null.
Geändert von HaWe (24.06.2020 um 13:32 Uhr) Grund: typo
Mal schnell gezeichnet:
Schwarz das Raster. Blau die tatsächliche Passage.
Was genau hast Du da im Fall b) gemacht?
im Fall b) hat der Roboter nicht versucht, zwischendrin durchzufahren, sondern außenrum.
Aber ich musste auch nur einen Pfad von A nach B finden, und nicht alle möglichen Felder befahren zum Saubermachen, denn es war ein Liefer-Robot, der von Start aus einen möglichst kurzen Pfad zum Ziel finden musste, kein Staubsauger-Robot.
Beim Staubsauger-Robot wird es sicher noch weit komplizierter, s.z.B. dein pdf - aber dann geht es bei Stellen, die nur per Umwege erreichbar sind (wie im Labyrinth) erst Recht nicht ohne (höher auflösende) Karte, damit nichts "vergessen" wird.
Ich glaube eher, dass der Roboter sich zwar zur globalen Orientierung eine ausreichend auflösende Map speichert, aber zumindest die Feinheiten (Kanten, Taschen) mit einer einfachen Rechtsfahrregel (Abstandsregelung ohne das Raster) abfährt. Der Sauger muss ja auch z.B. um Stuhlbeine herum. Solche Dinge im cm-Raster in die Map einzuzeichnen, würde spätestens beim Pathfinding eine immense Rechenleistung erfordern.
meint ihr nicht ein microcontroller wie tennsy 4.1 kann die daten nicht verarbeiten vom slam?
das leben ist hart, aber wir müssen da durch.
Doch sicher - irgendwie. Cruise Missiles flogen letztes Jahrtausend schon autark mit 'nem 300MHz-System.
Allerdings frage ich mich, warum so eng auslegen, wenn ich fürs halbe Geld einen nominal doppelt so leistungsfähigen Rechner bekomme (z.B. BPI M2 Zero).
ein microcontroller hat mehrere vorteile gegenüber eine rechner
stromverbrauch, echtzeitfähigkeit, ...
es gibt allerdings auch nachteile.
teensy 4.1 ist schon ein ziemliches schlachtschiff.
das leben ist hart, aber wir müssen da durch.
Berechtigungen
Zitieren
Lesezeichen