Hallo,
ich bin nochmal auf das Thema SLAM aufmerksam geworden. Jetzt habe ich gestern einen älteren Thread von Holomino gelesen, wo er auch eine Karte erstellt.
Nun stelle ich mir grundsätzlich die Frage, inwiefern man SLAM überhaupt zur Navigation eines Roboters benötigt.
SLAM beinhaltet immer das Erstellen einer Karte. Das kann sinnvoll sein, wenn ich als Mensch eine Karte von einer Umgebung benötige.
Bezugnehmend auf diese Karte kann ich dann dem Roboter Anweisungen geben, wo er hin fahren soll.
Zur Navigation von einem Startpunkt, zu einem Zielpunkt scheint es mir unnötig, eine Karte zu erstellen. Wenn ich an eine Navigation draussen denke,
wo dann GPS möglich ist, wird man kaum SLAM benutzen. Oder sehe ich das falsch?
Bei den Saugrobotern werden heute teils auch Karten der Wohnung erstellt, die dann irgendwo ins Netz auf einen Server geladen werden, beim Hersteller des Roboters
vermutlich, ich hatte so was beiläufig von Vorwerk gelesen, dass Roboter nicht mehr funktionieren, wenn es Serverprobleme gibt. Wozu wird dort eine Karte der Wohnung erstellt,
wen interessiert der Grundriss der Wohnung? Sicher nicht den, der darin wohnt.
MfG
also für Saugroboter etc. ist es doch klar: um wirklich alle Stellen anzufahren und keine auszulassen - oder tatsächlich ganz bestimmte Bereiche auszusparen, wenn der Robi da grundsätzlich nicht hin- oder durchfahren fahren soll aus irgendwelchen Gründen.
Witzig, ich finde es offensichtlich, dass man eine Karte benötigt. Als Mensch hast du ja auch eine Karte im Kopf wenn du von A nach B fährst. Und die Karte sagt dir, dass du von Hamburg nach Köln nicht über Berlin fährst. Genau das selbe für Roboter:
Wenn es die Aufgabe ist einen effizienten Weg von der Küche zum Wohnzimmer zu finden brauche ich doch eine Karte. Die Alternative solange rumzufahren bis ich zufällig im Wohnzimmer gelandet bin halte ich nicht für praktikabel.
Ja, draußen verwendest du GPS, aber das funktioniert ja nicht innerhalb deiner Wohnung, da 1. Man da kein GPS empfängt und 2. die Genauigkeit nicht hoch genug ist. Deswegen verwendet man drinnen gerne SLAM. Umgekehrt würde man im Auto eher nicht zu SLAM tendieren weil viel zu aufwendig.
Zum Thema Staubsaugerroboter:
1. Eine Odometrie ist immer mit Schlupf behaftet, aber du möchtest gleichzeitig feststellen, dass du jedes Feld einer Karte effizient angefahren hast.
2. Staubsaugerroboter mit Laserscanner fahren ja den sog. boustrophedon path ab. Also wie man als Bauer sein Feld pflügen würde. Es wäre allerdings deutlich schwieriger diesen Weg effizient zu planen wenn man keine Ahnung hat, wie sein Feld aussieht.
Kompletter Unsinn ist allerdings die Karte auf einen zentralen Server hochzuladen. Das ist vielleicht als Feature ganz nett, wenn man von der Arbeit mit dem Smartphone einen Bereich auf der Karte zeichnen kann wo der Roboter jetzt gefälligst zu saugen hat, das ging allerdings technisch auch ohne Herstellercloud...
Ich hoffe die Stichpunkte haben weitergeholfen.
Geändert von Defiant (24.06.2020 um 09:34 Uhr)
Dass man Bereiche sperrt, indem man Markierungen setzt, in Form von Baken oder so, ist wohl nicht mehr aktuell? Wenn ich Bereiche über die Karte markiere, die er nicht anfahren soll, dann ist die Karte wieder für den Menschen gemacht, damit der sich orientieren kann. Stellt also eine Kommunikationsvereinfachung dar.Zitat von HaWe
Mal anders gedacht: wenn ich davon ausgehe, dass anhand aller Sensoren ein fast beliebiger Punkt eindeutig wiedererkennbar ist - also zumindest Punkte, die weiter auseinanderliegen - und ich navigiere von A nach B. Angenommen, Punkt K ist Küche, Punkt T ist Toilette, Punkt W ist Wohnzimmer. Dann kann der Roboter die Punkte ansteuern (ich setze voraus, dass der den Weg erlernt hat, ohne Karte), ich kann aber auch bestimmte Punkte weglassen, dann steuert der die nicht an, um also so Bereiche in der Wohnung auszuschließen.
Was bezweckt man im Gegensatz mit SLAM - Bereiche Zentimetergenau abzufahren? Das würde dann einen gewissen Sinn ergeben, dass ich z.B. ein 50cm Quadrat in einem Raum besonders behandeln kann. Im Übrigen geht es doch auch immer darum, dass der Roboter Stellen/Hindernisse, die er nicht bearbeiten kann (um beim Saugroboter zu bleiben), autonom umfahren muss, schon deswegen, weil mit reichlich ortsveränderlichen Hindernisse zu rechnen ist.
MfG
Das kann man/ich so nicht stehen lassen. Meine Wohnung hat acht Räume (ohne Vorrats- und Besenkammer, ohne Kellerräume, Garage und Treppenhaus) und eine Süd- und eine Westterrasse. Wenn man da irgendwo ist und auf die Toilette muss könnte es praktisch sein, wenn man den Grundriss im Kopf hat und nicht zufällig durch die Wohnung stapft um den zugehörigen Raum zu finden.
Der Roboter mit ordentlichen Raumkenntnissen kann - wenn er es kann - sich einen regelmässigen Säuberungsplan zurecht legen und den abarbeiten. Die "Standardroboter" können das nicht. Daher müssen die eben mehrfach - auf mehr oder weniger zufälligen Routen, je nach Sensorausrüstung - hin und her fahren und manchen Fleck auch doppelt oder mehr- bzw. vielfach saugen. Die Gesamtheit dieser Zufälle bringt dann statistisch ein vollständiges Gesamtergebnis. Den Vergleich mit dem Toilettengang ohne Lageplan will ich jetzt nicht ausweiten.
Bei meinem WALL R habe ich auch keinen wirklichen Plan der Umgebung. Da hilft eine der möglichen Richtlinien für Blinde (oder Leute mit mehr als ein Promille): immer an der Wand lang. Seine Fahranweisung lautet etwa: Gib Gummi bei mehr als 1,5 m Freiraum nach vorne mit LEICHTER Rechtskurve, bei weniger Freiraum nach vorne proportional zum Freiraum abnehmende Geschwindigkeit UND mit abnehmendem Freiraum zunehmenden Lenkeinschlag links. Und so fährt WALL R dann eben nicht total irre (siehe hier) - lässt aber den Raum "in der Mitte" weitgehend unbefahren. Möglich wäre bei WALL R auch ein Anfahren einer Wand bis auf einen vorbestimmten Abstand, dann ne Art Wende um mehr als ein paar Grad bis weniger als 180° - und schon könnte der den ganzen Raum für zufällige Fahrmuster durchkreuzen.
Ciao sagt der JoeamBerg
Kann ich nach vollziehen und ich verstehe den Ansatz.
Ich kann mir aber vorstellen, dass so ein Verfahren zumindest rechenintensiv ist.
Ich habe es noch nicht ausprobiert, deswegen frage ich mal. Um mich an Strategien ran zu tasten, was dann auf mich zu kommt, wenn das Chassis zuverlässig fährt (sieht im Moment gut aus). Muss ja irgendwie eine gewisse Vorplanung machen.
Hilft im Moment alles weiter, weil ich mich praxisorientiert das erste Mal jetzt mit dem Thema auseinander setze. Theoretisch ist vieles manchmal recht einfach, praktisch tauchen dann aber u.U. Probleme auf, die nebenbei auch noch zu bewältigen sind.Ich hoffe die Stichpunkte haben weitergeholfen.
@oberallgeier
Danke für das Beispiel ohne SLAM! Eben so was reicht doch bei den meisten Saugrobotern aus, würde ich meinen.
MfG
Geändert von Moppi (24.06.2020 um 10:13 Uhr)
hast du schon mal etwas wie einen Saugroboter gebaut und mit einem Algorithmus programmiert, der wirklich keine Dreck-Ecken irgendwo stehen lassen darf? Probier's einfach mal, ohne Karte. Auch das permanente Aussparen von Bereichen ist ohne Karte IMO eine frustrane Angelegenheit.Ein Ansatz mit Karte und mit SLAM plus eindeutige Navigation und Positionsbestimmung ist für mich genau wie auch für Defiant absolut unverzichtbar und absolut offensichtlich.
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.
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 17: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 13:03 Uhr)
Berechtigungen
Zitieren
Lesezeichen