Gyroscope Offset Algorithm

[bdeming155]

Hello,

I am using the python package for the Fusion library. I am using an accelerometer, gyroscope, and external heading from a dual antenna GPS.

I've found that when the GPS heading cuts out, the drift in the heading estimate grows more rapidly when using the gyro offset correction algorithm vs. when I do not use it. Here is my code:

sample_rate = 200 gain: float = 0.5 gyro_range: float = 2000 acceleration_rejection: float = 10 magnetic_rejection: float = 10 recovery_trigger_period: float = 5

offset = Offset(sample_rate)
ahrs = Ahrs()

ahrs.settings = Settings(
    CONVENTION_NED,  # convention
    gain,  # gain
    gyro_range,  # gyroscope range
    acceleration_rejection,  # acceleration rejection
    magnetic_rejection,  # magnetic rejection
    recovery_trigger_period * sample_rate,
)  # recovery trigger period = 5 seconds

delta_t = np.diff(timestamps, prepend=timestamps[0])

euler = np.empty((len(timestamps), 3))

for index in range(len(timestamps)):

    gyro_reading_corrected = offset.update(gyroscope[index])

    # When GPS heading is available use that to correct heading
    if not np.isnan(gps_heading[index]):
        ahrs.update_external_heading(
            gyro_reading_corrected,
            accelerometer[index],
            gps_heading[index],
            delta_t[index],
        )

    # Otherwise just integrate gyro for heading
    else:
        ahrs.update_no_magnetometer(
            gyro_reading_corrected, accelerometer[index], delta_t[index]
        )

    # Append Intermediate Results
    euler[index] = ahrs.quaternion.to_euler()

I can send you the data I am using separately if that would help. Do you have any suggestions on why this is happening? I feel like the threshold of 3 degrees/second that is used in the offset correction algorithm is too large to be considered stationary?

Any input would be appreciated.

Here are some plots of estimated vs. ground truth yaw (it is clear from the data which segment of the mission has GPS cut out based on the yaw drift):

With offset correction

Without offset correction:

[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 info@x-io.co.uk

[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.