Odometrieberechung mit zwei Maussensoren

[robotino]

Hallo,
ich war bisher nur ein eifriger Leser dieses Forums, doch nun brauch ich doch mal Hilfe.

Ich benutze zwei konventionelle Mäuse um die Position meines Roboters zu bestimmen. Dieser läuft mit drei Rädern, kann sich also in jede beliebige Richtung bewegen und auf der Stelle drehen. Die Sensoren sind am "Heck" angebracht, in bekanntem Abstand. Die x-Richtung beider Sensoren zeigt dabei zum Drehpunkt des Roboters.

Wenn ich mich nun translatorisch bewege kann ich damit die Richtung in die ich fahre, für beide Maussensoren bestimmen. Wenn ich rotiere dann dann werden nur y-Werte der Mäuse aufgenommen und ich kann aus dem abgefahrenen Kreisbogen den Drehwinkel bestimmen.
Soweit so gut.
Nur wie könnte man die beiden getrennten Rechenwege zusammen in eine Brechnungsgrundlage pressen? Weil ich mich zB drehe, dann darf sich in dem Moment natürlich nicht die Absolutposition des Roboters verändern.

Hat da jmd. eine Idee, ich bin grad schon am verzweifeln ob dieses Problems, oder hab ich nur einfach einen Denkfehler.


Grüße,
robotino

[mare_crisium]

robotino,

es freut mich, noch jemanden zu finden, der sich hier mit dem Thema "Maus-Odometrie" beschäftigt ! Ich habe mir meine optischen Maussensoren selbst gebaut (mit dem ADNS 2610). Die Software habe ich auch zusammengepfriemelt. Sie läuft auf einem ATmega16 (16MHz) und kommuniziert mit dem PC über die RS232. Auf dem PC läuft eine in Delphi geschriebene graphische Darstellung des vom ATmega berechneten "Fahrzeug"-Ortes. Es funktioniert alles ganz ordentlich; nur ist die Genauigkeit der Ortsbestimmung noch nicht so wie ich's gern hätte.

Die Mathematik zu dem Thema ist unabhängig vom Messprinzip der Mäuse. Du findest sie in dem angehängten pdf. Sie ist gar nicht so schwierig, wenn man sich ein bisschen mit Vektoren auskennt. Man muss nur immer aufpassen, dass man nicht mit den verschiedenen Koordinatensystemen durcheinanderkommt .

Kannst aber jederzeit nachfragen, wenn 'was unklar sein sollte. Bin gespannt, ob Du's genauer hinkriegst als ich.

Ciao,

mare_crisium

Edit: Attachment gelöscht, wg. Upload-Quota.

[robotino]

Hallo,

habe endlich Zeit gefunden, dein Dokument einmal durchzulesen. Vielen Dank erstmal dafür.
Aber so ganz verstanden hab ich die Formeln noch nicht.

Bis zu deinem Gleichungssystem ist alles iO soweit, aber ich komme dann nicht auf deine Lösungen 2_1 und 2_2.
- Wozu dient dir das Kreuzprodukt mit e_z? Du drehst doch letztendlich nur deinen Vektor b_i um 90°
- Wenn ich die Gleichung nach x,y Komponenten aufschreibe, und zB b_1x = b_2x, dann erhält man eine Division durch 0
- in Gleichung 2_2 ist phi ein Skalar, die rechte Seite der Gleichung sind aber Vektoren, die ja auch als Ergebnis wieder ein Vektor bilden


Ich habe grad folgenden Ansatz:

X = 1/2 * (s1 + s2) * cos( (s1-s2)/2d )
Y = 1/2 * (s1 + s2) * sin( (s1-s2)/2d )

mit s_i = sqrt(m_ix^2 + m_iy^2), also quasi die Länge des Zurückgelegten Weges von Sensor i und d: Abstand zwischen beiden Sensorpunkten.

Damit kann ich allerdings keine kombinierten Bewegungen von Translation in beliebige Richtung und Rotation erreichen.
Da werd ich wohl noch ein wenig tüfteln müssen, aber vielen Dank erstmal für deine Arbeit.

Grüße

[robotino]

Abend,

nach einigem Ausprobieren funktioniert jetzt die Lösung von mare_crisium ausgezeichnet. Allerdings nicht die analytische Lösung nach Gleichungen 2.1 und 2.2, das hab ich nicht hinbekommen. Ich lasse mir aber in jedem Abtastschritt die Ergebnisse für die Positionsänderung numerisch berechnen, das geht auch wunderbar.
Einzig die Genauigkeit , vor allem beim einfachen Geradeausfahren, könnte etwas genauer ausfallen, aber das liegt eher an der Messwertaufnahme.

Ich habe festgestellt, das schon kleine Unebenheiten im Bodebelag dazu führen, das die Messwerte verfälscht werden. Ich presse daher die Maussensoren im Moment mit einer Federkonstruktion gegen den Boden, was die Genauigkeit verbessert hat. Aber ganz zufiedenstellend ist das Ergebnis noch nicht.

Grüße

[mare_crisium]

robotino,

so, jetzt bin ich wieder im Lande. Es hat mich gefreut, zu sehen, dass Du Dich so gründlich mit der Sache auseinandergesetzt hast. Eine exakte analytische Lösung des Gleichungssystems gibt es im allgemeinen nicht, weil es überbestimmt ist. Mit der Methode der kleinsten Fehlerquadrate kann man aber die Abweichung zwischen Messwerten und berechneten Werten so klein wie möglich machen. Es also eher eine optimale Anpassung, als eine Lösung. Im Anhang kannst Du die Einzelheiten sehen. Delta Phi ist ein Skalar, weil rechts ein Skalarprodukt steht ! Ich hab im Anhang versucht, die Formel suggestiver aufzuschreiben.

Ich lasse mir aber in jedem Abtastschritt die Ergebnisse für die Positionsänderung numerisch berechnen, das geht auch wunderbar.

Ja prima ! Das heisst, Du berechnest Drehung und Verschiebung, oder?

Die Genauigkeit ist ein echtes Problem. Meine Maussensoren liegen nicht auf dem Untergrund auf, sondern beäugen ihn durch eine Linse von 8mm Brennweite, die ca. 50mm über dem Untergrund montiert ist. Bei dieser Gegenstandsweite brauche ich auch keine Beleuchtung mehr; normales Tageslicht reicht dicke aus. Die Auflösung liegt bei ca. 3 Ticks/mm. Unebenheiten sind bei diesem Aufbau unschädlich, solange sie nicht zu weit aus dem Bereich der Schärfentiefe herausragen. Das Scharfstellen geht sehr einfach: Solange an der Fokussierschraube drehen, bis der SQUAL-Wert (Register 0x04) maximal ist.

Ein Testfeld ohne Unebenheiten hatte ich mir hergestellt, indem ich ein altes(!) Geschirrhandtuch mit Linoldruckfarbe eingerollt und dann auf einem DIN A2 Bogen weissen Zeichenkartons abgedruckt habe. Das gibt eine unregelmässige Struktur mit hohem Kontrast und ausreichend feiner Körnigkeit.

Bei mir ist die Positionsberechnung bei geraden Fahrten über 200 bis 300mm auf mindestens 1mm genau. Ungenau wird's erst bei Drehungen. Meine Berechnungen laufen auf einem ATmega16, der auch die Messwerte abfragt. Der "SLEEP"-Modus ist natürlich ausgeschaltet und wie gesagt, ich verwende kein Wechsellicht für die Ausleuchtung (die Sensorkamera macht 1600 Aufnahmen/s; da verursacht das 100Hz-Flackern einer Wechselstromlampe schlimme Fehlmessungen). Es gibt noch jede Menge anderer Fehlerquellen. Inzwischen habe ich eine Liste zusammengestellt, die ich in den nächsten Wochen abarbeiten werde. Zwei der Kandidaten sind:
1. ab und zu werden Messwerte zwar abgefragt, aber unvollständig oder falsch verarbeitet (z.B. durch pile-ups der Timerinterrupts). Das führt zu verschiedenen Fehlerbildern.
2. das Messintervall ist ab und zu so lang, dass ein Messwert überläuft (die delta_x- und delta_y-Register können ja nur -127 bis +127 darstellen), dann ist die berechnete Verschiebung zu kurz, bzw. die Drehung zu klein.

Bei Dir laufen die Rechnungen auf dem PC, nehme ich an? Welche Genauigkeit haben Deine Variablen? Die Kalibrierdaten der Sensoren streuen. Es ist eine gute Idee, gemittelte Werte aus mehreren Kalibierfahrten zu verwenden.

Ciao,

mare_crisium

Edit: Ach, ich habe wieder übersehen, dass Du ja mechanische Mäuse verwendest. Sprichst Du Deine Mäuse über PS/2 an?

Edit2: Attachment gelöscht, wg. Upload-Quota.

[mukipower]

Hallo mare_crisium und robotino,
ich habe gerade Eure interessanten Lösungsansätze gelesen. Ich mache gerade gerade meine Bachelorarbeit genau mit diesem Thema.
Ich habe 2 optische Mäuse per PS/2 an einem ATmega32 der die 4 Richtungsvektoren an den PC schickt. Leider konnte ich den Sleepmodus noch nicht abschalten, so das mir beim Anfahren ein Paar Werte verloren gehen.
Sonst liege ich schon für die reine X,Y- Messung bei 1% Fehler. Ich habe auch vor demnächst mit Linsen zu arbeiten.
Vorher muss ich aber noch Winkelmessung mathematisch verstehen und umsetzen. Die Idee mit dem Radiusabfahren finde ich sehr gut. Bedeutet das, wenn ich 3 oder 4 Sensoren habe, ich beide Probleme (Strecke und Winkel) in 2 einfachere Probleme Kapseln kann?

@ mare_crisium: Ich habe noch jeweils einen ATmega8 (SLAVE) pro Maus dazwischen geschaltet um die ganzen Deltas zu summieren damit mir nichts verloren geht, falls mein "MASTER" mal etwas lahm ist.

@ all, manchmal gibt die Maus eine sehr langsame Bewegung an obwohl sie sich nicht bewegt, liegt es daran dass sie ne billige 5 Euro Maus ist?

Leider kann ich die PDF's nicht runterladen da sie gelöscht wurden Könnt Ihr sie Bitte nochmal Posten, danke.

Ich hoffe das Thema ist für Euch noch nicht gestorben

Gruß, Stefan.