Recovery time after saturating the gyroscope.

[LazaroFilm]

During fast rotations, or when knocked, or whipped around, the raw gyro measurements plateau at for a while instead of tracking the board's movement. This is likely due to the maximum sensibility of the gyro. After that, the axis value is offset until the filter corrects the "drift" over a few seconds.

When the gyro saturation is detected, the gain should be raised for a short time to re-center the axis (similarly to the initialization phase).

[LazaroFilm]

here is a screenshot of the rawGyro on the y axis after flicking the board upward. the plateau value doesn't seem to be the same every time...

[reefwing]

Which sensor fusion algorithm are you using? Do you get a similar result with the others?

[LazaroFilm]

I'm using FUSION. I switched the gRes to GFS_2000DPS and it's now working better because it takes much more rotational speed to saturate the measurement. Thats's at the cost of definition, but I have yet to see if it impacts my use case: https://github.com/LazaroFilm/CyberLevel the repo is not up to date)

[reefwing]

Interesting - I forked the fusion library from Seb Madgwick which is based on his PhD thesis. It may be worth raising this issue on the orginal repo - obviously Seb is more of an expert on this than I am.

[LazaroFilm]

Thanks! I'll investigate and potentially raise the question on his repo. By the way I noticed that your fusion file differs from his. It looks like he added some nice corrections (including rejection algorithm for centrifugal force) Lastly, thank you for making this repo! It's been amazing for me to pursue my project!

[reefwing]

Glad you have found it useful, and thanks for letting me know that Fusion has been updated. I'll copy those changes across. Let me know if you track down a solution.

[reefwing]

I've updated the repo with the latest version of the Fusion Library. I tried the new library with and without the changes in your previous PR but it didn't seem to make any difference to the roll and pitch values returned. I tend to use the other fusion options because FUSION responds too slowly for a drone.

[FugLong]

Just FYI, I had this issue and the only way I found to fix it was increase the fusion gain to around 10. LazaroFilm's changes and the repo update didn't seem to fix it for me.

[LazaroFilm]

Hi I thought I'd update on this: I've since moved to a different board with a new sensor but still using the fusion algorithm. I've been using the X-IMU GUI app to troubleshoot my sensors from serial output and it's been extremely useful in fixing all my issues.

[reefwing]

Thanks for letting me know. I downloaded the X-IMU GUI app but I was under the impression that it only worked with the x-io hardware. I'd be VERY interested in knowing what protocol you are using to communicate with the GUI from an Arduino.

I'm in the process of updating my library and will include the latest version of Fusion. It looks like they are tweaking their library to make it more Arduino compatible.

[LazaroFilm]

The GUI simply reads Serial with a certain format I created a Print function that sends the serial commands when called at the end of your loop. Make sure your Serial Monitor is closed in your Arduino as only one serial connection can happen at any time. X-IMU GUI needs to be completely quit to upload a new sketch.

Yes, they had done some updates that were breaking C++ compiler but they just corrected it.

[reefwing]

Brilliant! Thanks very much for that. I had been rolling my own GUI in Processing, but the X-IMU one is better. Thanks again!

[LazaroFilm]

It's not perfect for my use but definitely better that the other serial plotters I found.

Now, I'm banging my head on misalignment matrix for calibrating the gyro and accelerometer. And he explicitly refuses to give any info on calibration (I'm guessing to promote his own pre-calibrated IMU 3) (I know this conversation has left the scope of the first issue...)

[reefwing]

As part of the library update I'm down the LPS22HB barometer rabbit hole at the moment. It turns out the class I was using could be improved and I'm adding some handy altitude functions at the same time.

From memory calibration of the sensor was more a LSM9DS1 issue than sensor fusion. Do you have to use their calibration? If you want to continue on calibration, we should probably open a new issue...

[reefwing]

FYI - The first step is done, I've pulled out the LPS22HB code and created a seperate repository. Next up the IMU!

[LazaroFilm]

I have created a repo for IMU calibration. Right now it's only a README. but feel free to use this is you wish to collaborate on an IMU calibration library.

[reefwing]

I've added your repo to my watchlist. My approach is to load the calibration into the sensor offsets. As I'm splitting the sensor and fusion libraries I want to pass in the most accurate IMU angles possible, regardless of sensor. I've also started adding support for the Xiao Sense which uses the LSM6DS3 IMU (no magnetometer). Nevertheless, happy to collaborate if there is overlap.

[reefwing]

To make using the x-IMU3 GUI easier I wrote an Arduino library for it. Give it a go and let me know what you think.

There is a write up about it on Medium.

[LazaroFilm]

I saw! Life took over my coding time (yeah coding is my hobby lol) I'll have to look at it when I get a chance. Nice idea!

[reefwing]

No problem - real life comes first! 8-)

[reefwing]

As discussed, I've pulled the Fusion algorithm out of the latest version of my library. On that basis, I will close this issue, but happy for you to raise another issue if required.