SLAM für autonomen Roboter nötig?

[Moppi]

Irgendwie muss man einen Roboter zielgerichtet steuern. Ich bin noch nicht sicher, welcher Ansatz, der mir einfällt, dabei vielleicht auch nicht zuende gedacht ist. Da mangelt es an Erfahrung. Das Erstellen von Karten ist eine naheliegende Sache, auf die man von selbst auch immer wieder mal kommt. Interessant ist vor allem, wenn schon jemand mit selbst erstellten Karten gearbeitet hat, weil der weiß, ob sich der Aufwand lohnt. Es besteht auch die Möglichkeit, das so jemand sagt: ist alles gut und schön, aber im Grunde kann man das, was ich an Nutzen darin sehe, einfach auch mit anderen Algorithmen lösen, wie dass ein Roboter in der Wohnung zuverlässig von A nach B fährt. An anderer Stelle hatte ich schon beschrieben, wie ich mir so etwas auch vorstellen kann.
Wie geht denn SLAM mit sich ortsveränderlichen Objekten um, wie Haustieren, oder Schuhe, Spielzeug, die in der Wohnung zufällig herumstehen und von einer Minute auf die andere verschwinden und an anderer Stelle auftauchen können? Deshalb ist es doch wichtig, dass ein Roboter solche Objekte erkennen und umfahren kann, auch dass ein Roboter damit rechnen muss, dass die Objekte kurze Zeit später verschwunden sind. Wenn diese Aufgabe gelöst ist und zum Beispiel ein Algorithmus eingesetzt wird, der Räume Bahn um Bahn abfährt (um mal beim Staubsauger zu bleiben) und wenn der Roboter in der Lage ist, einzelne Räume auch ohne richtige Karte zu finden, eben zum Beispiel immer an der Außenwand lang fährt, braucht es dann SLAM, wie in Wikipedia beschrieben? Was ist denn an SLAM offenbar und macht es damit unabdingbar?


MfG


PS: ich finde das mit den Bildern von Holomino eine gute und brauchbare Sache, weil man daraus auch sicher Dinge ablesen kann, wenn man sich selbst näher damit beschäftigt.
In welcher Sprache ein Code verfasst ist, ist für Beschreibungszwecke nicht so wichtig. Solang es ein Code für irgendeine Hochsprache bzw. irgendein "Basic" ist, kann man dann schon sehen, was im Code passiert. So Sachen wie "foreach" kann man nochmal nachschlagen.

[Defiant]

oh je, hier ist ja zuviel passiert gestern...ich muss zugeben ich hab das nicht gelesen und beziehe mich direkt auf den Vorposter:

Ich verwende ja ROS, was auch gerne von den Forschungsstätten verwendet wird und damit nicht grundsätzlich alles falsch macht. Staubsaugerroboter wie der Neato sollen angeblich auch ROS als Unterbau verwenden. Bei ROS gibt es im Navigation-Stack die lokale und die globale Karte. Die globale ist die per SLAM erstellte Karte, die lokale Karte ist was der Roboter aktuell sieht, z.B. ein Feld von 3x3m. Deine ortsveränderliche Objekte sind für die Lokalisierung in der globalen Karte kein Problem, da hier eh nur mit Wahrscheinlichkeiten gearbeitet wird und die Sensorwerte sowieso zu ungenau sind um eine 100% Überlappung zu erreichen. Zum Umfahren dieser Objekte wird die lokale Karte verwendet. Auf der globalen Karte wird erstmal nur der "grobe Weg" mit A* oder ähnlichem errechnet. Anhand dieses Weges wird dann auf der lokalen Karte kontinuierlich mit den aktuellen Sensorwerten und komplizierteren Wegfindungen neu geplant.

[Holomino]

Irgendwie muss man einen Roboter zielgerichtet steuern. Ich bin noch nicht sicher, welcher Ansatz, der mir einfällt, dabei vielleicht auch nicht zuende gedacht ist. Da mangelt es an Erfahrung. Das Erstellen von Karten ist eine naheliegende Sache, auf die man von selbst auch immer wieder mal kommt. Interessant ist vor allem, wenn schon jemand mit selbst erstellten Karten gearbeitet hat, weil der weiß, ob sich der Aufwand lohnt. Es besteht auch die Möglichkeit, das so jemand sagt: ist alles gut und schön, aber im Grunde kann man das, was ich an Nutzen darin sehe, einfach auch mit anderen Algorithmen lösen, wie dass ein Roboter in der Wohnung zuverlässig von A nach B fährt. An anderer Stelle hatte ich schon beschrieben, wie ich mir so etwas auch vorstellen kann.

Ich finde Deine Gedanken überhaupt nicht schlecht. Ich bin selber nicht begeistert von dem zu betreibenden Aufwand.
Für mich ist das eigentlich nur der sopisticated Ersatz der Märklin-Eisenbahn aus Kindertagen, bei dem man sich die Mühe spart, Schienen zu verlegen, der trotzdem auf Knopfdruck oder zeitgesteuert in die Küche fährt, zurückkommt und wieder am Lader andockt.
Und ich hatte auch lange Zeit das offensichtliche Problem, das Spielzeugkits für nen Hunni weit vor meiner Zielsetzung aufhörten und danach praktisch nur noch Akademikerlösungen und Industrieprodukte zu finden sind.

Aber ich hatte Dir an anderer Stelle auch schon einmal vorgeschlagen: Bau Dir eine Simulationsumgebung in der Programmiersprache Deiner Wahl. Die drei Wochen Arbeit lohnen sich! Das hat mir geholfen und es wird mit aller Wahrscheinlichkeit auch Dir helfen.
Ich könnte Dir ja mein C#-Gehuddel einfach übergeben, allerdings muss man sich meiner Ansicht nach sowohl in der Programmiersprache als auch in der Umgebung heimisch fühlen, um konstruktiv weiterarbeiten zu können.

Meine letzten Gedanken bezüglich der "einfacheren" Navigation, also dem Entlanghangeln an Wänden (ggf. mit Überqueren von Türdurchgängen) mit dem Ergebnis einer Linienliste habe ich noch nicht aus den Augen verloren, wobei "einfacher" für mich weniger die Programmierung (einmal gesofteter Quellcode kostet nix) und eher die Sensorik betrifft. Praktisch allerdings habe ich auch nur meinen uralten Linebuilder (bildet Linien aus der Punktwolke eines Rundumscans) herausgekramt, angepasst und verbessert.

Ich verwende ja ROS, was auch gerne von den Forschungsstätten verwendet wird und damit nicht grundsätzlich nicht alles falsch macht.

Der doppelten Negierung Deines Satzes warst Du Dir bewusst?

Aber mal ne Frage dazu: Verwendet ROS auch eine Rasterkarte?

[Defiant]

Der doppelten Negierung Deines Satzes warst Du Dir bewusst?

Danke, hab es geändert.

Aber mal ne Frage dazu: Verwendet ROS auch eine Rasterkarte?

Ja natürlich: http://wiki.ros.org/costmap_2d

[Holomino]

Ja natürlich: http://wiki.ros.org/costmap_2d

Irre, ich finde sogar die Funktion meines "ErodedGrid" wieder, in dem ich statt des Roboters die Hindernisse mit einem Radius eintrage, um dem A* die nicht befahrbaren Punkte nahe an den Hindernissen wegzunehmen.

[Moppi]

Bau Dir eine Simulationsumgebung in der Programmiersprache Deiner Wahl.

Habe ich ja eigentlich auch, meine Wohnung

Praktisch allerdings habe ich auch nur meinen uralten Linebuilder (bildet Linien aus der Punktwolke eines Rundumscans) herausgekramt, angepasst und verbessert.

Ich sehe an Deinen Ausführungen aber, dass Du andere Denkansätze verfolgst.

Wenn das Gerät mal richtig fährt, also dazu gehören jetzt noch Kurvenfahrten und Richtungswechsel, dann besteht die nächste Aufgabe darin, noch mal zu schauen, ob ich mir das Phänomen mit den Schritten wirklich sinnvoll zunutze machen kann. Indem ich über die Odometrie ein Korrekturverhalten hinbekomme, dass auch bei höheren Geschwindigkeiten die Richtung gehalten wird. Sonst müsste ich so was wie einen Kompass einsetzen. Oder, eine andere Idee war jetzt, jeden Motor mit einem Beschleunigungssensor zu versehen, um auch bei jedem Mikroschritt die Beschleunigung zu erfassen, nicht nur die Lichtschranke an der Welle. Sinnvoll könnte ich mir auch vorstellen, Hindernisse in Bodennähe zu erkennen, wie Absätze (Teppichkanten oder Leisten), damit man dort langsam drüber fährt, wegen einem ungewollten Richtungswechsel.

Wenn das dann mal funktioniert, dass das Gerät anständig fährt, würde ich die ersten Experimente mit Ultraschall machen und sehen, welche Ergebnisse ich bekomme. Irgendwie muss so ein Roboter dann ja doch die eigene Position erkennen können, von der er startet. In dem Zusammenhang werde ich auch noch mit RFID-Tags herumprobieren, das soll bis zu einigen Metern funktionieren, weiß nur noch nicht wie und ob das mit Passiven auch über größere Entfernung (1m oder auch 2m) funktioniert. Gibt viel zu tun.



MfG