Euler angles & drift

[adamgarbo]

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

[PaulZC]

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]

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

[PaulZC]

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]

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?

Cheers,
Adam

[adamgarbo]

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:

[PaulZC]

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]

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]

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]

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]

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]

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.

Cheers,
Adam

[PaulZC]

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

[gunarkroeger]

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]

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:

Test 2:

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]

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?