Indoor Navigation- wie macht Ihr das?

[lumi]

Warum so kompliziert. Eine Bake kannst du für weniger als 3 Euro bauen. In jeden Raum eine Bake mit einer ID und der Roboter bekommt einen, zwei oder drei TSOP1838B.
Dann sucht der Roboter eben nach der Bake mit der ID, welche er ansteuern soll. Den Weg zurück findet er ja anhand der ID's der vorhergehenden Baken, sozusagen, "gehe immer wieder zurück zur Ladestation bei Bake 0, wenn du deine Aufgabe bei Bake x erfüllt hast"

Bild im Anhang, wie das Ganze aussehen könnte. Kein PC nötig, keine komplizierten Berechnungen, keine Karte, nur nach dem Infrarotsignal suchen.
Ich selbst habe noch keine solche Ausfstellung gebaut, wir haben aber das System an unseren Swarmrobotern im Einsatz, die sich gegenseitig folgen (die höhere ID führt und die niedrigeren folgen).

[JoeM1978]

kompliziert desshalb weil Infrarot nicht durch Wände dringt und der Roboter kaum selbst erkennt wo er durch welche Tür muss.

Also muss man ihn entweder
1. selbst eine Karte erstellen lassen oder
2. eine Karte der befahrbaren Wege vorgeben, oder
3. er sucht sich seinen Weg durch die Wohnung per Zufallsprinzip

Stell ich mir lustig vor, wenn der Roboterschwarm 1m vor der Ziel-Bake wieder umdreht
weil ein Stuhlbein im weg ist und die ganze Mannschaft wieder (umsonst) 5 Runden durch die Wohnung marschiert.

[lumi]

Ja klar hat IR einige Einschränkungen. Aber wenn man es richtig angeht, dann hat es auch Vorteile, die nicht wegzuwischen sind.

Ich möchte dich nicht "überreden" sondern nur alle Fakten klar machen. Die Navigation kann ja so ausfallen, dass man mit 2 Empfängeren am Roboter misst, ob sich eine Bake im Rücken und eine vor dem Roboter befindet. Dann navigiert man anhand der ID in die richtige Richtung. Ein Stuhlbein kann durchaus im Weg sein, aber nach dem Umfahren des Hindernisses findet der Roboter die Bake recht schnell wieder (max. eine 360°-Umdrehung)

Eine gewisse Routine (Karte) kann man ja fest einprogrammieren, sozusagen Bake 0 im Rücken und Bake 1 in Front bedeuted, dass ich Raum 0 verlasse. Danach wird nach Bake 2 gesucht und das Spiel geht von vorn los.
Es kommt ja darauf an, wie genau die Navigation sein muss, direkt auf die Bake zuzufahren, dort anzukommen und was dann? Auf jeden Fall muss an der Position einer jeden Bake der Roboter die nächste oder die vorherige Bake sehen können, um Entscheidungen über die Richtung treffen zu können.

[JoeM1978]

Mit Baken ist es eben das Problem, das der Rob entweder sichtkontakt haben muss... also den direkten Weg fährt (+- kleine Hindernisse)...
oder wenn er keinen Sichtkontakt hat, muss er sich dann trotzdem Autonom über die vorhandene Sensorik seinen weg suchen.

Habe ich also den Roboter sowieso mit den Sensoren ausgestattet kann ich die doch genausogut zum erstellen einer Karte nutzen.
Die Frage ist dann eben... möchte ich die Karte an einen Computer übermittel (onboard oder per Funk)...
oder behalt ich die Karte "nur" in einem Speicher im Roboter.

Die ermittelten Sensordaten nur fürs stupide Hinderniss erkennen zu verwenden und danach zu verwerfen wäre
an sich Verschwendung und hat meiner Ansicht nach kaum was mit Navigation zu tun.

Hab ich die möglichkeit dem Rob. vorgegebene Fahrwege einzugeben (Grundrissskizze z.B.) ist eine Lösung mit Baken sicher das einfachste.
... es ist eben sehr von den bedingungen abhängig, wie die Räumlichkeiten sind.
Ob es immer die selbe Wohnung ist z.b. ... oder ob ich ihn "irgendwo an einem unbekannten Ort" aussetze.

[lumi]

Ja, das ist eine Möglichkeit und wie schon geschrieben, ich will dir ja nix einreden
Warum speicherst du die Daten der Umgebung nicht auf einer SD-Karte, wenn du um den EEprom besorgt bist?
Meine Sorge ist nur, dass alles zunichte gemacht wqird, falls die Räder mal durchdrehen und dadurch die Encoder-Daten unbrauchbar werden. Vielleicht kann man für jeden Raum ein bestimmtes MUster einprogrammieren, das als Referenz genommen werden kann.

[Valen]

Es braucht vielleicht eine menge Wissenschaft von Matrixrechnen. Aber SLAM sollte das Problem von Fahren in einer unsichere Umgebung lösen können: (Simultan Lokalisieren und Mappen)

http://de.wikipedia.org/wiki/Simulta...on_and_Mapping

[Robotniks]

Hallo zusammen,

jetzt mische ich mich auch wieder ein
Also die IR-Baken Lösung ist relativ praktikabel und funktioniert auch recht schön... man sollte sich aber im Klaren sein, dass dazu der Roboter erst mehrer zufällige Positionen anfahren muss bis er die Bake sieht.
Die Roomba Staubsauger machen das recht effektiv und sicher. Ich habe dieses System nachprogrammiert und als Baken die günstigen Saugroboter Baken von Pearls Versand verwendet (nur die Mechanik und Optik).
Bei heutigen Robotern ist es auch kein Problem einen PC, Netbook oder ein Notebook zu verwenden, da man mit einen Rechner sehr viele Probleme (z.B. Sprach Ein-/ Ausgabe, Computer Vision, WLAN usw.) wesentlich kostengünstiger und Flexibler lösen kann. Meine Versuche in den letzten Jahren haben jedoch gezeigt, dass Rad-Odometrie und die Baken-Navigation nicht unbedingt das gelbe vom Ei sind. Deshalb habe ich diese Variante bereits über Board geworfen. SLAM an sich funktioniert sehr gut, vorausgesetzt gute Sensoren bzw. einen Laserscanner siehe (ROS), mittels Sensorfusion kommt man hier auf sehr gute Werte. Auch das North-Star System oder Stargazer funktionieren sehr gut, aber unbezahlbar (Außer im Rovio) Momentan stütze ich mich auf Visuelle Landmarken (Glyphen) und Optical Flow (Optische Odometrie) nach Dr. Messner. Das ganze wird jetzt noch mit einer Szenenerkennung über SURF verstrickt. Das Modul programmiere ich gerade für eine Robotersoftware von der ich hoffe, dass Ihr noch mehr davon hört Ziel ist es mit einen Netbook (min. Atom CPU erste Generation) und einer Webcam und ein paar weniger Referenzmarken eine brauchbare Indoor-Navigation zu realisieren. Mit der Software selber kann so ziemlich jedes Hobby-Robotic Projekt in wenigen Stunden quasi Intelligent gemacht werden *lach*. Ich verwundert es nur, dass es in Richtung kostengünstige Navigation nichts auf den Markt gibt was universell eingesetzt werden kann.

Die Software selber geht mehr in die Richtung:

http://www.youtube.com/watch?v=iZ6936-ppCA

Aber nicht so kompliziert wie ROS, sonder man kann das ganze aus einzelnen Graphischen Modulen zusammenbauen und die Automatisierung mittels der Scriptsprache realisieren.

PS: Suche noch jemanden der in Sachen Website, Shopsystem auf aktuellen Stand ist und mir später hier ein wenig Arbeit abnehmen kann.
-> Auch werden später noch Tester gesucht...

Okay jetzt bin ich etwas abgeschweift und dazu auch demnächst mehr in einen anderen Thread...


Grüße Ulli

[HaWe]

Odometrie alleine ist nach spätestens 30 min. fahren immer ungenau - oft schon nach 30 sec.
Wenn du andererseits im unbekannten Terrain herumfährst, kannst du überhaupt nicht exakt navigieren, denn du hast ja keine Ortsreferenzdaten: da kannst du höchstens möglichst genau "koppeln" (also Ortbestimmung relativ zum Startpunkt - englisch: "dead reckonning").
Professionelle Systeme machen das indoors mit Sensorfusion (Odometrie, Gyro, Accelerometer) und stochstischen Filtern, insb. Kalmanfiltern (z.B. Staubsaugerroboter).

Ohne externe Referenzen mit Peilungen bekommst du aber nie eine wirklich genaue Ortsbestimmung.
Das brauchen aber keine Baken zu sein, es gehen theoretisch auch eine Vielzahl von Transpondern, die du überall verteilst, oder eine Vielzahl von (Ultraschall-, IR-) Entfernungsdaten in alle möglichen Richtungen.
In diesem Falle brauchst du aber zur Ortsberechnung ebenfalls stochastische Filter, am ehesten funktionieren hier SMC (sequentielle Monte Carlo Methoden, auch "Partikelfilter" genannt): die funktionieren perfekt, wenn die Referenzwerte stark verrauscht sind, aber man stattdessen ein vielzahl dieser Referenzen hat. Auch Odometriedaten und Gyro-Werte kann man in den SMC mit einkalkulieren.

Beide stochastischen Filter (Kalman und SMC) brauchen aber als Basis sehr große vorweg bekannte Datenmengen (z.B. Standardabweichung der Messgenauigkeiten sämtlicher Sensoren und/oder eine bekannte Karte des betr. Raums) und sehr viel Mathematik zur Auswertung. Ein ARM-Prozessor (wie der Arduino Due oder der Lego NXT) samt preemptivem Multitasking für Navigation in Echtzeit sind sicher Vorraussetzung. Vorgegebene oder ermittelte Karten lassen sich am bestem auf dem Flash speichern, quasi wie ein Schachbrettmuster.

Guckst du z.B. hier:

[Robotniks]

Hi,

Kalman und SMC sieht schon sehr vielversprechend aus aber die Randbedingungen sind so eine Sache.

Habe hier auch einen guten Kurs für SLAM gefunden:
https://drive.google.com/folderview?...zg&usp=sharing

Nicht ohne muss ich sagen... puh...

Eine feine Lösung ist auch der AVM-Navigator:
http://edv-detail.narod.ru/AVM_main.html

Ältere Test mit eine umgebauten Omnibot bei mir
http://www.youtube.com/watch?v=iAE7NXQgwC0

Derzeit läuft bei mir die Odometrie mit Marker-Abgleich (kommt die nächsten Wochen wieder ein Video auf FB).
Das ganze Navi-Modul wird langsam etwas komplex... Kartenerstellung kommt noch rein und einen A* habe ich schon vor ein paar Jahren mal programmiert und
Hindernisse einzeichnen lassen die gewichtet wurden... dieser läuft zwar noch nicht super aber ganz gut.

Mein Plan ist derzeit:
Odometrie + 9DOF IMU + Binary Marker Erkennng zum Abgleich (alternativ an der Ladestation eine Stereo IR-Bake, mit der der Roboter über die Winkel und den festen Abstand seine Position abgleichen kann).

Einfach und vor allem unterschiedliche Konfigurationen für den User möglich (von low Cost bis hochwertige Sensoren).
Statt der IMU kann auch ein Kompass das theta der Odometrie verbessen, bei mehreren Sensoren dann Sensorfusion (wird eine Herausforderung).

Robotic-Workbench ist ja modular aufgebaut und ich kann Sensore, Module und Befehle beliebig erweitern und den User stehen dann di High-Level Befehle und Graphischen-Module zum einfachen konfigurieren zur Verfügung.

Ich werde die nächsten Wochen mal die Homepage fertig machen und auch die grobe Anleitung online stellen und ein paar Videos dazu machen, derzeit sagen ja die paar Bilder in CV Video nicht soviel aus.

Grüße