3689392686?profile=originalHi folks - this is by first blog post here, so let me know if I'm commiting a faux pas in any manner :)

I've decided that the compass support on ArduPilotMega needs beefing up.  I'm working on this in a few ways:

1. Added MicroMag3 support - this is accomplished, though I still need to refactor to make things part of a better OO-design.

2. Added a LUT for both magnetic declination and inclination so that these values are populated by the GPS.

3. Looking to improve the drift correction algorithm.  I like in an area where the inclination of the magnetic field is about 70 degrees from horizontal.  Many people assume that the magnetic runs tagent to the earth's surface - this is significantly untrue.  Becuase the magnetic field vector is so close to vertical here, it actually provides a much better estimator for pitch and roll than yaw if the plane is horizontal.  Thus, I intend to modify the drift correction in the DCM to use the magnetic vector as a truly 3D vector.  This means that depending on the orientation of the plane, it will correct for pitch, roll, and/or yaw with varying levels of accracy.  Has anyone already looked into this?

4. Make a calibration wizard in "setup" and have it store the values in the EEPROM.








E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones


  • Adam-

    Check out my other post: http://diydrones.com/profiles/blogs/magnetic-declination-and?xg_sou.... It has the source code.  Some folks asked some good follow-up questions, so check the comments, too :)

    I'm on vacation, so I won't be able to dig into the code for a week or so.



  • Developer


    I just stumbled upon your post by searching for my own automatic declination blog post. I didn't realize that someone had already implemented this. Out of curiosity what was the size of your lookup table? 



  • Randy, thanks for the guidance. Fortunately,  I had guessed correctly and was already adding support to that area once Chris pointed me to the APM 2.0 trunk. The tricky part is that DataFlash and AP_Compass_MicroMag3 are going to have to share the same SPI line.  This leaves me with a few options:

    1. (current) DataFlash remains unchanged. AP_Compass_MicroMag3 saves "SPI state" before using it and then restores it after - think KeSaveFloatingPointState.  We can get away with this because DataFlash uses SPI in a synchronous (no interrupts) manner and we can force MicroMag3 to also work in a synchronous manner.  However, the latter would require the addition of void Compass::do_work() that would run in the fast (50hz) loop so that we can check for the DRDY pin and pull in new data when it is ready and then request the next axis. I'm estimating this call will take ~tens of microseconds once I tighten the timings.

    2. Create an SPI arbiter that would allow multiple devices to use the SPI bus in an async manner. This would involve disabling interrupts for a short periods of time.  I'll have to research if I have to disable them outright or if I can away with disable solely the SPI interrupt.


    On a somewhat related note, I'm using PK0-4 for the sideband signals.  Is there a GPIO arbiter that would make sure two devices aren't trying to use the same pin? Ideally at compile time? :)







    #define PK0_IN_USE




    #define PK0_IN_USE // compiler error already defined


  • Developer


         to make it fit in with the existing compasses we support, it would be great if you could make an addition to the AP_Compass library.  If you chose to do this you would need to create two new files AP_Compass_MicroMag3.cpp and AP_Compass_MicroMag3.h.  And you'd also need to make a minor change in the AP_Compass.h file to include your new h file. 


         I know it's often more difficult to try and fit yourself into someone else's framework but that's probably the easiest way to get support for the MicroMag3 without widespread changes to other people's code.



  • Great feedback guys! I'm going to play around with the data some to see what kind of size/accuracy tradeoff I can get.  It looks a lot more doable if we limit ourselves to inhabited latitudes (80 N -> 55 S) as we avoid the magnetic poles.
  • this week ? you tease... :)
  • 3D Robotics
    Bill, yes, the GCS is 2-way with APM 2.0 (coming out this week)
  • I.S. has the right idea. Many of the commercial drone systems I use at work store the declination information in the control console. Also makes updateing the data easier.


    Though it does require 2-way comms on the control console and, well, having a control console to begin with. I haven't been following the standard Ardupiolt setup for a while. Is the GCS 2-way now? How would Ardupilot handle it if there was no GCS to pull the data from?

  • Developer
    GCS would be a good place for a lookup table. Of course if you have a laptop GCS and an internet connection you can just get an accurate declination off the web...
  • Could be that LUT stored in the GCS?

    bigger=more precise LUT and less storage&computing on the Autopilot

This reply was deleted.