Gyroscope Offset Algorithm about fusion

[xioTechnologies]

Please can you share the data used to generate those plots. The offset correction algorithm works well in most applications but is understood to be incompatible with applications involving extremely smooth and slow motion. What is your application?

[bdeming155]

Thank you, I can email you the data if that works? Is there a good email address for xio technologies?

[xioTechnologies]

You can share here or email [email protected]

[bdeming155]

Thanks, just sent it to that email address

[xioTechnologies]

You have not responded to my question. What is your application? I would like to understand what the IMU is attached to and what kind of motion is expected.

[bdeming155]

This is for a marine application. The IMU is fixed to a small vehicle which is launched from a ship. The vehicle is powered on and initialized on the ship, and then is launched and dives below the water. This is why we have GPS heading at the beginning of the log and then it cuts out. Both the ship and vehicle dynamics are relatively slow. There is also a fair amount of vibration detected by the IMU due to motors on the vehicle.

[xioTechnologies]

Thank you for sharing the data and describing the application. I have plotted the first 2 minutes of gyroscope measurements below.

The gyroscope measurements represent exceptionally smooth motion and so would not be compatible with the offset correction algorithm. This is not an issue and is not unexpected. Any x-io product that includes the offset correction algorithm also includes the option to disable it for precisely these situations. The AHRS algorithm already works well without the offset correction algorithm, as demonstrated by your original plot.

You are using magnetic_rejection: float = 10. This enables the magnetic rejection feature with an error threshold of 10°. In the case of update_external_heading, this will mean that spurious GPS heading errors (>10°) will be rejected unless they persist for the recovery_trigger_period. If the GPS heading and AHRS heading disagree for the this period then the AHRS algorithm will immediately update to match the GPS heading. You may which to monitor the magnetic_recovery flag for an application-level indication of this event.

It is not clear from your post what the numerical value of recovery_trigger_period is. The units of this parameter is samples. If the sample rate is 200 Hz and the intended period is 5 seconds, then the value of recovery_trigger_period must be 1000 = 200 Hz * 5 seconds.