Data source for AHRS heading

[ghost]

As of the current release (0.5b1), AHRS heading is a debug placeholder. We don't seem to be reading the magnetometer at all. Current code take the Z-axis rotation rate, does some trig, and integrates. This give an indicated heading that spins fairly rapidly.

    f := math.Atan2(float64(d.gyro_reading.z), dist(float32(d.pitch), float32(d.roll)))
    h1_deg := -float64(3.42857142857)*f * (180.0 / math.Pi)
    d.heading = float64((sample_period * h1_deg) + d.heading)

When AHRS development gets focus over the next releases, has there been any thought given as to what the AHRS heading should represent? Off hand, I can think of at least five possibilities:

1. GPS track only
2. Magnetometer-derived magnetic heading only (wet compass mode).
3. Gyro-derived heading, with user corrections for heading (DG mode)
4. Gyro-derived heading, periodically / gradually corrected to GPS track
5. Gyro-derived heading, periodically / gradually corrected to magnetic heading with the magnetometer (HSI mode)

GPS track is readily available in the current code, and in flight, is the most stable of the above options. However, since it's track-based, it doesn't tell you which direction the airplane is actually pointed.

Magnetometer is sensitive to installation direction and metallic / electromagnetic interference, and likely would need calibration in any given airplane. But, it at least tells you where you are pointing. There's a library for a LSM303 sensor in github.com/kidoman/embd/sensor/lsm303 that might be adaptable for the Honeywell sensor.

I've monkeyed a bit with the gyro heading code. The following takes the raw yaw rate, applies a factor to correct for steady-state drift, and integrates. While it's not yet flight ready (constant correction factor and always initiates to hdg 360) , it's reasonably stable at rest (~1 deg/min drift in bench test) and more importantly, responds to yaw. If you turn the gyro module 90 degrees, ForeFlight heading turns 90 degrees. Turn it back, and it comes back about to where it started.

        gyro_z_drift := 1.8 // steady state drift in degrees per sec
        d.heading = float64(sample_period *(-2*(float64(d.gyro_reading.z)+ gyro_z_drift)) + d.heading)

[bradanlane]

I've flown behind a few different "glass panel" solutions - some with calibrated magnetometers and some without. At least one vendor initially used a gyro-derived heading with periodic correction by the magnetometer and then later changed the firmware to perform periodic correction from the GPS.

1. Gyro-derived heading, periodically / gradually corrected to GPS track
2. Gyro-derived heading, periodically / gradually corrected to magnetic heading with the magnetometer

I would say #3 is the most predictable (#4 would be a nice-to-have if we knew the AHRS wasn't overly susceptible ferris objects).

If you conclude the gyro code is becoming unwieldily then the solution is to use simple GPS track.

[skypuppy]

For 3D attitude, an IMU must be corrected for drift over time. An IMU, in my code, only shows the state of the ship relative to the earth and the horizon. The magnetometers, once calibrated, should theoretically maintain their known orientation (relative to magnetic north) over a considerable length of time. However, I hope to have mine renormalized every few minutes, usually with GPS or a whiskey compass or a DG. The length of time is subject to change as I get more experience with the model I use, the BNO055. No, I do not have the code for it anywhere close to working with stratux. Even with maximum Kalman filtering, an IMU will still drift over time and needs 'mini-calibration' from outside sources. Even our submarines still have that problem, and they don't travel nearly as fast as we do. In an IMU, it is ESSENTIAL that the mag, gyro, and attitude sensors all be used together to obtain an accurate 3D attitude reading. With the right hardware, an IMU could theoretically only needs to be fully calibrated only once, upon installation if they can store their cal factors. Others that do not, will need full recal upon every startup. The more internal filters they have, the better. :)

Of course, I could be wrong.

Skypuppy

On 11/22/2015 12:53 PM, bradanlane wrote:

I've flown behind a few different "glass panel" solutions - some with calibrated magnetometers and some without. At least one vendor initially used a gyro-derived heading with periodic correction by the magnetometer and then later changed the firmware to perform periodic correction from the GPS.

 1. Gyro-derived heading, periodically / gradually corrected to
    GPS track
 2. Gyro-derived heading, periodically / gradually corrected to
    magnetic heading with the magnetometer

I would say #3 https://github.com/cyoung/stratux/pull/3 is the most predictable (#4 https://github.com/cyoung/stratux/issues/4 would be a nice-to-have if we knew the AHRS wasn't overly susceptible ferris objects).

If you conclude the gyro code is becoming unwieldily then the solution is to use simple GPS track.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/126#issuecomment-158789189.

[bradanlane]

As I imagined, this is getting too complicated too quickly.

I would go with the following progression:

1. use GPS track as "heading"; get this working and release it (I can make this change in the WebUI with what we have today)
2. use gyro-derived heading, corrected with GPS; test if for a while; release it in the future

A number of vendors who actually make a living at this stuff stopped with the 2nd level of implementation. Are there even any portable vendors attempting to utilize a magnetometer based solution?

[RobertGary1]

I seem to recall when I was at the Garmin schoolhouse that they said the G1000 uses gyros for heading (like a dg) and then syncs with the magnetometer at select times.

-Robert

[bradanlane]

Permanent solutions have this option since the system can be calibrated to the magnetometer location and error. Much like a wet compass, the magnetometer reading needs to be recorded at multiple reference headings and an error table gets recorded. Any time the magnetometer is removed/installed and anytime there are changes to the aircraft which might alter the calibration table, the system needs to get recalibrated.

This is why I question if Stratux (or any portabl can successfully to be an ADHRS solution.

I think a good point of reference is the Dynon D2 "pocket panel". Is uses GPS ground track.

[RobertGary1]

Are you suggesting estimating the crab angle and adjust the GPS heading or just punt on true heading?

If it makes a difference I think a lot of us are planning on making this a fairly permanent installation. I wouldn't mind doing a full rose calibration because I'm going to Velcro the unit in place.

-Robert

[bradanlane]

"Punt on true heading". The "big boys" don't do it in a portable and even if you Velcro the thing down it will be easy to attach it off by 5 degrees.

GPS track is more than good.

[RobertGary1]

Well, at least for me, once I Velcro it down I'm not going to touch it. I can update it on the plane with a laptop. Not sure if that's the more common Use Case or not though. However heading is probably down the list of priorities. Accurate pitch and roll is probably the biggest need.

-Robert

[bradanlane]

Does ForeFlight have a "level" button to normalize its synthetic vision or does it require the external device (eg Stratux) to know what level is?

I ask because the Statux creates a baseline for what "level" is when it powers up. This is not useful in a tail wheel airplane.

As for "Velcro down an leave it", I suspect the majority of users will take it out of the plane after each flight. Time will tell.

[ghost]

I flew with the AHRS today... results were surprising, compared to what I'd seen on the ground.

First, the reported AHRS heading aligns with GPS track! Back on 8/21 (8d88e4f91c376c3dc6af28fba53a5d9753b7b0f0), Chris implemented a mpu6050.ResetHeading() function, which resets the heading to GPS ground track every time ry835ai.processNMEALine() is called.

That is sort of an all-or-nothing approach. If you rotate the AHRS, heading will show a turn with the correct direction and magnitude for a second or two. Then, the indicated heading is overwritten with the current GPS ground track.

A more subtle approach -- i.e. calculate an error function between GPS track and heading, and gradually apply a correction over several seconds -- would be more elegant and could potentially give a truer picture of what the airplane is doing at low speeds (pattern work, ground operations, etc.)

@bradanlane -- I think this validates much what you're suggesting. The beauty of that approach is that we're 80-90% of the way to a finished product.

As to pitch and roll, flight testing revealed a critical weakness in the current implementation: it stays level during coordinated turns. The p1 and r1 variables used in mpu6050.calculatePitchAndRoll() are functions of acceleration, and seem to damp out the roll response.

[skypuppy]

But that is exactly backwards. Gyro's are good ONLY for attitude, not heading. Sensor fusion of all the IMU sensors makes each sensor much more reliable for all 3 (or more) axes. But gyro's drift. And drift. And... A calibrated magnetometer is much more reliable and for a much longer time frame.

On 11/22/2015 03:42 PM, RobertGary1 wrote:

I seem to recall when I was at the Garmin schoolhouse that they said the G1000 uses gyros for heading (like a dg) and then syncs with the magnetometer at select times.

-Robert

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/126#issuecomment-158803315.

[skypuppy]

My theory is that stratux can be a successful solution with the right hardware and algorithms. Are they as accurate as the ones that cost tens and hundreds of thousands of dollars? No, but they don't need to be in our environment. Sanity cross checking with the other instruments is the key here. (As well as most other implementations.)

On 11/22/2015 03:56 PM, bradanlane wrote:

Permanent solutions have this option since the system can be calibrated to the magnetometer location and error. Much like a wet compass, the magnetometer reading needs to be recorded at multiple reference headings and an error table gets recorded. Any time the magnetometer is removed/installed and anytime there are changes to the aircraft which might alter the calibration table, the system needs to get recalibrated.

This is why I question if Stratux (or any portabl can successfully to be an ADHRS solution.

I think a good point of reference is the Dynon D2 "pocket panel". Is uses GPS ground track.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/126#issuecomment-158805511.

[RobertGary1]

Gyros are what ifr aircraft use for heading and you sync it with the wet compass on occasion. That's what Garmin was saying they're doing in software too. The magnetometer has the limitations of the wet compass that it's subject to dip in turns.

[skypuppy]

Once a (self-recordable) calibration is performed on the magnetometers, they can pretty well take care of themselves and know which way is north and up (crossing with accelerometer) with the final possible visual correction against a dg (sitting still) or GPS (if moving.) Changing a few degrees or inches is self-correcting. This is not true for those that are not self-recordable cals, but even some of those can be fed their cal factors by the Pi 2.

On 11/22/2015 04:07 PM, RobertGary1 wrote:

Well, at least for me, once I Velcro it down I'm not going to touch it. I can update it on the plane with a laptop. Not sure if that's the more common Use Case or not though. However heading is probably down the list of priorities. Accurate pitch and roll is probably the biggest need.

-Robert

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/126#issuecomment-158807656.

[skypuppy]

Look for errors in the sensor fusion algorithm.

On 11/22/2015 05:01 PM, AvSquirrel wrote:

I flew with the AHRS today... results were surprising, compared to what I'd seen on the ground.

First, the reported AHRS heading aligns with GPS track! Back on 8/21 (8d88e4f https://github.com/cyoung/stratux/commit/8d88e4f91c376c3dc6af28fba53a5d9753b7b0f0), Chris implemented a mpu6050.ResetHeading() function, which resets the heading to GPS ground track every time ry835ai.processNMEALine() is called.

That is sort of an all-or-nothing approach. If you rotate the AHRS, heading will show a turn with the correct direction and magnitude for a second or two. Then, the indicated heading is overwritten with the current GPS ground track.

A more subtle approach -- i.e. calculate an error function between GPS track and heading, and gradually apply a correction over several seconds -- would be more elegant and could potentially give a truer picture of what the airplane is doing at low speeds (pattern work, ground operations, etc.)

@bradanlane https://github.com/bradanlane -- I think this validates much what you're suggesting. The beauty of that approach is that we're 80-90% of the way to a finished product.

As to pitch and roll, flight testing revealed a critical weakness in the current implementation: it stays level during coordinated turns. The |p1| and |r1| variables used in mpu6050.calculatePitchAndRoll() are functions of acceleration, and seem to damp out the roll response.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/126#issuecomment-158816754.

[skypuppy]

That's why the sensor fusion algorithm is so important. It will self-correct.

On 11/22/2015 05:26 PM, RobertGary1 wrote:

Gyros are what ifr aircraft use for heading and you sync it with the wet compass on occasion. That's what Garmin was saying they're doing in software too. The magnetometer has the limitations of the wet compass that it's subject to dip in turns.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/126#issuecomment-158818041.

[dmurray14]

I've seen EKF mentioned a few times, is the final AHRS solution going to be based on it? If so, should handle all of this..

On Sun, Nov 22, 2015 at 6:30 PM, skypuppy notifications@github.com wrote:

That's why the sensor fusion algorithm is so important. It will self-correct.

On 11/22/2015 05:26 PM, RobertGary1 wrote:

Gyros are what ifr aircraft use for heading and you sync it with the wet compass on occasion. That's what Garmin was saying they're doing in software too. The magnetometer has the limitations of the wet compass that it's subject to dip in turns.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/126#issuecomment-158818041.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/126#issuecomment-158818216.

[224XS]

I'm not sure I see the value in having a magnetic compass function implemented at all. It is after all just reproducing an antique function full of error. My Blue Mountain EFIS (Gen4 Still going strong) has a three axis Honeywell Magnetometer. No dip, acceleration or turn error. It works great, but track between ground based references is still the only important outcome. Yes, there are times when ATC gives you a heading to follow, but they don't know the winds aloft with and more certainty than you do.

There are times when an engineer can do something but chooses not to because they know it will function poorly in the end-use environment. I think providing a magnetic north based on a portable device known in most uses to bounce around the fuselage in flight is one such time. When you think about it, the AHRS functions have the same weakness in a potable device but the data they provide is potentially more valuable (if even more sensitive to being jostled around).

[RobertGary1]

The FAA is pretty clear that they want assigned headings flown by compass not track for Ifr. Atc does keep track of the difference and expects everyone to be affected the same. They want some precision vectoring on approach and at altitude those of us with turbos can see substantial differences. But that's not to say that we can't just put a giant disclaimer on the whole thing telling pilots not to use the heading for instrument flying.

-Robert

[Bagarre]

I don't believe it is the intent of the Stratux project to be 'flown' in a way that would contradict the FAA. IE it's not a source for primary flight instruments. https://github.com/cyoung/stratux/issues/86 clarified that. "we do not want even the hint that a Stratux is to be used for flight operations. That is dangerous place to be"

Trying to get a correct mag heading in any hand held is a fools errand (IMO). I'd rather it by a gyro indication and let the presentation layer provide for a compass correction ...just like a DG.

[cyoung]

Compile and run the imu tools on the Pi: https://github.com/cyoung/linux-mpu9150

You will see that pitch, roll, and yaw are much more accurate using this method (even without the magnetometer).

[cyoung]

ForeFlight accepts AHRS headings as "Track-along-ground from true north". This is the reason that the heading "gyro" gets set from the GPS track.

[224XS]

Hi Robert! Wow! As a Comm/SEL myself I can not even imagine trying to fly a turbine in actual IFR based on a Stratux as you seem to suggest.

On that basis alone I would strongly suggest that Chris reconsider the whole idea of adding AHRS and Compass to the project to protect himself from legal claims from your widow. If you think it's a joke, just look at what's happening with Vans.

Sent from my iPhone

On Nov 23, 2015, at 9:28 AM, RobertGary1 notifications@github.com wrote:

The FAA is pretty clear that they want assigned headings flown by compass not track for Ifr. Atc does keep track of the difference and expects everyone to be affected the same. They want some precision vectoring on approach and at altitude those of us with turbos can see substantial differences. But that's not to say that we can't just put a giant disclaimer on the whole thing telling pilots not to use the heading for instrument flying.

-Robert

— Reply to this email directly or view it on GitHub.

[RobertGary1]

@224xs, not sure why you went nuclear on something I never even said. The discussion was on proper presentation of represented heading and my comment suggesting a note telling pilots from where the heading is derived. Only you suggested to just flying a heading that was incorrect because you stated that you thought atc didn't know the difference.

It appears you want to have an unrelated discussion that would probably be best in a different forum.

-Robert

[224XS]

Hi Robert, I'm sorry I seemed to miss understand you when you said ATC wanted mag heading courses when flying IFR with your turbo (sorry, I wrote turbine). The implication seemed clear that that you were asking for Stratux to provide what ATC wanted. What I said was that since Stratux was not intended to be accurate enough for ATC / IFR navs, we should not provide it at all cause someone will not understand the limitations.

Sent from my iPhone

On Nov 23, 2015, at 12:06 PM, RobertGary1 notifications@github.com wrote:

@224xs, not sure why you went nuclear on something I never even said. The discussion was on proper presentation of represented heading and my comment suggesting a note telling pilots from where the heading is derived. Only you suggested to just flying a heading that was incorrect because you stated that you thought atc didn't know the difference.

It appears you want to have an unrelated discussion that would probably be best in a different forum.

-Robert

— Reply to this email directly or view it on GitHub.

[skypuppy]

If you have the IMU with mag, attitude, and gyro all sensor-fused, all their weaknesses and all their strengths TOGETHER make for a much more solid and reliable result than any single sensor by itself.

On 11/23/2015 08:35 AM, David Ross wrote:

I don't believe it is the intent of the Stratux project to be 'flown' in a way that would contradict the FAA. IE it's not a source for primary flight instruments.

86 https://github.com/cyoung/stratux/issues/86 clarified that. "we

do not want even the hint that a Stratux is to be used for flight operations. That is dangerous place to be"

Trying to get a correct mag heading in any hand held is a fools errand (IMO). I'd rather it by a gyro indication and let the presentation layer provide for a compass correction ...just like a DG.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/126#issuecomment-158952690.

[skypuppy]

Thankfully, Chris has already said not to use it as such. It is a TOY to play with. It's just that it is also a very useful toy!

Skypuppy

On 11/23/2015 10:56 AM, 224XS wrote:

Hi Robert! Wow! As a Comm/SEL myself I can not even imagine trying to fly a turbine in actual IFR based on a Stratux as you seem to suggest.

On that basis alone I would strongly suggest that Chris reconsider the whole idea of adding AHRS and Compass to the project to protect himself from legal claims from your widow. If you think it's a joke, just look at what's happening with Vans.

Sent from my iPhone

On Nov 23, 2015, at 9:28 AM, RobertGary1 notifications@github.com wrote:

The FAA is pretty clear that they want assigned headings flown by compass not track for Ifr. Atc does keep track of the difference and expects everyone to be affected the same. They want some precision vectoring on approach and at altitude those of us with turbos can see substantial differences. But that's not to say that we can't just put a giant disclaimer on the whole thing telling pilots not to use the heading for instrument flying.

-Robert

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/126#issuecomment-158994871.

[skypuppy]

Robert, that was not I who said that.

Skypuppy.

On 11/23/2015 11:05 AM, RobertGary1 wrote:

@224xs https://github.com/224xs, not sure why you went nuclear on something I never even said. The discussion was on proper presentation of represented heading and my comment suggesting a note telling pilots from where the heading is derived. Only you suggested to just flying a heading that was incorrect because you stated that you thought atc didn't know the difference.

It appears you want to have an unrelated discussion that would probably be best in a different forum.

-Robert

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/126#issuecomment-158997476.

[skypuppy]

224XS, I most emphatically disagree with your wish. I hope the group continues to get the maximum functionality out of this project. Most pilots are responsible enough to know the limits of their airplane AND instrumentation and in fact, are required by federal regulation to do so.

The last thing we need is a bunch of lawyer popups like other commercial ops do; we'd just compile them out anyway. That is one of the great things about open source!

Skypuppy

On 11/23/2015 11:49 AM, 224XS wrote:

Hi Robert, I'm sorry I seemed to miss understand you when you said ATC wanted mag heading courses when flying IFR with your turbo (sorry, I wrote turbine). The implication seemed clear that that you were asking for Stratux to provide what ATC wanted. What I said was that since Stratux was not intended to be accurate enough for ATC / IFR navs, we should not provide it at all cause someone will not understand the limitations.

Sent from my iPhone

On Nov 23, 2015, at 12:06 PM, RobertGary1 notifications@github.com wrote:

@224xs, not sure why you went nuclear on something I never even said. The discussion was on proper presentation of represented heading and my comment suggesting a note telling pilots from where the heading is derived. Only you suggested to just flying a heading that was incorrect because you stated that you thought atc didn't know the difference.

It appears you want to have an unrelated discussion that would probably be best in a different forum.

-Robert

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/126#issuecomment-159009691.

[egid]

Just in terms of synthetic vision, syncing heading to compass (HSI or DG mode) makes the most sense; GPS track could result in synthetic vision showing something very much off to one or the other side, when it's in front of you, or vice versa. The effect would be magnified as crosswind increases.

[224XS]

Hi Skypuppy! I make not claim about pilots. My point concerns lawyers. Once they identify a pocket, they concoct a claim. That is how the system works. An RV10 pilot runs out of gas in a plane with he built with Home Depot parts in the fuel system. Who gets sued: Vans and Floscan. Maybe HD will be added later.

Sent from my iPhone

On Nov 23, 2015, at 3:25 PM, skypuppy notifications@github.com wrote:

224XS, I most emphatically disagree with your wish. I hope the group continues to get the maximum functionality out of this project. Most pilots are responsible enough to know the limits of their airplane AND instrumentation and in fact, are required by federal regulation to do so.

The last thing we need is a bunch of lawyer popups like other commercial ops do; we'd just compile them out anyway. That is one of the great things about open source!

Skypuppy

On 11/23/2015 11:49 AM, 224XS wrote:

Hi Robert, I'm sorry I seemed to miss understand you when you said ATC wanted mag heading courses when flying IFR with your turbo (sorry, I wrote turbine). The implication seemed clear that that you were asking for Stratux to provide what ATC wanted. What I said was that since Stratux was not intended to be accurate enough for ATC / IFR navs, we should not provide it at all cause someone will not understand the limitations.

Sent from my iPhone

On Nov 23, 2015, at 12:06 PM, RobertGary1 notifications@github.com wrote:

@224xs, not sure why you went nuclear on something I never even said. The discussion was on proper presentation of represented heading and my comment suggesting a note telling pilots from where the heading is derived. Only you suggested to just flying a heading that was incorrect because you stated that you thought atc didn't know the difference.

It appears you want to have an unrelated discussion that would probably be best in a different forum.

-Robert

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/cyoung/stratux/issues/126#issuecomment-159009691.

— Reply to this email directly or view it on GitHub.

[cyoung]

Let them find the stratux pockets, then. :)

[RobertGary1]

They are bound to the license agreement disclaimer too.

[1-prop-head]

On subject of the HMC5883 and using its reading to correct for gyro drift. One thing to consider is to remove those little magnets in the bottom of the antennas if you are placing the antenna near the GPS module.

[cyoung]

@224XS - https://www.reddit.com/r/flying/comments/3u41q9/dual_vacuum_pump_failure_in_imc/.

[1-prop-head]

Thanks And this is why I have a Dynon D1 and a Stratus 2 in N1494S And your stratux project is why my less monied friends will have the same instrument depth when they go in the clouds Built 3 so far all work excellent and are in use!

We all thank you dean

On Nov 24, 2015, at 4:28 PM, cyoung notifications@github.com wrote:

@224XS - https://www.reddit.com/r/flying/comments/3u41q9/dual_vacuum_pump_failure_in_imc/.

— Reply to this email directly or view it on GitHub.

[duecedriver]

I posted this over at reddit This should be all the secret sauce code we need, save for integrating the pressure altitude function, etc. Its C based code and should be simple to roll into the current software.

it includes all the quaternions calcs to offset acceleration and kalman filters and drift correction algorithms... ENJOY!!

keep up the great work!!

[–]skypuppy7 1 point 15 hours ago The BNO055 chip, ($35 from Adafruit, cheapest I've found yet) has "sensor fusion" hardware and software already on the chip. You just set the flags and ask for the data via the I2C lines. I'm working toward incorporating it into stratux but I have to learn Qt first --- and that AIN'T easy. I've used several excellent debuggers over the years but Qt is blowing my mind. Also, a separate GPS chip will be needed. permalinksavereportgive goldreply [–]duecedriver[S] 1 point 20 minutes ago That chip is interesting... I believe that we must focus on one hardware solution and program against it... This chip has advantages of built in inu and quaternions calculations but lacks gps/glonass/ and pressure alt capability so that would require another chip. The RY83AI is the most robust hardware solution but would require the secret source be written and or adopted from open source. It would give a more fine tuned control of the output and be easier since the source is in C not adafruit.. this is really the simplest fix right here... here is the entire codebase required for those that know C and how strutux is constructed.

http://www.x-io.co.uk/open-source-ahrs-with-x-imu/

The x-IMU‘s propriety on-board IMU and AHRS sensor fusion algorithms provide a real-time measurement of orientation relative to the Earth. Many projects require access to algorithm source code so that it may be run off-board, modified or used to post-process sensor data and take advantage of non-real-time techniques. This open source project implements Madgwick’s AHRS and IMU algorithms in C# and demonstrates their real-time performance alongside the x-IMU’s own propriety algorithm. The source code also includes Madgwick’s implementation of Robert Mayhony’s so called ‘DCM filter‘ in quaternion form.