LSM9DS0 Question about serious drift

Hi Kris,

I am currently using LSM9DS1 together with a SparkFun Arduino Pro Micro 3.3V 8MHz board to extract data from the sensor, and feed the data serially via SPI / USB connection to a Processing sketch that runs on my computer. I have been using your resources as a guideline for setting up the sensor and the Madgwick Filter on Processing. (Thank you for making your work so accessible and well commented!) The Processing sketch receives data from Arduino at about 200 Hz, while the filter continuously runs during other cycles, and updates a 3D box model in real time on the processing window. I am using this model to verify that the filter is working correctly.

I am running into a really odd and frustrating issue with the Madgwick Filter. When I rotate the board about a single axis slowly, the estimated results are quite accurate, which suggests that the gyroscope estimations are working well. However, when I move it around at a slightly more complex manner, for example trace a circular shape in the air or wiggle it around in a wavy pattern, the model will start twirling away with the motion, then very quickly and completely lose its real orientation. I know it is probably drift, and the problem seems to point to a very serious calibration problem, but I have taken care to calibrate the sensors very meticulously, so I’m tempted to think that it’s not the calibration.

I calibrated the accelerometer manually by taking the max and min values of each of the axis aligned with the direction of gravity, and averaged the two to find the bias. I calibrated the gyroscopes by leaving it at rest on my desk for about 30 seconds, and averaged the values to get the bias. I calibrated the magnetometers using an ellipsoid fit program that I found online, and obtained the center bias and the transformation matrix, which is applied to every magnetometer reading it receives. I hard-coded all of these calibration values onto the processing sketch.

The filter is definitely updated at least 5 times the sampling frequency (since I’m running it on my computer’s CPU), and that the bandwidths are set at about 10 – 20% that the sampling frequency.

There was a lot of helpful information from this conversation you had with kulve. I read that on LSM9DS1, the direction of magnetometer z-axis is pointing in the opposite direction of that of the gyroscope and accelerometer. I was able to confirm this on the data sheet and found that the x axis was also reversed. I simply added a negative sign on the incoming x and z-values of the magnetometer data before feeding it to the filter, but I don’t know if that’s an acceptable way to do this…

I thought it might be a sensor fault, and tried it on another identical sensor, but the same problem persists. I think there must be something inherently wrong with my set up or my code… I have only a very basic idea of how the filter works, and I've run out of ideas now... I kind of a novice at programming and don't have a deep understanding of what happens under the hood... Could it be that some how the filter works best when it runs on the same board as the sensor? Could it be that updating graphics in real time simultaneously affects the ability for the CPU to make precise enough time measurements for the filter to update accurately?

I hope that you or others browsing might be able to give me some clues…!

Please find my code here: Main Processing Sketch Supporting IMU Class

Thank you in advance for taking the time to help me out here! :)

Oct 27 '16 20:10 schanwanyu

Looks like you have done all the sensible things required to get good results. There is nothing tricky about the Madgwick or Mahony filters; they are just steepest descent-like iterative filters that aren't that complicated. Most likely there is something wrong with sensor data or the way you are feeding the scaled sensor data into the fusion filter functions.

On page 10 of the data sheet you can see the sensor axis orientations. Gyro and accel x, y, and z are aligned, as expected. But mag x is opposite accel/gyro x, so yes, the correct way to implement the Madgwick filter is to pass ax, ay, az, gx, gy, and gz, and then, -mx, my, mz. This should produce sensible results. Check that the yaw, pitch, and roll respond as you expect them when undergoing small rotations. In addition to pointing to true North when the yaw reads zero, the pitch and roll should remain constant when changing yaw only, and vice versa. The yaw and roll should remain constant when changing pitch, etc.

If not, the trouble is likely in the sensor response (assuming adequate calibration) and not the filter itself. If you are using the sensor indoors, next to a computer, or somewhere else where there might be magnetic transients the simple filter will not be able to detect and correct for these misleading magnetometer excursions. This is another although less likely source of problems.

We have seen a lot of variation in 3D orientation estimation due to the quality of the underlying sensor data, more so than the sensor fusion algorithm. In other words, we have been able to get 4 degree heading accuracy with the MPU9250 and the Madgwick filter, but usually only get 6 or 7 degree heading accuracy using the BNO055, which uses Bosch's fusion filter package. The difference is the sensors, the MPU9250 (MPU6500 + AK8963) is simply superior (lower jitter, more linear response) than the Bosch sensors, even though the Bosch fusion algorithms are significantly better than the simple Madgwick filter. My point is, maybe the LSM9DS1 is not capable of high-accuracy, stable orientation estimation no matter what filter you might choose.

Kris

-----Original Message----- From: schanwanyu [mailto:[email protected]] Sent: October 27, 2016 1:47 PM To: kriswiner/LSM9DS0 Subject: [kriswiner/LSM9DS0] Question about serious drift (#10)

Hi Kris,

I am currently using LSM9DS1 together with a SparkFun Arduino Pro Micro 3.3V 8MHz board to extract data from the sensor, and feed the data serially via SPI / USB connection to a Processing sketch that runs on my computer. I have been using your resources as a guideline for setting up the sensor and the Madgwick Filter on Processing. (Thank you for making your work so accessible and well commented!) The Processing sketch receives data from Arduino at about 200 Hz, while the filter continuously runs during other cycles, and updates a 3D box model in real time on the processing window. I am using this model to verify that the filter is working correctly.

I am running into a really odd and frustrating issue with the Madgwick Filter. When I rotate the board about a single axis slowly, the estimated results are quite accurate, which suggests that the gyroscope estimations are working well. However, when I move it around at a slightly more complex manner, for example trace a circular shape in the air or wiggle it around in a wavy pattern, the model will start twirling away with the motion, then very quickly and completely lose its real orientation. I know it is probably drift, and the problem seems to point to a very serious calibration problem, but I have taken care to calibrate the sensors very meticulously, so I'm tempted to think that it's not the calibration.

I calibrated the accelerometer manually by taking the max and min values of each of the axis aligned with the direction of gravity, and averaged the two to find the bias. I calibrated the gyroscopes by leaving it at rest on my desk for about 30 seconds, and averaged the values to get the bias. I calibrated the magnetometers using an ellipsoid fit program that I found online, and obtained the center bias and the transformation matrix, which is applied to every magnetometer reading it receives. I hard-coded all of these calibration values onto the processing sketch.

The filter is definitely updated at least 5 times the sampling frequency (since I'm running it on my computer's CPU), and that the bandwidths are set at about 10 - 20% that the sampling frequency.

There was a lot of helpful information from this conversation https://github.com/kriswiner/LSM9DS0/issues/8 you had with kulve. I read that on LSM9DS1, the direction of magnetometer z-axis is pointing in the opposite direction of that of the gyroscope and accelerometer. I was able to confirm this on the data sheet and found that the x axis was also reversed. I simply added a negative sign on the incoming x and z-values of the magnetometer data before feeding it to the filter, but I don't know if that's an acceptable way to do this.

I thought it might be a sensor fault, and tried it on another identical sensor, but the same problem persists. I think there must be something inherently wrong with my set up or my code. I have only a very basic idea of how the filter works, and I've run out of ideas now... I kind of a novice at programming and don't have a deep understanding of what happens under the hood... Could it be that some how the filter works best when it runs on the same board as the sensor? Could it be that updating graphics in real time simultaneously affects the ability for the CPU to make precise enough time measurements for the filter to update accurately?

I hope that you or others browsing might be able to give me some clues.!

Please find my code here: Main Processing Sketch http://pastie.org/private/sepd8dbqresu0alzvbtba# Supporting IMU Class http://pastie.org/private/jnsk464madg0hwhablqodg

Thank you in advance for taking the time to help me out here! :)

You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kriswiner/LSM9DS0/issues/10 , or mute the thread <https://github.com/notifications/unsubscribe-auth/AGY1qsZYEBy3YkkyBE_tOBbj9 RuFccsiks5q4Q2ygaJpZM4KiznQ> . <https://github.com/notifications/beacon/AGY1qmXJvTSzUtWlAnJ9o7vNpCqNjqUZks5 q4Q2ygaJpZM4KiznQ.gif>

Oct 28 '16 06:10 kriswiner

FYI, some results with the LSM9DS0 to illustrate my previous point...

https://github.com/kriswiner/EM7180_SENtral_sensor_hub/wiki/H.-Typical-Resul ts-Using-the-SENtral