raw and pitch change simultaneously

[aa18514]

Hi,

I can confirm the following:

a) I have calibrated my magnetometer, accelerometer and gyroscope correctly.

b) The data being passed in the Mahony and the Madgewick filter is in the correct order.
(ax, ay, az, gx, gy, gz, -1 * mx, my, mz)

I seem to be getting correct orientation for raw, but as pitch changes from +PI/2 to -PI/2, I also observe a change in yaw by PI radians, as pitch starts approach PI/2 radians, yaw starts getting distorted. I would be grateful if you could please provide some insight.

Many thanks,

[kriswiner]

No absolute orientation estimation is going to work well at the poles. Can you answer this question? When you are standing at the North pole of Earth, which direction is South?

…

On Fri, Apr 27, 2018 at 7:55 AM, aa18514 ***@***.***> wrote: Hi, I can confirm the following: a) I have calibrated my magnetometer, accelerometer and gyroscope correctly. b) The data being passed in the Mahony and the Madgewick filter is in the correct order. (ax, ay, az, gx, gy, gz, -1 * mx, my, mz) I seem to be getting correct orientation for raw, but as pitch changes from +PI/2 to -PI/2, I also observe a change in yaw by PI radians, as pitch starts approach PI/2 radians, yaw starts getting distorted. I would be grateful if you could please provide some insight. Many thanks, — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#11>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGY1qmzFvbblfX0_8rBCcHDQzWq7G1Zhks5tszFmgaJpZM4TqhT3> .

[aa18514]

I saw in your code, you have accelgyrocalLSM9DS1() and magcalLSM9DS1() functions, I run it and move the chip in figure 8 and take average of the bias values, is it a correct way to do calibration ? will the calibration affect the orientation ?

The real question is:
I believe that the roll, pitch and yaw should be independent to each other. When you rotate the chip in one direction, for example pitch, the other two should stay nearly the same. When I do one complete rotation, yaw and pitch change by the same amount, (for example one complete rotation for yaw by 2 * pi radians also gives the same change for pitch). so what is the problem ?

[kriswiner]

Are you sure the max x and y axes are aligned with the accel/gyro x and y axes? This is from my sketch: MadgwickQuaternionUpdate(ax, ay, az, gx*PI/180.0f, gy*PI/180.0f, gz*PI/180.0f, -mx, my, mz);

…

On Fri, Apr 27, 2018 at 8:47 AM, aa18514 ***@***.***> wrote: I saw in your code, you have accelgyrocalLSM9DS1() and magcalLSM9DS1() functions, I run it and move the chip in figure 8 and take average of the bias values, is it a correct way to do calibration ? will the calibration affect the orientation ? The real question is: I believe that the roll, pitch and yaw should be independent to each other. When you rotate the chip in one direction, for example pitch, the other two should stay nearly the same. When I do one complete rotation, yaw and pitch change by the same amount, (for example one complete rotation for yaw by 2 * pi radians also gives the same change for pitch). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGY1qr9uZ05Bg5lGcFky9PCFS-tXe3hDks5tsz2hgaJpZM4TqhT3> .

[aa18514]

the max x and y axes seem to be aligned with the accel/gyro x and y axes. I also think the response of the madgwick filter may be delayed which may be causing the issue

[kriswiner]

mag x is accel/gyro -x and you have to run the fusion rate at least 5x the sample rate for accurate results. What kind of MCU are you using?

…

On Fri, Apr 27, 2018 at 9:36 AM, aa18514 ***@***.***> wrote: the max x and y axes seem to be aligned with the accel/gyro x and y axes. I also think the response of the madgwick filter may be delayed which may be causing the issue — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGY1quuv2wMOPdtLkWGWjh92UFGFxwgzks5ts0kqgaJpZM4TqhT3> .

[aa18514]

I can confirm mag x is accel/gyro -x, I am using esp arduino board... "..fusion rate at least 5x the sample rate", I have not tried this yet, let me have a try and get back to you. Do you think value of beta may also affect the rate?

[kriswiner]

beta is irrelevant. With ESP8266 you should get ~1 kHz fusion rate.

…

On Fri, Apr 27, 2018 at 10:15 AM, aa18514 ***@***.***> wrote: I can confirm mag x is accel/gyro -x, I am using esp arduino board... "..fusion rate at least 5x the sample rate", I have not tried this yet, let me have a try and get back to you. Do you think value of beta may also affect the rate? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGY1qmWlP0jQ4AQjK1NCmWEnYyDcd-f7ks5ts1JBgaJpZM4TqhT3> .

[aa18514]

I can also confirm the fusion rate I get on ESP8266 board fluctuates slightly around 3.7 kHz (3.5kHz - 3.8 kHz)

[kriswiner]

If you have properly calibrated the sensors then this is the best you can do.

…

On Fri, Apr 27, 2018 at 10:45 AM, aa18514 ***@***.***> wrote: I can also confirm the fusion rate I get on ESP8266 board fluctuates around 3.7 kHz — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGY1quUbx5NYpVbOv6ArRBB_3dcAe9BAks5ts1krgaJpZM4TqhT3> .

[aa18514]

I use motionCal to calibrate my sensors please find my results as follows:

[aa18514]

to be more specific as pitch goes from 0 degrees to -60 degrees, yaw goes from 0 to -40 degrees. However a change in pitch from 0 degrees to 60 degrees gives no change in yaw, as expected

[kriswiner]

Something is wrong with either your sensor data (not calibrated) or your Madgwick function. The sketch I reposited at Github does not do this.

…

On Sat, Apr 28, 2018 at 10:29 AM, aa18514 ***@***.***> wrote: to be more specific as pitch goes from 0 degrees to -60 degrees, yaw goes from 0 to -40 degrees. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGY1qsnuj2hb0tlV_Mcd4o_Zv_9AO652ks5ttKbfgaJpZM4TqhT3> .

[aa18514]

Dear Kris,

Many thanks for your support, I can confirm the following:

a) The Mahony and the Madgewick functions remain unchanged.

I believe the problem could potentially come from the calibration. What is interesting is that I tried using the same approach (i.e motionCal to calibrate) with Adafruit NXP 9 DOF (https://learn.adafruit.com/nxp-precision-9dof-breakout?view=all) and that seems to perform fine.

I believe that motionCal uses microTesla base units, which is why while calibrating lsm9ds1, I tried catering for this and made the appropriate changes, the following lines change from:

mx = (float)magCount[0] * mRes - magBias[0]
my = (float)magCount[1] * mRes - magBias[1]
mz = (float)magCount[2] * mRes - magBias[2]

to the following:
mx = mRes * (0.1f * (float) magCount[0] - magBias[0]);
my = mRes * (0.1f *(float) magCount[1] - magBias[1]);
mz = mRes * (0.1f * (float) magCount[2] - magBias[2]);

perhaps I am missing something else?

Best Wishes

[kriswiner]

The accel and mag units are normalized anyway in the fusion algorithm so this is likely not the issue. This sounds like an NED issue, but your function call looks OK, not sure. It seems to work for me. Are you sure you are usin the LSM6DS1 and not the LSM6DS0?

…

On Sun, Apr 29, 2018 at 4:37 PM, aa18514 ***@***.***> wrote: Dear Kris, Many thanks for your support, I can confirm the following: a) The Mahony and the Madgewick functions remain unchanged. I believe the problem could potentially come from the calibration. What is interesting is that I tried using the same approach (i.e motionCal to calibrate) with Adafruit NXP 9 DOF (https://learn.adafruit.com/ nxp-precision-9dof-breakout?view=all) and that seems to perform fine. I believe that motionCal uses microTesla base units, which is why while calibrating lsm9ds1, I tried catering for this and made the appropriate changes, the following lines change from: mx = (float)magCount[0] * mRes - magBias[0] my = (float)magCount[1] * mRes - magBias[1] mz = (float)magCount[2] * mRes - magBias[2] to the following: mx = mRes * (0.1f * (float) magCount[0] - magBias[0]); my = mRes * (0.1f *(float) magCount[1] - magBias[1]); mz = mRes * (0.1f * (float) magCount[2] - magBias[2]); perhaps I am missing something else? Best Wishes — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGY1qunYzG1SJL7zNZ-MICik07iAP7c_ks5ttk6hgaJpZM4TqhT3> .

[kriswiner]

One oother thing, the gyro units have to be converted to radians/sec before being passed to the fusion algorithm. Are you doing this? On Sun, Apr 29, 2018 at 4:54 PM, Tlera Corporation <tleracorp@gmail.com> wrote:

…

The accel and mag units are normalized anyway in the fusion algorithm so this is likely not the issue. This sounds like an NED issue, but your function call looks OK, not sure. It seems to work for me. Are you sure you are usin the LSM6DS1 and not the LSM6DS0? On Sun, Apr 29, 2018 at 4:37 PM, aa18514 ***@***.***> wrote: > Dear Kris, > > Many thanks for your support, I can confirm the following: > > a) The Mahony and the Madgewick functions remain unchanged. > > I believe the problem could potentially come from the calibration. What > is interesting is that I tried using the same approach (i.e motionCal to > calibrate) with Adafruit NXP 9 DOF (https://learn.adafruit.com/nx > p-precision-9dof-breakout?view=all) and that seems to perform fine. > > I believe that motionCal uses microTesla base units, which is why while > calibrating lsm9ds1, I tried catering for this and made the appropriate > changes, the following lines change from: > > mx = (float)magCount[0] * mRes - magBias[0] > my = (float)magCount[1] * mRes - magBias[1] > mz = (float)magCount[2] * mRes - magBias[2] > > to the following: > mx = mRes * (0.1f * (float) magCount[0] - magBias[0]); > my = mRes * (0.1f *(float) magCount[1] - magBias[1]); > mz = mRes * (0.1f * (float) magCount[2] - magBias[2]); > > perhaps I am missing something else? > > Best Wishes > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#11 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AGY1qunYzG1SJL7zNZ-MICik07iAP7c_ks5ttk6hgaJpZM4TqhT3> > . >

[aa18514]

Dear Kris,

I can confirm that I am using the LSM6DS1 using MCU esp8266, I can also confirm that the data is being passed as radians/s to the fusion algorithm,

[kriswiner]

Not sure what else I can say. You appear to be doing everything right so it should work for you as it does for me.

…

On Mon, Apr 30, 2018 at 6:20 AM, aa18514 ***@***.***> wrote: Dear Kris, I can confirm that I am using the LSM6DS1 using MCU esp8266, I can also confirm that the data is being passed as radians/s to the fusion algorithm, — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGY1qo3674htAQroBM3siIZaNV8-viO4ks5ttw-lgaJpZM4TqhT3> .

[aa18514]

Hi Kris,

Many thanks for your reply, I used a new LSM9DS1 chip and followed the same steps and everything seems to work. I consider the thread closed.