Cartesian to angle

[jhersh]

Floating point operations are not done in the FPGA on cRIO, they are done in the PPC core's FPU. You can look at the details for it here: http://cache.freescale.com/files/32b...e300coreRM.pdf

Edit: FP instructions are in section 3.2.4.2 (pg 119).

[ajd]

Why would you want atan2(0,0) to return 0, as opposed to any other value? If your point is at the origin, the line between the origin and your point could point in any direction. What is the use case for atan2(0,0) = 0 being helpful?

[Jared Russell]

Originally Posted by jhersh

Floating point operations are not done in the FPGA on cRIO, they are done in the PPC core's FPU. You can look at the details for it here: http://cache.freescale.com/files/32b...e300coreRM.pdf

Edit: FP instructions are in section 3.2.4.2 (pg 119).

Joe,

Thanks for the link to this document! For those interested, the latency (in cycles) of each instruction on the PPC is listed starting on page 300 (section 7.7). Hopefully this can be a tool to help settle arguments in the future.

[Ether]

Originally Posted by jhersh

Floating point operations ... are done in the PPC core's FPU. You can look at the details for it here: http://cache.freescale.com/files/32b...e300coreRM.pdf

Edit: FP instructions are in section 3.2.4.2 (pg 119).

Thanks for the link Joe.

Using two fmadds instructions¹, at one cycle each², you can get arctangent(x) in the first octant accurate to +/- 0.25 degrees. Pretty tough to beat with a lookup table.

Wrap 3 compares, 1 divide, and 1 more add around that, and you've got atan2(y,x) accurate to +/- 0.25 degrees good for all four quadrants.



¹Para 3.2.4.2.2 Table 3-9

²Para 1.1

[Ether]

atan2(x,y) gives +/-pi clockwise from the +Y axis. That puts the discontinuity on the -Y axis, which then requires you to add conditional logic to fix it. There's a better way.


BTW, concerning atan2(0,0), many modern implementations, such as the microcode in the FP unit of the Pentium*, helpfully return zero when both arguments are zero. Does anyone know what the FRC versions of LabVIEW, C++, and Java do?


* here's a short test code written in Delphi:

USES windows, sysutils;


Function FPatan2(y : extended; x : extended): Extended;
Assembler;
asm fld [y] ; fld [x] ; fpatan end ;


BEGIN

write(FPatan2(0,0),' Pentium FP processor built-in microcode');

END.

[Aren Siekmeier]

Originally Posted by Ether

Does anyone know what the FRC versions of LabVIEW, C++, and Java do?

I'm pretty sure LabVIEW has two different atan commands in its Math/Trig library (which I believe is supported on the cRio). The first takes a float which should be your y/x value, and then spits out theta on the interval (+pi/2, -pi/2) relative to +X (note the inability to deal with infinite slope, one of the problems avoided by the other command). The other takes an x and a y separately, then does all the logic for you to return theta on the interval [0,2pi) from +X. To find the angle from +Y, you can subtract 90 (careful of wrapping, if it matters), or feed y in for x and -x in for y (the second one is waaaaay better).

Edit: Theta is counter-clockwise from reference point, of course. All x and y inputs are on [-1, 1] as one would expect on a unit circle.

Edit: And now I see that you asked for clockwise from +Y. Simply flip your inputs around the y-axis: give it y for x and +x for y.

[Aren Siekmeier]

In theory, this two parameter atan calculation only needs to do the following:

Take the arc cosine of x, which is on [-1, 1] to get theta on [0, pi], via whatever method is effective (lookup table, polynomial approximation, etc.) If y is less than 0, subtract theta from 2pi. Done. Theta is on the interval [0, 2pi), counterclockwise from the positive x-axis.

Then you swap inputs as outlined above to get the special, non conventional stuff the OP is asking for. This effectively flips the whole situation about y=x, which is equivalent to the relationship between his question and convention.

[Ether]

Originally Posted by compwiztobe

I'm pretty sure LabVIEW has two different atan commands in its Math/Trig library (which I believe is supported on the cRio). The first takes a float which should be your y/x value, and then spits out theta on the interval (+pi/2, -pi/2) relative to +X (note the inability to deal with infinite slope, one of the problems avoided by the other command). The other takes an x and a y separately, then does all the logic for you to return theta on the interval [0,2pi) from +X.

Two things:

1) The question was asked in the context of the handling of atan2(0,0) for FRC. The answer, for LabVIEW, is that it returns 0, at least according to the simple test I ran on a desktop PC (not in a cRIO). Not being a LabVIEW guru, I don't know if it sets any error flags which might have side effects elsewhere. Does anyone know what the FRC versions of C++ and Java do when running on cRIO?

2) LabVIEW atan2 does not return [0,2pi). It returns an answer in the range (-pi..pi] (not surprisingly).

Originally Posted by compwiztobe

Take the arc cosine of x,

You are given arbitrary (x,y). So you must take the arc cosine of x/sqrt(x²+y²). Not that it matters for purposes of FRC, but numerically that is inferior to a properly implemented atan2(y,x) (and also suffers from the 0,0 problem). Also, since the sign of y is lost in the squaring operation, additional conditional logic is necessary to get the desired range.

[Greg McKaskle]

There were a number of questions raised. I'll respond to the ones I remember.

What is atan2 of 0 and 0. In LabVIEW, it is 0, at least on an Intel mac. I don't have a cRIO in front of me. I hope/suspect that the PPC LV will return the same, but since I don't have the LV test suite in front of me to prove that is a tested result, I'll speculate that it returns zero. The applied mathematicians on the LV team tend to be picky about things like that, so they have test suites that enforce the results across platforms. Can someone test for sure?

What does the FPGA do? Is it Intel? It is not Intel, and it doesn't natively do FPU operations. It is a field programmable gate array, a bunch of low level logic operations. In order for it to do an integer addition, an adder has to be constructed in it. If you also wish to multiply, a multiplier has to be constructed. The results of those operations are determined by the adder or multiplier you emit to the FPGA. The FPGA image used for FRC contains no floating point trig operations, and in fact I doubt it contains any floating point operations at all as they consume gates very quickly.

Which is faster/better, the atan2 operation, or a lookup table? I have my suspicion/opinion, but this is the sort of thing where the actual answer is ... it depends. Rather than take someone's answer, the approach I'd encourage you to take is to implement both and learn the magnitude of the operations involved. If the lookup table is pretty fast, what if you interpolate for more precision. My point is that knowing A is faster than B is useful info, but more useful is to know the rest of the tradeoffs, and to know how much faster and why.

Greg McKaskle