Indoor Navigation- wie macht Ihr das?

**JoeM1978** · 20.02.2013, 17:25

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** · 21.02.2013, 01:16

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** · 21.02.2013, 10:11

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** · 21.02.2013, 15:44

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** · 21.02.2013, 16:44

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** · 23.02.2013, 00:13

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

**vinni.k** · 24.10.2013, 16:52

Hallo Leute,
ich greife das Thema wieder auf, denn ich baue gerade einen Saugroboter und Suche noch nach Navigationsmöglichkeiten.
Der Roboter soll sich strukturiert durch Räume arbeiten und auch ungeplante Hindernisse umfahren.
Als Chip bekommt er einen Arduino Mega 2560 (das Board hab ich schon).
Ich habe mir schon 5 Abstandssensoren besorgt (hc_sr04), vier für vorne, hinten, rechts und links und einen für unten (Stufenerkennung).
Nun meine Fragen:
1. Wie baut man sich so einen "Bake", bzw. was ist das genau?
2. Ist eine genaue Lokalisierung mit mehreren von denen möglich (kann man den Abstand von Roboter zu Bake messen) ?
3. Wie kann man so eine Raumkarte (Grundriss) digital mit einem Mikrocontroller erstellen (bzw. am PC und sie dann einbinden) ?
4. Habe ein Video gesehen http://www.youtube.com/watch?v=IMI63k5W3sU wo jemand einen Lasersensor selber gebaut hat. Kann man sowas besser und ohne Legotechnikteile realisieren?
5. Wie siehts aus Ulli, gibt es Fortschritte bei dem Projekt und ist so was z.B. mit einem Raspberry Pi realisierbar?

Allgemein hatte ich daran gedacht, in mein Projekt einen Raspberry einzubauen, denn der Arduino hat ja schon eine etwas begrenzte Rechenleistung!

Ich hoffe, dass wenigstens ein paar meiner Fragen zu beantworten sind

Viele Grüße,
Vinni

HaWe · 18.10.2014, 14:43

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** · 18.10.2014, 18:29

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