Arcsin Calculation Algorithm

[Leo M]

NOW we're getting a discussion going!

I agree completely with Dr. Joe - TIME is of the essence in these competitions. Any engineering project depends on control of all four of these aspects - methods, materials, money, and people. With time = money (or resources - CPU time, cash, space, etc.), it is impossible to succeed if too much of a limited resource is expended in non-productive ways.

That being said, maybe it would be an interesting intellectual exercise (it being October, and the new game being two months away) to look at whether this algorithm CAN be implemented, and HOW it could be done. Then each team can decide on whether it is worth their while to do it?

First, let me point out that Newton's Method does not employ any series expansions - that would be out of the question for arcsin calculations!

I did a quick test to see how many loops it would take for the algorithm to converge at different values of the sine from -1 to +1.

At +/- 1, four loops got to within 0.001 of the exact value of the angle, and ten loops to within 1E-6.
At +/- 0.7, two loops converged within 2E-5.
Near zero, the algorithm converges to very nearly the exact value after the first loop (as one would expect).

A value within 0.001 is going to be close enough in any competition - maybe too close. What mechanism is anyone going to devise that needs more accuracy than that? You could implement a version that just goes through twice, calls it done, and still gets very close to the mark each time. I don't know what is involved with the lookup function in terms of CPU usage, and how it would compare to a two-loop calculation.

Now for the real fun part - how Pbasic implements the sine and cosine functions. According to the BASIC Stamp Programming Manual 2.0c, the SIN and COS operators use a method that is a little unusual - at least to me. These operators take an argument not in degrees or radians, but in "binary radians", sometimes known as "brads". That is, they break the circle into 0 to 255 units (brads), each equivalent to 1.406 degrees. So, the argument passed to the SIN function is an angle in brads, expressed as an integer from 0 to 255.

The value returned by the function is based not on a unit circle like the ordinary sine value in our calculators, but on a circle of radius 127. We see that number a lot in this language, don't we? The results are given in two's complement form to accommodate negative values. The functions return integer values from -127 to +127.

So, at zero degrees we get sin(0 brads) = 0; at 45 degrees we have sin(32 brads) = 90. At 90 degrees, sin(64 brads) = 127; at 180 degrees, sin(128 brads) = 0; and at 270 degrees, sin (192 brads) = -127.

Brads X (180/128) = degrees & degrees X (128/180) = brads.

Now, whether it is worth implementing this method is something else again. It looks like it will work, but that is only 1/4 of the overall engineering problem. Does your team have the people necessary to do it, the time to get it done, the design that can benefit from it? I don't know - you tell me.

But, don't you think the mental exercise is beneficial? There's a lot to this problem, and a successful implementation would be, if nothing else, satisfying to the person who actually accomplished it. That's part of the FIRST experience too, is it not?

This is only my very humble opinion. If you actually want to build a robot that gets out on the field in time, follow Dr. Joe's advice. But, if you are looking for some worthy intellectual opponent during the off-season, give this one a try.......

Again, let me know how it goes, and good luck.