How can i get relatively accurate data on sustained accelerations ?

[earthPerson-001]

I am using this algorithm to estimate roll,pitch and yaw for an electric scooter. The use case requires providing relatively accurate attitude estimation on sustained accelerations and vibrations.

What i have done

constexpr uint16_t GYRO_SAMPLE_RATE_HZ = 100;

FusionAhrsSettings settings = {
    .convention = FusionConventionNed,
    .gain = 0.05f,
    .gyroscopeRange = 2000.0f,
    .accelerationRejection = 10.0f,
    .magneticRejection = 10.0f,
    .recoveryTriggerPeriod = 10 * GYRO_SAMPLE_RATE_HZ,
};

The problem is that, scooter might go through sustained acceleration for very long time. And if the vehicle is still accelerating when the recovery is initiated, it will use invalid data to correct for the current state.

As per my understanding, accelerationRejection will reject any sensor values from accelerometer if the difference between system state (gyro predicted) and accelerometer only attitude is greater than accelerationRejection.

Now the question is:

• How does acceleration recovery work ? Is my understanding correct or there is some sort of logic for using only valid sensor measurements for recovery ?
• What if high acceleration is still present when recovery is initiated ?
• If i set recoveryTriggerPeriod to 0, will accelerationRejection and magneticRejection still work ?
• What should i do to be completely dependent upon gyro in cases of high acceleration ?

The used IMU sensor is LSM6DSOX and magnetometer is IIS2MDCTR.

[xioTechnologies]

Please can you explain what you mean by a "sustained acceleration for very long time". What kind of values are you suggesting?

The acceleration rejection feature is explained in the README:

The acceleration rejection feature reduces the errors that result from the accelerations of linear and rotational motion. Acceleration rejection works by calculating an error as the angular difference between the instantaneous measurement of inclination indicated by the accelerometer, and the current measurement of inclination provided by the algorithm output. If the error is greater than a threshold then the accelerometer will be ignored for that algorithm update. This is equivalent to a dynamic gain that deceases as accelerations increase.

Prolonged accelerations risk an overdependency on the gyroscope and will trigger an acceleration recovery. Acceleration recovery activates when the error exceeds the threshold for more than 90% of algorithm updates over a period of t / (0.1p - 9), where t is the recovery trigger period and p is the percentage of algorithm updates where the error exceeds the threshold. The recovery will remain active until the error exceeds the threshold for less than 90% of algorithm updates over the period -t / (0.1p - 9). The accelerometer will be used by every algorithm update during recovery.

The algorithm behavior that may occur if high accelerations are still present when recovery is complete would depend on the kind of accelerations you are suggesting. Either way, the algorithm would recover into a state that is not providing accurate measurements.

A recoveryTriggerPeriod value of 0 disables the acceleration rejection and magnetic rejection features.

[earthPerson-001]

Please can you explain what you mean by a "sustained acceleration for very long time". What kind of values are you suggesting?

Providing raw sensor data extracted from IMU and magnetometer of the running electric scooter with the following columns:

current_time, current_time_ms, bike_accl_data_mg[0],
bike_accl_data_mg[1], bike_accl_data_mg[2], bike_gyro_data_mdps[0],
bike_gyro_data_mdps[1], bike_gyro_data_mdps[2], bike_mag_data_mG[0],
bike_mag_data_mG[1], bike_mag_data_mG[2], bike_fusion_rpy.roll,
bike_fusion_rpy.pitch, bike_fusion_rpy.yaw, gps_data.latitude,
gps_data.longitude, gps_data.course, gps_data.epochTime,
gps_data.epochTimeMs, gps_available, gps_data.speed, gps_data.altitude

Please ignore the indevice values, only the raw IMU data (bike_accl_data_mg, bike_gyro_data_mdps) is important for the question.

Regardless, same setting is used in both indevice estimation and host estimation:

ahrs.settings = imufusion.Settings(
    imufusion.CONVENTION_NED,
    0.5,
    2000,
    10,
    10,
    10 * 100,  # recovery trigger period (10 s at 100 Hz)
)

constexpr uint16_t GYRO_SAMPLE_RATE_HZ = 100;

FusionAhrsSettings settings = {
    .convention = FusionConventionNed,
    .gain = 0.5f,
    .gyroscopeRange = 2000.0f,
    .accelerationRejection = 10.0f,
    .magneticRejection = 10.0f,
    .recoveryTriggerPeriod = 10 * GYRO_SAMPLE_RATE_HZ,
};

2026-03-11T14-28-33-combined-AGM_RPY.csv

Modified Script for plotting the data from indevice fusion and fusion carried out in host device

Output:

A recoveryTriggerPeriod value of 0 disables the acceleration rejection and magnetic rejection features.

So, none of the acceleration values will be ignored even if they are outside of the provided error margin ?

The use case is the following:
I want to completely rely on gyro reading for higher accelerations (without any error recovery) because any correction carried out during high acceleration condition will make the estimation even worse than the gyro bias. Correct me on this if i am wrong i.e. if there is some sort of mechanism for picking only valid acceleration value for recovery.

Another query, Does setting recoveryTriggerPeriod to high number (for e.g. 1 minute) will increase the chance of picking the correct values of acceleration for proper correction ? Or, it will just delay the correction period and pick all values up to that interval (even the incorrect ones) ?

[xioTechnologies]

You have not explained what you mean by "sustained acceleration for very long time". Please can you describe what the scooter is physically doing. e.g. what terrain, speeds, maneuvers. Is this is a scooter doing a slow morning commute or somersaults in a skate park? Please provide some context.

So, none of the acceleration values will be ignored even if they are outside of the provided error margin ?

Yes, the acceleration rejection feature will be disabled and the acceleration rejection feature is the only mechanism by which the accelerometer would be ignored.

I want to completely rely on gyro reading for higher accelerations (without any error recovery)

I interpret this to mean that you want to enable the acceleration rejection feature but disable acceleration recovery. I do not recommend this but you can effectively achieve it by setting .recoveryTriggerPeriod = UINT_MAX. This period would be sufficiently long (1.36 years for a sample rate of 100 Hz) that recovery can never be triggered. In practice, you risk putting the algorithm into a state where the accelerometer is perpetually ignored regardless of accelerations.

Your plot suggests you do not need to do this because acceleration recovery is already never triggered with your configured 10 seconds trigger period.

Correct me on this if i am wrong i.e. if there is some sort of mechanism for picking only valid acceleration value for recovery.

Acceleration recovery is triggered when both the accelerometer and gyroscope cannot be trusted. The accelerometer cannot be trusted because the acceleration error has been too high for too long; and the gyroscope cannot be trusted because it has been used exclusively for a period deemed too long by the designer (you) to continue to provide a reliable measurement of orientation. In this case, that period has been configured to 10 seconds.

This hopefully makes clear why it is not possible to pick only valid acceleration values; because if neither the gyroscope or accelerometer can be trusted, then there is no reference to determine validity. The best that can be done is to restart the algorithm and hope that this gets us back into a stable state.

In practice, the system should be designed so that acceleration recovery never occurs. The application should monitor the acceleration recovery flag as a potential assert.

Your plot indicates that your magnetic measurements are almost unusable. If you cannot remedy this then I suggest you omit the magnetometer from your processing.

[earthPerson-001]

You have not explained what you mean by "sustained acceleration for very long time". Please can you describe what the scooter is physically doing. e.g. what terrain, speeds, maneuvers. Is this is a scooter doing a slow morning commute or somersaults in a skate park? Please provide some context.

In my case, the term scooter means a electric motorcycle. The scooter can be in acceleration for minutes at once. The scooter is capable of going from 0-40km/h in 6 seconds. There are other factors like constant vibrations which can create upto 8g spikes for up to milisecond which can be interpreted as acceleration as well (falsely). Other factors like bumpy roads (even offroad) terrain can further poison the sensor readings.

This hopefully makes clear why it is not possible to pick only valid acceleration values; because if neither the gyroscope or accelerometer can be trusted, then there is no reference to determine validity.

This clarifies the approach in the current implementation.

I meant to ask, in cases where the magnitude of acceleration exceeds 1g by massive amounts (upto 3g-16g magnitude), can't we confidently reject accelerometer readings and use gyroscope without having to know how huge the accumulated bias is in gyroscope ?

Here i am asking for an approach to only use gyroscope when i fully know that accelerometer cannot be trusted because of huge rotational or linear accelerations.

Your plot indicates that your magnetic measurements are almost unusable. If you cannot remedy this then I suggest you omit the magnetometer from your processing.

This is because of missing hard iron and soft iron calibration in magnetometer, please ignore the magnetometer.

[xioTechnologies]

Large accelerations (e.g. 3g to 16g) are already ignored by the acceleration rejection feature. Such accelerations would result in large errors in the instantaneous measurement of inclination indicated by the accelerometer, and so cause the accelerometer to be ignored. Gating the accelerometer on magnitude alone is fraught because non-1g accelerations aren't actually the problem; the issue is whether those non-1g accelerations averaged over a period of time, fail to represent the direction of gravity.

To phrase it another way, we have no problem with vibrations of any magnitude or bandwidth provided that those oscillations are mean-zero.

[earthPerson-001]

So, if given enough sampling rate, the values won't be affected by vibrations.

Deviating from this, in my case, maximum sampling rate (with processing) i can get is only nearly 100hz. Are there additional suggestion for that case ? Again, the problem is vibrations, very high linear and rotational acceleration when the sampling frequency is low.

[xioTechnologies]

So, if given enough sampling rate, the values won't be affected by vibrations.

That is not what I said.

I expect that 100 Hz is below the input bandwidth. If this is true then the design is fundamentally flawed. I suggest you either mechanically decouple the IMU, or increase your sample rate significantly. Ideally both.

[earthPerson-001]

Understood. I will try to increase the sample rate.

P.S. The sensor sample rate is nearly 400hz but effective processing rate is 100Hz because other tasks is being done in the micro-controller.

Sorry for asking this again, but, won't capping off readings with very high acceleration be beneficial for both cases (high sample rate and low sample rate). I mean to ask what are the drawbacks of capping of (rejecting) very high acceleration ?

[xioTechnologies]

The sensor sample rate is nearly 400hz but effective processing rate is 100Hz

This is the kind of flaw I am referring to. A sample rate of 400 Hz would presumably have an anti-aliasing filter of ≤200 Hz. If you are only reading those samples at 100 Hz then the vibrations would manifest as aliased signals; and you presumably introduce phasing/jitter errors as the 100 Hz update arbitrarily plucks samples from a 400 Hz stream.

I mean to ask what are the drawbacks of capping of (rejecting) very high acceleration ?

You would be discarding potentially useful measurements (when oscillations are mean-zero). This could leave you with no acceleration measurements in the case of sustained vibrations. You also risk masking the original acceleration to create asymmetries that distort the observed direction of gravity.

[earthPerson-001]

This is the kind of flaw I am referring to. A sample rate of 400 Hz would presumably have an anti-aliasing filter of ≤200 Hz. If you are only reading those samples at 100 Hz then the vibrations would manifest as aliased signals; and you presumably introduce phasing/jitter errors as the 100 Hz update arbitrarily plucks samples from a 400 Hz stream.

Ok. I will try to increase both sensor sampling rate and processing rate.

For example: If i have sensor ODR rate at 833Hz (one possibility above from 417Hz) but only able to process at effective rate of around ~400Hz, what are the implications ? Should i decrease the ODR of sensor to 417HZ ?

You would be discarding potentially useful measurements (when oscillations are mean-zero). This could leave you with no acceleration measurements in the case of sustained vibrations. You also risk masking the original acceleration to create asymmetries that distort the observed direction of gravity.

Got it.

[xioTechnologies]

I suggest you search online to understand sample rate vs. bandwidth. There are countless videos and tutorials covering this and they will do a far better job of explaining than I could here.