1 Maussensor, Drehung berechnen

Zitat:

---

Zitat von Sternthaler

Aus der Doku von PRobot kann man entnehmen:
Werte von -128 bis 127 finden sich in 3 Register-Paaren:
delta_X: 0x03 0x17 0x43
delta_Y: 0x02 0x18 0x42
Und für die Overflow-Bits gibt es nur das Register 0x16
Bei der Beschreibung zu 0x16 steht, dass dann die Register 0x17 und 0x18 zu lesen sind.
Nutzt du diese 3 Register? Wie initialisiert du den Sensor?

---

Hi!

Code:

---

/*!
 * Uebertraegt ein write-Kommando an den Sensor
 * @param adr Adresse
 * @param data zu schreibendes byte
 */
void pan_write(unsigned char adr, unsigned char data){...}

---

Initialisierung:

Code:

---

//Reset PAN3101
pan_write(0x00,0x80); //Full chip reset
// kein Sleep modus
        pan_write(0x00,0x01);

---

Code:

---

/*Liest die Daten aus dem PAN3101
Wird true zurückgegeben, haben sich die Koordinaten seit dem letzten Abruf
geändert, ansonsten nicht.*/
int pan_readPos(void){
        unsigned char ino;
        signed char buf_x,buf_y;
       
        int ret;

        //Endlosschleife

        ino=pan_read(0x16);

        //wenn 7tes bit vom Register 0x16 gesetzt ist wurde die Maus bewegt => Bewegungsdaten abfragen
        if(ino&(1<<7)){               
                //Deltax Register auslesen
                buf_x=pan_read(0x17);
                //und zu der Positionvariable addieren
                pan_posx += buf_x;
               
                /* Nachschaun ob das Überlauf-Bit im Register 0x16 gesetzt ist
                  wenn das der Fall ist muss je nach Vorzeichen der Deltax Variable x
                  noch 128 (überlauf nach oben) dazugezählt oder eben 128 abgezogen werden
                */
                if(ino&(1<<3)){
                        if(buf_x<0){
                                pan_posx-=128;
                        }else{
                                pan_posx+=128;
                        }
                }
               
                //ab hier nochmal das Gleiche für die yRichtung

                buf_y=pan_read(0x18);
                pan_posy += buf_y;
               
                if(ino&(1<<4)){
                        if(buf_y<0){
                                pan_posy-=128;
                        }else{
                                pan_posy+=128;
                        }
                }
                ret= 1;
        } else
                ret = 0;
       
                //hier kann jeder seine Ausgabevariante selber wählen ;)
       
        //(*x) = pan_posx;
        //(*y) = pan_posy;
       
        return ret;
}

---

Zitat:

---

Zitat von jeffrey

hoi,
ich denke nicht, dass die y-werte nur durch die falsche einbaulage kommen, dazu sind die 6° fehler viel zu wenig, da wären das dann um die 200, bei 2000 schritten in x-richtung.

---

Ich bin auch definitiv davon Überzeugt, dass sich der Y-Wert bei einer Drehung genau um den Mittelpunkt nicht ändern darf (laut Mathematischer logik).

Ich habe jetzt einen Fehler beim Anschluss des Maussensors gefunden:
Der "PS2 Chip", welcher vorher zuständig war, die Daten des Sensors auszuwerten und an den PC weiterzuleiten, war ncoh mit dem Maussensor verbunden und hat mir wahrscheinlich immer Daten "gestohlen".

Wenn ich jetzt Alpha neu messe, bekomme ich einen viel kleineren Wert:

Gefahrene Strecke in Ticks auf 100mm
1516,6|29663

Umrechnungsfaktor
ɑ = 0,003371203

Fehlausrichtung: ψ 1,519713139 = 87,07314896°

Dazu habe ich auch eine .xls erstellt.

@mare_crisium
Dabei habe ich herausgefunden, dass ich bei der Gefahrenen Strecke in Ticks den Absolutwert (positiven Wert) nehmen muss, damit ich für wq eine Zahl um 0 erhalte. Ansosnten ist der Wert für wq 10 mm was meiner Meinung nach falsch ist.

In der PDF wäre auch empfehlenswert anzugenben, in welcher einheit "d" in die Drehwinkel-Formel eingesetzt werden muss.

Hallo zusammen

@PRobot
danke für die Codeschnippsel. Das sieht ja sehr gut aus.

Bei der Berücksichtigung von einem eventuellen Überlauf:

Code:

---

      buf_x=pan_read(0x17);
                //und zu der Positionvariable addieren
      pan_posx += buf_x;
         
                /* Nachschaun ob das Überlauf-Bit im Register 0x16 gesetzt ist
                  wenn das der Fall ist muss je nach Vorzeichen der Deltax Variable x
                  noch 128 (überlauf nach oben) dazugezählt oder eben 128 abgezogen werden
                */
      if(ino&(1<<3)){
        if(buf_x<0){
            pan_posx-=128;
        }else{
            pan_posx+=128;
        }
      }

---

addierst bzw. subtrahiert du die 128.
Ist es richtig, dass abgezogen wird, wenn buf_x < 0 ist?
Ich werfe dese Frage nur in der Raum, das ja die Werte in Register 0x17 und 0x18 als 2'er complement angegeben sind.
Ich bin mir sicher, dass es so korrekt sein müsste, aber dies könnte nochmal eine Stelle zum Nachdenken sein.

Und in deinem EXCEL komme ich in dem Block 'Umrechnungsfaktor' mit dem Wert '1 mm = 296,63 Ticks' nun auf 7534,402 Tiks / inch
Das glaube ich nicht ;-)


@jeffrey
Erst mal was einfaches: Das c steht für count (count per inch = cpi)
Deine Rechnung konnte ich so nachvollziehen. Aber Vorsicht mit den, mal von mir in den Raum geworfenen, 400 cpi (die ja mal nur 40 waren). Dieser Sensor müsste 800 cpi zu haben. Ich hatte mich ja auf eine Doku gestützt, die hier nicht relevant ist.

Jetzt muss ich erst einmal nach Hause
Gruß Sternthaler

Howdy, PRobot,

prima, dass Du den Fehler gefunden hast! Durch Deine Rechentabelle habe ich auch einen in meinem pdf _V04 gefunden :-( . Im Anhang meine Version Deiner Rechnung. Die Absolutwerte brauchst Du nicht zu nehmen. V_05 der pdf-Datei kommt demnächst.

Ciao,

mare_crisium

Die Y Werte kommen sowohl durch die Einbaulage als auch durch den Winkel des Sonsors. Wie schon oben geschrieben kann man den Winkel des Sensors einfach durch eine Drehmatrix korrigieren. Die XLS Files kann ich leider nicht lesen, deshalb wiess ich nicht welche Formeln da drinstehen. Nach dem Korrigieren der Drehung gibt dann die eine Achse (hier wohl X) die Drehung und die andere den zurückgelegten Weg. Wenn der Sensor wie gezeichent etwas ausserhalb der Mitte ist, kriegt man halt eine kleinen Weg auf einem Kreis, wenn man den Robot um die Mitte dreht.

Guten Abend zusammen,

hier ist die versprochene neue Version in der ich den (hoffentliche letzten :-) ) Fehler beseitigt und die Kalibiermethode von PRobot eingebaut habe.

@jeffrey,
Ja, es ist möglich, dass der Asuro trotz identischer Messwerte von beiden Odometern nicht geradeaus fährt: Es reicht aus, wenn die beiden Raddurchmesser sich unterscheiden.

@Besserwessi,
die .xls-Dateien kannst Du lesen, wenn Du Dir OpenOffice herunterlädst und installierst.

Ciao,

mare_crisium


Edit: Anhang gelöscht wg. Upload-Quota

Hi mare_crisium
jetzt scheint die Berechnung zu stimmen.
Ich bekomme jetzt auch die richtigen werte für Wegstrecken und -längen:
Wegstrecke wp 1000,000000 mm
Wegstrecke wq 0,000000 mm
Weglänge si 1000 mm
Drehwinkel -1,22288E-16 -7,00659E-15

Um die Drehung zu berechnen, muss ich wie folgt vorgehen:

• *Die Startposition wird gespeichert (z.B. 0|0)
  *Der Roboter dreht sich auf dem Mittelpunkt
  *Nach der Drehung wird die Endposition gespeichert (z.B. 1622|107) (diese koordinaten sollten 45° entsprechen)
  *Die deltaX (=1622) und deltaY (=107) in die Winkel Formel von mare_crisium einsetzten
  *Das Ergebnis sollte Theoretisch in diesem Fall 45° ergeben
  *Die Messwerte liegen bei mir aber immer ungefähr 16% oberhalb des *Richtwertes, also muss ich das Ergebnis noch mit 0,84 multiplizieren.
  *Somit erhalte ich ein Ergebnis mit ca. 2-3 Grad abweichung

Jetzt muss ich das alles nochmals genauer in Versuche ausprobieren, wie sich der Roboter verhält

Hi, PRobot,

prima, dass es jetzt klappt :-) ! Den ersten Teil Deines Postings verstehe ich so, dass Du den Maussensor nun so justiert hast, dass eine seiner Messrichtungen in Fahrtrichtung zeigt.

Der zweite Teil macht mir aber noch zu schaffen, weil der Faktor 0,84 nicht sein darf. Ich habe also Deine die Daten in die Rechentabelle eingegeben (x (Ticks) = 107 in Spalte A, y (Ticks) = 1622 in Spalte B). Ausserdem habe ich den maus_winkel auf 0 und alpha auf 0,0313 gesetzt. Als Zwischenergebnis zeigt mir die Spalte J einen Drehwinkel von 46,5°. Das wäre ja gar nicht mal so schlecht. Aber aus den Spalten L und M bekomme ich dann einen Drehwinkel von nur 39° heraus.

Die Erklärung, warum der aus Spalte L und M berechnete Winkel so weit daneben liegt, ist folgende: In Spalten L und M wird numerisch integriert. Dieses Verfahren liefert nur dann brauchbare Werte, wenn viele, möglichst kleine Teilschritte verarbeitet werden; grosse Teilschritte führen zu einem sehr ungenauen Ergebnis.

Könntest Du noch einen Versuch machen, bei dem Du während der Drehung möglichst viele Zwischenwerte speicherst? Dann sollte auch das Ergebnis aus Spalte L und M genauer werden. Nur mit einem Faktor kannst Du Integrationsfehler nicht ausgleichen.

Ciao,

mare_crisium

P.S.: Ich hänge noch ein pdf an, dass Dir den Bahnintegrations-Algorithmus erklärt.

Eidit: Anhang siehe mein Beitrag vom 28.09.2008

Ich habe jetzt einige Messungen durchgeführt, wo ich den Roboter mit der Hand manuell im Kreis gedreht habe und alle 250ms die Position gemessen wird.
Ich habe folgende Messungen durchgeführt:
5 x gemessen für 90°
5 x gemessen für 45°
3 x gemessen für 180°

Ich habe auch gleich Versucht, die Messdaten in die Excel-Datei von mare_crisium auszuwerten.
Ich kann nur folgendes zu mare_crisium's Arbeit sagen: :APPLAUS: :APPLAUS: :APPLAUS:
Ich erhalte folgende Endwinkel bei den Messreihen:
90° 1. Messung: -114,7°
90° 2. Messung: -93,7°
90° 3. Messung: -94,4°
90° 4. Messung: -91,3°
90° 5. Messung: -108,0°

45° 1. Messung: -47,3°
45° 2. Messung: -40,5°
45° 3. Messung: -45,2°
45° 4. Messung: -41,8°
45° 5. Messung: -53,9°

180° 1. Messung: -175,9°
180° 2. Messung: 171,4°
180° 3. Messung: -171,7°

Also die Werte (zumindest bei 45° und 90 °) sind verdammt nahe am sollwert.

Noch etwas ist mir aufgefallen:
Wenn der letzte Wert der y-Koordinate der Spalte m (also "e_p (normiert)") negativ ist, so ist auch der Winkel negativ.
Bei der 2. Messung bei 180° ist dieser Wert aber Positiv und somit auch der Winkel positiv.
Also muss ich den Betrag vom Endwinkel nehmen, um zu bestimmen, wie viel sich der Roboter in die entsprechende Richtung gedreht hat.

Hier noch die .xls (Diesmal im Zip Format, da die Datei ansosten zum Hochladen zu groß ist) wo ich die Messdaten und die Dazugehörige Auswertung habe.

Jetzt muss ich nur noch einen Alghorithmus entwickeln, welcher das dann alles Ausrechnet, was aber nur ein kleines Problem im Vergleich zu dem Ganzen hier ist. O:)

Also Danke nochmals an alle und natürlich an erster Stelle an mare_crisium

PRobot,

vielen Dank für das Lob - es freut mich, dass ich Dir weiterhelfen konnte. In Deiner Datei habe ich die Diagramme und die Berechnungen in Spalten T und U geändert. Der Diagrammtyp muss "X-Y-Diagramm" sein und der Datenbereich muss die Spalten T und U umfassen. In Spalten T und U musst Du Spalte H als "s_i" nehmen, weil Dein Robby in Richtung der y-Achse fährt. Die Diagramme zeigen jetzt sehr schön die Bahn an, die Dein Robby gefahren ist. - Leider kann ich nicht zippen, deshalb habe ich von Deinen Tabellen immer nur die ersten beiden beibehalten.

In dem Konzept stecken aber noch mehr Möglichkeiten: Wenn man den Ort des Fahrzeugs (wie in _V103a.pdf beschrieben) und seine Fahrtrichtung kennt (den Vektor e_p (normiert)), kann man auch den Richtungswinkel zu einem Zielort ausrechnen. Die z-Komponente des Kreuzproduktes von e_p (normiert) und dem Einheitsvektor zum Zielpunkt liefert den Sinus dieses Winkels und eignet sich ganz prima, um den Robby geregelt auf das Ziel losfahren zu lassen.

Im übrigen sind heute meine ADNS2610 angeliefert worden :-) .

Ciao,

mare_crisium

Edit: Anhang gelöscht wg. Upload-Quota