Als "sinnvolle Anwendung" dachte ich z.B. an eine Art Touchpad mit dem man durch Auflegen eines Fingers durch ein LCD-Menu scrollen kann.
find ich eigentlich auch schade, weil eine wegmessung wird beim RP6 ja schon mit den encodern gemacht. da fällt mir dann keine sinnvolle anwendung für den maussensor mehr ein.
gruß
Als "sinnvolle Anwendung" dachte ich z.B. an eine Art Touchpad mit dem man durch Auflegen eines Fingers durch ein LCD-Menu scrollen kann.
Bild hier
Atmel’s products are not intended, authorized, or warranted for use
as components in applications intended to support or sustain life!
gute idee. doch leider stell ich mir diese anwendung für mich momentan noch viel zu kompliziert vor. ich muss mich jetzt einfach mal mit einer cmos kamera in dieses thema einsteigen.
vielleicht kannst du mir ja mal meine letztens gestellte frage in deinem thread Minimallösung: Kamera für den RP6
beantworten. du scheinst ja mit kameras schon sehr viele erfahrungen gemacht zu haben?
danke schon mal im voraus für deine hilfe
radbruch,
tut mir leid, dass Dich die Mäuschen so enttäuscht haben ! Könnte aber sein, dass da vielleicht doch noch was geht. Wenn Du Lust hast, guck' doch mal in den Fred "Maus-Odometrie", den Robotino unter KI angefangen hat.
Ciao,
mare_crisium
Den "Maus-Odometrie"-Fred habe ich natürlich auch schon entdeckt ;)
Es gibt wieder den Rundungsfehler beim Auslesen der Deltadaten und den Schlupf am Boden. Auch hier wird der Schwanz der Maus (oder des Roboters) irgendwann mal zur Seite zeigen. Ohne externe Referenzen wie GPS, Baken, Kameras oder Markierungen wird sich der Bot verirren.
Bild hier
Atmel’s products are not intended, authorized, or warranted for use
as components in applications intended to support or sustain life!
radbruch,
tja, das mit dem Drehen ist so eine Sache. Du hast recht: Bei der Berechnung der Mausposition auf dem Bildschirm können Drehungen überhaupt nicht erfasst werden. Der Maussensor liefert zwei Zahlen, delta-x und delta-y, und die reichen bei einer frei beweglichen Maus nur aus, um x- und y-Koordinate der Bildschirmposition zu berechnen.
Bei einem Maussensor, der an ein Fahrzeug montiert ist, ist das anders: Nehmen wir mal an, der Maussensor ist an einem Asuro montiert und zwar so, dass die x-Achse des Maussensors genau senkrecht zu den Antriebsachsen, also in Vorwärtsrichtung zeigt. Der Asuro kann sich nur vorwärts/rückwärts bewegen und/oder drehen. Seitwärtsfahren kann er nicht. Diese Beschränkung der möglichen Bewegungen nutzt man aus, und kann - mit nur einem Maussensor - die Bewegungen des Asuro tatsächlich nachrechnen.
Die zwei Zahlen, die der Maussensor liefert, werden jetzt in Drehwinkel und Fahrstrecke umgesetzt: Jede Bewegung in x-Richtung, die der Maussensor anzeigt, bedeutet, dass der Asuro vorwärts/rückwärts gefahren ist. Jede Bewegung in y-Richtung besagt, dass er sich gedreht hat.
Der Drehwinkel lässt sich aus der Bewegung in y-Richtung und dem Abstand des Messflecks vom Bezugspunkt ausrechnen. Damit bekommt man die neue Vorwärtsrichtung (im ortsfesten Koordinatensystem). Mit der neuen Vorwärtsrichtung und den Bewegungsdaten in x-Richtung ist dann auch der neue Ort des Asuro auszurechnen.
Eine Drehung des Asuro allein macht die Genauigkeit der Ortsbestimmung noch nicht zunichte. Die Richtung und Länge der Bewegung wird dabei immer noch ziemlich genau berechnet. Erst über mehrere Drehungen und längere Wegstrecken wird die Messgenauigkeit allmählich und vor allem durch die Rundungsfehler beim Berechnen der neuen Vorwärtsrichtung immer schlechter.
Ich kann meinen Versuchsaufbau mit zwei Maussensoren jedenfalls in jeder Richtung umherschieben und ihn dabei auch um 180° drehen und habe am Ende einer Bewegung von ca. 50cm Länge einen Positionsfehler von weniger als 5cm. - Das ist immer noch unbefriedigend - aber: Wir arbeiten dran !
Ciao,
mare_crisium
Hallo
Das Problem liegt nicht in der (umfangreichen und auch mit Rundungsfehlern behafteten) Berechnung der vorwärts/seitwärts-Bewegung. Es liegt hier:
Und eben diese Zahlen enthalten ebenfalls einen Rundungsfehler und der addiert sich unter ungünstigen Umständen enorm. Die geringste Abweichung in der Ausrichtung führt unweigerlich in Chaos.Der Maussensor liefert zwei Zahlen, delta-x und delta-y...
Ich habe meine Versuche mit dem Maussensor verschoben/eingestellt. Deshalb habe ich keine eigenen Erfahrungen damit, das oben geschriebene ist möglicherweise totaler Unsinn. Aber ich vermute, sobald irgendwo ein Schlupf oder Rundungsfehler auftritt kann man die Odometrie, ohne externe Referenzen als einziges Navigationssystem,vergessen. Ein Fehler von 10% ist übrigens vollkommen unakzeptabel!
Gruß
mic
Bild hier
Atmel’s products are not intended, authorized, or warranted for use
as components in applications intended to support or sustain life!
Im Moment hänge ich an genau diesem Problem - nicht mit RP6 und Mäusen, sondern mit meinem MiniD0 bzw. Encodern an den Motorwellen. Immerhin bin ich nach einer Drehung um 990°, einer 180°Kurve, einer 90°Kurve, dazwischen immer Geradenstücke und zum Schluss eine Drehung um 540°, nach insgesamt mehr als 80 cm Fahrstrecke bei einer Abweichung von +- 1 mm, maximal +-25 mm. Maximal leider auch fast 10%. Aber ich arbeite dran . . . .Zitat von radbruch
Ciao sagt der JoeamBerg
Das liegt in erster Linie am Schlupf der Räder. Teste mal mit entfetteten Radoringen auf einer sauberen waagrechten Glas-/Spiegelfläche ;)
Bild hier
Atmel’s products are not intended, authorized, or warranted for use
as components in applications intended to support or sustain life!
Na ja, meine Räder
............Bild hier
haben O-Ring-Slicks und der Schreibtisch ist relativ fettlos . . . .
Ciao sagt der JoeamBerg
Lesezeichen