Author Topic: Implementation of Meeus' Algorithms  (Read 3033 times)

Bob101

  • Jr. Member
  • **
  • Posts: 71
    • View Profile
Implementation of Meeus' Algorithms
« on: July 24, 2012, 12:13:09 PM »
Hey,

I have been looking through the SunCalculations.ino file of Mega_SunTracker_Heliostat_Program_V097_b and I have a few questions.

1) Which edition of Meeus' Book are the algorithms taken from?
2) Were any extra changes to the actual algorithm made (eg... extra terms in the expansions, different coefficients in the expansions)?
3) Did you consider converting everything to radians from the start and doing away with the "to_BigRad" functions?
4) You sometimes comment "multiplied/divided by 15 to convert to hours" eg... in the function "SunsRightAscension" or "LocalHourAngle". Could you please explain to me why this is and why "15" (or link me or refer to Meeus)?

I compared most of the code to the new second edition of Meeus and I can see the following differences:
- In "MeanAnomalyOfTheSun" v4=35999.05029, v1=0.0001537, v2 is removed, v3 = 357.52911, term "v2*t*t*t" is removed
- In "SunsEquationOfTheCenter" v1=1.914602, v8=0.000289

Has this been changed in Meeus or did you alter this?




Gabriel

  • Administrator
  • Hero Member
  • *****
  • Posts: 651
    • View Profile
Re: Implementation of Meeus' Algorithms
« Reply #1 on: July 24, 2012, 02:03:10 PM »
1) I'm also using the second edition.
2) There were no intentional changes to the algorithm. I've checked other programs I've written that are based around this code pretty darn closely, but Mega version could contain some typos.
It looks my book has the same calculation for the Mean Anomaly of the Sun that yours does. I can't find where I got the
m = 357.52910 + 35999.05030 *t - 0.0001559 *t*t - 0.00000048*t*t*t;
from, but I know I didn't just make it up. I'm sure it's in there somewhere. Its just a slightly more accurate version of the same thing that is probably sitting in some footnote somewhere. Page 338 has another similar version for the sun's mean anomaly which is yet another slightly different version of the same thing.

3) It probably wouldn't be a bad idea to convert some of the angles to radians ahead of time. Now that I'm looking at it, I'm not sure why I didn't do that in the first place. It would save some computation time.

4) The multiply / divide by 15 explanation is hardly mentioned in the Meeus book. I spent several very frustrating hours trying to figure out why my output wasn't matching the book's before I finally figured out what was going on. For whatever reason, astronomers sometimes measure angles in hours, not degrees or radians. To convert from an angle measured in degrees to an angle measured in hours, just divide by 15.
So (360 degrees)/15 = 24 hours.
I'm not an astronomer, but I'm guessing that this must be some convention that is assumed knowledge.
Now that I'm looking at the code though, it seems like the whole mess could be skipped over for the sake slightly more efficient calculations.

You may have already seen this, but the code I have for the Maple microcontroller is a lot easier to read than the Mega's code.
http://cerebralmeltdown.com/forum/index.php?topic=332.0


Bob101

  • Jr. Member
  • **
  • Posts: 71
    • View Profile
Re: Implementation of Meeus' Algorithms
« Reply #2 on: July 24, 2012, 02:21:25 PM »
Thanks for that.

Ok, it could be some typos or something more accurate from a footnote that I didn't see. I will go through the code and take note of which page it corresponds to, then I can hopefully provide you with a list of discrepancies and specific page numbers to check against, can never hurt. I'm sure there are no major changes, you've been using your library for some time and anything important would have been seen by you.

Agree with the radians conversion. Also cleans the code up. I could help with this if you want.

Thanks for explaining the 15. That makes sense now. I'm also not an astronomer but I agree with your interpretation!

I will take a look at your maple code but I think I understand the Arduino code fine (just not the algorithm itself... but that's probably better learnt from Meeus... or from the theory he's derived these approximations from). Personally I have an Arduino Uno and would be willing to buy an Arduino Mega more than a Maple so I am pretty tied to the Arduino code. I have been working on a fairly complicated solar tracker arrangement (it's mounted on a motorhome that tours Europe - i.e... changing gps location and orientation) and have gotten the GPS, electronic compass, motor driver, and motor reader circuit all working (the motors are brushed DC motors with hall sensors in them) . I don't fancy doing that all again on another board even if it is superior in some way!

Also, (not to be too pushy :P) with the arbitrary precision library I imagine it's now possible to do just as accurate calculations on the Arduino as the Maple (albeit slower... but for solar tracking that's not such a pain I guess). I was seeing most trig functions evaluate in 3 seconds or less... given the relatively few calls you have a full calculation surely can't take more than a minute!

The final unknown is whether the Arduino has enough memory (2kb) to be calculating trig functions and remembering all these extra constants as big numbers. If that proves to be a problem it's probably possible to clean the memory before evaluating trig functions.

I also find it hard to believe how big the BigNumber library is. For comparison the LSM303 (compass) and VNH5019 (motor driver) libraries from Pololu are like 5kb each.

Gabriel

  • Administrator
  • Hero Member
  • *****
  • Posts: 651
    • View Profile
Re: Implementation of Meeus' Algorithms
« Reply #3 on: July 25, 2012, 05:52:27 AM »
I actually did the Maple code just a a couple of days before I discovered the BigNumber library. Had I found it earlier, I probably wouldn't have bothered with the Maple.

And yes, the BigNumber library is large. I'm actually surprised that you got it to fit on the Uno because I can't get the full sun position algorithm to fit on my Duemilanove. I think the boot loader takes up less space on the Uno though, so maybe that's why you can do it.

Bob101

  • Jr. Member
  • **
  • Posts: 71
    • View Profile
Re: Implementation of Meeus' Algorithms
« Reply #4 on: July 25, 2012, 08:31:06 AM »
It's a shame about the timing but the Maple looks like a pretty cool unit.

If it's not too rude to ask: which code/micro/method of tracking (table/algorithm) is your priority now?

As for my Uno, I haven't loaded the full sun position algorithm onto it yet. I just loaded the BigNumber library and then wrote the BigNumberMath library. I eyeballed the sun position code to understand how it worked.

I notice that the sun position code contains "if accuracy" type lines that switch between the inbuilt functions and the BigNumber functions. I have not checked this yet but I suspect that even having unreachable lines calling the inbuilt trig functions will cause the compiler to include them in the binary and use space unnecessarily on the micro (I guess they are using lookup tables which could be big, I will check this). It may be possible to shoehorn the BigNumber + BigNumberMath + SunPosition part of your code onto the Uno with a few commented out lines... I will get back to you on this.

Another idea I had is... the v1,v2 etc... are often stored as strings then passed to BigNumber on use. It might make sense to declare them BigNumbers from the start as then the Arduino will never have an equivalent string and BigNumber in the 2kb SRAM (not sure if this actually makes a difference).

Finally, one could even modify the BigNumber class to enable BigFloats which would probably provide vastly more accuracy. I would want to try to avoid this though as it would take a significant time investment and performance seems pretty good with BigNumbers.



Bob101

  • Jr. Member
  • **
  • Posts: 71
    • View Profile
Re: Implementation of Meeus' Algorithms
« Reply #5 on: July 25, 2012, 08:46:18 AM »
A quick look suggests that the Arduino uses math.h from avr-libc. See http://www.arduino.cc/en/Math/H

Checking the avr-libc functions

atan contains:
Algorithm:
Code: [Select]
if (x > 1)
  return Pi/2 - atan(1/x)
elif (x < -1)
  return -Pi/2 - atan(1/x)
else
  return x * (1 - C1 * x**2 + ... + C8 * x**16)

Where C1...C8 are read from the table:
Code: [Select]
.L_table:
.byte 8
.byte      0x4a,0xd7,0x3b,0x3b ;  0.0028662257
.byte 0xce,0x01,0x6e,0x84,0xbc ; -0.0161657367
.byte 0xbf,0xfd,0xc1,0x2f,0x3d ;  0.0429096138
.byte 0x6c,0x74,0x31,0x9a,0xbd ; -0.0752896400
.byte 0x56,0x83,0x3d,0xda,0x3d ;  0.1065626393
.byte 0x00,0xc7,0x7f,0x11,0xbe ; -0.1420889944
.byte 0xd9,0xe4,0xbb,0x4c,0x3e ;  0.1999355085
.byte 0x91,0x6b,0xaa,0xaa,0xbe ; -0.3333314528
.byte 0x00,0x00,0x00,0x80,0x3f ;  1.0000000000
.end

This is an inaccurate Taylor expansion... maybe numbers have been jiggled to make sure it gives the right result for every float.

Cos and Sin both use fp_sinus which contains a table:
Code: [Select]
.L_table:
.byte 5
.byte      0xa8,0x4c,0xcd,0xb2 ; -0.0000000239
.byte 0xd4,0x4e,0xb9,0x38,0x36 ;  0.0000027526
.byte 0xa9,0x02,0x0c,0x50,0xb9 ; -0.0001984090
.byte 0x91,0x86,0x88,0x08,0x3c ;  0.0083333315
.byte 0xa6,0xaa,0xaa,0x2a,0xbe ; -0.1666666664
.byte 0x00,0x00,0x00,0x80,0x3f ;  1.0000000000
.end

The Taylor coefficients of Sin.

This is also taking memory. Not sure how much :P. Will check experimentally later!

This is all about space vs speed vs accuracy. You can't have it all. They have gone for speed, speed, speed. Makes sense for general purpose code but not for tracking slow moving objects with high accuracy.
« Last Edit: July 25, 2012, 08:48:22 AM by Bob101 »

Gabriel

  • Administrator
  • Hero Member
  • *****
  • Posts: 651
    • View Profile
Re: Implementation of Meeus' Algorithms
« Reply #6 on: July 25, 2012, 10:51:55 AM »
Right now I'm just trying to clean up some things in the Sun Tracking / Heliostat program. So far, I've managed to get all the various features to fit on the Duemilanove, but with the lower accuracy sun position calculations. I also added the ability to do single axis tracking (which is untested).

I still need to do some double checking to make sure everything works intuitively for people living south of the border. Once that has been finished, I think I will have added pretty much everything anyone would ever need for sun tracking.

I will update the Mega code once this all has been done for anyone who might need the extra accuracy or space.

At some point, the 32-bit Arduino Duo will come out. It should hopefully be capable of double precision math which means that the BigNumber library will no longer be required. We'll see how it goes though. Either way though, the Mega version should be fine if you don't need speed.