0
$\begingroup$

we are currently trying to get an LSM6DSV (specifically LSM6DSV16X) IMU working, which has in-built sensor fusion. It's important for us, that there is very little drift over time, and the sensor itself lists ~0.7 degrees per 5 minutes in the sort of conditions we assume to belong in. We do get fusion vectors out of the sensor, however, they seem to drift very heavily, when in movement, with very little back and forth rotation, I can get upwards of 2 degrees of drift every minute, even though that's past even the worst case drift from the datasheet.

The relevant code can be found here: https://github.com/wigwagwent/LSM6DSV16X/blob/main/src/sensors/lsm6dsv16xsensor.cpp

But in short, we mainly used the example provided by st themselves, and we only really use the provided "game vector". The algorithm can output a gravity vector and a gyroscope bias that we don't know how to utilize properly, if it's necessary.

The module was soldered onto an off the shelf bmi160 breakout board like this, as that one has the same footprint and passive components that the lsm family requires. This being a soldering issue isn't out of the question either.

We tried increasing the gyroscope and accelerometer ODR values, but that didn't solve the issue. We are currently looking into manually setting the gyroscope bias, but we aren't sure how that could be done effectively.

Any insight would be greatly appreciated!

Improve this question
$\endgroup$
3
  • $\begingroup$ You are trying to perform dead reckoning which is more difficult over longer periods of time. How accurate do you need to be over what period of time? The answer may be to switch to GPS. But that is only a guess because you are posting in a robotics rather than an arcade stackexchange site. I don't recommend STMicro sensor software if no source code is provided because of support issues. Since you have the source code you can backwards engineer it to determine if their calibration (if any) aligns with your requirements. $\endgroup$
    – st2000
    Commented Aug 6, 2023 at 13:36
  • $\begingroup$ @st2000 (fitting username btw), the ST library is literally only for driving the sensor from a microcontroller. The code is very much available, and nothing complicated. It's included in our project as well here: github.com/wigwagwent/LSM6DSV16X/blob/main/lib/LSM6DSV16X/… We are using a wrapper library over this that we are also improving for convenience. We only really need an accurate rotation data, not position, so GPS wouldn't solve our usecase. $\endgroup$
    – Gorbit99
    Commented Aug 7, 2023 at 1:03
  • $\begingroup$ @Gorbit99 If all you need is accurate rotation data, why are you using an accelerometer+gyroscope to perform dead reckoning when you could be using a magnetometer to get an absolute position? This would have substantially less drift (it's why you frequently see them on boards with gyro+accel). $\endgroup$
    – cst0
    Commented Sep 6, 2023 at 15:18

2 Answers 2

Reset to default
1
$\begingroup$

Consider dead reckoning will only provide accuracy over a short period of time. As any sampling errors will accumulate over time.

When testing, it is usually desired to know the state of calibration. On the linked to GITHUB project we find the README comment:

Sensor calibration

It is generally recommended to turn trackers on and let them lay down on a flat surface for a few seconds.* This will calibrate them better.

This infers continuous calibration. Concerning the gyroscope, consider performing bias calibrations when it is clearly known the gyroscope is at rest and discontinuing calibration before moving the gyroscope. To find the 3 gyroscope bias values, average each of the X, Y & Z sensors individually over many samples. After calibration is turned off, subtract these bias values from each sample before using for dead reckoning.

Improve this answer
$\endgroup$
3
  • $\begingroup$ I went ahead and answered your question. But only WRT gyroscope bias. The question is good, but there are missing requirements. If you edit your question and include them you may get better more complete answers. What accuracy over what period of time? Is angle drift happening at rest? Is angle drift happening during motion? It may also help to know what the goal is. If you are building a 3D mouse, then you don't care where in 3D space you are in. Only tilt and rotation. And you will occasionally return to a known physical position which can mitigate drifting problems. $\endgroup$
    – st2000
    Commented Aug 7, 2023 at 12:11
  • $\begingroup$ The question is really "how could we achieve the advertised accuracy", as the datasheet for the lsm6dsv lists the drift as 0.7 degrees per 5 minutes, but we don't get anywhere near that. $\endgroup$
    – Gorbit99
    Commented Aug 7, 2023 at 19:03
  • $\begingroup$ This may be the drift at rest. How is the data sheet worded where you pulled this specification from? $\endgroup$
    – st2000
    Commented Aug 8, 2023 at 2:15
0
$\begingroup$

This is very likely a gyroscope calibration issue, in particular your yaw angular velocity sensor (e.g. gyro_z). Consider to calibrate at rest your gyro for a few seconds (simple average over samples) and subtract at runtime such offset. This should alleviate the problem.

If you are a sensor fusion export, I suggest to code yourself a kalman filter that also estimates imu biases online, bypassing the need for a manual calibration and being robust to temperature/electronic flickering over time.

Improve this answer
$\endgroup$
4
  • $\begingroup$ The IMU is doing sensor fusion itself. I believe the issue was solved by increasing the datarate of the gyro and accelerometer. The resulting rotations were much more accurate afterwards. $\endgroup$
    – Gorbit99
    Commented Jan 6 at 5:25
  • $\begingroup$ well, of course, you cannot expect good sensor fusion if you sample your IMU at anything below 100 hz... $\endgroup$
    – SystemSigma_
    Commented Jan 6 at 11:28
  • $\begingroup$ it wasn't below 100 Hz, it was at 120 or 240 or something, and it got raised 7.68kHz $\endgroup$
    – Gorbit99
    Commented Jan 6 at 17:32
  • 1
    $\begingroup$ This still does not make any sense, you won't get rid of gyro drift simply by increasing to such extreme speeds your output data rate. Maybe the sensor internally does something you don't know or it triggers some internal routine at higher speeds. Read your datasheet carefully $\endgroup$
    – SystemSigma_
    Commented Jan 7 at 9:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.