Macht das Sinn? Das IDENTISCHE Posting wie gerade eben, von deinem Original 1:1-kopiert nach vier Tagen ! Die meisten hier haben einen längeren Gedächtnishorizont :-/
Druckbare Version
Macht das Sinn? Das IDENTISCHE Posting wie gerade eben, von deinem Original 1:1-kopiert nach vier Tagen ! Die meisten hier haben einen längeren Gedächtnishorizont :-/
Mensch oberallgeier,
... ich dachte glatt, hier wäre ein anderer Thread als "mbot stellt sich vor"
Ich hatte "Indoor-Navigation" im Sinn,
in dem Thread hatte ich nämlich in meinem vorletzten Beitrag v4l empfohlen,
.. da wollte ich noch erwähnt haben, dass für schnelle Reaktionen, das komprimierte Format umständlich ist,..
... dachte für diesen Thread ganz allgemein, wäre die volle Nutzung von 1-2 Webcams
auf nem Raspberry unter Raspbian interessant, um diese für Indoor-Navigation zu nutzen.
Naja, ... hab ich wohl mit meinem geringen Gedächtnishorizont falsch verstanden...
Gut das du so aufgepasst hast, sonst hätte ich hier noch weitere Tipps zur Webcam-Nutzung verteilt.
z.B. dass man v4l2-Formate vernachlässigen kann, wenn es nur um Standortbestimmung (Indoor) geht.
... heißt: hierfür kann man auch die komprimierten v4l2 Formate verwenden....
... naja..., immer schön die Augen auf ;- )
Gruß mbot
Hallo zusammen,
gibts schon was neues zur Indoornavigation?
Ich selber hatte momentan nicht soviel Zeit aber wem mein Projekt interessiert kann hier schon paar Schnappschüsse sehen:
https://www.facebook.com/RoboticWorkbench
Hi, das Thema ist ein bisschen eingeschlafen :-)
Jetzt habe ich wieder etwas Zeit um weiter zu machen.
Hat schon jemand von euch mit SLAM ohne ROS gearbeitet?
Derzeit schweben mir verschiedene Varianten zur Navigation vor:
- Optische Odometrie über Kamera (leider extrem von den Lichtverhältnissen abhängig)
- Klassische Odometrie mit Radencodern (geht ganz gut wenn der Boden eben ist)
- Odometrie mit Radencodern, Kompass und Gyros über Sensorfusion)
- Leitlinie über Tape (naja nicht der Brüller aber genau :-) )
- Baken über IR (geht auch sehr gut)
- Optische Baken (Pattern Matsch über CV)
- Outdoor über GPS (Läuft und mit DGPS hoch genau)
Werde wohl in das Navigationsmodul verschieden Optionen einbauen und diese kann man je nach verwendeter Hardware auswählen und konfigurieren.
So kann jeder User auf unterschiedliche Navigations-Methoden zurückgreifen und diese über die interne Sensorfusion verknüpfen (steigert die Genauigkeit).
Frage: Was fällt euch dazu noch ein und welche Methoden gibt außer den Klassischen Zählen der Radimpulse zur Aufnahme der zurückgelegten Wegstrecke (Odometrie nicht Winkelabhängig) rein den relativen Weg.
Grüße RWB'ler :-)
Ich habe mir auch schon Gedanken zur Indoor Navigation gemacht, und finde IR-Baken einerseits gut, da sie günstig sind, andererseits auch nicht, da sie wie schon in einem Beitrag zuvor erwähnt, im Haus/Wohnung "rumligen".
Da ich viel mit Raspberry PI Boards Bastel, stellt sich mir die Frage, ob es nicht möglich wäre, ein Cubietruck oder Banana Pi als Basis zu nutzen, da diese Boards mehr Leistung zur Verfügung stellen, und dann mit einem der genannten Boards und einer Webcam mit Laser eine Karte des Raumes zu erstellen. Ich weiß nicht wieviel Arbeit das in Anspruch nimmt, da ich bis jetzt nur am Versuchen bin, mit einem Raspi , Webcam und einem Laser eine Distanz zu berechnen.
Eine weitere Idee war, das Prinzip eines 3D Scanners zu nutzen, und viele Laser übereinander zu setzen und durch Roatation der "Laserleiste" eine Karte zu modellieren. Die Karte wäre demnach nur sehr grob, würde aber meiner Meinung nach schon reichen. Das Gute an dieser Variante wäre, dass nur einmal eine Karte erstellt werden müsste, diese auf eine SD-Karte beispielsweise geladen werden könnte und dann schon von einem Mircrocontroller oder Raspi etc. verwendet werden könnte.
Das waren nur Ideen, also mich bitte nicht für Verrückt erklären :)
Das mit Laser und Kamera ist so eine Sache, geht bei bestimmten Lichtverhältnissen ganz gut bis zu einer gewissen Entfernung, jedoch recht langsam.
Die Entfernung über den Laser kannst du über Triangulation machen https://wiki.zimt.uni-siegen.de/fert...erte_Fertigung.
Die Karte musst du aber trotzdem updaten und mit der alten Karte vergleichen, da sich ja nicht alle Objekte statisch verhalten (Stühle, Ball ect.) die Objekte kannst Du dann "gewichten" und den Roboter die Karte lernen lassen.
Grüße
Entweder haben hier alle das Problem im Griff oder keiner hat Ideen...
Ich werde mich jetzt mal mit Trägheitsnavigation (inertial navigation) befassen...
Grüße
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:
http://www.youtube.com/watch?v=ZQ5b6OYLlqU
http://www.youtube.com/watch?v=dtyzjoE2FWU
http://www.youtube.com/watch?v=YIZEzGQ3ENY
http://www.youtube.com/watch?v=Rj7s3PbNaiM
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