Arduino Nano 33 BLE with LSM9DS1 sensor -> problem with implementation Madgwick libary

[mataldomen]

Hey Kris,

I am writing to You becouse I have big problem with my Arduino board and I can't resolve this from week.

I want to implement Madgwick filter and quaternions into my Arduino Nano 33 BLE board. After that i receive a lot of really crazy numbers without any sense.

I configured My board with ArduinoLSM9DS1 libary (https://www.arduino.cc/en/Reference/ArduinoLSM9DS1) it's really simply part of code in comparison into yours. For me is perfect beacouse I am beginner.

In my first use of this board I used data from sensors and I calculated Eulers angles to receive pitch,roll and yaw. I received preety good numbers.

Nextly I want to implement madgwick from here(https://x-io.co.uk/open-source-imu-and-ahrs-algorithms/)

Maybe You know with Your experience why I still cant use Madgwick on my board ? Maybe You done someting before on this board ?

[kriswiner]

Wow, way wrong.

Did you move the sensors in all three dimensions while gathering the mag calibration data?

On Wed, Mar 31, 2021 at 8:46 PM willyconcarne12 @.***> wrote:

Thanks for sending this - I tried out adding the mag_max and mag_min from the code included: (int16_t mag_max[3] = {-32767, -32767, -32767}, mag_min[3] = {32767, 32767, 32767};) instead of (int16_t mag_max[3] = {0, 0, 0}, mag_min[3] = {0, 0, 0};)

Calibration Result: [image: Calibration 2] https://user-images.githubusercontent.com/58528850/113240510-7746fc80-9272-11eb-9ce3-5df72f57ef8a.PNG

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/LSM9DS1/issues/14#issuecomment-811616619, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKT6LNFAD7JJUS5EPVDTGPUBPANCNFSM4KWHMCKQ .

[j-mcc1993]

One thing that hasn't come up here... have you all been adjusting the magnetic declination parameter? That parameter depends on your location, and unless you happen to live in the SF Bay Area, the parameter that's in the code won't be accurate to your location.

[willyconcarne12]

@kriswiner Doh! Yes I moved the sensor in a figure eight like it said (rotating it while also waving) while calibrating. Just tried it again with it sitting completely still the entire calibration and got these results.

@j-mcc1993 great point - yes I had updated the location (using https://www.magnetic-declination.com/). I'm in Dallas so have +2.56 in there vs 13.3 for San Fran.

I'm hoping that once calibration is fixed, that should be the fix for my unstable axis when rotating the sensor (ex. x-axis pointing left from sensor start position --> perform twist motion with the sensor and return to start position --> x-axis is now pointing up or some other direction).

https://user-images.githubusercontent.com/58528850/113311491-fb2ed200-92ce-11eb-804d-28863846c505.mp4

[kriswiner]

Something is way wrong with the mag data. How are you applying the mag calibrations?

On Thu, Apr 1, 2021 at 7:45 AM willyconcarne12 @.***> wrote:

@kriswiner https://github.com/kriswiner Doh! Yes I moved the sensor in a figure eight like it said (rotating it while also waving) while calibrating. Just tried it again with it sitting completely still the entire calibration and got these results.

[image: Calibration 3] https://user-images.githubusercontent.com/58528850/113310964-675d0600-92ce-11eb-83c7-92752ddd1b6c.PNG

@j-mcc1993 https://github.com/j-mcc1993 great point - yes I had updated the location (using https://www.magnetic-declination.com/). I'm in Dallas so have +2.56 in there vs 13.3 for San Fran.

I'm hoping that once calibration is fixed, that should be the fix for my unstable axis when rotating the sensor (ex. x-axis pointing left from sensor start position --> perform twist motion with the sensor and return to start position --> x-axis is now pointing up or some other direction).

https://user-images.githubusercontent.com/58528850/113311491-fb2ed200-92ce-11eb-804d-28863846c505.mp4

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/LSM9DS1/issues/14#issuecomment-811958344, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKWUKYOZWWDGAOH2Q6DTGSBKBANCNFSM4KWHMCKQ .

[willyconcarne12]

Hate to sound helpless but I'm not sure what to pull to answer your question (and thank you so much for helping/any guidance! really trying to learn).

Should I send you my sketch?

[kriswiner]

Yes, @.***

On Thu, Apr 1, 2021 at 10:23 AM willyconcarne12 @.***> wrote:

Hate to sound helpless but I'm not sure what to pull to answer your question (and thank you so much for helping/any guidance! really trying to learn).

Should I send you my sketch?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/LSM9DS1/issues/14#issuecomment-812055624, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKQKTT2PUTPGXKL7EM3TGSTY5ANCNFSM4KWHMCKQ .

[willyconcarne12]

Awesome. Your email is redacted on here (@.***) but I just sent you a private message on hackaday.io (if you still have access to that) w/ a link to the sketch.

[kriswiner]

// Calculate the magnetometer values in milliGauss // Include factory calibration per data sheet and user environmental corrections mx = (float)magCount[0] mRes; // - magBias[0]; // get actual magnetometer value, this depends on scale being set my = (float)magCount[1] mRes; // - magBias[1]; mz = (float)magCount[2] mRes; // - magBias[2];*

You are not applying the magBias values, why not? Uncomment and try again...

On Thu, Apr 1, 2021 at 11:19 AM willyconcarne12 @.***> wrote:

Awesome. Your email is redacted on here (@.***) but I just sent you a private message on hackaday.io (if you still have access to that) w/ a link to the sketch.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/LSM9DS1/issues/14#issuecomment-812086263, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKUOJA2RBQPWT6PAW53TGS2KLANCNFSM4KWHMCKQ .

[willyconcarne12]

[kriswiner]

Better, but there is still something wrong. When you weren;t using the biases, you were showing very small mag values. Probably a scaling issue somewhere...

Look up the local mag field expected (use USGS site) and compare to what you are getting. Where I am I should see (X,Y, Z) 50, 200, and 400 milligauss, and when properly calibrated this is about what I see. Plus try the face up/face down test. Are the Mz values equal and opposite? What is the scale value of the mag vector, should be ~450 mG, etc. Lots of tests to see if your mag values are reasonable.

On Thu, Apr 1, 2021 at 11:39 AM willyconcarne12 @.***> wrote:

[image: Calibration 4] https://user-images.githubusercontent.com/58528850/113339164-b2d3dc00-92ef-11eb-914c-a2d8f50e8b63.PNG

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/LSM9DS1/issues/14#issuecomment-812097380, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKSUQUW2OFJ545XNBGDTGS4XZANCNFSM4KWHMCKQ .

[kriswiner]

OK, I just noticed that the mag biases are set to be written to the mag bias registers, that's why it was commented out in the main loop. So I would go back to commenting these out and then ask, why are the mag values so low?

On Thu, Apr 1, 2021 at 11:50 AM Tlera Corporation @.***> wrote:

Better, but there is still something wrong. When you weren;t using the biases, you were showing very small mag values. Probably a scaling issue somewhere...

Look up the local mag field expected (use USGS site) and compare to what you are getting. Where I am I should see (X,Y, Z) 50, 200, and 400 milligauss, and when properly calibrated this is about what I see. Plus try the face up/face down test. Are the Mz values equal and opposite? What is the scale value of the mag vector, should be ~450 mG, etc. Lots of tests to see if your mag values are reasonable.

On Thu, Apr 1, 2021 at 11:39 AM willyconcarne12 @.***> wrote:

[image: Calibration 4] https://user-images.githubusercontent.com/58528850/113339164-b2d3dc00-92ef-11eb-914c-a2d8f50e8b63.PNG

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/LSM9DS1/issues/14#issuecomment-812097380, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKSUQUW2OFJ545XNBGDTGS4XZANCNFSM4KWHMCKQ .

[willyconcarne12]

I have been pouring through... I wonder if it has to do with the Device address and/or Mag address. I am only using an Arduino Nano 33 BLE (i.e. NOT +MS5611 Teensy 3.1 Add-On shield). However, when I set #define ADO 1 to #define ADO 0, I can't get any data to come across the monitor.

// Using the LSM9DS1+MS5611 Teensy 3.1 Add-On shield, ADO is set to 1 // Seven-bit device address of accel/gyro is 110101 for ADO = 0 and 110101 for ADO = 1

define ADO 1

if ADO

define LSM9DS1XG_ADDRESS 0x6B // Device address when ADO = 1

define LSM9DS1M_ADDRESS 0x1E // Address of magnetometer

define MS5611_ADDRESS 0x77 // Address of altimeter

else

define LSM9DS1XG_ADDRESS 0x6A // Device address when ADO = 0

define LSM9DS1M_ADDRESS 0x1D // Address of magnetometer

define MS5611_ADDRESS 0x77 // Address of altimeter

endif

[kriswiner]

Has nothing to do with device addresses.

It has to do with how the mag data is being converted from bytes to int16, how it is being scaled to milligs and how the calibration is being applied.

What I don;t understand is the sketches in my github repo just work, so how could you be having such trouble? Is it the Nano?

On Thu, Apr 1, 2021 at 5:36 PM willyconcarne12 @.***> wrote:

I have been pouring through... I wonder if it has to do with the Device address and/or Mag address. I am only using an Arduino Nano 33 BLE (i.e. NOT +MS5611 Teensy 3.1 Add-On shield). However, when I set #define ADO 1 to

define ADO 0, I can't get any data to come across the monitor.

// Using the LSM9DS1+MS5611 Teensy 3.1 Add-On shield, ADO is set to 1 // Seven-bit device address of accel/gyro is 110101 for ADO = 0 and 110101 for ADO = 1

define ADO 1

if ADO

define LSM9DS1XG_ADDRESS 0x6B // Device address when ADO = 1

define LSM9DS1M_ADDRESS 0x1E // Address of magnetometer

define MS5611_ADDRESS 0x77 // Address of altimeter

else

define LSM9DS1XG_ADDRESS 0x6A // Device address when ADO = 0

define LSM9DS1M_ADDRESS 0x1D // Address of magnetometer

define MS5611_ADDRESS 0x77 // Address of altimeter

endif

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/LSM9DS1/issues/14#issuecomment-812251845, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKVCTZKM6EF5NYQNZ73TGUGSVANCNFSM4KWHMCKQ .

[willyconcarne12]

I apologize in advance if this is also not anywhere close to the solution, but trying to help. I do see a few differences looking at the sketch vs. the code snippet in the wiki you sent (https://github.com/kriswiner/MPU6050/wiki/Simple-and-Effective-Magnetometer-Calibration).

Sketch includes a "uint8_t data[6]" uint8_t data[6]; // data array to hold mag x, y, z, data uint16_t ii = 0, sample_count = 0; int32_t mag_bias[3] = {0, 0, 0}; int16_t mag_max[3] = {-32767, -32767, -32767}, mag_min[3] = {32767, 32767, 32767};

vs. wiki snippet uint16_t ii = 0, sample_count = 0; int32_t mag_bias[3] = {0, 0, 0}, mag_scale[3] = {0, 0, 0}; int16_t mag_max[3] = {-32767, -32767, -32767}, mag_min[3] = {32767, 32767, 32767}, mag_temp[3] = {0, 0, 0};

I also see a dest 1 AND dest 2 in mag_scale of the snippet but only dest 1 in the sketch (or at least in the same section; may be located elsewhere or not needed?).

Sketch void magcalLSM9DS1(float * dest1)

vs. snippet void magcalMPU9250(float * dest1, *float dest2**) . . . // Get soft iron correction estimate mag_scale[0] = (mag_max[0] - mag_min[0])/2; // get average x axis max chord length in counts mag_scale[1] = (mag_max[1] - mag_min[1])/2; // get average y axis max chord length in counts mag_scale[2] = (mag_max[2] - mag_min[2])/2; // get average z axis max chord length in counts

float avg_rad = mag_scale[0] + mag_scale[1] + mag_scale[2]; avg_rad /= 3.0;

dest2[0] = avg_rad/((float)mag_scale[0]); dest2[1] = avg_rad/((float)mag_scale[1]); dest2[2] = avg_rad/((float)mag_scale[2]);

[kriswiner]

That is an extra bit of calibration to equalize the response on the three axes. Not the cause of your trouble.

What I don't understand is that even without mag calibration you should be seeing reasonable values for the mag field. Your mag offset biases are rather large and when you apply them you are getting somewhat odd mag field values.

I would take a look at the mag output with no calibration, and then with the calibration to see if the code is doing what you expect. Even just siting still on a table and uncalibrated, you should get sensible mag data that approximates what the USGS says is typical for your area.

On Thu, Apr 1, 2021 at 7:29 PM willyconcarne12 @.***> wrote:

I apologize in advance if this is also not anywhere close to the solution, but trying to help. I do see a few differences looking at the sketch vs. the code snippet in the wiki you sent ( https://github.com/kriswiner/MPU6050/wiki/Simple-and-Effective-Magnetometer-Calibration ).

Sketch includes a "uint8_t data[6]" uint8_t data[6]; // data array to hold mag x, y, z, data uint16_t ii = 0, sample_count = 0; int32_t mag_bias[3] = {0, 0, 0}; int16_t mag_max[3] = {-32767, -32767, -32767}, mag_min[3] = {32767, 32767, 32767};

vs. wiki snippet uint16_t ii = 0, sample_count = 0; int32_t mag_bias[3] = {0, 0, 0}, mag_scale[3] = {0, 0, 0}; int16_t mag_max[3] = {-32767, -32767, -32767}, mag_min[3] = {32767, 32767, 32767}, mag_temp[3] = {0, 0, 0};

I also see a dest 1 AND dest 2 in mag_scale of the snippet but only dest 1 in the sketch (or at least in the same section; may be located elsewhere or not needed?).

Sketch void magcalLSM9DS1(float * dest1)

vs. snippet void magcalMPU9250(float dest1, float dest2) . . . // Get soft iron correction estimate mag_scale[0] = (mag_max[0] - mag_min[0])/2; // get average x axis max chord length in counts mag_scale[1] = (mag_max[1] - mag_min[1])/2; // get average y axis max chord length in counts mag_scale[2] = (mag_max[2] - mag_min[2])/2; // get average z axis max chord length in counts

float avg_rad = mag_scale[0] + mag_scale[1] + mag_scale[2]; avg_rad /= 3.0;

dest2[0] = avg_rad/((float)mag_scale[0]); dest2[1] = avg_rad/((float)mag_scale[1]); dest2[2] = avg_rad/((float)mag_scale[2]);

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/LSM9DS1/issues/14#issuecomment-812282403, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKU3ORAUL7JGABONTKDTGUTZVANCNFSM4KWHMCKQ .

[willyconcarne12]

This might what these guys were wrestling with?

https://forum.arduino.cc/index.php?topic=663160.msg4467543#msg4467543

[kriswiner]

No, this is not your problem yet.

Here are the steps to get accurate mag data for each axis:

1) read two register bytes 2) combine two register bytes into one int16_t signed integer 3) scale signed integer to get field value in Gauss or milliGauss

I suspect your code (or your Nano) is not doing one or more of these steps correctly.

You can verify by checking the mag field you measure against what the USGS says you should expect. Once you have done this, you can move on to proper calibration.

On Fri, Apr 2, 2021 at 11:41 AM willyconcarne12 @.***> wrote:

This might what these guys were wrestling with?

https://forum.arduino.cc/index.php?topic=663160.msg4467543#msg4467543

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/LSM9DS1/issues/14#issuecomment-812660084, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKUEIEW6FR75IT36VUTTGYFWVANCNFSM4KWHMCKQ .

[willyconcarne12]

Thank you for that! Hate to ask another ignorant question, but is this the area of mag calibration adjustment once verifying?

the 32768.0 denominator here

void getMres() { switch (Mscale) { // Possible magnetometer scales (and their register bit settings) are: // 4 Gauss (00), 8 Gauss (01), 12 Gauss (10) and 16 Gauss (11) case MFS_4G: mRes = 4.0 / 32768.0; break; case MFS_8G: mRes = 8.0 / 32768.0; break; case MFS_12G: mRes = 12.0 / 32768.0; break; case MFS_16G: mRes = 16.0 / 32768.0; break;

and the correlating 32768 in the mag_max and mag_min scale here?

uint8_t data[6]; // data array to hold mag x, y, z, data uint16_t ii = 0, sample_count = 0; int32_t mag_bias[3] = {0, 0, 0}; int16_t mag_max[3] = {-32768, -32768, -32768}, mag_min[3] = {32768, 32768, 32768};

i.e. is 32768 "the number"?

[kriswiner]

The sensor data is signed 16-bits, so max values will be +/- 2^15 = 32768. Verify this for yourself.

On Fri, Apr 2, 2021 at 12:01 PM willyconcarne12 @.***> wrote:

Thank you for that! Hate to ask another ignorant question, but is this the area of mag calibration adjustment once verifying?

the 32768.0 denominator here

void getMres() { switch (Mscale) { // Possible magnetometer scales (and their register bit settings) are: // 4 Gauss (00), 8 Gauss (01), 12 Gauss (10) and 16 Gauss (11) case MFS_4G: mRes = 4.0 / 32768.0; break; case MFS_8G: mRes = 8.0 / 32768.0; break; case MFS_12G: mRes = 12.0 / 32768.0; break; case MFS_16G: mRes = 16.0 / 32768.0; break;

and the correlating 32768 in the mag_max and mag_min scale here?

uint8_t data[6]; // data array to hold mag x, y, z, data uint16_t ii = 0, sample_count = 0; int32_t mag_bias[3] = {0, 0, 0}; int16_t mag_max[3] = {-32768, -32768, -32768}, mag_min[3] = {32768, 32768, 32768};

i.e. is 32768 "the number"?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/kriswiner/LSM9DS1/issues/14#issuecomment-812667700, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKQEEXAY7HW2XPWZ6YTTGYIBHANCNFSM4KWHMCKQ .