-         

Ergebnis 1 bis 5 von 5

Thema: Odometrie - "normaler" fehler oder Softwareproblem

  1. #1
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    28.05.2007
    Ort
    Mannheim
    Alter
    30
    Beiträge
    270

    Odometrie - "normaler" fehler oder Softwareproblem

    Anzeige

    SMARTPHONES & TABLETS-bis zu 77% RABATT-Kostenlose Lieferung-Aktuell | Cool | Unentbehrlich
    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:
    Code:
    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
    Wer aufhört besser zu werden, hat aufgehört gut zu sein

    Jeder I/O Port kennt drei Zustände: Input, Output, Kaputt

  2. #2
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    27.08.2004
    Ort
    Kreis Starnberg
    Alter
    52
    Beiträge
    1.819
    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.

  3. #3
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    08.12.2005
    Beiträge
    535
    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
    Angehängte Dateien Angehängte Dateien

  4. #4
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    27.08.2004
    Ort
    Kreis Starnberg
    Alter
    52
    Beiträge
    1.819
    @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.

  5. #5
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    28.05.2007
    Ort
    Mannheim
    Alter
    30
    Beiträge
    270
    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...
    Wer aufhört besser zu werden, hat aufgehört gut zu sein

    Jeder I/O Port kennt drei Zustände: Input, Output, Kaputt

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •