- Akku Tests und Balkonkraftwerk Speicher         
Seite 5 von 7 ErsteErste ... 34567 LetzteLetzte
Ergebnis 41 bis 50 von 63

Thema: 1 Maussensor, Drehung berechnen

  1. #41
    Benutzer Stammmitglied
    Registriert seit
    07.10.2007
    Beiträge
    58
    Anzeige

    Praxistest und DIY Projekte
    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).

  2. #42
    Benutzer Stammmitglied
    Registriert seit
    07.10.2007
    Beiträge
    58
    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.
    Angehängte Dateien Angehängte Dateien

  3. #43
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    29.05.2005
    Beiträge
    1.018
    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
    Lieber Asuro programieren als arbeiten gehen.

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

  5. #45
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    26.11.2005
    Ort
    bei Uelzen (Niedersachsen)
    Beiträge
    7.942
    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.

  6. #46
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    08.12.2005
    Beiträge
    535
    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

  7. #47
    Benutzer Stammmitglied
    Registriert seit
    07.10.2007
    Beiträge
    58
    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

  8. #48
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    08.12.2005
    Beiträge
    535
    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

  9. #49
    Benutzer Stammmitglied
    Registriert seit
    07.10.2007
    Beiträge
    58
    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.

    Also Danke nochmals an alle und natürlich an erster Stelle an mare_crisium
    Angehängte Dateien Angehängte Dateien

  10. #50
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    08.12.2005
    Beiträge
    535
    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

Seite 5 von 7 ErsteErste ... 34567 LetzteLetzte

Berechtigungen

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

LiFePO4 Speicher Test