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