How to verify D435i imu calibration is correct?

[jaehwan-pi]

• Before opening a new issue, we wanted to provide you with some useful suggestions (Click "Preview" above for a better view):

  • Consider checking out SDK examples.
  • Have you looked in our documentations?
  • Is you question a frequently asked one?
  • Try searching our GitHub Issues (open and closed) for a similar issue.

• All users are welcomed to report bugs, ask questions, suggest or request enhancements and generally feel free to open new issue, even if they haven't followed any of the suggestions above :)

---

Required Info
Camera Model	D435i
Firmware Version	05.11.06.250
Operating System & Version	Ubuntu 16.04
Kernel Version (Linux Only)	(e.g. 4.14.13)
Platform	PC
SDK Version	2.29.0
Language	C
Segment	AR

Issue Description

Hello, I've just performed D435i imu calibration by using python script, provided in realsense SDK.
Calibration result in terminal is as below.

[ -3.57099204e-03 8.14340250e-05 -1.73322418e-03]
[1000 1000 1000 1000 1000 1000]
using 6000 measurements.
[[ 1.01783041e+00 1.18498262e-02 1.62972744e-02]
[ 3.21068733e-04 1.01414161e+00 5.42254716e-02]
[ -1.94634955e-02 -5.37384002e-02 1.01510521e+00]
[ 7.22336602e-02 1.48811274e-01 1.43795810e-01]]
residuals: [ 6.52936376 24.36565831 38.79660801]
rank: 4
singular: [ 434.28531194 431.50442709 428.51429413 77.39974539]
norm (raw data ): 9.646322
norm (fixed data): 9.805926 A good calibration will be near 9.806650

As the gravity norm looks reasonable, I wrote the result to the device.

When I check the accelerometer value at some orientation in realsense-viewer, however, the norm of accelerometer value is not close to 9.8 m/s^2.
The value is around 9.3m/s^2 when I enable or disable motion correction.

In my intuitive thinking, the value should be close to 9.8 m/s^2 after imu calibration.
Is my situation is reasonable?
Any advice would be really appreciated.

[MartyG-RealSense]

I hope the link below will be helpful. It describes how to use the RealSense Viewer after a Python script calibration has been done to verify the value when aiming to get it close to '9.8'.

#4751 (comment)

[jaehwan-pi]

I hope the link below will be helpful. It describes how to use the RealSense Viewer after a Python script calibration has been done to verify the value when aiming to get it close to '9.8'.

#4751 (comment)

Thank you for your quick reply.
Actually I've seen the article #4751 before, does it mean the acc. norm should be close to '9.8' at any orientation with "RS2_OPTION_ENABLE_MOTION_CORRECTION" OFF?
If so, my result seems not good as it gives '9.3' at some orientation.

[MartyG-RealSense]

The IMU calibration white paper says that a good calibration will be near '9.806650'. It gives an example data output where the raw value is '9.675980' and the 'fixed' value is '9.802881'.

[jaehwan-pi]

The IMU calibration white paper says that a good calibration will be near '9.806650'. It gives an example data output where the raw value is '9.675980' and the 'fixed' value is '9.802881'.

Yes. When I check the python script result, it is as below.

norm (raw data ): 9.646322
norm (fixed data): 9.805926 A good calibration will be near 9.806650

which means that it is verified.
So I updated the calibration result to the D435i device.
However, right after this when I check the acc. output in realsense-viewer, it is not close to 9.8.
Does it mean the calibration result is good, but it is not written properly to the device?

[MartyG-RealSense]

In the white paper there is another section directly after the above extract about writing the calibration to the device. Have you followed the procedure below please?

[jaehwan-pi]

In the white paper there is another section directly after the above extract about writing the calibration to the device. Have you followed the procedure below please?

Yes. I've written the calibration result to the device, according to the white paper.

Writing files:
accel_191105_1.txt
gyro_191105_1.txt
[-0.00299058 0.00120678 -0.00196624]
[1000 1000 1000 1000 1000 1000]
using 6000 measurements.
[[ 1.01937936 0.01629258 0.00991348]
[-0.00316487 1.016629 0.04268179]
[-0.0220307 -0.05614011 1.01880061]
[-0.02490054 0.1097225 0.16858324]]
residuals: [ 6.08555272 38.33698878 72.12811308]
rank: 4
singular: [ 433.71344549 432.71332731 424.77746343 77.40842193]
norm (raw data ): 9.622876
norm (fixed data): 9.805355 A good calibration will be near 9.806650
Would you like to write the results to the camera's eeprom? (Y/N)Y
Writing calibration to device.
Device PID: 0B3A
Device name: Intel RealSense D435I
Serial number: 843112072930
Firmware version: 05.11.06.250
SUCCESS: saved calibration to camera.
Done.

But the realsense viewer still shows acc output '9.3' with or without motion correction.

[MartyG-RealSense]

In #4571 the user in that case, after having calibrated, had similar large deviations when pointing the D435i downwards or upwards instead of it facing straight ahead (they got 9.4 from the downward facing orientation). Is your camera pointing up or down please?

That user also got values closer to their expectations when using the rs-motion sample program instead of the RealSense Viewer. Would it be possible for you to try this program if you have not done so already and see if it gives better results?

https://github.com/IntelRealSense/librealsense/tree/master/examples/motion

[jaehwan-pi]

In #4571 the user in that case, after having calibrated, had similar large deviations when pointing the D435i downwards or upwards instead of it facing straight ahead (they got 9.4 from the downward facing orientation). Is your camera pointing up or down please?

That user also got values closer to their expectations when using the rs-motion sample program instead of the RealSense Viewer. Would it be possible for you to try this program if you have not done so already and see if it gives better results?

https://github.com/IntelRealSense/librealsense/tree/master/examples/motion

I performed a quick test according to your advice.
I measured the norm value of acc output, both in realsense-viewer and rs-motion.
The orientation of the device is set to 6 different cases according to the calibration white paper. (section 4.3.2)
(I used D435i box to hold it firmly as provided in "librealsense/tools/rs-imu-calibration/images/
")
In rs-motion.cpp main function, I added a couple of lines to check the value in the terminal as below.

// Get accelerometer measures
rs2_vector accel_data = motion.get_motion_data();

        auto acc_norm = sqrt(accel_data.x*accel_data.x + accel_data.y*accel_data.y + accel_data.z*accel_data.z);
        std::cout << "acc_norm: " << acc_norm << std::endl;

The result is as below.

1. Position 1

• viwer: 9.73(motion correction on), 9.48(motion correction off)
• rs-motion: 9.72

2. Position 2

• viwer: 9.78(motion correction on), 9.58(motion correction off)
• rs-motion: 9.77

3. Position 3

• viwer: 9.91(motion correction on), 9.76(motion correction off)
• rs-motion: 9.91

4. Position 4

• viwer: 9.87(motion correction on), 9.65(motion correction off)
• rs-motion: 9.88

5. Position 5

• viwer: 9.32(motion correction on), 9.24(motion correction off)
• rs-motion: 9.22

6. Position 6

• viwer: 10.32(motion correction on), 9.91(motion correction off)
• rs-motion: 10.32

So the viewer and the rs-motion example both gives abnormal value of gravity norm at some orientation.

When I see the rs-motion estimated orientation visualization, it looks reasonable with some dynamic lag(up to 1 sec approximately) when I change the orientation.

[MartyG-RealSense]

Thanks so much for the detailed test feedback!

Do you require further assistance or are you satisfied with the results, please?

[jaehwan-pi]

Thanks so much for the detailed test feedback!

Do you require further assistance or are you satisfied with the results, please?

As you can see the gravity norm value, it is not close to 9.8 even after the imu calibration.
It would be nice if you please provide further assistance how to get the value close to 9.8 at any orientation of the device.

[MartyG-RealSense]

Are you resting the D435i on a completely level surface when doing the calibration, please? The link below may be useful reading.

#3239

[jaehwan-pi]

I am off-shift now as it is nearly midnight in my time zone but I have made a note to take another look at your problem when I am back in 7 hours.

Are you resting the D435i on a completely level surface when doing the calibration, please? The link below may be useful reading.

#3239

Thank you for reply in quick!
I've tested on my desk, which is assumed to be level surface.
I just downloaded an Surface level app on my cell phone and put on my desk, it says 0 deg/ 1.0 deg. which is very close to the level surface.
Please check when you get back to your office. Thank you!

[MartyG-RealSense]

I went through all of the data again several times and did further research. It seems that the problem is that you can achieve a good calibration result but it does not appear to persist after the calibration is written to the camera.

#5177 (comment)

If that is the case then one of the Intel RealSense team members such as @ev-mp will be best able to advise you on the next step in the investigation. Good luck!

[ev-mp]

@jaehwan-pi , the results presented in your previous post show significant deviations in steps 5 and 6 that apparently weren't rectified by calibration:

The result is as below.

Position 1
viwer: 9.73(motion correction on), 9.48(motion correction off)
rs-motion: 9.72
Position 2
viwer: 9.78(motion correction on), 9.58(motion correction off)
rs-motion: 9.77
Position 3
viwer: 9.91(motion correction on), 9.76(motion correction off)
rs-motion: 9.91
Position 4
viwer: 9.87(motion correction on), 9.65(motion correction off)
rs-motion: 9.88
Position 5
viwer: 9.32(motion correction on), 9.24(motion correction off)
rs-motion: 9.22
Position 6
viwer: 10.32(motion correction on),** 9.91**(motion correction off)
rs-motion: 10.32

The scaling is off by ~5% along the specific axis, which is not acceptable.
Can you share the IMU calibration for verification? ('rs-enumerate-devices -c')

I suspect that this could be due to improper leveling of the device required in stages 2 and 4 (para 4.3.2.2, 4.3.24 accordingly) of the relevant white paper. But we'll wait for the calibration data before proposing rectification steps.

[jaehwan-pi]

@jaehwan-pi , the results presented in your previous post show significant deviations in steps 5 and 6 that apparently weren't rectified by calibration:

The result is as below.

Position 1
viwer: 9.73(motion correction on), 9.48(motion correction off)
rs-motion: 9.72
Position 2
viwer: 9.78(motion correction on), 9.58(motion correction off)
rs-motion: 9.77
Position 3
viwer: 9.91(motion correction on), 9.76(motion correction off)
rs-motion: 9.91
Position 4
viwer: 9.87(motion correction on), 9.65(motion correction off)
rs-motion: 9.88
Position 5
viwer: 9.32(motion correction on), 9.24(motion correction off)
rs-motion: 9.22
Position 6
viwer: 10.32(motion correction on),** 9.91**(motion correction off)
rs-motion: 10.32

The scaling is off by ~5% along the specific axis, which is not acceptable.
Can you share the IMU calibration for verification? ('rs-enumerate-devices -c')

I suspect that this could be due to improper leveling of the device required in stages 2 and 4 (para 4.3.2.2, 4.3.24 accordingly) of the relevant white paper. But we'll wait for the calibration data before proposing rectification steps.

Here is my calibration result.

Device info:
Name : Intel RealSense D435I
Serial Number : 843112072930
Firmware Version : 05.11.06.250
5.11.6.250
Recommended Firmware Version : 05.11.06.250
Physical Port : /sys/devices/pci0000:00/0000:00:14.0/usb2/2-7/2-7:1.0/video4linux/video0
Debug Op Code : 15
Advanced Mode : YES
Product Id : 0B3A
Usb Type Descriptor : 3.2
Product Line : D400
Asic Serial Number : 903223050581

.....

Motion Intrinsic of "Gyro" MOTION_XYZ32F
Bias Variances: 0.000000000000000 0.000000000000000 0.000000000000000
Noise Variances: 0.000000000000000 0.000000000000000 0.000000000000000
Sensitivity :
1.000000 0.000000 0.000000 -0.000053
0.000000 1.000000 0.000000 0.000018
0.000000 0.000000 1.000000 -0.000032

Motion Intrinsic of "Accel" MOTION_XYZ32F
Bias Variances: 0.000000000000000 0.000000000000000 0.000000000000000
Noise Variances: 0.000000000000000 0.000000000000000 0.000000000000000
Sensitivity :
1.019777 -0.003257 -0.024311 0.003639
0.022153 1.017656 -0.023045 0.035226
-0.016549 0.057250 1.017623 0.249794

It is weird that the bias values are all zeros.
How can I deal with?

[ev-mp]

The accelerometer's sensitivity matrix shows a notable bias for the third axis compared to the first two
1.019777 -0.003257 -0.024311 0.003639
0.022153 1.017656 -0.023045 0.035226
-0.016549 0.057250 1.017623 0.249794

I'm not an expert but this might be due to the camera's axes being not strictly orthogonal during the calibration process. (Putting @dmirota on notice)
Are you using level or any other precision sensor to verify the posture's horizontal/vertical alignment?

[jaehwan-pi]

The accelerometer's sensitivity matrix shows a notable bias for the third axis compared to the first two
1.019777 -0.003257 -0.024311 0.003639
0.022153 1.017656 -0.023045 0.035226
-0.016549 0.057250 1.017623 0.249794

I'm not an expert but this might be due to the camera's axes being not strictly orthogonal during the calibration process. (Putting @dmirota on notice)
Are you using level or any other precision sensor to verify the posture's horizontal/vertical alignment?

I used D435i sensor box as recommended in " "librealsense/tools/rs-imu-calibration/images/"
So I assumed that it is closely aligned to the horizontal/vertical.

[vishnukumarts]

+1.
I am also facing the same error. @RealSense-Customer-Engineering any update?

[Runepx4]

I am also facing the same error. The error is more or less the same across 4 different D435i - also on untouched factory calibrated cameras. I have also tried to use an Xsense IMU as a reference point for the calibration. The result is still a weird sensitivity matrix.

Motion Intrinsic of "Accel" MOTION_XYZ32F
Bias Variances: 0.000000000000000 0.000000000000000 0.000000000000000
Noise Variances: 0.000000000000000 0.000000000000000 0.000000000000000
Sensitivity :
1.016629 -0.007477 -0.000527 -0.033371
0.006057 1.011412 -0.001964 -0.182079
-0.011695 0.003967 1.019348 0.317798

@ev-mp , @RealSense-Customer-Engineering have you been able to reproduce the error or figure out whats happening? Is it a firmware, software SDK issue, or?

[lishanggui]

The rs_imu_calibration.py provided by Intel realsense requires that each position (write paper) needs to be completely horizontal or vertical during the calibration process. It is difficult to achieve absolute horizontal or vertical experimental conditions, and the accuracy of the calibration will be affected. Recently, I used other methods for calibration, and wrote the calibration results to the device through the rs_imu_calibration.py writer. I found that the results output using realsense-viewer and rs-motion are the same as above, and I suspected that it was an input device There was a problem with the post-correction imu data conversion process. Then I did this kind of experiment, let the equipment output the imu raw data, and use the calibration data to transform it by a program written by myself. As a result, the equipment was placed in a different way and the gravity acceleration was 9.8. Therefore, it is concluded from these experiments that the main reason for the inaccurate results after imu calibration is the problem of the underlying conversion. At the same time, I think that rs_imu_calibration.py is not a particularly good method, because reducing the accuracy requires more experimental equipment Horizontal and vertical. @MartyG-RealSense @ev-mp

[MartyG-RealSense]

@lishanggui. Thanks so much for your very detailed feedback! I'm sure a member of the Intel RealSense team will be able to respond to your test conclusions.

[Ttoto]

I am also facing the same error. The error is more or less the same across 4 different D435i - also on untouched factory calibrated cameras. I have also tried to use an Xsense IMU as a reference point for the calibration. The result is still a weird sensitivity matrix.

Motion Intrinsic of "Accel" MOTION_XYZ32F
Bias Variances: 0.000000000000000 0.000000000000000 0.000000000000000
Noise Variances: 0.000000000000000 0.000000000000000 0.000000000000000
Sensitivity :
1.016629 -0.007477 -0.000527 -0.033371
0.006057 1.011412 -0.001964 -0.182079
-0.011695 0.003967 1.019348 0.317798

@ev-mp , @RealSense-Customer-Engineering have you been able to reproduce the error or figure out whats happening? Is it a firmware, software SDK issue, or?

I come across with the same situation with my D435i. Such error happen on z-axis.

[RealSenseSupport]

Hi @jaehwan-pi @Ttoto

This PR #6029 was implemented. Please have a look and try the latest updates to see if your issues are fixed.

*If we don’t hear from you in 7 days, this issue will be closed.