FWIW, I just saw the following message on the BasicStamps list. I’m guessing that ARCTAN is new with the Beta version of the editor. How many of you would have used this this year if you had know about it?
As I often remind list users … you should download the data sheet for the
Memsic device. The calculation of angle using both axis of the 2125 is comes
directly from Memsic data. It works because the PBASIC ArcTan function
returns a vector angle for a line that extends from 0, 0 to X, Y – the
Memsic 2125 returns X and Y in g-force (that’s why both sensors are
required). Since the sensor returns positive and negative g force values,
all quadrants of a circle can be covered.
To be fair, ArcTan was not previously documented but is included in the new
PBASIC Help File that will be provided with the compiler update that will be
out soon. Since we’re discussing it though, ArcTan returns Brads (0 - 255),
not degrees, so a conversion to degrees is required.
Do they download a table if you use this function? Do they use some of the clever approximation techniques we have discussed on these forums?
I can see how they can add IF-THEN-ELSE because they already had all the stuff in the ROM mask to do it, they just needed their compiler to actually do it. Somehow adding new functions (especially a pretty complicated function like ARCTAN) seems more of a stretch.
I am very curious.
As to your question, Yes, I think I might have used it. Not on our RC Stamp2 but on the Stamp2 we had on our auxiliary board – our Virtual Compass board. It could have been very useful.
It’s actually for a dual-axis accelerometer manufactured by Memsic but made by parallax. The source code is at the bottom of the page. It’s the last thing in the “Dual.bs2” source file.
arctangent
'The arctangent uses the vectoring algorithm, where the value of
'y instead of z is driven to zero as a result of the decision in each
'time through the loop. That is, by driving the tangent of the angle
'to zero, we drive up the angle up to the value we want to find,
'given the initial tangent of that angle.
tans data word 32768 ' arctan 1
data word ..... ' arctan 1/2
data word ..... ' arctan 1/4
...
data word ..... ' arctan 1/32678
var x word ' accumulated x component (cos)
var x0 word ' a helper variable
var y word ' accumulated y component (sin)
var z word ' this will be the accumulated angle
var i nib ' loop counter
var A word ' angle read from tans table
ys var y.bit15
xs var x.bit15
zs var z.bit15
y=y0 ' we will compute the arctan
x=x0 ' based on tan theta = y0/x0
for i=0 to 15
read 2*i,A..byte0
read 2*i+1, A.byte1
x=x0 ' a copy of the current value of x
x0 = x + (-ys^(-ys^(abs y>>i) + ys)+ys)
y = y - (-ys^(-xs ^(abs x>>i) + xs)+ys)
z = z + (-ys^A+zs
next
donecalc:
x=x0
'The formula for x0 can doubtless be simplified by quite a bit, as it
'involves double negatives.
x0 = x + (-ys^(-ys^(abs y>>i) + ys)+ys)
^^^^^^^^^^^^^^^^^^^------divide the abs y by 2^i
and restore the sign
^^^^^^^^^^^^^^^^^^^^^^^^^^^^---and negate if y is negative
so the result is positive no matter what.:
x0 = x + (abs y>>i)
Note that you need to fill in the tans table when you write your code for the algoritm to calculate properly.
There is a Taylor series approximation for arctan out there that is nothing more than repeated multiplications, divisions, additions, and subtractions. That’s probably how they do it.
I don’t think they are doing a Taylor Series approximation, but they could be.
Taylor Series approximations are nice in theory but are not the best for rapid convergence which is what you want when computations cost you code space and computation time.
Anyway, I am still curious how Parallax actually pulled off this function.
A couple things I’ve learned (or deduced):[list=1][li]The editor DOES NOT download a lookup table into EEPROM. (I verified this by examining the memory map in the editor.)
[/li][li]My initial guess was incorrect that ATN is new with the 2.0 beta version of the editor. It IS supported in all currently available versions (both Windows and DOS) of the editor for all versions of the BASIC Stamp 2. (It is not supported by the DOS editor for the BS1.)
[/li][li]ATN is NOT implemented in the editor (other than that it knows how to tokenize it for the BASIC Stamp.) It IS implemented in the BASIC Stamp interpreter chip.
[/li][/list=1]I still don’t know HOW they implemented it… (But then why should I care as long as it works.:)) Joe, was your concern due to the fact that you thought it was implemented in the editor, and were therefore afraid that it would steal code space from you? If that’s not it, I’m curious why you’re not equally concerned about SIN and COS. Do you know of methods for calculating SIN and COS that are more efficient than any that you’re aware of for ATAN?
If the functions were available sin the ROM of a STAMP2 since Adam & Eve ate the apple, why have we been sufferring so long without it?
If it is a new function in the ROM, then how far back can I go on my controllers before the ATN function won’t work?
In 1998 we had our first type of swerve, I have retroactively fit a 2000 (the first year for IFI) controller on that robot. Can I use ATN on that STAMP2?
Don’t know.
I also am curious just because I am curious. Did they keep backward compatibility with older ROM’s OR did they keep down code space on the current systems OR are they very clever sheep and do both (perhaps they look at the ROM version, download a table if they have an older ROM and use a newly available tolkenized implementation if they have a newer ROM)?
That is the sum total of my reason for asking HOW.
To be fair,** ArcTan was not previously documented **but is included in the new
PBASIC Help File that will be provided with the compiler update that will be
out soon.
This seems to imply that the function has been around (not sure how long, but possibly always), but just wasn’t documented. If you want to know ‘why’ it wasn’t documented … well, I can offer a few conspiracy theories, but I don’t think they’ll help
As has been discussed before, the Stamp 2sx is basically just a glorified Ubicom SX microcontroller. The interesting thing about that is that the SX doesn’t include SIN or COS either, so something about the extra cicuitry included with the Stamp allows them to implement these things in very minimal program space (the ATN function doesn’t seem to take up much more space than a simple +). How exactly this works, I have no idea :).
*Originally posted by rbayer *
**How exactly this works, I have no idea :). **
It works like this: The BASIC Stamp has an interpreter chip (firmware in ROM) which the SX executes.The SX microcontroller interprets tokens in EEPROM by executing this interpreter firmware. The firmware contains instructions to calculate SIN and COS and ATN. The PBASIC program (in EEPROM) only needs to include a token, and the interpreter does the rest.
*Originally posted by Abwehr *
**Might there be an ATAN op-amp or PIC inside the RC? It would seem rather peculiar for there to be one, especially if it has not been documented…
Are there any identities to calculate ATAN based on other trig functions? I only know of applicable ones for hyperbolic arctangent.
My money is still on a Taylor series. **
Unfortunately, it will take a very large amount of terms for a Taylor Series to converge if your angle is far away from your starting point. After about the 3rd term the powers exceed the ability of the stamp.
Some of the algorithms by the author on this page might serve as a nice approximation of the angle, but the looping makes it less efficient than many would like. It basically approximates the angle first by assuming that, instead of having an arc between (1,0) and (0,1), there’s a straight line, like that of a triangle. Then, it uses the “guess and check” method using the cosine equation to converge on the angle.
