D435I IMU Calibration Not Accurate

[nickjeliopoulos]

Required Info
Camera Model	D435I
Firmware Version	5.11.11
Operating System & Version	Win10
Kernel Version (Linux Only)
Platform	PC
SDK Version	stable 2.21.0
Language	python
Segment	Robot

Issue Description

I have attempted to calibrate the D435I IMU using the rs_imu_calib.py script. In order to ensure that the camera is held stationary and level, a tripod with bubble levels was used to orient the camera during the calibration process. After calibration, the acceleration reported in the Y direction is different depending on the orientation of the camera. The acceleration reads 9.4 m/s^2 along the +Y axis, and flipping it around gives a reading of 10.4 m/s^2 on the -Y axis. Additionally, the normalized acceleration from the RealSense Viewer is reported as 9.6 m/s^2, which is not close to 9.80 m/s^2.

Here is the output from the rs_imu_calib.py script post-calibration:

The calibration script states that the norm fixed data is very close to gravity, but it does not appear that way in the RealSense Viewer. I have a feeling that the calibration procedure was carried out properly, and some sort of issue is stemming from the RealSense Viewer or our camera hardware.

Thank you for your time.

[MartyG-RealSense]

If you are trying to calibrate the camera in a downward-facing position, Intel support team member Alexandra from the Intel Support forum had this to say to another user attempting to calibrate the D435i in a downward-looking orientation:

"Calibrating the IMU for a downward facing position will not be possible ... our calibration for the IMU will calibrate it upright, that’s our configuration or expected configuration. You would have to do some compensations in SW on your own to translate the data into downward facing looking camera".

From that discussion emerged a link to a project for rotating a point cloud based on camera rotation:

https://github.com/GruffyPuffy/imutest

[nickjeliopoulos]

Thank you for your reply, Marty.

I think I may not have described the issue properly.
When held in position 5 (these images were taken from the IMU calibration whitepaper) we get a reading of 9.4 m/s^2.

When held in position 6 we get a reading of 10.4 m/s^2.

We are confused on why this is occurring post-calibration. We have only followed the instructions of the rs_calib.py, and it reports that the data has been fixed properly, but that is not the case when viewing the accel/gyro streams in the RealSense Viewer.

Thank you for your time.

[MartyG-RealSense]

Thank you very much for the clarification.

Are you able to achieve more consistent results if you test the IMU with the rs-motion demo, please?

#4391 (comment)

[nickjeliopoulos]

The rs-motion demo seems to behave reasonably. I am not sure how such a discrepancy between the reported acceleration in the RealSense Viewer and the rs-motion demo can exist.

I wrote a program to poll my D435i for motion frames and print out the normalized magnitude of the acceleration, and it matches up with what the RealSense viewer reports for Position 5 and 6 above.

Do you have any inkling on what the issue could be?

Thank you for your time MartyG!

[MartyG-RealSense]

The rs-motion documentation suggests that it uses something called a Complementary Filter to stabilize the data. To quote:

---

We use an approximate version of Complementary Filter to balance gyroscope and accelerometer results. Gyroscope gives generally accurate motion data, but it tends to drift, not returning to zero when the system goes back to its original position. Accelerometer, on the other hand, doesn't have this problem, but its signals are not as smooth and are easily affected by noises and disturbances. We use alpha to aggregate the data. New theta is the combination of the previous angle adjusted by difference computed from gyroscope data, and the angle calculated from accelerometer data. Note that this calculation does not apply to the Y component of theta, since it is measured by gyroscope only.

[ev-mp]

@gorshborsh, can you share the IMU intrinsic calibration ?

rs-enumerate-devices -c

When the IMU calibration is performed and flushed to D435i's memory a new "Motion Correction" option would appear in realsense-viewer under the "Motion Module" branch.
Toggling this will change the IMU values, and in case of a properly performed IMU-calibration should bring the accelerometer's norm close to the expected 9.8.
In the attached screenshot I manage to get a reasonable 9.65 with self-calibration on my desk.

The code that controls this is rs:options API RS2_OPTION_ENABLE_MOTION_CORRECTION

[ev-mp]

@gorshborsh , did you manage to verify the IMU calibration as specified ?
Please update

[ev-mp]

@gorshborsh , feel free to reopen as needed.