Odometrie - "normaler" fehler oder Softwareproblem

[robodriver]

Hallo Leute,

ich sitze momentan an der Umsetzung der Odometrie meines Roboters und habe folgendes Problem:

Testen tu ich die Odometrie wie folgt:
Winkelberechnung:
- 3 volle umdrehungen nach rechts oder links drehen und dann den berechneten Winkel mit dem reellen Winkel vergleichen.
Dabei komme ich auf eine Abweichung von etwa einem Grad (recht konstant)
Koordinatenberechnung:
- 4 Meter geradeaus fahren und dann den real zurück gelegten Weg nach messen. Dabei komme ich auf eine Abweichung von 0-2,5 cm.

Also alles in allem könnte man ja sagen, dass die Odometrie recht genau ist.

Mein Problem ist aber:
Wenn ich den Bot normal geradeaus fahren lasse, dann läuft mir der Winkel weg. Nach 2 Metern verfahrweg bin ich teils schon bei knapp 40 Grad Abweichung.

Nun habe ich überall schon gelesen, dass eine Odometrie recht ungenau ist. Aber leider steht nirgens was man unter "recht ungenau" versteht.

Desshalb mal meine Frage:
Ist ein Fehler von 40 Grad auf 2 Metern ein "normaler" Odometrie-Typischer Fehler oder liegt das vielleicht doch an was anderem noch?

Mal ein paar Daten:
Mein Radumfang: 21,5 cm
Auflösung: 256 Incremente pro Radumdrehung
Radabstand: 28cm
Berechnet wird immer, sobald ein Rad 20 Incremente erreicht hat (nach der Vorherigen Messung), der Counter wird dann für beide Räder wieder auf 0 gesetzt.

Berechnung tu ich alles als Single (32 Bit Gleitkommazahl)

Und für die die es noch interessiert, bzw. die vielleicht was damit anfangen können, meine Formel zur Berechnung:


Sub Refresh_koordinaten
Statusbit.calc_koordinaten = 0

Tmp_winkel = Winkel

'Wenn Rückwärts gefahren wird:
If Raddrehung.rechts_zuruck = 1 And Raddrehung.links_zuruck = 1 Then
Tmp_winkel = Winkel + 180
A = Links
Links = Rechts
Rechts = A
End If

If Tmp_winkel < 0 Then Tmp_winkel = 360 + Tmp_winkel
If Tmp_winkel > 360 Then Tmp_winkel = Tmp_winkel - 360

Tmp_single = Links + Rechts
Tmp_single = Tmp_single / 2 'Mittelwert
Tmp_single = Tmp_single * 0.898 'Umrechnung Incr. in Millimeter

'neue X-Koordinate berechnen:
Tmp_single2 = Deg2rad(tmp_winkel)
Tmp_single2 = Tmp_single * Sin(tmp_single2)
X = X + Tmp_single2

'neue Y-Koordinate berechnen:
Tmp_single2 = Deg2rad(tmp_winkel)
Tmp_single2 = Tmp_single * Cos(tmp_single2)
Y = Y + Tmp_single2

'neuen Winkel berechnen:
If Links > Rechts Then
Tmp_single = Links - Rechts
Tmp_single = Tmp_single * 0.898 'Umrechnung Incr. in Millimeter
Tmp_single2 = 360 / 1583.3626974 '1583,... ist der Wendekreis des Bots
Tmp_single2 = Tmp_single2 * Tmp_single
Tmp_winkel = Tmp_winkel + Tmp_single2
Else
Tmp_single = Rechts - Links
Tmp_single = Tmp_single * 0.898
Tmp_single2 = 360 / 1583.3626974
Tmp_single2 = Tmp_single2 * Tmp_single
Tmp_winkel = Tmp_winkel - Tmp_single2
End If

Winkel = Tmp_winkel

If Raddrehung.rechts_zuruck = 1 And Raddrehung.links_zuruck = 1 Then
Winkel = Tmp_winkel - 180
End If

If Winkel < 0 Then Winkel = 360 + Winkel
If Winkel > 360 Then Winkel = Winkel - 360

Return
End Sub


Wäre toll wenn mir irgendwer, der sich damit auskennt, vielleicht einen Tipp geben könnte.

danke und Gruß Robodriver

[ranke]

Ich denke, daß der Abweichung von 40° bei 2 Meter Laufstrecke sicher ein korrigierbarer Fehler in der Datenerfassung oder -auswertung zugrunde liegt.
Nach dem Code rechnest Du mit 0.898 mm/Incr und Rad, nach der Geometrie (215mm Radumfang, 256 Incr./Umdr.) errechne ich 0,84 mm/Incr und Rad.
Für einen Vollkreis um den Aufstandspunkt des festgehaltenen Rads rechnest Du 1583 Inkremente, ich rechne aus der Geometrie (Spurweite 280mm) 2.093 Inkremente.
Diese Abweichungen sind nicht ohne weiteres erklärbar (außer ich hätte mich verrechnet?).
Die errechnete Winkelabweichung bei Geradeausfahrt könnte durch Fehler in der Erfassung der Inkremente verursacht sein.

[mare_crisium]

robodriver,

40° auf 2m scheint mir auch viel zuviel. Ich schlage vor, bei der Fehlersuche die Berechnungmethode (wie Ranke auch) und die Rechenzeit zu prüfen. Mit der Rechenzeit meine ich folgendes: Wenn die neue Berechnung startet, bevor die laufende Rechnung abgeschlossen ist (z.B. wenn das Erreichen der 20 Inkremente einen Interrupt auslöst), dann verwendet sie unfertige Werte und liefert Schrott :-(. Das Verfahren in dem angehängten pdf sollte schneller sein, weil es die zeitaufwendigen Sinus- und Cosinus-Berechnungen vermeidet. Vielleicht kannst Du damit sogar die Berechungszeit soweit verkürzen, dass Du die tolle Auflösung Deiner Grayscheiben besser nutzen kannst (z.B. eine Berechnung alle 4 Inkremente).

Ciao,

mare_crisium

[ranke]

@mare_crisium:
Das sieht ja sehr schick aus, was Du da geschrieben hast. Darf ich anregen, daß Du das vielleicht im RN-Wissen zugänglich machst, wenn Du magst? Sonst verschwindet es nach ein paar Wochen wieder in der Versenkung. Fertig ausgearbeitet ist es ja schon.

[robodriver]

Hallo ranke und mare_crisium,

ersteinmal vielen Dank für eure Antworten. :)
Also das mit dem Radumfang von 21,5cm kann auch ein MEssfehler sein.
Ich habe die Werte in der Software später individuell nochmal angepasst, bis die gefahrenen Wegstrecken mit dem realen Weg überein stimmten. Daher die Abweichung.
Also die 0,898mm/Incr. sind dann schon die die der realität am nächsten kommen.

Das Beispiel von mare werde ich mir mal ansehen. Momentan fehlt mir leider mal wieder etwas die Zeit dafür.

Ich denke ich werde mich mitte/ende nächste Woche da nochmal ran setzen und hier nochmal melden.

Gruß und Danke
Robodriver

^^edit:
Ach ja, hab nochwas vergessen:
Wie ich sehe wird in der Beschreibung auch nicht weiter drauf eingegangen:
Wie genau sollte man die Variablen berechnen? Reicht hier Singe mit 32 Bit aus oder sollte man double mit 64Bit benutzen?
Oder macht das einen kaum spürbaren Unterschied?

Weil eine 64-Bit Operation nimmt auf einem 8-Bit Controller halt auch nochmal wesentlich mehr speicher und Zeit weg, als eine 32-Bit Operation...