search

kriswiner / LSM9DS1

ST's new smaller, lower-power 9-axis motion sensor
41 stars 28 forks source link

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

Open mataldomen opened 4 years ago

mataldomen commented 4 years ago

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 commented 4 years ago

Lots of examples of correcting for gyro offsets in the repository.

If you have a residual gyro offset different from zero at rest, the fusion algorithm interprets this as rotation and therefore heading drift.

Collect gyro data at rest and then you can subtract the offset from the actual data, pretty simply. Same for accel offset calibration.

On Wed, Jun 10, 2020 at 12:33 PM MigSanc notifications@github.com wrote:

@kriswiner https://github.com/kriswiner that seems in agreement with my data. Do you have any reference for why gyro drift actuates especially on the heading value? Or any reference to how calibrate/compensate gyro?

Thanks in advance

— 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-642213608, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKUMKE7G5HQPPI63KATRV7NZXANCNFSM4KWHMCKQ .

PhySan0111 commented 4 years ago

Thanks @kriswiner ! I will give it a go!

mnajib76 commented 4 years ago

This repo has examples of how to calibrate the sensor at runtime, we would need to modify it to conform with the Arduino imu API.

I had a quick look at trying to migrate the code but haven't managed to finish it yet. There is a lot going on.

hi @MichaelFBA , did you manage migrate the code to use with Nano Ble Sense?

PhySan0111 commented 4 years ago

Hi @mnajib76

There is a good code that you can use: https://github.com/FemmeVerbeek/Arduino_LSM9DS1

I used some parts of the library above and some and then after aligning the axis to the NED convention, calibrating and using madgwick filter to calculate quaternions and obtain euler angles, everything worked fined and without drifts. Give it a try

mnajib76 commented 4 years ago

Hi @MigSanc,

Thanks for your reply. I will try to work on it.. Thanks!

mnajib76 commented 4 years ago

Hi @MigSanc ,

If you don't mind could you explain the step you do to get this done in detail? How did you "aligning the axis to the NED convention"? sorry if this question is too basic to ask but I really new with this and I need a guide to help me do this project.. If you don't mind could you give example how you do this? thanks !

PhySan0111 commented 4 years ago

No problem @mnajib76

So, if you check the LSM9DS1 datasheet (https://www.st.com/resource/en/datasheet/lsm9ds1.pdf), you will see that the axis for each sensor is as follows, correct? image

So, the NED convention states that the axis should be aligned with North (N), East(E), Down(D). So, choose which face of the arduino BLE you want to be facing north and to which axis does that correspond. From there align all of them to be equal and follow the same convention. As an example: image In this case, I chose the tip of the arduino board opposed to the USB port connection to be aligned with North. In this case, the x axis from the accelerometer and the gyroscope are already aligned with the convention and the y axis of the magnetometer is as well

aN = ax, gN = gx aE = ay, gE = gy mE = my But all the others, are not. Example: the z axis of accelerometer, gyroscope and magnetometer should all be pointing "Down", so the new transformation becomes the opposite sign aD = -az, gD = -gz, mD = -mZ.

Then, apply the same principle to all others remaining. Post your transformations here and I will check it later on.

Best regards

mnajib76 commented 4 years ago

Hi @MigSanc !

Thanks for your explanation. Sorry for late respond since I've been busy with other stuff. Anyway, my progress as of now I know how to calibrate the acc,gyr, and mag sensor by using this (ref 1) guide.. And after calibrate the data , I feed the calibrated data using "Output of Read method" in the "ref 1" documentation into MadgwickAHRS data fusion algorithm which I get from here (ref 2) . And I did NED convention as you suggest. Kindly see my code below

`#include

include

Madgwick filter; unsigned long microsPerReading, microsPrevious;

void setup() {

// put your setup code here, to run once: Serial.begin(9600);

filter.begin(238);

if (!IMU.begin()) { Serial.println("Failed to initialize IMU!"); exit(1); }

IMU.setAccelFS(3); IMU.setAccelODR(4); IMU.setAccelOffset(-0.006524, -0.012115, -0.017701); IMU.setAccelSlope (1.004801, 0.999822, 0.997208);

IMU.setGyroFS(3); IMU.setGyroODR(4); IMU.setGyroOffset (2.120483, -0.655273, 0.308716); IMU.setGyroSlope (1.165733, 1.136184, 1.163230);

IMU.setMagnetODR(8);
IMU.setMagnetOffset(-12.634888, 38.231812, -2.759399); IMU.setMagnetSlope (1.594882, 1.571591, 1.637965);

microsPerReading = 1000000 / 238; microsPrevious = micros();

}

void loop() { // put your main code here, to run repeatedly: float x_acc, y_acc, z_acc; float x_gyr, y_gyr, z_gyr; float mx, my, mz; float roll, pitch, heading; unsigned long microsNow;

microsNow = micros(); if(microsNow-microsPrevious>=microsPerReading) { if (IMU.accelerationAvailable()&&IMU.gyroscopeAvailable()&& IMU.magneticFieldAvailable()){ IMU.readAccel(x_acc, y_acc, z_acc); IMU.readGyro(x_gyr, y_gyr, z_gyr); IMU.readMagnet(mx, my, mz); }

  filter.update(x_gyr,y_gyr,-z_gyr,x_acc,y_acc,-z_acc,-mx,my,-mz);

  roll = filter.getRoll();
  pitch = filter.getPitch();
  heading = filter.getYaw();

  Serial.print(heading);
  Serial.print(",");
  Serial.print(pitch);
  Serial.print(",");
  Serial.println(roll);

  microsPrevious = microsPrevious + microsPerReading;

}

}`

I put 238Hz as the Output data rate from documentation. However I still not get the reading correctly. In image below is when the sensor stay on flat surface...Hmmm...where did I missed?

image

mnajib76 commented 4 years ago

Opss.. I got this error in my code

So the correct one is `filter.update(x_gyr,y_gyr,-z_gyr,x_acc,y_acc,-z_acc,-mx,my,-mz);. But still now work :(`

kriswiner commented 4 years ago

gyro data needs to be in radians for the filter.

On Fri, Jul 17, 2020 at 10:54 PM mnajib76 notifications@github.com wrote:

Opss.. I got this error in my code

So the correct one is ``filter.update(x_gyr,y_gyr,-z_gyr,x_acc,y_acc,-z_acc,-mx,my,-mz);. But still now work :(

— 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-660432424, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKSJLD4JSADMUMT6CELR4E2HZANCNFSM4KWHMCKQ .

mnajib76 commented 4 years ago

Hi @kriswiner , thanks for highlighting that. However from the code example seems like it suggest convert to degree/s

image

It seems my code show improvement on its values which is make sense after re calibrate. But another issue is I found the value of pitch and roll are fluctuate when I rotate and the reading slowly settle down after the sensor stay level.

image

And the roll and pitch data seem fluctuate/overshoot as below

image

Now I'm stuck.lol..Do you have any Idea what happens @kriswiner ?

Thanks and regards

PhySan0111 commented 4 years ago

Hi @mnajib76

The code that you have posted before in ( https://github.com/kriswiner/LSM9DS1/issues/14#issuecomment-660429239 ) reads gyroscope data in degrees per second and the Madgwick library that you posted already converts from degrees/s to radians/s, so that is taken care. The fluctuations might be due to the beta value or/and the time updating readings to the Madgwick filter. So, the beta value acts as a proportional gain to compensate for the error on the measurements. If the beta value is too high, the angles will jitter a lot. If beta value is too low then it will fail to compensate and will take time to reach a stable value. Concerning the timing, remember that you are setting the filter to 238Hz right? But, are you truly updating the values on the filter at that rate? In my opinion, I would make some tests, and divide the problem into minor ones. Personally, it helps me to checkpoints and find out where is the error. These are the checkpoints that I do when using IMU's:

1) after calibration, are the accelerometer values correct to the position? if flat --> az = 1 and ax=ay=0; If tuned 90º--> az=0 and ax=1 or 0 and ay=0 or 1 depending the axis that you rotated 2) after calibration, if the sensor is still, the gyroscope should be around 0. You are not moving, so it should not report any movement. 3) go through the magnetometer data. After calibration plot a cartesian chart with 3 sets of data (like below) image If your magnetometer data is centered around 0 and all circles have the same radius, then your magnetometer calibration was successful 4) Time to move to the frequency analysis: Print the looping frequency that you read and send data to the madgwick filter. If you are setting the filter.begin() to expected 238samples per second you need to achieve this rate. I suggest that you modify the Madgwick library to have as an argument the time that you are looping through measurements, for two reasons:

If @kriswiner has something to add I will be glad to hear from him. Nevertheless, I hope the guide helps! And if something is needed I will be glad to help :)

Best regards!

kriswiner commented 4 years ago

Only that if you run the gyro at 250 Hz your mcu needs to be able to iterate 10 - 20 times per new gyro data sample to converge. So your mcu must be able to achieve 2 -3 kHz fusion rate. No AVR mcu can do this.

What fusion rate do you obtain?

On Sat, Jul 18, 2020 at 10:04 AM MigSanc notifications@github.com wrote:

Hi @mnajib76 https://github.com/mnajib76

The code that you have posted before in ( #14 (comment) https://github.com/kriswiner/LSM9DS1/issues/14#issuecomment-660429239 ) reads gyroscope data in degrees per second and the Madgwick library that you posted already converts from degrees/s to radians/s, so that is taken care. The fluctuations might be due to the beta value or/and the time updating readings to the Madgwick filter. So, the beta value acts as a proportional gain to compensate for the error on the measurements. If the beta value is too high, the angles will jitter a lot. If beta value is too low then it will fail to compensate and will take time to reach a stable value. Concerning the timing, remember that you are setting the filter to 238Hz right? But, are you truly updating the values on the filter at that rate? In my opinion, I would make some tests, and divide the problem into minor ones. Personally, it helps me to checkpoints and find out where is the error. These are the checkpoints that I do when using IMU's:

  1. after calibration, are the accelerometer values correct to the position? if flat --> az = 1 and ax=ay=0; If tuned 90º--> az=0 and ax=1 or 0 and ay=0 or 1 depending the axis that you rotated

  2. after calibration, if the sensor is still, the gyroscope should be around 0. You are not moving, so it should not report any movement.

  3. go through the magnetometer data. After calibration plot a cartesian chart with 3 sets of data (like below) [image: image] https://user-images.githubusercontent.com/47632850/87857506-35ae3580-c91f-11ea-805e-5af24e8eaf3c.png If your magnetometer data is centered around 0 and all circles have the same radius, then your magnetometer calibration was successful

  4. Time to move to the frequency analysis: Print the looping frequency that you read and send data to the madgwick filter. If you are setting the filter.begin() to expected 238samples per second you need to achieve this rate. I suggest that you modify the Madgwick library to have as an argument the time that you are looping through measurements, for two reasons:

    • the sample frequency will be dynamic instead of static
    • consequently, the quaternion filter will be more accurate that way

  5. start playing with beta value and understand how beta plays a role in compensating errors in measurements.

  6. confirm that the euler angles are as expected. Some versions of the madgwick library don't use the correct way to calculate euler angles

If @kriswiner https://github.com/kriswiner has something to add I will be glad to hear from him. Nevertheless, I hope the guide helps! And if something is needed I will be glad to help :)

Best regards!

— 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-660511627, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKRCAMCHABQUNPMYU7LR4HIZ5ANCNFSM4KWHMCKQ .

j-mcc1993 commented 4 years ago

Hi all,

I made the necessary changes to adapt @kriswiner's example to the Nano 33 boards. You can find the updated code here.

I hope this will be of some help!

isetthestandard commented 3 years ago

I read almost all of the comments but i never get a working solution. Is there anybody with an arduino nano 33 ble sense who get yaw pitch roll in degrees and can post his sketch?

Best regards

MrStashley commented 3 years ago

So in your project which way is your nano 33 ble facing? Mine was on its side turned to the left, so left was down and right was up etc. because of this I had to use different signs for my XYZ. If yours is the same way I can show you how I did mine, I'll post it later today, but if not I recommend experimenting with different combinations of positive and negative X Y and Z as well as using the madgwickAHRS library as I described in some of my earlier posts. Good Luck and lmk if you have any further questions!

kriswiner commented 3 years ago

@foxy-munich

Can't get quaternions? Can't get accurate heading? What is the problem exactly?

The sketches available here and at Adafruit and at Sparkfun and elsewhere are never going to be exactly what you need for your specific hardware situation. You are going to have to make modifications to suit.

Is this just a "can't make the Arduino Nano work" kind of problem? Maybe an Arduino Nano forum would be more appropriate?

On Tue, Nov 10, 2020 at 7:03 AM Cole Lashley notifications@github.com wrote:

So in your project which way is your nano 33 ble facing? Mine was on its side turned to the left, so left was down and right was up etc. because of this I had to use different signs for my XYZ. If yours is the same way I can show you how I did mine, I'll post it later today, but if not I recommend experimenting with different combinations of positive and negative X Y and Z as well as using the madgwickAHRS library as I described in some of my earlier posts. Good Luck and lmk if you have any further questions!

— 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-724759024, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKS72ERIKQ2QDRHND2LSPFI3NANCNFSM4KWHMCKQ .

j-mcc1993 commented 3 years ago

@foxy-munich

The LSM9DS1_BasicAHRS_Nano33.ino sketch should work now without any issues on your Nano33 if you download it again. I realized I made a small error that would give you some odd looking values. Let me know if you have any further issues, I should be able to help.

EDIT: Another thing to be aware of is that the yaw value is being adjusted based on your local magnetic declination. You may want to double check this offset if you're located outside of the San Francisco Bay Area. You can look up the magnetic declination in your location and then substitute it for the value being subtracted from yaw on line 476.

@kriswiner thanks again for the code, it was a lot of fun to play with!

isetthestandard commented 3 years ago

@j-mcc1993

I try to use you sketch https://github.com/j-mcc1993/LSM9DS1/blob/master/LSM9DS1_BasicAHRS_Nano33.ino

but I get this compiling error:

`In file included from C:...\AppData\Local\Arduino15\packages\arduino\hardware\mbed\1.1.6\cores\arduino/Arduino.h:86:0, from sketch\sketch_nov11a.ino.cpp:1: C:\Users...\AppData\Local\Arduino15\packages\arduino\hardware\mbed\1.1.6\variants\ARDUINO_NANO33BLE/pins_arduino.h:82:14: error: expected unqualified-id before numeric constant

define D1 1

          ^

C:\Users...\Documents\Arduino\sketch_nov11a\sketch_nov11a.ino:242:10: note: in expansion of macro 'D1' uint32_t D1 = 0, D2 = 0; // raw MS5611 pressure and temperature data ^~ exit status 1 Error compiling for board Arduino Nano 33 BLE. `

Do you have any advise to solve this problem?

I have solved the problem by renaming D1 and D2.

Now your code works!

The output yaw, pitch, roll is when my nano stands still on a surface Yaw, Pitch, Roll: 141.06, -0.00, 0.06 Can you explain to me why the yaw is not 0 or nearly 0?

j-mcc1993 commented 3 years ago

@foxy-munich Glad to hear you were able to fix it! I wonder if that compilation error is OS specific.. I will have to test it out later.

Those values sound accurate to me, your yaw value is effectively telling you what compass direction the Arduino is pointing to. A yaw of 0 means your Arduino should be pointing towards true north (assuming you adjusted the declination value), while a value of 180 would indicate your Arduino is pointing south. If you spin the Arduino around on a flat surface, you should see the yaw value range between 0-360 while your pitch and roll stay near 0.

isetthestandard commented 3 years ago

It seems that the 1 and 2 are the problems. (Windows 10 20h2 is my operqting system) And now the yaw value makes sense to me. I thougt when i start the nano i have a 0 value and the rotation will change it. But then i have to calculate the yaw delta by myself.

Thank yo very much for the help

Grun2000 commented 3 years ago

@j-mcc1993

I try to use you sketch https://github.com/j-mcc1993/LSM9DS1/blob/master/LSM9DS1_BasicAHRS_Nano33.ino

but I get this compiling error:

In file included from C:\...\AppData\Local\Arduino15\packages\arduino\hardware\mbed\1.1.6\cores\arduino/Arduino.h:86:0, from sketch\sketch_nov11a.ino.cpp:1: C:\Users\...\AppData\Local\Arduino15\packages\arduino\hardware\mbed\1.1.6\variants\ARDUINO_NANO33BLE/pins_arduino.h:82:14: error: expected unqualified-id before numeric constant #define D1 1 ^ C:\Users\...\Documents\Arduino\sketch_nov11a\sketch_nov11a.ino:242:10: note: in expansion of macro 'D1' uint32_t D1 = 0, D2 = 0; // raw MS5611 pressure and temperature data ^~ exit status 1 Error compiling for board Arduino Nano 33 BLE.

Do you have any advise to solve this problem?

I have solved the problem by renaming D1 and D2.

Now your code works!

The output yaw, pitch, roll is when my nano stands still on a surface Yaw, Pitch, Roll: 141.06, -0.00, 0.06 Can you explain to me why the yaw is not 0 or nearly 0?

What did you rename D1 and D2 to?

StRob1980 commented 3 years ago

Hi guys, I've got @j-mcc1993 ported code for the Nano 33 BLE up and running, Thank you for sharing! (I had to comment out the "D1" part as I also got the compiler error, same as @Grun2000, but I'm not using the pressure sensor anyway so I just removed that). So now it is up and running but the roll, pitch and yaw has some strange behavior. If I move the device slowly, it seems to work quite nice, but if I do a fast change it seems that it has a to strong derivative gain or if it is some orientation that is not aligned correctly. See the plot. I put the board on -90 degree and flip it to 0 as fast as I can. you can see that it is going in the wrong direction at first and I want to get rid of that, but I don't know where the error occur. Is it orientation? is it the Madgwick filter coefficients? I tried to change sign on the gy in readGyroData() as I thought that might be used for fast changes but that didn't change a thing. Exactly the same behavior. roll_-90_to_0

kriswiner commented 3 years ago

Sensor data needs to be fed into the Madgwick fusion filter as NED, otherwise I would suspect inadequate sensor calibration.

How did you check your calibration?

On Sun, Jan 10, 2021 at 12:46 PM StRob1980 notifications@github.com wrote:

Hi guys, I've got @j-mcc1993s ported code for the Nano 33 BLE up and running, Thank you for sharing! (I had to comment out the "D1" part as I also got the compiler error, same as @Grun2000 https://github.com/Grun2000, but I'm not using the pressure sensor anyway so I just removed that). So now it is up and running but the roll, pitch and yaw has some strange behavior. If I move the device slowly, it seems to work quite nice, but if I do a fast change it seems that it has a to strong derivative gain or if it is some orientation that is not aligned correctly. See the plot. I put the board on -90 degree and flip it to 0 as fast as I can. you can see that it is going in the wrong direction at first and I want to get rid of that, but I don't know where the error occur. Is it orientation? is it the Madgwick filter coefficients? I tried to change sign on the gy in readGyroData() as I thought that might be used for fast changes but that didn't change a thing. Exactly the same behavior. [image: roll_-90_to_0] https://user-images.githubusercontent.com/77176483/104134646-536acd80-538b-11eb-803d-7bbdf7d4e850.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-757541392, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKXUXMISMSV5AHRRMHDSZIG3DANCNFSM4KWHMCKQ .

StRob1980 commented 3 years ago

Yes, I thought that was already taken care of as @j-mcc1993 already got it working on the same device as I use and I use his code (with my own changes of course), but it was not. I´m open to that I miss that he might have compensate for NED where I don't understand of course. But when I change sign (multiply by -1) on az, gz, mx and my, before Madgwick I get rid of the sign error on fast movments. But:

Here is my Orientation (I used @MigSanc pics, thanks): image image

StRob1980 commented 3 years ago

Sensor data needs to be fed into the Madgwick fusion filter as NED, otherwise I would suspect inadequate sensor calibration. How did you check your calibration? … On Sun, Jan 10, 2021 at 12:46 PM StRob1980 @.***> wrote: Hi guys, I've got @j-mcc1993s ported code for the Nano 33 BLE up and running, Thank you for sharing! (I had to comment out the "D1" part as I also got the compiler error, same as @Grun2000 https://github.com/Grun2000, but I'm not using the pressure sensor anyway so I just removed that). So now it is up and running but the roll, pitch and yaw has some strange behavior. If I move the device slowly, it seems to work quite nice, but if I do a fast change it seems that it has a to strong derivative gain or if it is some orientation that is not aligned correctly. See the plot. I put the board on -90 degree and flip it to 0 as fast as I can. you can see that it is going in the wrong direction at first and I want to get rid of that, but I don't know where the error occur. Is it orientation? is it the Madgwick filter coefficients? I tried to change sign on the gy in readGyroData() as I thought that might be used for fast changes but that didn't change a thing. Exactly the same behavior. [image: roll_-90_to_0] https://user-images.githubusercontent.com/77176483/104134646-536acd80-538b-11eb-803d-7bbdf7d4e850.png — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKXUXMISMSV5AHRRMHDSZIG3DANCNFSM4KWHMCKQ .

I check my calibration like this: ax=0 , ay=0, az=-1. gx=0, Gy=0, gz=0.

  MagX MAgY MagZ
Min -0.38 -0.37 -0.43
Max 0.41 0.36 0.43

I note that the magnetic field is strongest in up/down direction. Not north/south.

kriswiner commented 3 years ago

Az should be +1 when gravity is down.

The mag field magnitude is wrong, magnitude is 0.69 Gauss, should be closer to 0.5 and components should agree with your local geomagnetic values...

On Tue, Jan 12, 2021 at 4:20 PM StRob1980 notifications@github.com wrote:

Sensor data needs to be fed into the Madgwick fusion filter as NED, otherwise I would suspect inadequate sensor calibration. How did you check your calibration? … <#m3459811042458699887> On Sun, Jan 10, 2021 at 12:46 PM StRob1980 @.***> wrote: Hi guys, I've got @j-mcc1993s ported code for the Nano 33 BLE up and running, Thank you for sharing! (I had to comment out the "D1" part as I also got the compiler error, same as @Grun2000 https://github.com/Grun2000 https://github.com/Grun2000, but I'm not using the pressure sensor anyway so I just removed that). So now it is up and running but the roll, pitch and yaw has some strange behavior. If I move the device slowly, it seems to work quite nice, but if I do a fast change it seems that it has a to strong derivative gain or if it is some orientation that is not aligned correctly. See the plot. I put the board on -90 degree and flip it to 0 as fast as I can. you can see that it is going in the wrong direction at first and I want to get rid of that, but I don't know where the error occur. Is it orientation? is it the Madgwick filter coefficients? I tried to change sign on the gy in readGyroData() as I thought that might be used for fast changes but that didn't change a thing. Exactly the same behavior. [image: roll_-90_to_0] https://user-images.githubusercontent.com/77176483/104134646-536acd80-538b-11eb-803d-7bbdf7d4e850.png — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14 (comment) https://github.com/kriswiner/LSM9DS1/issues/14#issuecomment-757541392>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKXUXMISMSV5AHRRMHDSZIG3DANCNFSM4KWHMCKQ .

I check my calibration like this: ax=0 , ay=0, az=-1. gx=0, Gy=0, gz=0. MagX MAgY MagZ Min -0.38 -0.37 -0.43 Max 0.41 0.36 0.43

I note that the magnetic field is strongest in up/down direction. Not north/south.

— 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-759120202, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKU6GUJ7UAYYKMFQ4KDSZTRNHANCNFSM4KWHMCKQ .

StRob1980 commented 3 years ago

If I just read out the acc-sensor without changing sign on az i read 1.02 at rest. Flat on the table, component side up. But I should convert to NED so directly after the read of sensor I multiply az with -1, then I get -1 when plotting. What fundamental things am I missing? :) Or should I plot the sensordata without NED-conversion and just change sign in the magwick function call?

What do you mean by "magnitude is 0.69", what do you get that from? My data says 0.36-0.43? The max shows the up/down field as that is the strongest and that is 0.49 Gauss at my location according to https://www.ngdc.noaa.gov/geomag/calculators/magcalc.shtml#igrfgrid, which is close to 0.5 as you say.

kriswiner commented 3 years ago

Measured mag field is a vector, so its magnitude is SQRT( Mx^2 + My^2 + Mz^2) which should be ~0.5 Guass

On Wed, Jan 13, 2021 at 1:25 PM StRob1980 notifications@github.com wrote:

If I just read out the acc-sensor without changing sign on az i read 1.02 at rest. Flat on the table, component side up. But I should convert to NED so directly after the read of sensor I multiply az with -1, then I get -1 when plotting. What fundamental things am I missing? :) Or should I plot the sensordata without NED-conversion and just change sign in the magwick function call?

What do you mean by "magnitude is 0.69", what do you get that from? My data says 0.36-0.43? The max shows the up/down field as that is the strongest and that is 0.49 Gauss at my location according to https://www.ngdc.noaa.gov/geomag/calculators/magcalc.shtml#igrfgrid, which is close to 0.5 as you say.

— 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-759748867, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKQGXN4B4VS5PCT54N3SZYFTVANCNFSM4KWHMCKQ .

StRob1980 commented 3 years ago

Aaah! I see. And you took my calibration data? The vector should be at stand still? If I put my bord with X pointing true north and Down is Down, then I read: mx=0.14G my=0.01G mZ=0.42G and that is about what I read from ngdc.noaa.gov; mx=0,153 my=0,0136 mz=0,4903 Isn't that to be considered good enough?

And the vectors magnitude, when at rest facing north, is 0.442832.

kriswiner commented 3 years ago

Might be good enough, don't know just from this.

If you are well-enough calibrated, and are passing the sensor data as NED to the Madgwick filter, and are iterating the filter 10 - 20 times per new gyro data set, then you should be getting no-drift heading accuracy of ~4 degrees or so. At least this is what I get. Maybe a Nano can;t run at 2 - 3Khz fusion rate?

On Wed, Jan 13, 2021 at 2:42 PM StRob1980 notifications@github.com wrote:

Aaah! I see. And you took my calibration data? The vector should be at stand still? If I put my bord with X pointing true north and Down is Down, then I read: mx=0.14G my=0.01G mZ=0.42G and that is about what I read from ngdc.noaa.gov; mx=0,153 my=0,0136 mz=0,4903 Isn't that to be considered good enough?

And the vectors magnitude, when at rest facing north, is 0.442832.

— 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-759784420, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKWFSWX5E3FNL347AIDSZYOVHANCNFSM4KWHMCKQ .

StRob1980 commented 3 years ago

Ok.. I only get 305 Hz. But that still don´t explain the up-side down roll. I´d like to understand that. I flip my axis as NED so I should get correct orientation at least. It is correct to flip all three Z-axis and mX? 

if (readByte(LSM9DS1XG_ADDRESS, LSM9DS1XG_STATUS_REG) & 0x01) {  // check if new accel data is ready  
    readAccelData(accelCount);  // Read the x/y/z adc values

    // Now we'll calculate the accleration value into actual g's
    ax = (float)accelCount[0]*aRes - accelBias[0]; 
    ay = (float)accelCount[1]*aRes - accelBias[1];   
    az = ((float)accelCount[2]*aRes - accelBias[2])*-1; // *-1 for NED-conversion as positive az is up on sensor, down in NED.
  } 

  if (readByte(LSM9DS1XG_ADDRESS, LSM9DS1XG_STATUS_REG) & 0x02) {  // check if new gyro data is ready  
    readGyroData(gyroCount);  // Read the x/y/z adc values

    // Calculate the gyro value into actual degrees per second
    gx = (float)gyroCount[0]*gRes - gyroBias[0]; 
    gy = (float)gyroCount[1]*gRes - gyroBias[1];  
    gz = ((float)gyroCount[2]*gRes - gyroBias[2])*-1; // *-1 for NED-conversion   
  }

  if (readByte(LSM9DS1M_ADDRESS, LSM9DS1M_STATUS_REG_M) & 0x08) {  // check if new mag data is ready  
    readMagData(magCount);  

    // Calculate the magnetometer values in milliGauss
    mx = ((float)magCount[0]*mRes)*-1; //-1 for NED conversion
    my = (float)magCount[1]*mRes;   
    mz = ((float)magCount[2]*mRes)*-1; //-1 for NED conversion

MadgwickQuaternionUpdate(ax, ay, az, gx*PI/180.0f, gy*PI/180.0f, gz*PI/180.0f, mx, my, mz); roll = atan2(2.0f * (q[0] * q[1] + q[2] * q[3]), q[0] * q[0] - q[1] * q[1] - q[2] * q[2] + q[3] * q[3]); image

StRob1980 commented 3 years ago

@kriswiner The Nano 33 BLE uses nRF52840, a cortex M4 based 32 bit µC running at 64MHz so I guess it is comparable to the Teensy 3.1 you used in the same project if the comments about that is correct? So do you have any idea why you achieved 3-4 kHz filter execution when I just get 305 Hz?

(My assumptions that you did is that I have not changed the update frequency of the Gyro and it was set to 200+Hz)

kriswiner commented 3 years ago

Should be able to get fusion (iteration) rates above 1 kHz with the nRF52. No idea why without examining your code, which I don't really want to do. There are lots of examples of how to manage the Magwick fusion filter. I do it like this https://github.com/kriswiner/MPU9250/blob/master/AK8963_as_slave/AK8963Slave0_MPU9250_Ladybug.ino (see line 233 and following)..

On Tue, Jan 19, 2021 at 1:07 AM StRob1980 notifications@github.com wrote:

@kriswiner https://github.com/kriswiner The Nano 33 BLE uses nRF52840, a cortex M4 based 32 bit µC running at 64MHz so I guess it is comparable to the Teensy 3.1 you used in the same project if the comments about that is correct? So do you have any idea why you achieved 3-4 kHz filter execution when I just get 305 Hz?

(My assumptions that you did is that I have not changed the update frequency of the Gyro and it was set to 200+Hz)

— 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-762704603, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKSMDPFFFFRZNQYOUGLS2VDVVANCNFSM4KWHMCKQ .

StRob1980 commented 3 years ago

Are you using the FPU? And if so, do you have to activate it manually or is that already done when choosing device?

kriswiner commented 3 years ago

Yes, the STM32L4 has an FPU and this is automatically used. Don't know about the Nano 33 or whatever you are using. But there are a lot of things that a user could do to screw up fast execution. If you consult the sketch I linked to, maybe you can identify the main differences in logical flow and find what it messing you up.

On Wed, Jan 20, 2021 at 7:20 AM StRob1980 notifications@github.com wrote:

Are you using the FPU? And if so, do you have to activate it manually or is that already done when choosing device?

— 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-763704358, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKXLMVTRZMOYF454H53S23YC7ANCNFSM4KWHMCKQ .

willyconcarne12 commented 3 years ago

Hey all - I have been grappling with getting this (calibrated, full orientation; quaternions) with the Arduino Nano 33 BLE as well. Does anyone have a library they were able to get all the way there?

Brand new here and have spent the last 2 months trial + erroring, with some successes with pieces in isolation but can't get it all together.

ANY help/guidance would be MUCH appreciated.

kriswiner commented 3 years ago

https://github.com/kriswiner/LSM9DS1/blob/master/LSM9DS1_BasicAHRS_Nano33.ino

doesn't work for you??

On Tue, Mar 16, 2021 at 8:33 AM willyconcarne12 @.***> wrote:

Hey all - I have been grappling with getting this (calibrated, full orientation; quaternions) with the Arduino Nano 33 BLE as well. Does anyone have a library they were able to get all the way there?

Brand new here and have spent the last 2 months trial + erroring, with some successes with pieces in isolation but can't get it all together.

ANY help/guidance would be MUCH appreciated.

— 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-800367505, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKUKNE2LOZMJ67MJTLDTD525LANCNFSM4KWHMCKQ .

j-mcc1993 commented 3 years ago

@willyconcarne12 if you run into a compilation error with the sketch linked in the above comment, try referring to this comment: https://github.com/kriswiner/LSM9DS1/issues/14#issuecomment-725237203

StRob1980 commented 3 years ago

I struggled with https://github.com/kriswiner/LSM9DS1/blob/master/LSM9DS1_BasicAHRS_Nano33.ino and still didn't get it to work properly. Drift in heading when turning the board. If you turn the board on a flat surface back and fourth you will end up in different heading and slowly compensating (minutes). If I remember correctly the orientation is not correctly compensated to NED, I had to change sign on some. (believe it is mentioned in my earlier comments). After alot of effort I bought a BNO055 just to see what is achivable and I can say that it works like a charm right out of the box. Even without calibration if you are not interested in absolute heading, just relative. No offence, we all appreciate all of your support, but I think it´s fair to say that the sketch provided is not complete and working for the Nano33BLE. At least as far as I could see.

kriswiner commented 3 years ago

The magic of Black-box Arduino sketch + Sensor breakout bought online == Accurate absolute orientation estimation rarely happens in my experience.

If this works for you using the BNO055, then great, end of discussion.

For most of us, sensor quality + adequate sensor calibration are the key ingredients to accuracy.

There are much better sensors now than the LSM6DS1 (the BNO055 is not among them).

But I suspect your problem with "didn't get it to work properly" is inadequate calibration, which is something I can help with if you are willing to step out of the "works like a charm right out of the box" fantasy world.

On Wed, Mar 17, 2021 at 2:51 AM StRob1980 @.***> wrote:

I struggled with https://github.com/kriswiner/LSM9DS1/blob/master/LSM9DS1_BasicAHRS_Nano33.ino and still didn't get it to work properly. Drift in heading when turning the board. If you turn the board on a flat surface back and fourth you will end up in different heading and slowly compensating (minutes). If I remember correctly the orientation is not correctly compensated to NED, I had to change sign on some. (believe it is mentioned in my earlier comments). After alot of effort I bought a BNO055 just to see what is achivable and I can say that it works like a charm right out of the box. Even without calibration if you are not interested in absolute heading, just relative. No offence, we all appreciate all of your support, but I think it´s fair to say that the sketch provided is not complete and working for the Nano33BLE. At least as far as I could see.

— 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-800947464, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKXBHSOLELXBNBI3Q43TEB3SDANCNFSM4KWHMCKQ .

willyconcarne12 commented 3 years ago

https://github.com/kriswiner/LSM9DS1/blob/master/LSM9DS1_BasicAHRS_Nano33.ino doesn't work for you?? … On Tue, Mar 16, 2021 at 8:33 AM willyconcarne12 @.**> wrote: Hey all - I have been grappling with getting this (calibrated, full orientation; quaternions) with the Arduino Nano 33 BLE* as well. Does anyone have a library they were able to get all the way there? Brand new here and have spent the last 2 months trial + erroring, with some successes with pieces in isolation but can't get it all together. ANY help/guidance would be MUCH appreciated. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#14 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKUKNE2LOZMJ67MJTLDTD525LANCNFSM4KWHMCKQ .

I got it to work! One of the main hang-ups was changing D1 & D2 (as others mentioned) to something like pinD1 & pinD2. The other half of my struggle was adjusting the code to feed into Unity and capture it on that side, which I finally got through. Next is dialing in sensitivity as well as orienting the w/x/y/z axis with that of the object.

But that is NOTHING compared to the work you put into this library. I don't know how to thank you! And am learning so much in the process. @j-mcc1993 @kriswiner

StRob1980 commented 3 years ago

It might be inadequate calibration, sure. I followed the calibration routine in the code and also tried with increased number of samples. I did it on a wooden table far from any magnetic interference. I tried to get some other examples with hard and soft iron calibration to work with my Nano33BLE but with no luck unfortunately. The BNO055 was, as I mentioned, just to see if my poor result was "as good as it gets" or if there still was something wrong with my implementation (or HW for that matter). And It clearly showed that it was my implementation. So I will return to this later on. But as I know I would be helped of knowing that others did not get the sketch to work without some TLC it could be fair to tell others of what to expect to save them some time. Hope I didn't step on any toes, that was not my intention and I apologize for that.

@willyconcarne12 Did you get the heading/yaw responsive and somewhat accurate?

willyconcarne12 commented 3 years ago

@StRob1980 I appreciate your take as I appear to be in a similar boat. I am still wading through the right levers to pull and what each one does specifically as well as reading the the side notes with each section. For example, GyroMeasError (264, 265) comments seem completely relevant to optimizing performance vs. accuracy ("...not fast enough for a quadcopter or robot car!" [without adjustments]).

Accuracy vs. response speed vs. sampling rates vs. bias, etc. levers to try to learn, pull and balance. Heck of a wrestling match going on over here! Thrilled I have the data now feeding and I'm moving the object, but the new brick wall has appeared in trying to get the model object oriented with the sensor and stable. No disconnects occurring so far which is great and when I lay it flat it will stabilize back to it's original position after a few seconds, but sense there's a lot more mountain to climb.

StRob1980 commented 3 years ago

@willyconcarne12 I hope we can follow your progress here. I wish you a happy climbing. :)

willyconcarne12 commented 3 years ago

Ok so still at it - making progress. It seems my calibration/bias is way off on:

1) accelerometer, especially z-axis (bias 952) 2) magnetometer

Calibration

I have tried toggling just about everything... any thoughts?

kriswiner commented 3 years ago

Actually, the accel data look OK, so maybe a problem with the reporting of your biases?

Mag calibration way off though. magnitude of mag vector should be ~450 mgauss. When comparing face up Mz or face down Mz should be equal and opposite, etc.

On Wed, Mar 31, 2021 at 3:16 PM willyconcarne12 @.***> wrote:

Ok so still at it - making progress. It seems my calibration/bias is way off on:

  1. accelerometer, especially z-axis (bias 952)
  2. magnetometer

[image: Calibration] https://user-images.githubusercontent.com/58528850/113218132-a181c580-9244-11eb-981c-47fc91e75376.PNG

I have tried toggling just about everything... any thoughts?

— 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-811501734, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKSTNQYHSIU7CGCOJ33TGONK7ANCNFSM4KWHMCKQ .

willyconcarne12 commented 3 years ago

Well that's good on accel!

Hmmm... well here are the current initial params (I have been trying different things completely off the wall if you can't tell...)...

// 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

define SerialDebug true // set to true to get Serial output for debugging

// Set initial input parameters enum Ascale { // set of allowable accel full scale settings AFS_2G, AFS_4G, AFS_8G, AFS_16G };

enum Aodr { // set of allowable gyro sample rates AODR_PowerDown, AODR_10Hz, AODR_50Hz, AODR_119Hz, AODR_238Hz = 1, AODR_476Hz, AODR_952Hz };

enum Abw { // set of allowable accewl bandwidths ABW_408Hz = 1, ABW_211Hz, ABW_105Hz, ABW_50Hz };

enum Gscale { // set of allowable gyro full scale settings GFS_245DPS, GFS_500DPS = 1, GFS_NoOp, GFS_2000DPS };

enum Godr { // set of allowable gyro sample rates GODR_PowerDown, GODR_14_9Hz, GODR_59_5Hz, GODR_119Hz, GODR_238Hz = 1, GODR_476Hz, GODR_952Hz };

enum Gbw { // set of allowable gyro data bandwidths GBW_low, // 14 Hz at Godr = 238 Hz, 33 Hz at Godr = 952 Hz GBW_med, // 29 Hz at Godr = 238 Hz, 40 Hz at Godr = 952 Hz GBW_high = 1, // 63 Hz at Godr = 238 Hz, 58 Hz at Godr = 952 Hz GBW_highest // 78 Hz at Godr = 238 Hz, 100 Hz at Godr = 952 Hz };

enum Mscale { // set of allowable mag full scale settings MFS_4G, MFS_8G, MFS_12G, MFS_16G };

enum Mmode { MMode_LowPower, MMode_MedPerformance, MMode_HighPerformance = 1, MMode_UltraHighPerformance };

enum Modr { // set of allowable mag sample rates MODR_0_625Hz, MODR_1_25Hz, MODR_2_5Hz, MODR_5Hz, MODR_10Hz, MODR_20Hz, MODR_80Hz = 1 };

define ADC_256 0x00 // define pressure and temperature conversion rates

define ADC_512 0x02

define ADC_1024 0x04

define ADC_2048 0x06

define ADC_4096 0x08

define ADC_D1 0x40

define ADC_D2 0x50

// Specify sensor full scale uint8_t OSR = ADC_4096; // set pressure amd temperature oversample rate uint8_t Gscale = GFS_500DPS; // gyro full scale uint8_t Godr = GODR_238Hz; // gyro data sample rate uint8_t Gbw = GBW_high; // gyro data bandwidth uint8_t Ascale = AFS_8G; // accel full scale uint8_t Aodr = AODR_238Hz; // accel data sample rate uint8_t Abw = ABW_408Hz; // accel data bandwidth uint8_t Mscale = MFS_8G; // mag full scale uint8_t Modr = MODR_80Hz; // mag data sample rate uint8_t Mmode = MMode_HighPerformance; // magnetometer operation mode float aRes, gRes, mRes; // scale resolutions per LSB for the sensors

--

Also, does ADO have any effect on that?

kriswiner commented 3 years ago

No. Take a look here https://github.com/kriswiner/MPU6050/wiki/Simple-and-Effective-Magnetometer-Calibration and try again on the mag calibration.

On Wed, Mar 31, 2021 at 4:09 PM willyconcarne12 @.***> wrote:

Well that's good on accel!

Hmmm... well here are the current initial params (I have been trying different things completely off the wall if you can't tell...)...

// 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

define SerialDebug true // set to true to get Serial output for debugging

// Set initial input parameters enum Ascale { // set of allowable accel full scale settings AFS_2G, AFS_4G, AFS_8G, AFS_16G };

enum Aodr { // set of allowable gyro sample rates AODR_PowerDown, AODR_10Hz, AODR_50Hz, AODR_119Hz, AODR_238Hz = 1, AODR_476Hz, AODR_952Hz };

enum Abw { // set of allowable accewl bandwidths ABW_408Hz = 1, ABW_211Hz, ABW_105Hz, ABW_50Hz };

enum Gscale { // set of allowable gyro full scale settings GFS_245DPS, GFS_500DPS = 1, GFS_NoOp, GFS_2000DPS };

enum Godr { // set of allowable gyro sample rates GODR_PowerDown, GODR_14_9Hz, GODR_59_5Hz, GODR_119Hz, GODR_238Hz = 1, GODR_476Hz, GODR_952Hz };

enum Gbw { // set of allowable gyro data bandwidths GBW_low, // 14 Hz at Godr = 238 Hz, 33 Hz at Godr = 952 Hz GBW_med, // 29 Hz at Godr = 238 Hz, 40 Hz at Godr = 952 Hz GBW_high = 1, // 63 Hz at Godr = 238 Hz, 58 Hz at Godr = 952 Hz GBW_highest // 78 Hz at Godr = 238 Hz, 100 Hz at Godr = 952 Hz };

enum Mscale { // set of allowable mag full scale settings MFS_4G, MFS_8G, MFS_12G, MFS_16G };

enum Mmode { MMode_LowPower, MMode_MedPerformance, MMode_HighPerformance = 1, MMode_UltraHighPerformance };

enum Modr { // set of allowable mag sample rates MODR_0_625Hz, MODR_1_25Hz, MODR_2_5Hz, MODR_5Hz, MODR_10Hz, MODR_20Hz, MODR_80Hz = 1 };

define ADC_256 0x00 // define pressure and temperature conversion rates

define ADC_512 0x02

define ADC_1024 0x04

define ADC_2048 0x06

define ADC_4096 0x08

define ADC_D1 0x40

define ADC_D2 0x50

// Specify sensor full scale uint8_t OSR = ADC_4096; // set pressure amd temperature oversample rate uint8_t Gscale = GFS_500DPS; // gyro full scale uint8_t Godr = GODR_238Hz; // gyro data sample rate uint8_t Gbw = GBW_high; // gyro data bandwidth uint8_t Ascale = AFS_8G; // accel full scale uint8_t Aodr = AODR_238Hz; // accel data sample rate uint8_t Abw = ABW_408Hz; // accel data bandwidth uint8_t Mscale = MFS_8G; // mag full scale uint8_t Modr = MODR_80Hz; // mag data sample rate uint8_t Mmode = MMode_HighPerformance; // magnetometer operation mode float aRes, gRes, mRes; // scale resolutions per LSB for the sensors

--

Also, does ADO have any effect on that?

— 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-811523136, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTDLKWOW4CT7OLWO73HVKLTGOTRLANCNFSM4KWHMCKQ .

willyconcarne12 commented 3 years ago

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: Calibration 2