FXOS8700CQ tilt compensation reduced complexity?

[mbdl]

Hello

I have spent a few days playing around with the KL26Z board and the example code for a tilt compensated compass. As this is clearly geared towards the beasty ARM Cortex chip running an operating system, attempting to port this to a low end 8 bit microcontroller has been a headache to say the least. In fact I can see that I will exhaust the memory available on my target micro.

Has anyone managed to implement a tidy example of tilt compensated compass using the FXOS8700CQ including a similar calibration mechanism to the example given by Freescale?

Cheers

M

[Joshevelle]

Hello Mikael,

Thanks for using our communities.

Freescale eCompass uses a lot of complex algorithms, including matrix, vectors, floating point, etc. I'm not an 8-bit expert, but I  don't think that exporting eCompass to an 8bit uC could be possible.

All the eCompass related information/documentation can be found in the following URL:

www.freescale.com/sensorfusion

Perhaps michaelestanley​ might help you.

Regards,

Josh

[mbdl]

Hi Josh

I think you are correct. Actually my project has mutated a little now and I will be adding GPS destination control which will dictate how much to + or - a compass regulated bearing. I.e. compass will take on a role as a high speed inner control loop with less emphasis on accuracy. Because of this I am forced to upgrade my MCU to deal with more floating point trig operations. Of course this means I can once again try to tackle compass tilt compensation, hopefully without memory issues as I have gone from 368 bytes to 8 kbytes RAM and moved to 16 bit core.

The actual tilt compensation using floating point trig should not be an issue but I am scratching my head over how calibration can be implemented.

1. Linearity of magnetic heading as influenced by soft iron interference is not of concern as I don't currently have any issues using existing 2D compass.

2. True heading to target location will be 'integrated out' by use of GPS, leaving the compass for relative direction control only ("maintain whatever direction"), so if it happens to think South is North it does not matter, likewise true north vs magnetic north will not matter, so long as it can work in any orientation.

3. The device is small enough for a human to rotate in any dimension for initial calibration.

Will simply instructing the user to do 3 rotations one after the other (pitch, roll and yaw) while capturing the min/max of each axis of motion suffice? How does this work if the user combines motions or moves around? It seems this could seriously skew the min/max values to the point of swamping the hard iron bias (min+max)/2. Is there a more robust method that is small mcu friendly?

Could accelerometer calibration potentially be avoided by assuming some nominal scaling factors?

Regards

M

[Joshevelle]

Hello Mikael,

Since your project is still in the design stage, I would highly recommend you to use a Kinetis (low cost 32bits MCU). The whole eCompass software is written for Kinetis MCUs and the problems you are currently facing are already solved in the Kinetis libraries. You can download those libraries for free in the URL I mentioned above and use them directly in your project. Therefore you would only concentrate in your application, rather than trying to solve the eCompass algorithm.

Unfortunately we cannot help you to migrate the software to another MCU.

Regarding your point #2. In order for an electronic compass to maintain a specific direction, the calibration routine should be as accurate as possible, any small amount of offset will directly affect the heading angle. Also, the hard and soft iron will increase the offset over the time if the calibration routine was not properly implemented.

All of your questions are answered in AN4246, but the algorithms are not small MCU friendly.

http://cache.freescale.com/files/sensors/doc/app_note/AN4246.pdf

Hope it helps.

Josh