Euler angles & drift - Githubissues

adamgarbo commented 3 years ago

Hi @PaulZC,

I'm testing the ICM-20948 and DMP this morning and have been observing some strange behaviour with Example7_DMP_Quat6_EulerAngles.ino.

When the ICM-20948 is powered up, it appears to drift over several seconds before stabilizing. This can be seen in the graph below. The IMU is not moved while the data is being recorded. The IMU is also on a level surface and the pitch and roll values should be much closer to zero.

Is there any form of calibration that needs to first be performed?

Cheers, Adam

imu

PaulZC commented 3 years ago

Hi Adam, I think this is the same issue as noted in #34. I'm still double-checking that we have everything configured correctly. Can you please try rotating the sensor around all three axes first. Does that help? Thanks, Paul

adamgarbo commented 3 years ago

Hi Paul,

Just tested and it doesn't appear to make a difference. The pitch/roll was 10° off. I also noticed that after being rotated and placed back on a level surface, the IMU begins to drift again. I experienced this same behaviour with some of the Madgwick fusion code attempts for the ICM-20948.

Happy to test!

Cheers, Adam

imu2

PaulZC commented 3 years ago

Hi Adam, Please give v1.2.2 a try. I think we might be getting closer! Example6 (9-axis Quaternion) and Example7 (6-axis Quaternion) have been updated. You can now pipe data straight to ZaneL's Node.js Quaternion animation tool. Much nicer than columns of numbers! Best wishes, Paul

adamgarbo commented 3 years ago

Hi Paul,

I saw the addition of the animation tool earlier this morning. Will try it out!

I retested Example7_DMP_Quat6_EulerAngles and appear to get the same results. The sensor initializes at a pitch, roll, and yaw of 0, 0, 0 and slowly drifts to values of 8.9, -11.9, -11.2. The sensor is on a level surface, so the pitch and roll should be much closer to 0.

Are you aware of what the sensor is doing during those first ~100 samples? Does the ICM-20948 require time to stabilize or should it be able to determine its orientation immediately? I assume the "Quat6" means it's only making use of the accelerometer and magnetometer to calculate the Euler angles?

imu3

Cheers, Adam

adamgarbo commented 3 years ago

Two other things to note: 1) I've found that it is extremely difficult to get the sensor to achieve an absolute pitch value close to 90°. In the two above figures, I did a complete 360° spin about the Y-axis, but as you can see, the pitch values almost look like they are damped.

2) Can you able to confirm if the Euler angles will always be relative to the orientation of the sensor when it initializes? I noticed that when I reset the board while it was rotated 90°, it still gave the same values:

imu4

PaulZC commented 3 years ago

Thanks Adam, Yes, Quat6 - as I understand it - only uses Accel and Gyro. I really don't know what the cause of the drift is. Again, as I understand it, Quat6 is relative to the start position - there is no absolute orientation (using the magnetometer). Only Quat9 gives you that. It looks like I might have roll and pitch swapped? One should go +/-180, the other only +/-90. But I note your difficulty getting to 90. At least it might now be possible to remove the offset/bias by calibrating it out. I shall leave that to the community though. I've done as much as I can with this for now. (I need to get back to other projects!) There are other modes to try - Geomagnetic being one. Please feel free to experiment - if you can spare the time! Cheers, Paul

adamgarbo commented 3 years ago

Thanks, Paul,

I completely understand the desire to move on. I don't even want to think about how much time I've spent down the IMU rabbit hole!

Does InvenSense not require any form of calibration for the ICM-20948? In my previous projects that made use of the LSM303, it was essential to calibrate both the accelerometer and magnetometer (6-DOF). This would involve determining the min/max values for each sensor and then hardcoding the values into the code. There's also soft/hard-iron effect calibration, but that's a whole other can of worms.

I'm still keen to try and make use of the ICM-20948 in my projects. I had high hopes for the BNO080, but I'm really surprised by how unstable/unreliable that sensor is.

Will keep you posted on how I make out with the ICM-20948!

Cheers, Adam

PaulZC commented 3 years ago

Thanks Adam,

I have another note from InvenSense which describes the In-Use Calibration of their sensors. Again, they don't want this shared openly so sadly I cannot share it with you. But it does contain useful stuff:

Gyro Calibration: The DMP calibrates the gyro biases as it goes from a "motion" to a "no motion" state. It does mention a threshold that defines one from the other but doesn't suggest that you need to alter that. So I guess the key thing here is to move/rotate the ICM, then stop moving, and repeat... They say that once calibrated, the gyro noise should be less than 0.5dps.

Gyro Temperature Compensation: The Gyro performance benefits from the DMP being able to build a temperature profile against motion / no motion events. I guess, in your case, this could be really important. They suggest calibrating over a temperature range of at least 5 degrees.

Accelerometer: Again the DMP needs to build a bias model for the accel.. They suggest:

Device needs to be oriented in 3 different orientations
Several samples of data needs to be measured on each stable orientation
Average of the data is used to calculate the linear acceleration for each accelerometer’s axis
The readings on each axis is measured against the previous biases to determine if data is valid
Once all 3 axis biases is determined, new biases are applied to raw accel data
Accel will constantly be monitored for changes to the biases and will be modified accordingly

The library doesn't (currently) contain a "save settings" feature. It would be a interesting experiment to save the DMP registers. Power off/on. Reload and see if the accuracy improves (like you used to have to do on the BNO050). The two "mems" functions let you read and write DMP memory and ICM_20948_DMP.h contains the memory map. The nine bias calibration values are an obvious candidate. Maybe Gyro Slope too. The two Accel Cal Temperature values. Compass Bias Offset....

Oh, the hours we could spend...!

All the best, Paul

adamgarbo commented 3 years ago

Hi Paul,

In the ICM-20948 documentation is there any mention of absolute orientation? Or perhaps a setting to tell the sensor what orientation it will be deployed in so measurements can be made relative to a known reference?

For my projects (and I suspect most user applications), the biggest DMP challenge seems to be that the ICM-20948 never actually knows where it is in three-dimensional space. I haven't had my coffee yet, but wouldn't relative measurements require at least a single known orientation in order to work? I wonder if this will prove to be a challenge with the OLA, which power cycles the ICM-20948 when it goes to sleep.

It's really too bad that InvenSense is so tight-lipped about the ICM-20948!

Cheers, Adam

PaulZC commented 3 years ago

Magnetic North... The compass and Quat9 are your friend. Maybe Geomagnetic Rotation Vector too but I haven't tried that one...:

// DMP sensor options are defined in ICM_20948_DMP.h // INV_ICM20948_SENSOR_ACCELEROMETER (16-bit accel) // INV_ICM20948_SENSOR_GYROSCOPE (16-bit gyro + 32-bit calibrated gyro) // INV_ICM20948_SENSOR_RAW_ACCELEROMETER (16-bit accel) // INV_ICM20948_SENSOR_RAW_GYROSCOPE (16-bit gyro + 32-bit calibrated gyro) // INV_ICM20948_SENSOR_MAGNETIC_FIELD_UNCALIBRATED (16-bit compass) // INV_ICM20948_SENSOR_GYROSCOPE_UNCALIBRATED (16-bit gyro) // INV_ICM20948_SENSOR_STEP_DETECTOR (Pedometer Step Detector) // INV_ICM20948_SENSOR_STEP_COUNTER (Pedometer Step Detector) // INV_ICM20948_SENSOR_GAME_ROTATION_VECTOR (32-bit 6-axis quaternion) // INV_ICM20948_SENSOR_ROTATION_VECTOR (32-bit 9-axis quaternion + heading accuracy) // INV_ICM20948_SENSOR_GEOMAGNETIC_ROTATION_VECTOR (32-bit Geomag RV + heading accuracy) // INV_ICM20948_SENSOR_GEOMAGNETIC_FIELD (32-bit calibrated compass) // INV_ICM20948_SENSOR_GRAVITY (32-bit 6-axis quaternion) // INV_ICM20948_SENSOR_LINEAR_ACCELERATION (16-bit accel + 32-bit 6-axis quaternion) // INV_ICM20948_SENSOR_ORIENTATION (32-bit 9-axis quaternion + heading accuracy)

adamgarbo commented 3 years ago

Hi Paul,

My absolute orientation question stemmed from the fact that the sensor always seems to starts at 0,0,0 (Euler or quaternions). I'm looking more into the modes now! From the example, it appears that it's first required to enable the DMP orientation sensor and then apply additional modes?

// Enable the DMP orientation sensor
success &= (myICM.enableDMPSensor(INV_ICM20948_SENSOR_ORIENTATION) == ICM_20948_Stat_Ok);

// Enable any additional sensors / features
//success &= (myICM.enableDMPSensor(INV_ICM20948_SENSOR_RAW_GYROSCOPE) == ICM_20948_Stat_Ok);
//success &= (myICM.enableDMPSensor(INV_ICM20948_SENSOR_RAW_ACCELEROMETER) == ICM_20948_Stat_Ok);
//success &= (myICM.enableDMPSensor(INV_ICM20948_SENSOR_MAGNETIC_FIELD_UNCALIBRATED) == ICM_20948_Stat_Ok);

You may aslo be interested to see that when outputting quaternions from Example6_DMP_Quat9, the same drift pattern is observed (see below). I wonder if the other modes may improve this.

imu5

Cheers, Adam

PaulZC commented 3 years ago

I don’t think the order matters as the DMP is not running at that point. It gets started immediately afterwards.

gunarkroeger commented 3 years ago

I was using the library provided by ericalbers and was able to read the accuracy values (going from 0-3) for the 3 sensors. The imu has to rotate and lay still in different orientations to calibrate all sensors. The issue is, you have to perform those steps after every power-up.
I was searching how to save the calibration and the new version of this library turned up. I hope this functionality can be added to it soon.

adamgarbo commented 3 years ago

Thanks for the additional info, @gunarkroeger. Yes, having to manually calibrate the sensor after each power cycle is a major challenge. My hopes were that I'd be able to enable power to the sensor, record the pitch/roll/yaw (absolute orientation) and then disable power. It doesn't seem that this is currently possible.

To further address the drift, I conducted two tests using Example6_DMP_Quat9. In the first test, I powered on the ICM-20948 but didn't move it. In the second test, I powered on the sensor but then rotated it around each of its three axes. I then left both sensors to sit for several minutes until their values stabilized. The results are shown below:

Test 1: imu_q1

Test 2: imu_q2

I'm not overly knowledgeable about how the quaternions are calculated but I would assume this drift should not be occurring? Which values are actually correct?

Cheers, Adam

gunarkroeger commented 3 years ago

The quaternions are just a mathematical representation of rotation that does not have issues Euler angles have (like gimbal lock). drift is expected on power on because it is still not calibrated. showing the values of the accuracy registers would help to debug this.
However, after the sensors are calibrated, you left it still until stabilization, then rotate and put it back in the same position, it should go back to the same quaternion values as before (preferably quickly) and stay there.
I would say though, that your quaternion values are missing q4. Perhaps it is not used because if normalized, you can obtain q4 from the other 3 values?

adamgarbo commented 3 years ago

Hi @gunarkroeger,

Example6_DMP_Quat9 also outputs an accuracy value (data.Quat9.Data.Accuracy). I've included a graph for the two most recent tests. You mentioned a range of 0-3, but this valule is in the hundreds, so I'm not sure of the min/max.

imu_accuracy

PaulZC commented 3 years ago

Hi Adam, Gunar (@gunarkroeger ) is referring to these accuracy figures: https://github.com/sparkfun/SparkFun_ICM-20948_ArduinoLibrary/blob/master/src/util/ICM_20948_DMP.h#L741-L743 Those should be requested automatically when you enable the 'raw' accel, gyro and compass features: https://github.com/sparkfun/SparkFun_ICM-20948_ArduinoLibrary/blob/master/src/util/ICM_20948_C.c#L1576-L1590 Once the sensors are enabled, you can check: Does the Header contain Header2 https://github.com/sparkfun/SparkFun_ICM-20948_ArduinoLibrary/blob/master/src/util/ICM_20948_DMP.h#L462 Does Header2 contain the accuracy figures https://github.com/sparkfun/SparkFun_ICM-20948_ArduinoLibrary/blob/master/src/util/ICM_20948_DMP.h#L483-L485 If so, print them. Cheers, Paul

PaulZC commented 3 years ago

E.g. https://github.com/sparkfun/SparkFun_ICM-20948_ArduinoLibrary/blob/master/examples/Arduino/Example9_DMP_MultipleSensors/Example9_DMP_MultipleSensors.ino#L288-L290 https://github.com/sparkfun/SparkFun_ICM-20948_ArduinoLibrary/blob/master/examples/Arduino/Example9_DMP_MultipleSensors/Example9_DMP_MultipleSensors.ino#L298-L302

adamgarbo commented 3 years ago

Thanks, Paul!

Still trying to wrap my head around everything. Even having worked with IMUs in the past, I'm finding that I get lost really easily with the ICM-20948 code.

In Example6_DMP_Quat9, can we use the same quaternion to Euler angle calculations from Example7_DMP_Quat6_EulerAngles? I assume the Q1, Q2 and Q3 from data.Quat9.Data is incorporating all three sensors (accel/gyro/mag)?

      // Convert the quaternions to Euler angles (roll, pitch, yaw)
      // https://en.wikipedia.org/w/index.php?title=Conversion_between_quaternions_and_Euler_angles&section=8#Source_code_2

      double q0 = sqrt( 1.0 - ((q1 * q1) + (q2 * q2) + (q3 * q3)));

      double q2sqr = q2 * q2;

      // roll (x-axis rotation)
      double t0 = +2.0 * (q0 * q1 + q2 * q3);
      double t1 = +1.0 - 2.0 * (q1 * q1 + q2sqr);
      double roll = atan2(t0, t1) * 180.0 / PI;

      // pitch (y-axis rotation)
      double t2 = +2.0 * (q0 * q2 - q3 * q1);
      t2 = t2 > 1.0 ? 1.0 : t2;
      t2 = t2 < -1.0 ? -1.0 : t2;
      double pitch = asin(t2) * 180.0 / PI;

      // yaw (z-axis rotation)
      double t3 = +2.0 * (q0 * q3 + q1 * q2);
      double t4 = +1.0 - 2.0 * (q2sqr + q3 * q3);
      double yaw = atan2(t3, t4) * 180.0 / PI;

Cheers, Adam

PaulZC commented 3 years ago

Hi Adam, "get lost easily the the ICM-20948 code". Oh yes, Welcome to my World! ;-) The Quaternion to Euler calculation - as I understand it - is perfectly valid for both Quat6 and Quat9. The only difference is that the Quat9 Quaternion orientation includes the magnetometer/compass data. Quat6 Quaternion is based on Accel and Gyro only - hence is relative not absolute. Gunar (@gunarkroeger ): InvenSense use normalized Quaternions where: Q0^2 + Q1^2 +Q2^2 +Q3^2 = 1. The ICM-20948 only provides Q1-Q3. Q0 can be calculated from: sqrt( 1 - (Q1^2 + Q2^2 + Q3^2)) Cheers! Paul

adamgarbo commented 3 years ago

Thanks, Paul!

Gosh, you must be seeing the ICM-20948 code in your dreams by now! I may have to wait for someone who is more knowledgeable than I to produce a turnkey solution for pitch/roll/yaw.

I'm finding that even with Quat9 and the 'raw' accel, gyro, and compass features enabled, the sensor doesn't seem to know when returns to the exact same position. In the graph below, I rotated the sensor about the X-axis multiple times. You can see that there's a gradual step-change in all of the orientation values, despite being in the exact same position. This addition/subtraction issue was also encountered with the Madgwick attempts at sensor fusion for the ICM-20948.

I'm happy to close this issue as unresolved for now, unless you think it has value as an advertisement for someone else to pick up the torch.

Cheers, Adam

imu_rotate2

PaulZC commented 3 years ago

Best guess: that’s the DMP gradually compensating for the sensor bias/offset. Cheers, Paul

PaulZC commented 3 years ago

Hi Adam (@adamgarbo ), Please try v1.2.3. I had one of the Accel parameters set incorrectly... Thanks! Paul

adamgarbo commented 3 years ago

Hi @PaulZC,

Thanks for the update. The short-term sensor drift is present but the long-term drift appears to be resolved (see below). The sensor had all three raw sensor readings enabled during recording.

Do you know why the pitch/roll readings have such a significant offset when on a level surface? Is there a way to compensate/correct for this?

df9

Cheers, Adam

ruffner commented 3 years ago

Hey everyone. Not sure if ya'll have seen this already seen this but https://github.com/jevois/jevois/tree/master/src/jevois/Core has an ICM20948 driver implementation that might be useful to cross reference.

PaulZC commented 3 years ago

Many thanks Matt (@ruffner ), This line is interesting. It seems standard for bit 6 of Power Management 2 to be set, but that's the first time I've seen bit 7 being set. (Both are reserved - their use is not documented.) Cheers, Paul

PaulZC commented 3 years ago

From the InvenSense SmartMotion code: Bit 6 is "Pressure Standby". But there is no definition for bit 7...

stamstamNitzan commented 3 years ago

Is it possible that the results are not as good as declared by manufactured because of section 14.2 (and 8.4)?

https://cdn.sparkfun.com/assets/7/f/e/c/d/DS-000189-ICM-20948-v1.3.pdf

PaulZC commented 3 years ago

Thanks @stamstamNitzan - good to know,

We do use the “auto” clock setting:

https://github.com/sparkfun/SparkFun_ICM-20948_ArduinoLibrary/blob/master/examples/Arduino/Example6_DMP_Quat9_Orientation/Example6_DMP_Quat9_Orientation.ino#L116

https://github.com/sparkfun/SparkFun_ICM-20948_ArduinoLibrary/blob/master/src/util/ICM_20948_ENUMERATIONS.h#L40

14.1 is interesting too. Maybe we are just seeing the gyros stabilising?

Best wishes,

Paul

stamstamNitzan commented 3 years ago

@PaulZC Thank you for the references, I am mechanical engineer and I only worked with Matlab so C in new(ish). Why are we setting DMP to false? Don't we want to enable it in this example? Line 131: success &= (myICM.enableDMP(false) == ICM_20948_Stat_Ok);

There is a typo mix Z and Y in the notation in line 161 and line 194 https://github.com/sparkfun/SparkFun_ICM-20948_ArduinoLibrary/blob/77316d21e4b6266087cb56e0f48583bb7686cae1/src/util/ICM_20948_ENUMERATIONS.h#L161

PaulZC commented 3 years ago

Hi @stamstamNitzan , In line 131 we do want to disable the DMP while we load and configure it. We then enable it once it has been configured. Look near the end of setup. You will see success &= (myICM.enableDMP() == ICM_20948_Stat_Ok); which enables the DMP. Thank you for the typo - I will correct that in the next release. Best wishes, Paul

nakeze commented 3 years ago

Hi everyone, I am using the 1.2.4 version of this library and try to use the rotation vectors information of the sensor. My problem is that when I move the ICM and put it back to its initial position, the Euler angles I obtain are different (up to 15°). I used the examples 6 and 7, with the same result. Reading this thread, I understand that this issue was solved with V1.2.3 . Unfortunately, switching to V1.2.3 didn't solve my issue. Any update on this problem ? Cheers, Nicolas

PaulZC commented 3 years ago

Hi Nicolas (@nakeze ),

I think you are possibly seeing the same thing as Issue #53?

The current situation is:

InvenSense provided us with documentation on how to use the DMP, but they admit the documentation is not complete and they have asked us not to make it public.
We got the DMP running: using the InvenSense documentation; reverse-engineering InvenSense's example code (which is really opaque); reverse-engineering the I2C bus traffic created by InvenSense's example code.
We think we have the DMP configured correctly, but it is really difficult to tell.
We are not sure if the drift error is caused by incorrect configuration, or a calibration issue, or if that is 'as good as it gets' with the DMP
It has taken us many days of effort to get to this point and we really can't justify spending many more days on it. (There has been much stumbling around in the dark up to this point.)
We are hoping the community can help us work out what is going wrong and help us fix these issues.

I wish the situation was different, but here we are... Very best wishes, Paul

nakeze commented 3 years ago

Hi @PaulZC , Just to inform you and people facing the problem that I solved my issue switching to the Teensy-ICM-20948 library. I dug just a bit, didn't find any obvious differences in the way to extract quaternion from DMP. Very best wishes too, Nicolas

PaulZC commented 3 years ago

Hi @adamgarbo / @nakeze / @niv1900 / @ruffner / @gunarkroeger / @stamstamNitzan , Please give v1.2.5 a try. I made some important corrections to the way the magnetometer data was being read - which I hope will correct the Quat9 and compass behavior. The testing I've done here suggests the DMP is a lot more stable after: being rotated around each axis a few times; being held stationary in all six orientations for a few seconds. You may still see some drift in the Quat6 data as that does not use the magnetometer. Let me know how you get on. Best wishes, Paul

stamstamNitzan commented 3 years ago

Hi @adamgarbo / @nakeze / @Niv1900 / @ruffner / @gunarkroeger / @stamstamNitzan , Please give v1.2.5 a try. I made some important corrections to the way the magnetometer data was being read - which I hope will correct the Quat9 and compass behavior. The testing I've done here suggests the DMP is a lot more stable after: being rotated around each axis a few times; being held stationary in all six orientations for a few seconds. You may still see some drift in the Quat6 data as that does not use the magnetometer. Let me know how you get on. Best wishes, Paul

That is great! I will give it a run, it might take me few days, I am working on another project :)

Thank you!

stamstamNitzan commented 3 years ago

@PaulZC I have decided to abandon Sparkfun and use Arduino Nano 33 BLE Sense instead. The library there is awesome, I got it running in just a few hours, whereas I have been struggling for weeks with Sparkfun.

PaulZC commented 3 years ago

Hi @stamstamNitzan , Which library are you using on your Nano 33 BLE? Best wishes, Paul

adamgarbo commented 3 years ago

@stamstamNitzan In case you're unaware, @jremington has written a comprehensive AHRS library for the LSM9DS1: https://github.com/jremington/LSM9DS1-AHRS

I've also abandoned the ICM-20948 (and BNO080) and had intended to switch to the LSM9DS1, but there's currently a global shortage. So instead, I switched to the Adafruit LSM6DS33 + LIS3MDL. This particular IMU has been around forever, but I was able to adapt Jim's tilt-compensated heading example from the LSM9DS1 repository and it works like a charm once the magnetometer is calibrated.

Cheers, Adam

stamstamNitzan commented 3 years ago

@PaulZC I am using https://github.com/FemmeVerbeek/Arduino_LSM9DS1 It is a great one. Calibration is a bit long, but once you know your constants, you can simply use them.

@adamgarbo Thanks I will take a look

Nitzan :)

adamgarbo commented 3 years ago

@PaulZC, please let me know if you think it would be a good time to close this issue. There have been some really great discussions, though I'm not sure there is actually a resolution to be had.

PaulZC commented 3 years ago

Hi Nitzan (@stamstamNitzan ), Good to know. Thank you. Glad that’s working for you. Hi Adam (@adamgarbo ), Let’s leave it open a little longer. I spent a few hours over the weekend going through the SPI data from ZaneL’s Teensy wrapper, byte by byte. I think I might have missed something on the gyro DLPF. It looks like InvenSense enable the gyro DLPF (but not the accel one). This library currently leaves both DLPFs disabled. I also want to check the gyroSF one last time. Cheers, Paul

marc6h commented 3 years ago

@adamgarbo ICM-20948 is the only 9DOF chip which is regularly produced these days. Other sensors like LSM9DS1 and BNO055 won't be available for a long time by the look of things. So I think many will still be interested in the development of issues like this.

PaulZC commented 3 years ago

Hi Adam (@adamgarbo) / All,

I have, I think, solved this issue.

By going byte by byte through the SPI data from the InvenSense example, I found that: the I2C Master, accel and gyro were all being placed in low power mode initially (our library did the same thing); but that later the setting was changed leaving only the I2C Master in low power mode. Having the accel and gyro in low power mode was causing the erroneous behavior you were seeing. Using the Quat9 example, I can now power up the ICM-20948 in a random orientation and - after rotating it slowly around all three axes and holding it stationary in all six orientations - the quaternions become well behaved, returning to the same absolute values on every occasion. I even have two different ICM-20948's giving me the same quaternions when placed in the same position.

If you are interested in the root cause, please see dmp.md and do a search on that page for LP_CONFIG. We were setting LP_CONFIG to 0x70, but had missed that it is later changed to 0x40. Those two bits were causing all our troubles...

Please try v1.2.6. I think you will be pleased!

Please remember that the Euler angles example uses the Game Rotation Vector (Quat6) which does not use the magnetometer data and so does not provide absolute orientation. Only the Quat9 example provides absolute orientation.

Best wishes, Paul

mfide commented 3 years ago

More information about ICM20948 sensor types: https://source.android.com/devices/sensors/sensor-types

PaulZC commented 3 years ago

Thank you Mehmet - that is really useful! Best wishes, Paul PS. I have not forgotten about your accel bias issue - I just have not had time to investigate it...

mfide commented 3 years ago

I wanna add one note about real part calculation of quaternion. What we get from DMP as a quaternion is only i, j and k part without w (real) part. Quaternion should be a unit vector, so it has length 1. And by doing simple math you calculated w from w = sqrt(1.0 - ((q.x * q.x) + (q.y * q.y) + (q.z * q.z))); But w should have 2 roots here, it can be positive or negative which changes yaw, pitch and roll values at the end but you consider only positive values. This was the whole point of using quaternion instead of euler angles. DMP should return 4 values, not 3 but I guess this is not the case for ICM20948.

PaulZC commented 3 years ago

Hi Mehmet, Yes. correct, there is more detail on this in #55 Best, Paul

mfide commented 3 years ago

Hi Paul, Thank you for the highlighting. I didn't know that it has already been discussed there :)

adamgarbo commented 2 years ago

I believe this issue can now be closed. I encourage any users who have any questions and/or concerns regarding the operating of the ICM-20948 to create a new issue.

sparkfun / SparkFun_ICM-20948_ArduinoLibrary

Euler angles & drift #40