My comment wasn't intended as criticism of your solution, merely suggesting that there is an established approach for someone needing sensor fusion with an MPU9150/MPU9250.tuupola wrote: ↑Fri Mar 02, 2018 8:27 amMine actually does support both hard and soft iron bias correction...
But I think there is a general question for @Loboris. Is it a good idea to build in to his firmware support for an ever growing selection of devices? I think it's a potential support and documentation nightmare (for him). I think each driver should be documented and supported by its creator. Users should choose and install the one they wish to use, as per the Pyboard. That approach has worked well for several years.
The magnetometer correction I referred to is a procedure where you invoke a calibration routine and slowly rotate the device around each orthogonal axis. You then stop the calibration phase and the routine calculates and applies the correction factors. Smartphone apps such as compasses and Google Sky have such options. We (myself and @turbinenreiter) have found the process to be absolutely necessary if you want remotely accurate heading data from sensor fusion.
In practice re-calibration is often necessary: I don't think storing static values is likely to be useful.
@OutoftheBOTS_ Re gyro calibration I think it depends on your usage. My understanding of the Madgwick fusion algorithm is that it filters out gyro bias. In practice (for sensor fusion) we found that the magnetometer is the only thing that requires calibration.
@on4aa Funnily enough yesterday I PM'd @Loboris suggesting the same thing: that he requests a subforum for this port. It would be a big improvement. As the volume of queries grows, a user with a problem would find it much simpler to locate a prior solution rather than navigating this colossal thread.