Hallo, Es geht um die Genauigkeit von Cordic(4.0) arc tan.(Xilinx ISE14.7) Hat da jemand im Forum bereits Erfahrungen damit? folgendes Problem : Der Input in das Cordic ArcTan ist wie Folgt: Ein Beispiel : Y/X :501/2999 = 0.16705568523 = tg(a) Der Input X_in(25:0) soll dann 1.0 sein d.h als 1Q26 : 01000000000000000000000000 Der Input Y_in(25:0) Als 1Q26 skaliert 0.16705568523= 00101010110001000011000000 Dies ergibt den Resultat am ArcTan als 2Q26 : a= 00010010110110011011110001 = 0.1472697556 rad = 8.43798014118 Grad Gemäss HP Taschnrechner sollte der Resultat aber 9.57158570725 Grad sein dies ist eine ziemliche Differenz. Bei anderen Werten Richtung 45 Grad wird die Differenz kleiner, bei 45 Grad ist der fehler=0. Bei Winkeln nahe bei 0 Grad ist die Resultat-differenz jedoch sehr gross. Eine Aenderung der div. Parameter: max pipelining,No pipelining,Iteration usw.hat kein Einfluss auf den Resultat. Ich habe das selbe auch mit Cordic(5.0) probiert , => Resutat ist gleich. Ist das Problem bekannt ? Ist das ArcTan im Cordic (IP-xilinx) unbrauchbar ? was gibt es für Alternativen ? Meine Anwendung : Inverse Transformation von XYZ auf 5 Achsen eines Knickarm-Roboters.
Anton Kurka schrieb: > Ist das Problem bekannt? Ja. Je weiter man in den Randbereich kommt, desto größer wird der Fehler. > Ist das ArcTan im Cordic (IP-xilinx) unbrauchbar? Für Deine Anwendung vielleicht, aber prinzipiell nein. > was gibt es für Alternativen? Selber schreiben? Duke
Hallo Duke Danke für die klare Antwort. 9.57 Grad ist nicht ganz der Randbereich,aber bereits hier macht es 11.7% Abweichung, kann es so viel sein ? Also das heisst, Polynominal Approximation im VHDL,"viel Vergnügen" erwartet mich in dem Fall !! Oder Look-up Tabelle ? Gruss Anton
Anton Kurka schrieb: > Es geht um die Genauigkeit von Cordic(4.0) arc tan Cordic ist gut bei sin und vos, aber schlecht bei arctan https://www.convict.lu/Jeunes/Math/arctan.htm
Anton Kurka schrieb: > Also das heisst, Polynominal Approximation im VHDL,"viel Vergnügen" > erwartet mich in dem Fall !! Das lässt sich aber schön nach dem Horner-Schema in einer Schleife abhandeln. Koeffizienten gibts bei Matlab, nehme ich mal an. Ich bin ja schon so alt, dass ich mir meine Koeffizienten noch immer aus dem Buch "Computer Approximations" von Hart et al hole. Hier als Beispiel der Forth-Code, mit dem ich gemäß "Hart 3341" den Sinus bestimme mit 27 bit precision, pi/2 > frac >= 0 und 1 = 2**(cell_width-2):
1 | : sin ( ufrac --- usin ) |
2 | [ &000151485 -&004673767 + &079689679 + -&645963711 + &1570796318 + 2* scale-factor ] |
3 | dup >r ( ufrac auf den Returnstack ) |
4 | dup *. >r ( ufrac**2 auf den Returnstack ) |
5 | [ &000151485 scaled ] Literal r@ *. |
6 | [ -&004673767 scaled ] Literal + r@ *. |
7 | [ &079689679 scaled ] Literal + r@ *. |
8 | [ -&645963711 scaled ] Literal + r> *. |
9 | [ &1570796318 scaled ] Literal + r> *. |
10 | ; |
Das *. ist Erklärungsbedürftig: Es multipliziert 2 Zahlen und liefert den höherwertigen Teil des Produkts zurück. Das lässt sich ziemlich geradeaus in VHDL transkribieren. Und das Scaling der Koeffizienten muss man halt offline machen. Es wird so gescaled, dass bei pi/2 wirklich 1 herauskommt.
:
Bearbeitet durch User
also bei mir sind 00010010110110011011110001 = 11210944 (11210944 / 2^26) *180/pi = 9.57160853680243
Anton Kurka schrieb: > Dies ergibt den Resultat am ArcTan als 2Q26 : a= > 00010010110110011011110001 Wo sitzt denn da der Dezimalpunkt? Soll das 00.010010110110011011110001 sein oder doch 0.00010010110110011011110001 Anton Kurka schrieb: > 2Q26 : a= > 00010010110110011011110001 = 0.1472697556 Das passt wenn du den Dezimalpunkt so gesetzt hast: 0.0010010110110011011110001 Das würde ich aber als 1Q25 bezeichnen.
Aha, das ist: The output angle, Pout radians, is expressed as a fixed-point twos complement number with an integer width of 3 bits (2QN format). Was ich daran seltsam finde ist, dass sonst bei aQb das a angibt wie viele Bits Integer das sind. Aber gut, hier wurde das Vorzeichen wohl zu den Integerbits gezählt. Und dann gibt es noch die Notation als Qa.b , wieso einen Standard wenn man auch viele haben kann? Wie wandelt man das denn in Dezimal um? Lua schrieb: > 00010010110110011011110001 = 11210944 Das verstehe ich nicht.
Konnte man da nicht irgend etwas mit X und Y veranstalten, um es genauer oder einfacher zu machen? Der ARCTAN ist doch in 2 Achsen symmetrisch. Ist das bei dem CORE schon berücksichtigt? Gfs. liesse sich das Rechentempo steigern, wenn man das per Hand löst und dies in Genauigkeit investieren? CORDIC ist dafür bekannt, dass es teilweise lange iterieren muss und sehr genaue Tabellen braucht, wenn es funktionieren soll.
Hallo Klaus Besten Dank für die Ausführliche Antwort. Sorry,ich war jetzt lange Zeit mit anderen Problemen beschäftigt sa habe ich gar nicht gemerkt das da ganze Menge Antworten auf mein Forum Beitrag.Nun werde ich gern die" Computer Approximations" anschauen. Ich habe verschiedene Aproximations verfahren ausprobiert : Hier das Resultat :Resultate als Comment ...... X = 0.166666666666; //float, Beispiel: X=501 /Y=2999 X9 = pow(X,9); X11 = pow(X,11); // usw. } void calc(){ atang1= Pidiv4 * X - X*(X -1)*(0.2447 + 0.0663* X);// =0.166420534253 atang2= 0.141499*X4 -0.343315*X3 -0.016224*X2 +1.003839*X -0.000158; // =0.165217608213 atang3= X - X3/3 + X5/5 - X7/7;// =0.165148675442, Taylor Aprox. atang4= X - X3/3 + X5/5 - X7/7 + X9/9;// =0.165148690343 atang5= X - X3/3 + X5/5 - X7/7 + X9/9 - X11/11;// =0.165148690343 } Richtige Resultat? :0.16514867740814, die Frage ist wie Genau rechnen die online Rechner ? Auffalend ist das Atang3 besser ist als Atang5, wie ist das zu erklären ? Es sollte doch mit steigende "Order" genauer sein und nicht schlechter ?
Hallo, Ja , beim Cordic aTan sind natürlich X Y Eingänge, die aber im Bereich max +/-1 sein müssen. Deshalb wird es beim Z.Bsp X=3000, Y =500 ergibt 500/ 30000 = 0.16666666 das ergibt den Wert für Y, für X=1.Beim überschreiten von 45 Grad müssen die X Y Werte vertauscht werden und Resultat + Pi/4 setzen, input im 1Qn Format, output in 2Qn. Das Problem von Xilinx Cordic 4,0 und auch 5.0 ist die sehr schlechte Genauigkeit bei Werten nahe 0.Ich suche immer noch nach möglich einfache Approximation mit Genauigkeit von mindestens 10^-10.
Hallo Klaus leider habe ich niergens das Buch gefunden, wie müssen die Koeff sein für arcTang ? Kannst Du mir helfen Bitte ?
Anton Kurka schrieb: > Hallo Klaus > leider habe ich niergens das Buch gefunden, wie müssen die Koeff sein > für > arcTang ? Kannst Du mir helfen Bitte ? Er meint vermutlich das hier: https://www.amazon.de/Computer-Approximations-Hart-JF-al/dp/0471356301 /regards
:
Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.