After most recent changes, FusionAhrs.initialising flag never set. about fusion

[xioTechnologies]

Dead reckoning would use earth acceleration, not linear acceleration. Dead reckoning using an IMU is typically not possible due to the exponential accumulation of errors. You can explore this using simulated sensor data to see how small sensor errors have a big effect on the double integrated result.

[st2000]

After testing on several devices I am seeing that the NAN problem is random. And it appears to only occur, if at all, after I initiate my calibration procedure. When I do this, I set the minimums to a very positive number (1000) and the maximums to a very negative number (-1000).

Ahh! There's a thought. If the min & max are opposite of normal but otherwise equal in magnitude and they were used to generate magnitude adjustments...
...yes, there's the problem. A divide by zero in my calibration code created one NAN in the magnetometer 3 by 3 correction matrix. When used by the FusionAhrsUpdateNoMagnetometer() function, the NAN propagated to all the quaternion values. And from there on, nothing worked.

Other than the realization that once a NAN creeps into the quaternion values, there's likely nothing to be done except to call FusionAhrsInitialise() again ... I think we're good.

[st2000]

BTW, thanks for fixing the order of offset / magnitude adjustment in FusionCalibrationMagnetic() in hash 15e463c!

[st2000]

Also, is there a community where questions can be fielded by other uses regarding the Fusion code? I hate opening up issues that end up being a problem on my end. For instance, my magnetic compass was also working before I integrated the latest Fusion changes.

Now it appears I need to switch it from what NWU to NED to make it act correctly.

[xioTechnologies]

I am not aware of a such a forum. The only change related to magnetic performance was the switch from $m = Su - h$ to $m = S(u - h)$ in the magnetic calibration model, as discussed here. This change is unrelated to the earth axes convention.

[st2000]

This change is unrelated to the earth axes convention.

Agreed. In fact I was able to remove some of my code which adjusted the offset by the magnitude before passing the offset to the Fusion correction funcitons.

To make clear what I am seeing, I have and am calling both the function FusionCompassCalculateHeading() for a "magnetic bearing" and the functions (FusionAhrsUpdate(), FusionAhrsUpdateNoMagnetometer(), FusionAhrsGetQuaternion() & FusionQuaternionToEuler()) to get euler.angle.yaw which is as far as I understand is the "magnetic + gyroscope bearing".

Before the upgrade, the magnetic only bearing was fast but noisy. The magnetic + gyroscope bearing was smooth but still reactive. And would correct its self to agree with the magnetic bearing given time (additional several seconds).

But after the upgrade, the magnetic only bearing appeared to contain more noise and appeared to rotate in the reversed direction than expected.

It is not a very good fix, but switching just the FusionCompassCalculateHeading() from NWU to NED gives more reasonable bearing values. But they are still not as good as before merging in the current version of Fusion (1.2.1).

-thanks

[xioTechnologies]

If you would like assistance with this then I suggest you create an issue that clearly describes the unexpected behaviour using annotated plots and including code examples where appropriate.

If the issue is specifically an unexpected difference in behaviour between versions then I suggest you log sensor data to file and then demonstrate the different behaviour of each version using identical data.

[st2000]

Turns out it was a problem in my code. Logic error caused my code to assign the magnitude adjustment of the Y magnetometer sensor a near zero value. I gave that correction matrix to Focus and "bad in" / "bad out" ensued. Thanks for your help. Next up, I'm going to try X, Y, Z dead reckoning using the FusionAhrsGetLinearAcceleration() function.