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?

To: basicstamps@yahoogroups.com
From: jonwms@aol.com
Date: Thu, 24 Apr 2003 16:06:13 EDT
Subject: Re: [basicstamps] Re: accelerometer issues and questions (Parallax/Memsic dev…

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.

– Jon Williams
– Parallax

How did they pull this off?

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.

Joe J.

' Trig routines courtesy Tracy Allen, PhD. (www.emesystems.com)

  disp = disp */ 983 / 3                        ' normalize input to 127
  angle = 63 - (disp / 2)                       ' approximate angle
  DO                                            ' find angle
    IF (COS angle <= disp) THEN EXIT
    angle = angle + 1
  angle = angle */ 360                          ' convert brads to degrees

  GOSUB Arccosine
  angle = 90 - angle

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.

If we follow the link we get: this.


'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
'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.

*Originally posted by Jnadke *
’ Trig routines courtesy Tracy Allen, PhD…

No. That’s not it. This paper describes the undocumented arctan (ATN) function as well as an undocumented hypotenuse (HYP) function.

I can see how to use ATN but I don’t know how they implemented it.

Do they put a table in EEPROM space if you use the function?

Do they put in a mini-loop to successively approximate the function?

Do they do a mini-table in EEPROM plus a calculation to refine the number to an 8 bit number?

If you know, please explain…

Joe J.

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.

If you know, tell us please.

Joe J.

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?

Here is why I care HOW:

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.

Joe J.

email text from gwross’ first post

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 :slight_smile:

A taylor series might not be too innacurate when you are dealing with answers ranging from 0-255, right?

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.

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.

*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.