Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question about serious drift #10

Open
schanwanyu opened this issue Oct 27, 2016 · 5 comments
Open

Question about serious drift #10

schanwanyu opened this issue Oct 27, 2016 · 5 comments

Comments

@schanwanyu
Copy link

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! :)

@kriswiner
Copy link
Owner

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:notifications@github.com]
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
#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
#10 , or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qsZYEBy3YkkyBE_tOBbj9
RuFccsiks5q4Q2ygaJpZM4KiznQ> .
<https://github.com/notifications/beacon/AGY1qmXJvTSzUtWlAnJ9o7vNpCqNjqUZks5
q4Q2ygaJpZM4KiznQ.gif>

@kriswiner
Copy link
Owner

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

-----Original Message-----
From: schanwanyu [mailto:notifications@github.com]
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
#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
#10 , or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGY1qsZYEBy3YkkyBE_tOBbj9
RuFccsiks5q4Q2ygaJpZM4KiznQ> .
<https://github.com/notifications/beacon/AGY1qmXJvTSzUtWlAnJ9o7vNpCqNjqUZks5
q4Q2ygaJpZM4KiznQ.gif>

@schanwanyu
Copy link
Author

Thank you, Kris, for the feedback. It will take me some time, but I will start investigating the problem from the sensor output level. I feel more confident about the filter now. I will let you know as soon as I've identified the culprit! :)

Thanks!

@schanwanyu
Copy link
Author

Hi Kris,

I finally found out what was causing the strange drift problem...! Apparently the LSM9DS1 chip's default sign for gyroscope is reversed...! I flipped the signs of the gyroscope outputs, and the filter works perfectly! I still don't know whether this is simply a property of LSM9DS1, or whether that happens to other chips as well. I don't recall ever seeing anyone else changing this setting on their sensors. Well I hope this helps anyone who is struggling with the same problem.

Thanks!

@kriswiner
Copy link
Owner

kriswiner commented Apr 22, 2020 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants