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).

Liste der Anhänge anzeigen (Anzahl: 1)

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

Liste der Anhänge anzeigen (Anzahl: 1)

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

Liste der Anhänge anzeigen (Anzahl: 1)

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

Ich habs geschafft: \:D/
Jetzt habe ich einen funktionierenden Code zur berechnung der Drehung mit Hilfe von mare_crisiums Dokumentationen und .xls erstellt:
(Falls ihr Verbesserungsvorschläge habt, bitte melden)
Dazu sind 2 Funktionen nötig:
-Eine zum Initialisieren der Variablen, welche beim Start des Roboters aufgerufen wird
-Eine, welche immer nach einer kurzen Drehung die aktuelle Position auswertet.

Also hier der Code (einfach in eine Header File kopieren und im Programm includieren)
ACHTUNG: Die defines müssen an euren Maussensor angepasst werden. Zur näheren Beschreibung und zur Berechnung siehe in der Dokumentation von mare_crisium weiter vorn im Thread.

Code:

/* ################################################### 27.09.08 - TurnAlgorithm.h --------------------------------------------------- Header File welche diverse Funktionen zum Berechnen der Drehung beinhaltet ################################################### */ #include <stdlib.h> #include <math.h> //PI mit 2 multipliziert (= 360°) #define PI_DOUBLE 6.283185307179586476925286766559 //PI mit 2 dividiert (= 90°) #define PI_HALF 1.5707963267948966192313216916398 // Benötigte Variablen zur Berechnung #define TURN_ALGO_ALPHA 0.0336681 //Benötigter Wert zum Umrechnen von Ticks in mm #define TURN_ALGO_DIST 62.6 //Abstand zwischen Maussensor-Messpunkt und Roboter-Mittelpunkt in mm #define TURN_ALGO_MOUSE_ANGLE -1.62187951 //Fehlausrichtungswinkel der x-Richtung der Maus zur Längsachse des Roboters im Bogenmaß #define TURN_ALGO_COS_MOUSE_ANGLE -0.05106097 //cos(TURN_ALGO_MOUSE_ANGLE) #define TURN_ALGO_SIN_MOUSE_ANGLE -0.99869554 //sin(TURN_ALGO_MOUSE_ANGLE) /** * Initialisiert die Variablen, welche benötigt werden, um die Drehung zu berechnen * @param CurrX Beinhaltet die aktuelle X-Position des Sensors * @param CurrY Beinhaltet die aktuelle X-Position des Sensors * @param LastX Pointer auf die Variable mit der letzten X-Koordinate (übergabe an Funktion TurnAlgo_update) * @param LastY Pointer auf die Variable mit der letzten Y-Koordinate (übergabe an Funktion TurnAlgo_update) * @param Last_e_p_norm_x Pointer auf die Variable mit dem letzten Wert von e_p (normiert) x (übergabe an Funktion TurnAlgo_update) * @param Last_e_p_norm_y Pointer auf die Variable mit dem letzten Wert von e_p (normiert) x (übergabe an Funktion TurnAlgo_update) * @param Last_e_q_norm_x Pointer auf die Variable mit dem letzten Wert von e_q (normiert) x (übergabe an Funktion TurnAlgo_update) * @param Last_e_q_norm_y Pointer auf die Variable mit dem letzten Wert von e_q (normiert) y (übergabe an Funktion TurnAlgo_update) * @param turnAngle Pointer auf die Variable welche den Winkel beinhalten wird (übergabe an Funktion TurnAlgo_update) * */ void TurnAlgo_init(int CurrX, int CurrY, int *LastX, int *LastY, double *Last_e_p_norm_x, double *Last_e_p_norm_y, double *Last_e_q_norm_x, double *Last_e_q_norm_y, double *turnAngle) { *LastX = CurrX; *LastY = CurrY; *Last_e_p_norm_x = 1.0; *Last_e_p_norm_y = 0.0; *Last_e_q_norm_x = 0.0; *Last_e_q_norm_y = 0.0; *turnAngle = 0.0; } /** * Wird nach jeder kurzen Drehung aufgerufen, um den neuen Winkel zu berechnen * @param CurrX Beinhaltet die aktuelle X-Position des Sensors * @param CurrY Beinhaltet die aktuelle X-Position des Sensors * @param LastX Pointer auf die Variable mit der letzten X-Koordinate (übergabe an Funktion TurnAlgo_update) * @param LastY Pointer auf die Variable mit der letzten Y-Koordinate (übergabe an Funktion TurnAlgo_update) * @param Last_e_p_norm_x Pointer auf die Variable mit dem letzten Wert von e_p (normiert) x (übergabe an Funktion TurnAlgo_update) * @param Last_e_p_norm_y Pointer auf die Variable mit dem letzten Wert von e_p (normiert) x (übergabe an Funktion TurnAlgo_update) * @param Last_e_q_norm_x Pointer auf die Variable mit dem letzten Wert von e_q (normiert) x (übergabe an Funktion TurnAlgo_update) * @param Last_e_q_norm_y Pointer auf die Variable mit dem letzten Wert von e_q (normiert) y (übergabe an Funktion TurnAlgo_update) * @param turnAngle Pointer auf die Variable welche den Winkel beinhalten wird (übergabe an Funktion TurnAlgo_update) * */ void TurnAlgo_update(int CurrX, int CurrY, int *LastX, int *LastY, double *Last_e_p_norm_x, double *Last_e_p_norm_y, double *Last_e_q_norm_x, double *Last_e_q_norm_y, double *turnAngle) { double delta_x = (CurrX - (*LastX)) * (double)TURN_ALGO_ALPHA; //Delta X in mm double delta_y = (CurrY - (*LastY)) * (double)TURN_ALGO_ALPHA; //Delta Y in mm double delta_y_norm = delta_x * (double)TURN_ALGO_SIN_MOUSE_ANGLE + delta_y * (double)TURN_ALGO_COS_MOUSE_ANGLE; //Delta Y in mm mit berücksichtigung der Fehlausrichtung double delta_angle = delta_y_norm / (double)TURN_ALGO_DIST; double e_p_not_norm_x = (*Last_e_p_norm_x) + delta_angle * (*Last_e_q_norm_x); //e_p (nicht normiert) x double e_p_not_norm_y = (*Last_e_p_norm_y) + delta_angle * (*Last_e_q_norm_y); //e_p (nicht normiert) y double e_p_not_norm_sum = sqrt(pow(e_p_not_norm_x,2) + pow(e_p_not_norm_y,2)); //Betrag von e_p (nicht normiert) double curr_e_p_norm_x = e_p_not_norm_x/e_p_not_norm_sum; double curr_e_p_norm_y = e_p_not_norm_y/e_p_not_norm_sum; *LastX = CurrX; *LastY = CurrY; *Last_e_p_norm_x = curr_e_p_norm_x; *Last_e_p_norm_y = curr_e_p_norm_y; *Last_e_q_norm_x = e_p_not_norm_y * (-1); *Last_e_q_norm_y = e_p_not_norm_x; *turnAngle = atan2(curr_e_p_norm_y, curr_e_p_norm_x) * (-1); //Winkel im bereich von [-179,179] if (*turnAngle < 0) *turnAngle = PI_DOUBLE + *turnAngle; }

Ich habe das alles so realisiert, dass der Drehfunktion die Variablen der Vorherigen dreh-berechnung als Pointer übergeben werden.

In der TurnRobot funktion kann ich einfach einen Winkel übergeben, zu dem hingedreht werden soll, also nicht, um wieviel gedreht wird. Würde man der Funktion zu umschreiben, dass man übergibt, um wie viel gedreht wird, dann wäre die Fehlerwahrscheinlichkeit sehr viel höher.
Man kann auch mal einfach Geradeaus fahren, und danach Drehen. Die absolute Winkelangabe sollte dann trozdem funktionieren.

Ein Aufruf könnte dann wie folgt aussehen

Code:

int TurnAlgo_LastX; int TurnAlgo_LastY; double TurnAlgo_Last_e_p_norm_x; double TurnAlgo_Last_e_p_norm_y; double TurnAlgo_Last_e_q_norm_x; double TurnAlgo_Last_e_q_norm_y; double TurnAlgo_currAngle; // -------------- Main-Funktion -------------- int main(void) { /*###Initialisierungsphase###*/ // ... eigene Initialisierungen TurnAlgo_init(0, 0, &TurnAlgo_LastX, &TurnAlgo_LastY, &TurnAlgo_Last_e_p_norm_x, &TurnAlgo_Last_e_p_norm_y, &TurnAlgo_Last_e_q_norm_x, &TurnAlgo_Last_e_q_norm_y, &currAngle); while(1) { //Hauptschleife } } /** *Dreht den Roboter zum angegebenen Winkel * @param degree Grad, auf die gedreht werden soll */ void turnRobot(int endDegree) { int startPos_X, startPos_Y; pan_getPos(&startPos_X, &startPos_Y); TurnAlgo_update(startPos_X, startPos_Y, &TurnAlgo_LastX, &TurnAlgo_LastY, &TurnAlgo_Last_e_p_norm_x, &TurnAlgo_Last_e_p_norm_y, &TurnAlgo_Last_e_q_norm_x, &TurnAlgo_Last_e_q_norm_y, &TurnAlgo_currAngle); double startAngle = TurnAlgo_currAngle; double endAngle = (M_PI * endDegree) / 180.0; //Winkel in Bereich von 0 bis 360° (= PI_DOUBLE) umrechnen while (endAngle >= PI_DOUBLE) endAngle -= PI_DOUBLE; while (endAngle <0) endAngle += PI_DOUBLE; double diff = endAngle - TurnAlgo_currAngle; //Gibt an, ob sich der Roboter gegen den Uhrzeiger (mathematischer Drehsinn) = 0 oder mit dem Urhzeiger = 1 dreht int turnDirection = 0; //Überprüfung, ob Differenz mehr als 180° (= PI), wenn ja, andere Drehrichtung verwenden, da dort der Weg kürzer ist. if (diff > M_PI) { turnDirection = 1; diff -=PI_DOUBLE; } else if (diff < M_PI*(-1)) { turnDirection = 0; diff +=PI_DOUBLE; } else if (diff > 0) turnDirection = 0; else if (diff < 0) turnDirection = 1; else { return; //Nothing to do } int speedL; int speedR; if (turnDirection == 0) //Drehrichtung = 0 { speedL = -245; speedR = 255; } else if (turnDirection == 1) //Drehrichtung = 1 { speedL = 255; speedR = -245; } int newPos_X, newPos_Y; //Schleife wird auch innerhalb unterbrochen, sobald der endAngle erreicht ist while (startAngle!=endAngle) { moveRobot(speedL, speedR, 3); pan_getPos(&newPos_X, &newPos_Y); TurnAlgo_update(newPos_X, newPos_Y, &TurnAlgo_LastX, &TurnAlgo_LastY, &TurnAlgo_Last_e_p_norm_x, &TurnAlgo_Last_e_p_norm_y, &TurnAlgo_Last_e_q_norm_x, &TurnAlgo_Last_e_q_norm_y, &TurnAlgo_currAngle); if (TurnAlgo_currAngle == endAngle) break; if (turnDirection == 0) { if ((startAngle < endAngle) && (TurnAlgo_currAngle >= endAngle)) break; //Beim startWinkel 170° abziehen, da es vorkommen kann, dass der TurnAlgo_currAngle den Winkel 259° anstatt 0° hat und dann unterbrochen werden würde else if ((startAngle > endAngle) && (TurnAlgo_currAngle >= endAngle) && (TurnAlgo_currAngle < startAngle - 2.9670597283903602807702743064306)) //Bereich liegt über dem 4. und 1. Quartal break; } else if (turnDirection == 1) { if ((startAngle > endAngle) && ((TurnAlgo_currAngle <= endAngle) || (TurnAlgo_currAngle > endAngle + M_PI))) break; //Beim startWinkel 170° addieren, da es vorkommen kann, dass der TurnAlgo_currAngle den Winkel 1° anstatt 0° hat und dann unterbrochen werden würde else if ((startAngle < endAngle) && (TurnAlgo_currAngle <= endAngle) && (TurnAlgo_currAngle > startAngle + 2.9670597283903602807702743064306)) //Bereich liegt über dem 4. und 1. Quartal break; } } }

Danke an alle die mitgeholfen haben.

Edit: Code verbessert

Edit 2 (Dez. 2014): PDF von mare_crisium zur Berechnung erneut hochgeladen: (siehe post #62):
https://www.roboternetz.de/community...l=1#post609113

PRobot,

prima :-) ! Beim Durchsehen des Algorithmus (mit beschränkten C-Kenntnissen) ist mir nur aufgefallen, dass Du e_q_norm_y mit 0.0 initialisierst; der Startwert muss aber 1.0 sein.

Auf die Variablen e_q_norm_x und e_q_norm_y kannst Du ganz verzichten, wenn Du schreibst

double e_p_not_norm_x = (*Last_e_p_norm_x) - delta_angle*(*Last_e_p_norm_y)
double e_p_not_norm_y = (*Last_e_p_norm_y) + delta_angle*(*Last_e_p_norm_x)

Das ist eine mögliche, aber keine notwendige Vereinfachung des Programms.

Freut mich, dass Du's hingekriegt hast. Berichte 'mal über die Testfahrten!

Ciao,

mare_crisium

Edit: Fehler in Formel für e_p_not_norm_y korrigiert: Zeiger (*Last_e_p_norm_x) durch Zeiger (*Last_e_p_norm_y) ersetzt (Danke, für den Hinweis, SternThaler :-) !

Guten Morgen zusammen.

@mare_crisium
e_q_norm_y mit 0.0 oder 1.0 initialisieren?
Ich kann diese Variablen nicht finden? Meinst du die Variable Last_e_q_norm_y, die in der Funktion TurnAlgo_init() auf 0.0 gesetzt wird?

Falls dein Vorschlag mit der Vereinfachung oben im Programm von PRobot schon enthalten ist, dann ist dort ein Unterschied zu deinem Vorschlag:
Du mare_crisium schreibst:
double e_p_not_norm_x = (*Last_e_p_norm_x) - delta_angle*(*Last_e_p_norm_y)
Gefunden bei PRobot habe ich:
double e_p_not_norm_x = (*Last_e_p_norm_x) + delta_angle * (*Last_e_q_norm_x)

Und auch bei "double e_p_not_norm_y = ..." finde ich einen Unterschied.

Ansonsten kann ich der Mathematik (leider) nicht mehr folgen.
Nur bei deinen im letzten Post angegeben Excel-Diagramme bekomme ich in den Kopf, dass es sich um wunderbare Halbkreise handelt ;-). Jubel, habt ihr gut gemacht.

Lasst euch bloß nicht von meinem Geschreibsel stören. Wahrscheinlich ist das sowieso nicht relevant.
Gruß Sternthaler

Zitat:

Lasst euch bloß nicht von meinem Geschreibsel stören.

Ist doch immer wieder nett etwas von dir zu lesen :)

Einen schönen Sonntagmorgen!
@ SternThaler,

Ihr habt zwar noch Oktoberfest, aber deshalb musst Du Deine Mathekenntnisse nicht gleich unter die Moass stellen!

Deine erste Anmerkung ist richtig: Ich meine "Last_e_q_norm_y".

Der zweite Unterschied, den Du bemerkt hast, ist genau die Vereinfachung, die ich vorschlagen wollte: e_q_norm_x ist gleich (-1)*e_p_norm_y und e_q_norm_y ist e_p_norm_x. Erinnerst Du Dich: Das ist der Trick, mit dem man einen Vektor um +90° drehen kann ;-). PRobot hat den Vorschlag noch nicht eingearbeitet.

Zitat:

Zitat von Sternthaler

Ansonsten kann ich der Mathematik (leider) nicht mehr folgen.

Na, damit Du wieder Mut schöpfst, hänge eine neue Version des Algorithmus an, in der ich versucht habe, die Sache mit ein paar zusätzlichen Zeichnungen verständlicher zu machen.

@ radbruch:
Gönn' doch dem armen Haifisch auch mal ein Erfolgserlebnis!!

Ciao,

mare_crisium

Edit: Anhang gelöscht wg. Upload-Quota

hoi,
also beim letzten bild stimmt irgendwas net ganz. sonst hab ich des ganze net wirklich durchgelesen. aber da es funktioniert scheint es au zu stimmen ;-)
mfg jeffrey

jeffrey,

danke für den Hinweis. Hab's ausgebessert.

mare_crisium

Liste der Anhänge anzeigen (Anzahl: 1)

Hai zusammen. (Wenn er denn mal was zu futtern bekommt? Ha, ha, ha.)

@radbruch: Lass bitte, bitte den armen Smilie leben. Für den Hai spende ich mal ne Makrele.
Und hier kann man sehen, dass die Beiden Freunde sind (so passiert auch der Makrele nix.): http://www.taucher.net/edb/Embudu_Vi...Atoll_b63.html
(ca. 1/4 der Seite scrollen)

Jetzt weiß ich wenigstens, warum ich dem Ganzen wohl nicht folgen konnte.
Liegt vor allem nicht am Oktoberfest, da ich etwas weiter nördlich, recht dicht beim Liborifest, zu finden bin. Wir trinken hier Bier nicht im Moass, sondern in Massen ;-). Und am Samstag war es aber mal wieder Wein mit Freunden.

Mathe, und 90°-Drehung:
Gut, dass du mare_crisium, noch mal deinen Koppelnavigations-Algorithmus mitschickst. Ich bin mir recht sicher, dass es sich bei deinem Vorschlag um die Formel (2.7) handeln müsste.
Dann aber sollte doch die Berechnung bei deinem Vorschlag zum Ermitteln von e_p_not_norm_y mit:
double e_p_not_norm_y = (*Last_e_p_norm_y) + delta_angle*(*Last_e_p_norm_x)
erfolgen? Oder etwas doch nicht?
Seht ihr nun warum ich lieber auf die Wiesen gehen sollte? Ich kann nämlich nur bei euch nachlesen was ihr so tolles macht, es aber nicht selber nachrechnen, so dass am Ende eben nur merkwürdige Hinweise kommen können. Die gebe ich euch natürlich auch dann in Moassen, selbst wenn ihr nicht danach fragt ;-).

Einen ruhigen, erfolgreichen Wochenbeginn wünscht euch
Sternthaler

Guten Morgen, zusammen!

@Tierfreund SternThaler:
hast recht: Es ist Formel (2.7) und den Fehler im alten Posting habe ich korrigiert.

Wohnst Du wirklich in der Nähe von London? (London Interbank Borrowing Rate - Fest???)

Ciao,

mare_crisium

Na, wer ist denn noch alles wach?

@LustigeIdeen-mare_crisium
Ne, ab übermorgen nicht mehr. Nachdem ich einen Teil der letzten Überweisung einer Deu.Bank (KxW, oder so ähnlich) aus u s a habe umleiten können, werde ich nun auf so eine kleine Insel umziehen. Dort kann man hervorragend Fische und Smilies beobachten ;-)

Nun aber erst einmal ein: Gute Nacht
Sternthaler

Zitat:

Zitat von Sternthaler

... Wir trinken hier Bier nicht im Moass, sondern in Massen ...

Hmmmmmm, grübelgrübel: vermutlich nicht ausm Moass, klar, da ist ja auch kein ganzer Liter drin, laut Aussage eines unbedeutenden Lokalpolitikers - der wohl andauernd zumindest gegen das Eichgesetz verstößt. Ohhh - Lokalpolitiker - das hat ja ein paar hübsche Nebenbedeutungen (Lokal = Wirtschaft/Alk-ausschank) . . . . oder sind das dann die Hauptbedeutungen . . . . und ich hab´s nur bisher nicht gerafft ! ? ! ? ! !

... sondern in Massen: also trinken zu hunderten Leuten, die beieinander sitzen und sich zum Kom.saufen animieren? Oder ihr trinkt das Bier einfach massenhaft?

Dazu diese Anmerkung (ist ja sowieso schon alles OT):
Nordlich zum Bayern: Nu sajen sie mal, Mann, wat trinken sie denn so viel Bier? Bayer: Jo woils mir holt schmeckd! Nordlicht: Also ich trinke nur soviel, wie ich Durst habe. Bayer: Grod wia d`Viechar.

Zitat:

Zitat von Sternthaler

... merkwürdige Hinweise ... selbst wenn ihr nicht danach fragt ...

Das erinnert mich total an unbedeutende und auch bedeutende Lokal- und sonstige Politiker. Die reden auch immer ungefragt - das ging ja noch - aber unquali . . . . ok, ich hör auf.

Liste der Anhänge anzeigen (Anzahl: 1)

Hier für die Nachwelt gesichert, die PDF von mare_crisium. Viel Spaß!!

Vielen Dank! Super, dass du die PDF nach 6 Jahren noch gefunden hast..