Acceleration Rejection based on orientation change or magnitude of acc vec? about fusion

[xioTechnologies]

The acceleration rejection feature is not based on the magnitude of the accelerometer. As stated in the README, the "acceleration rejection works by comparing the instantaneous measurement of inclination provided by the accelerometer with the current measurement of inclination of the algorithm output."

The angle between these two measurements of inclination can be calculated as

θ = arcsin [ |a × b| / (|a| |b|) ]

where a is the Earth's vertical axis indicated by the accelerometer, and b is the Earth's vertical axis indicated by the algorithm output. If vectors a and b are of unit magnitude then the equation simplifies to

θ = arcsin [ |a × b| ]

The normalised accelerometer measurement is a unit vector that can be assumed to describe the Earth's vertical axis and so be substituted for a to get

θ = arcsin [ |FusionVectorNormalise(accelerometer) × b| ]

The Earth's vertical axis indicated by the algorithm output is equal to the third column of the transposed rotation matrix. The algorithm calculates this scaled by 0.5 on line 117 as halfGravity. This can be multiplied by 2 and then substituted for b to get

θ = arcsin [ |FusionVectorNormalise(accelerometer) × 2 halfGravity| ]

This can be rearranged to

θ = arcsin [ 2 |FusionVectorNormalise(accelerometer) × halfGravity| ]

The cross product of FusionVectorNormalise(accelerometer) and halfGravity is calculated on line 138 as ahrs->halfAccelerometerFeedback. The equation can therefore be written as

θ = arcsin [ 2 |ahrs->halfAccelerometerFeedback| ]

The acceleration rejection feature compares θ with the threshold ahrs->settings.accelerationRejection. This comparison can be written as

arcsin [ 2 |ahrs->halfAccelerometerFeedback| ] ≤ ahrs->settings.accelerationRejection

The left hand side of this equation is computationally expensive, and the right hand side is a constant. The equation can be rearranged so that operations are applied to a pre-calculated constant, and so reduce the computational load of the algorithm. The optimised equation is

|ahrs->halfAccelerometerFeedback|² ≤ ( 0.5 sin [ ahrs->settings.accelerationRejection ] )²

The right hand side is in the form |x|² to avoid the square root operation. The equation can now be re-written as

FusionVectorMagnitudeSquared(ahrs->halfAccelerometerFeedback) ≤ ( 0.5 sin [ ahrs->settings.accelerationRejection ])²

Line 77 overwrites ahrs->settings.accelerationRejection with a value equal to the left hand side. The equation therefore becomes

FusionVectorMagnitudeSquared(ahrs->halfAccelerometerFeedback) ≤ ahrs->settings.accelerationRejection

This is the comparison implemented on line 141 to determine if the accelerometer should be ignored for a given algorithm update.

A threshold of 10 degrees is recommended for most applications. If you wish to tune this value for your specific application then I suggest you log sensor data representative of both typical motion and edge case scenarios (e.g. extreme motion), and then process this data using advanced_example.py. This script will plot the algorithm outputs, internal states, and flags. An optimal threshold will maximise the amount of time the accelerometer is ignored during motion without triggering an acceleration rejection timeout.

[herbertvuijk]

Hi there, follow up on this one. Thanks for the extensive detailing on the mechanics of how accelero rejection works

""acceleration rejection works by comparing the instantaneous measurement of inclination provided by the accelerometer with the current measurement of inclination of the algorithm output.""

So the idea is to reject the accelero measurements when the orientation/inclination outputted by the algorithm, differs to much from the orientation derived from the accelero.

What is the added value of this approach? Because if I understand correctly as soon as there is lots of acceleration or rotation it's likely that the orientation of algo vs accelerometer will be too different, and the accelerometer will get rejected. But this will only contribute to more drift from that point on right, because now we are only relying on the gyroscope while we are already drifted from the accelerometer orientation?

So it's basically impossible to recover from an accelero rejection, except when the rejectiontimeout occurs or when the gyro inclination and accelero inclination coincidentally coincides, which will then start taking the accelero into account again..

Maybe I'm still not getting it completely, but I don't understand this approach from a conceptual point of view as to me it looks like rejecting accelero as soon as the orientation drifts to much only contributes to more drifting.

[xioTechnologies]

The acceleration rejection feature provides a demonstrable improvement to accuracy and reliability in a range of real-world applications.

There are several issues with your description. Perhaps you will understand things better if you see the feature in action. I suggest you run the Gait Tracking script with and without the acceleration rejection feature to see the difference in performance. Change the value on line 42 to 0 to disable the feature. You will then see the error increases from 82 mm to 2.5 m. The script also plots the algorithm internal states so you can see how the accelerometer is used or rejected throughout the data.