LSM6DSV half precision error at ~180 degrees

[Gorbit99]

Hi,

We're using the lsm6dsv's SFLP algorithm to calculate IMU rotation. Recently however we noticed that the resulting rotation has big gaps at around the 180degree mark. We believe this is because of the half float precision, specifically because there aren't a lot of representable values near 1. See below image for our calculated accuracy results which match the actual results we're seeing:

 

[Federica Bossi]

Hi @Gorbit99 ,

 Have you already done gyroscope and accelerometer calibration in order to compensate the offset? If not, please do this and let me know if this helps.

[Gorbit99]

Hi Federica,

It's not about an offset, it's some values that are physically impossible to hit. Specifically around the 180 degrees. Even if a sensor is perfectly calibrated, it will skip some values.

[Tamacchi]

Hi @Federica Bossi , to explain further:

According to the image, the gaps around the 180-degree mark correspond to the limitations of FP16 in representing values when X approaches -1 with high precision. There are fewer representable numbers close to X = -1, which results in larger gaps in the possible quaternion values, and hence in the perceived rotation.

This is a known issue with FP16, as it has only 10 bits for the fraction (mantissa), limiting its ability to represent numbers close together when they are near the ends of its range. As rotations approach 180 degrees, the quaternions tend to have components near x= -1, and the precision of FP16 is not sufficient to represent small changes in angle, resulting in the observed "gaps".

A possible fix would be to enhance the sensor fusion algorithms to utilize FP32 instead of FP16 through a firmware update, if possible.

[Gorbit99]

Bump

We're still facing this issue, and it'd be very important for us to get this fixed somehow. I'd assume that there's some built in solution to this, but neither the samples, nor the datasheet is of any help.

[dorpomi]

Bump.

Here's a more detailed explanation of what is causing the issue:
1. As per the datasheet, LSM6DSV sends the game rotation vector data using 16-bit floating-point format.
2. The largest number less than one FP16 can represent is approximately 0.99951172, which means there are no representable numbers between that and 1.0.
3. The game rotation vector data is sent as quaternions, so the 0.99951172 figure represents a quaternion component.
4. Using any utility to convert quaternions to Euler angles, entering 0.99951172 as a Z component results in a rotation of approximately 176.41885993 degrees along the Z axis.

This implies that LSM6DSV cannot send any rotation values between the -176.42, 180.00, 176.42 points, which is exactly the issue we experience and what is shown in the calculated plot above. The rotation values simply snap into one of those points, skipping the 180-degree point most of the time because the sensor is not perfectly horizontal. This results in a 7.16 degrees gap, which may be further worsened if we utilize any kind of prediction algorithms to compensate network delays.

@Federica Bossi  This flaw in the product design makes the game rotation vector feature unusable in its current state. Other IMUs avoid this problem by utilizing a fixed-point format with, for example, a 14 Q-point value (although 15 would be ideal in this case). I hope it is possible to release a firmware update for this IMU to change the number format.

[Federica Bossi]

Hi all,

You wrote that: the game rotation vector data is sent as quaternions, so the 0.99951172 figure represents a quaternion component.

However you can refer to the AN5922 where in section 9.6.3 we explain that: Game rotation vector: X, Y, and Z axes (vector part of the quaternion) are stored in half-precision floatingpoint format, where w (scalar part of the quaternion) is computed in software after reading the data from the FIFO, since the game rotation vector is a unit quaternion.

For more details you can also look at wikipedia: 

 

[Gorbit99]

Hi Federica,

I appreciate the help, but that's not the issue. We do calculate the w component of the quaternion from the x^2 + y^2 + z^2 + w^2 = 1 equation. Let's assume z=0.99951172, x and y are 0. From that equation, one can calculate w being 0.03124614504. So we get a quaternion of the form:

x=0, y=0, z=0.99951172, w=0.03124614504

Converting that quaternion to an angle, we get z=176.4188726 degrees as a result. It's physically impossible to get anywhere closer to 180 degrees, because that would need the z value to be closer to 1. For example, to get 178 degrees, we would need z=0.9998477, which will be rounded to either 1 or 0.99951172 because of the half precision. Therefore there is a significant gap between about 176 degrees and 180 degrees that are unrepresentable.

This is our problem.

[Federica Bossi]

Hi @Gorbit99 ,

I understand your problem now. It is a known issue on which we are working.

For our next product it will be fixed and all the quaternion components will be saved in FIFO.

Sorry for that.

[Gorbit99]

Sorry, but are you telling me that the stock we already have is essentially useless? I don't quite understand, how storing all components in the FIFO would fix this issue, if they are still half precision, the same error would still show up.

[Federica Bossi]

Hi @Gorbit99 ,

It is not an ST problem related to our libreries and sensors but it is an arithmetical problem when recalculating the weight. We are working to offer a workaround for the next generation IMUs.

[Gorbit99]

Hi Federica,

Sorry, but either we aren't talking about the same problem, or we are on entirely different pages about the issue.

The issue I am talking about is the following: With the number format the sensor is currently using, it is physically impossible for the sensor to send over a rotation representing 178 degrees. This isn't an arithmetical problem, it's simply a firmware problem, therefore it's an issue with the actual sensor, even if not with the hardware side of it.

And just so you understand my side of this issue, we've invested a not obvious amount of time and money into this sensor, so it'd be best if there was a workaround to this issue.

[Federica Bossi]

Hi @Gorbit99 ,

If you have bought a lot of parts and you need support, you should contact the OLS opening a ticket at this page.

This is not a case for st community.

[dorpomi]

Hi @Federica Bossi ,

Can you please ask the engineers behind the IMU whether it is possible to flash another firmware on the IMU or override it on boot? We believe that the current issue can be resolved by simply encoding the rotational values in a slightly different format, and the ability to update the firmware is the first step towards a fix.

[Simon24]

Hi all,

What is the status of this issue? Is there already a firmware update available? We bought a large quantity of lsm6dsv with the idea of using the sensor fusion function provided to us. We therefore need a solution to this issue really soon.

[flaufer]

Hi @Federica Bossi ,

are there any updates on this issue? I agree with @dorpomi - the fix is a matter of representation/encoding and a solution would be rather straight-forward.

Btw. does the ISM330BX use the same SFLP algorithm and has the same issues?

Kine regards,

Felix