samuelk Geschrieben June 30, 2015 at 09:24 Geschrieben June 30, 2015 at 09:24 Hallo Ich möchte auf einem Roboter als Positionserkennung im Raum relativ zur ersten Nullposition ein IMU Brick verwenden. Über die Beschleunigung in x und y Richtung will ich die Geschwindigkeit und daraus den zurückgelegten Weg berechnen. Im Forum und auf der TF-HP habe ich nichts dazu gefunden und bin mir deshalb nicht sicher ob die Genauigkeit des Bricks dazu ausreicht. Gibt es dazu irgendwelche Erfahrungen/Tipps/Kritik?? immer her damit Vielen Dank Zitieren
Nic Geschrieben June 30, 2015 at 10:29 Geschrieben June 30, 2015 at 10:29 Ein sehr interressanter Bericht zur Lagebestimmung von Fzg unter http://mechlab-engineering.de/2014/03/tinkerforge-imu-zur-lageerkennung-von-fahrzeugen/ Zitieren
samuelk Geschrieben June 30, 2015 at 12:08 Autor Geschrieben June 30, 2015 at 12:08 Danke für die schnelle Antwort. Aber in dem Artikel wird die Geschwindigkeit über das GPS Brick bestimmt. Und wie beschrieben funktioniert das erst ab einer Geschwindigkeit von > 5km/h und draußen. Der Roboter wird jedoch für Messungen innen eingesetzt und fährt ca. 2km/h. Deshalb wollte ich den IMU Brick direkt einsetzen. Zitieren
Nic Geschrieben June 30, 2015 at 12:41 Geschrieben June 30, 2015 at 12:41 Lässt sich die Geschwindigkeit nicht auch ermitteln aus Raddrehzahl und -umfang ? Zitieren
raphael_vogel Geschrieben June 30, 2015 at 13:13 Geschrieben June 30, 2015 at 13:13 Wie Nic erwähnt hat ist das mit Odometrie relativ einfach zu machen, wenn die Räder keinen Schlupf haben, was in Innenräumen besser ist als Außen. Aber mit der Zeit wirst du auch mit Odometrie immer größere Fehler bekommen, und nach einger Zeit weisst du nicht mehr wo du genau bist. Generell ist die Positionsbestimmung (Localization) bei Robotern nicht einfach zu lösen. Oft werden multiple Sensordaten fusioniert, um Fehler auszugleichen (Kalman Filter -> https://en.wikipedia.org/wiki/Kalman_filter). Zitieren
raphael_vogel Geschrieben June 30, 2015 at 13:23 Geschrieben June 30, 2015 at 13:23 Eine andere Möglichkeit ist die Positionsbestimmung mittels Trilateration. Es werden die Abstände zu 3 feststehenden Landmarken ermittelt. Dies kann mit einem Laserscanner gemacht werden. Ich werde das mit dem neuen Laser Range Finder Bricklet das bald kommt mal ausprobieren ! Schönes Video mit Erklärung wie das gemacht wird: Zitieren
samuelk Geschrieben June 30, 2015 at 14:35 Autor Geschrieben June 30, 2015 at 14:35 Das Problem ist, dass ich Mecanum Räder verwende... Also seeehr viel Schlupf Leider... Auch bei dem beigefügten Video ist das Problem, dass es doch noch einigermaßen ungenau ist. Der Roboter ist ein Testroboter für RFID-Transponder und gerade bei stehenden Wellen etc. kommt es auf einige Zentimeter an. Meine Überlegung ist noch einen optischen Maussensor (z.B. ADNS2610) am Unterboden anzubringen. Oder über 2 Lasermessgeräte (z.B. Bosch GLM 100 C) über eine Referenzfläche vorne und an einer Seite eine exakte Messung durchzuführen. Als Referenz kann man z.B. Personenabsperrbänder nehmen, welche je nach benötigter Länge aufspannen kann. http://image.img-erento.com/absperrgitter-zaeune/personenleitsystem-absperrband-absperrgitter-zaeune-274218-5043715_dia_1.jpg Da ich aber zur Ausrichtung vom Roboter zur Antenne schon einen IMU verwende, wäre das eben die eleganteste Lösung gewesen :/ Meint ihr also, dass es damit eher nicht möglich ist? Zitieren
baboboy Geschrieben July 1, 2015 at 13:44 Geschrieben July 1, 2015 at 13:44 Hallo Samuel, ich glaube nicht, dass du damit deine gewünschte Genauigkeit erreichen kannst. Du brauchst zumindest in regelmäßigen Abständen wieder eine absolute Position, da dein Fehler mit der Zeit sehr groß wird. Wenn du den IMU Brick schon hast, dann kannst du ja einfach mal folgendes machen: - Laufend Beschleunigungsdaten aufzeichnen. - Mit dem Roboter an einer definierten Position beginnen, eine gewisse Strecke abfahren und anschließend genau zum Ausgangspunkt zurückkehren. - Die aufgezeichneten Beschleunigungsdaten z.B. in Excel importieren, zweifach integrieren und schauen wie nahe du bei allen Achsen an der 0 bist. Du hast bei Kurvenfahrten das Problem, dass zusätzlich eine Zentripetalkraft wirkt, die von dem Sensor als Beschleunigung wahrgenommen wird und das Ergebnis enorm verfälscht. Der Fehler kann zwar mit dem Drehratensensor rausgerechnet werden, ist aber vermutlich nicht ganz trivial. Um zumindest systematische Fehler rauszurechnen brauchst du schon ein bisschen Mathe/Physikkentnisse. Ich würde da mal nach fertigen Algorithmen schauen (Stichwort ->Sensor Fusion). Das Thema Positionsbestimmung/Navigation in geschlossenen Räumen ist ein Thema, an dem aktuell noch viel geforscht wird. Es gibt auch komplette Abschlussarbeiten, die sich nur diesem Thema widmen, vielleicht findest du da noch Anregungen. Zitieren
düdo26 Geschrieben July 2, 2015 at 21:11 Geschrieben July 2, 2015 at 21:11 Hallo Samuel, ich hatte eine ähnliche Idee. Der Stack mit Master, Servo, IMU und WLAN etc. ist auf einem Chassis mit kräftigen Elektromotoren montiert: https://www.pololu.com/product/1566 Zu Beginn wollte ich nur mal schauen ob ich den Winkel auslesen kann um den Robbi auf Befehl sich einmal um 360° drehen zu lassen. Aber der errechnete Winkel weicht in einigen Bereichen stark ab, in anderen stimmt er. Auch im Brickviewer ist dies sichtbar. Wird der IMU vom Fahrzeug räumlich entfernt stimmt die Anzeige wieder. Ich fürchte dass mir da entweder die Antriebsmotoren oder die Servomotoren (Kamera Pan/Tilt) mit ihrem Magnetfeld einen Strich durch die Rechnung machen . In einem anderen thread steht dass dynamische Felder nicht rauszurechnen sind. Käme jetzt auf einen Versuch an ob die Felder statisch oder dynamisch sind. Der Fehler tritt auch auf wenn ich den Robbi von Hand statt mit den Motoren drehe. Grüße und viel Erfolg! Zitieren
mchott Geschrieben July 3, 2015 at 08:41 Geschrieben July 3, 2015 at 08:41 Nur mal so..das IMU liefert doch einen Kompass..und mit Abstandssensoren könnte man doch die Entfernung zu den Wänden messen. Dann hätte man auch wieder einen Abgleich und wäre eventuell genauer?! Zitieren
baboboy Geschrieben July 3, 2015 at 09:10 Geschrieben July 3, 2015 at 09:10 Auf den Kompass würde ich mich nicht verlassen. Ich habe mal etwas ähnliches mit einem Android Smartphone probiert, das war völlig unzuverlässig sobald irgendwas aus Eisen in der Nähe war. Wenn du dann noch E-Motoren in der Nähe betreibst kannst du es wahrscheinlich komplett vergessen. Aber die Abstandssensoren klingen auf jeden Fall vielversprechend. Zitieren
mchott Geschrieben July 3, 2015 at 09:34 Geschrieben July 3, 2015 at 09:34 Aber ohne den Kompass weiß man ja nicht, zu welcher Wand man gerade den Abstand misst?! Es bleibt ein spannendes Thema. Eventuell ist es auch mit einem Boden voller NFC-Aufkleber zu lösen, dann hätte man einige Referenzpunkte, die man überfährt und damit kann man seine Abweichungen häufiger korrigieren, ohne dabei ständig wieder zurück zur Homebase zu müssen. Oder man nutzt einen drehbar gelagerten Distanzmesser, der quasi wie ein klassisches Radar die Lage bestimmt, was aber dann schon ambitioniert sein dürfte. Zitieren
baboboy Geschrieben July 3, 2015 at 12:00 Geschrieben July 3, 2015 at 12:00 Ja, das mit der Ausrichtung im Raum ist ein Problem, aber ich bin mir sicher, dass der Kompass dafür keine Lösung ist. Die Frage ist, muss sich der Roboter überhaupt drehen können? Mit den Mecanum Rädern kann er sich ja auch so in alle Richtungen bewegen, das ist ja gerade das Schöne an den Dingern. Vielleicht ist es möglich den Roboter am Anfang manuell auszurichten und dann nur noch nach vorne und seitlich zu verfahren, ohne den Roboter dabei zu drehen (kommt natürlich darauf an, wie genau der Testlauf aussieht, das kann uns nur Samuel beantworten). Wenn man vier Lasersensoren am Roboter befestigt (vorne, hinten, links und rechts), kann man sogar erkennen wenn sich der Roboter verdreht. Nämlich dann, wenn die Summe der beiden gegenüberliegenden Strecken größer wird. Zitieren
samuelk Geschrieben July 3, 2015 at 12:27 Autor Geschrieben July 3, 2015 at 12:27 Danke für die rege Beteiligung Also ich denke mit den IMUs wird das nichts. Ich habe es anhand einiger einfachen Versuche getestet wie die doppelte Integration von der Beschleunigung zur Strecke funktioniert. Und das Ergebnis ist leider nicht genau genug... Die Ausrichtung des Roboters bezüglich einer Gierbewegung ist aber trotzdem noch geplant. Laut TF ist die Änderung genau zu messen, nur absolut gibt es Ungenauigkeiten. Die Magnetfelder der Motoren könnten natürlich zu einem Problem werden... In dem Fall ist es aer evtl möglich über ESD Folie etc. diese möglichst gut abzuschirmen. Meine Idee ist es falls es mit Tinkerforge doch nicht funktioniert, für eine Seite 2 laserabstandssensoren anzubringen. Wenn man den Gierwinkel dann so justiert, dass diese 2 den gleichen Abstand zur Referenzfläche haben, dann ist der Roboter richtig ausgerichtet. Der Roboter soll sich nicht drehen... Er DARF es bestenfalls nicht.... Die Theorie: Er kann in jede richtung fahren, ohne seine Ausrichtung zu änder Die Praxis: Er führt eine leichte Gierbewegung aus. --> Diese muss kompensiert werden, durch Drehung des Unterbaus. Zitieren
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.