IMU configuration

[daniel.b...@gmail.com]

Hi,

I'm trying to calibrate my x-IMU 2.4 (InvenSense MPU 6050) and Asus Xtion with the Kalibr toolbox. The translation result from Kalibr is [0.117 -0.011 -0.041] but in real approximately [0.080 0.025 -0.035].

Now several questions occurred.

The main question is how I can select or estimate the correct accelerometer_noise_density, accelerometer_random_walk, gyroscope_noise_density and gyroscope_random_walk values.

The paper "Unified Temporal and Spatial Calibration for Multi-Sensor Systems" refers to the usage of the Allan Variance. Is the angular random walk from the "IEEE Std 952-1997" your noise density and the bias stability your random walk values?

What are the used units:
accelerometer_noise_density [rad/s/sqrt(Hz)]
accelerometer_random_walk [rad/s/sqrt(s)]
gyroscope_noise_density [m/s^2/sqrt(Hz)]
gyroscope_random_walk [m/s^2/sqrt(s)]

What is referred with continous-time? Is it correct to use the gyroscope_noise_density as the Allan deviation at tau 1 second divided by sqrt(updaterate)?

Another question is how to derive these parameters from the manufacturer data sheet.

For your ADIS16448 this would result in (http://www.analog.com/static/imported-files/data_sheets/ADIS16448.pdf):
accelerometer_noise_density: 0.23 mg/sqrt(Hz) = 0.0023 m/s^2/sqrt(Hz)
accelerometer_random_walk: 0.11 m/s/sqrt(h) = 0.0018 m/s/sqrt(s)
gyroscope_noise_density: 0.0135 deg/s/sqrt(Hz) = 2.3562e-04 rad/sec/sqrt(Hz)
gyroscope_random_walk: 0.66 deg/sqrt(h) = 1.9199e-04 rad/sqrt(s)

Your definition (imu_adis16448.yaml):
accelerometer_noise_density: 0.01 #continous
accelerometer_random_walk: 0.0002
gyroscope_noise_density: 0.005 #continous
gyroscope_random_walk: 4.0e-06

Differs the data sheet so much from your calibration or is there a failure in my selection from the data sheet?

Thanks
Daniel

[Paul Furgale]

Hi Daniel,

Great questions. We knew this would come up. Can you post the PDF report and output that Kalibr generated when doing the calibration?

We are working on the other answers.

Thanks!

Paul

[Daniel Baumann]

Hi,

here is the PDF report and the result. The IMU configuration was derived with the Allan variance. It is the same IMU and camera hardware configuration as in the first entry but another computation.

Thanks for your help!

Daniel

[Paul Furgale]

Hi Daniel,

Thanks for posting the result files. These help a lot. Something is really wrong with the optimization you posted. I'm posting the result files from our sample dataset for comparison.

The first warning of a problem is the errors after calibration:

Reprojection error squarred (cam0):  mean 214.053277681, median 74.4762436724, std: 384.963118132
Gyro error squarred (imu0):          mean 3138.16043825, median 906.548673425, std: 15960.4298566
Accelerometer error squarred (imu0): mean 5963.15108445, median 499.604505842, std: 173628.134309

These are *way* too high. If you see numbers like this, you know you can't trust the results. Compare these to our sample dataset:

Reprojection error squarred (cam0):  mean 0.0266269882083, median 0.0175690109969, std: 0.031673316691

Reprojection error squarred (cam1):  mean 0.0249169862923, median 0.016704846293, std: 0.0284431211119

Gyro error squarred (imu0):          mean 0.0118840564361, median 0.00579575492288, std: 0.0396879462967

Accelerometer error squarred (imu0): mean 0.343696414031, median 0.158795754927, std: 1.60734889392

However, to me, these numbers are rather too low. The mean value reported in this plot is the Normalized Innovation Squared (NIS). A full description is available in [1], see [2] for an application. If our models are correct, the answers should be 2, 3, and 3 (reprojection, gyro, accelerometer), the dimension of the error term. If they are significantly different, it means that something about our model is wrong. The three big problems will be

1. Overfitting of the spline to the trajectory,
2. Outliers, or
3. Incorrect noise models.

One of our students will post a will post a wiki page about noise models for low-cost IMUs, so here I'll just briefly touch on (1) and (2).

We covered case (1) in our paper [2] where it was absolutely necessary to adapt the spline to avoid overfitting. In our experience, this isn't necessary for the pose spline in the IMU case because the inertial measurements essentially regularize the curve. The bias spline could be a problem in this regard but, as these are short datasets, you are safe tightening up this value so that the spline is nearly constant. (You should also run the IMU for 5-10 minutes before capturing the dataset to try to stabilize the device temperature but that is another story!)

Outliers in your calibration dataset will ruin everything. Because we are using cubic polynomials to represent the state, you will get the best results with smooth motion. When I look at the predicted vs. measured accelerometer plot, I see a single measurement with a high force at about t=32.5. Because we aren't using any outlier rejection mechanisms, a single measurement like this can pull the whole calibration out of alignment! My favorite visualization of this is the "influence function" of different loss terms ([3], p36). Outliers with large values act as a lever. The larger the value, the more an outlier influences the result. Did you bump the IMU in this dataset? That could be a source of the problem.

Can you collect another dataset where you are careful to make the motion smooth and post the results again?

Thanks!

Paul

[1] Bar-Shalom, Yaakov, X. Rong Li, and Thiagalingam Kirubarajan. Estimation with applications to tracking and navigation: theory algorithms and software. John Wiley & Sons, 2004.

[2] Oth, Luc, et al. "Rolling shutter camera calibration." Computer Vision and Pattern Recognition (CVPR), 2013 IEEE Conference on. IEEE, 2013. (pdf)

[3] Zhang, Zhengyou. "Parameter estimation techniques: A tutorial with application to conic fitting." Image and vision Computing 15.1 (1997): 59-76. (pdf)

[Paul Furgale]

Hi Daniel,

As promised, here is our page about IMU intrinsics and Alan Variance (thanks Janosch!).

https://github.com/ethz-asl/kalibr/wiki/IMU-Noise-Model-and-Intrinsics

Let us know if you have any questions.

Best,

Paul

[Daniel Baumann]

Hi,

thanks for the helpful wiki page and the details. I have now evaluated the dataset with the Allan variance estimates.

First a new computation with the previous dataset and without the high force at t=32.5 (report-imucam-0_30.pdf). The results are better but the errors also too high:
Reprojection error squarred (cam0):  mean 66.5149497788, median 22.9005220635, std: 158.192882412
Gyro error squarred (imu0):          mean 2820.75409742, median 776.26830877, std: 13987.0513073
Accelerometer error squarred (imu0): mean 916.826338501, median 318.083396301, std: 4102.75987557

In the following the results with the correct parameters derived with the Allan variance analysis:
Reprojection error squarred (cam0):  mean 8.3090861423, median 4.70631636125, std: 10.8107911668
Gyro error squarred (imu0):          mean 14.7875273043, median 4.34830806398, std: 71.945656748
Accelerometer error squarred (imu0): mean 4.79248087364, median 2.00029039152, std: 13.5567197764

The main problem was the time synchronization between the camera and IMU. The camera has a delay of 27 ms. After correcting the times, using the "--time-calibration" argument and the the noise values multiplied by 10 is the result:
Reprojection error squarred (cam0):  mean 0.379076805639, median 0.227122250377, std: 0.474064452131
Gyro error squarred (imu0):          mean 0.177635979537, median 0.0594871338953, std: 0.711496516402
Accelerometer error squarred (imu0): mean 0.0533202985285, median 0.0197787630928, std: 0.142892298073

With this noise model matches also the estimated transformation between IMU and camera.

Thanks for your help
Daniel

[Paul Furgale]

Hi Daniel,

Hey, that is a great result. Thanks for sharing the steps you had to go through. I hope that is helpful for others!

Best,

Paul

[estel...@gmail.com]

Hi

I'm having some trouble determining the bias noise quantities for a 3DM-GX3-25 IMU. I have looked at the wiki, but still can’t figure out how to get the bias standard deviation. The datasheet gives an in-run bias stability of 0.04mg and 18deg/hr and an initial bias error of 0.002g and 0.25deg/s. http://files.microstrain.com/3DM-GX3-25-Attitude-Heading-Reference-System-Data-Sheet.pdf
For the same sensor http://arxiv.org/abs/1402.5450 provides a standard deviation of 0.0001m/s^3/sqrt(Hz) and 0.000618 rad/s^2/sqrt(Hz).
I have converted the datasheets values back and forth and seem to be stuck. Can you please help me understand how to get those quantities?

Regards
Estelle

[Janosch]

Hi Estelle,

Kalibr models errors in the gyroscopes and the accelerometers as follows:

measurement = true quantity + "white noise" + "slowly varying sensor bias".

Your question refers to how the bias variation is specified. In Kalibr, the sensor bias is modelled as a "random walk" process. Mathematically,

b_dot = sigma_b * w,

where b is the sensor bias, and w denotes "white noise". In other words b is an accumulation of small random fluctuations, and sigma_b (Kalibr: gyroscope_random_walk / accelerometer_random_walk in the IMU config yaml file) specifies how much b walks around. Sometimes, sigma_b is referred to as the "diffusion" of b.

sigma_b is rarely specified in sensor datasheets, since in reality the sensor bias is often a combination of all sorts of random processes (which we - and many others - cumulatively capture in one "random walk" process).

The "in-run bias stability" you mention typically refers to bias variation caused by "1/f noise" (e.g. flickering) in the sensor. Such a noise process leads to an Allan standard deviation which is constant towards longer integration times, and this constant is then termed "bias (in)stability". In practice, most manufacturers refer to the "bias stability" simply as the lowest point in the Allan variance - a key indicator of sensor noise performance.

Strictly speaking, there is no direct relation between "bias stability" and sigma_b, since they refer to different noise processes. One could assume that after the lowest point in the Allan variance, the bias behaves like a random walk, and hence compute sigma_b once the bias stability and the "rate/acceleration white noise density" are known.

My recommendation, however, would be to compute the Allan variance for your 3DM-GX3-25, and then obtain sigma_b from that. The wiki page explains the process.

Keep in mind that you might (will) have to increase the sigma_b you obtain from this procedure by factors. The reason for this is as follows: The noise model, computed from data captured when the sensor is at rest, does not capture effects such as scale errors or misalignment that will appear once the IMU undergoes motion. In other words your sensor error model will be too optimistic. To make Kalibr aware of that, increase the sigmas.

We have not worked with this particular IMU, and we'd be interested to see the results you get.

Let us know if you have further questions.

Janosch

[long yu]

Can any one tell me how to "evaluated the dataset with the Allan variance estimates"?  is there any source code or tools to do it ?

[riflei...@gmail.com]

http://fr.mathworks.com/matlabcentral/fileexchange/55765-avar