SLAM für autonomen Roboter nötig?

[Moppi]

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

[HaWe]

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.

[Moppi]

um wirklich alle Stellen anzufahren und keine auszulassen - oder tatsächlich ganz bestimmte Bereiche auszusparen

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.
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

[HaWe]

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.

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.

Witzig, ich finde es offensichtlich, dass man eine Karte benötigt.

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.

[Moppi]

hast du schon mal etwas wie einen Saugroboter gebaut und mit einem Algorithmus programmiert, der wirklich keine Dreck-Ecken irgendwo stehen lassen darf?

Also es geht ja darum, dass ich gerade was baue, wo ich noch nach Entscheidungshilfen suche, welche Lösungen ich erwäge.
Deshalb ist die Frage nicht nachzuvollziehen.

Da ich aber mit einem normalen Staubsauger auch nicht 100% jede Ecke erreiche und auch Stücken frei bleiben, die ich mal nicht erwische, erübrigt sich für mich die Frage, ob ein Roboter das können muss. Geht allein schon deshalb nicht, weil es auf die Konstruktion ankommt. Kein Roboter kommt in unserer Wohnung an jede Ecke dran.

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.

Nein, es ist eben nicht absolut offensichtlich. Offensichtlich ist es aber eine Lösung für ein Problem.



MfG

[HaWe]

selbstverständlich geht es nur um Stellen, wo er grundsätzlich hinkommen kann, auch wenn sie möglicherweise etwas versteckt sind, du Scherzkeks
durch zufälliges Herumfahren wirst du NIE alle zugänglichen Stellen abdecken, und auch nicht durch paralleles Abfahren von versetzten Geraden (Boustrophedon Pfad)!

[Defiant]

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.

[Moppi]

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

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.

Ich hoffe die Stichpunkte haben weitergeholfen.

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.


@oberallgeier
Danke für das Beispiel ohne SLAM! Eben so was reicht doch bei den meisten Saugrobotern aus, würde ich meinen.

MfG

[Defiant]

Ich kann mir aber vorstellen, dass so ein Verfahren zumindest rechenintensiv ist.

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.

[HaWe]

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.