imu internal reference calibration
提示：本文部分大部分内容都是通过多次实验测试总结得出，有些地方比较玄学，也不是很严谨，希望懂得的小伙伴能在评论区指出。
foreword
Put the conclusion here first. The calibration of imu noise parameters is not very important for vio (such as vins, orb3), although their configuration files require an imu noise parameter, and the reason will be explained in the text. If the calibration of the imu is just to give a value to the noise parameter of the imu in the vio configuration file, it is not necessary to spend too much time pursuing an accurate noise parameter of the imu, which is time-consuming and meaningless.
1. Introduction to imu noise model
For a detailed introduction to the noise model of imu, you can refer to the introduction of the kalibr document, but the explanation is not very clear. It is recommended to read An introduction to inertial navigation to deepen your understanding. I also made a summary of the imu noise model .
Here are just a few things to watch out for:
- The noise of imu is divided into two types, " White Noise " and " Bias ", both have continuous time model and continuous time model. The two modes can be converted to each other. Here, it is emphasized that some calibration tools output continuous type ( imu_utils ), some are discrete ( kalibr_allan ). In addition, some VIO algorithms require continuous imu noise parameters, and some require continuous noise parameters, which are identified according to codes or units.
- In order to facilitate the subsequent calibration of the imu-cam, it is necessary to talk about the format of the imu noise parameters required by Kalibr. The noise parameters required by Kalibr are all continuous-time models, and the units are as follows:
2./imu/data sum/imu/data_raw distinction
The imu of px4 has two messages, one is /mavros/imu/data and the other is /mavros/imu/data_raw. It is explained in the mavros wiki that data is the solution of the pose, and data_raw is the original data. Generally speaking, most imu sensors have data and data_raw messages, but I don’t know who is more inclined to use them in vio, or it’s almost the same. Is there any comment section that can answer this question.
I recorded the data of the imu of the zed2 camera and the imu of the px4 in a static state , and recorded it in the following picture:
- The upper part of the picture above is the angular velocity information measured by the gyroscope of the px4's imu. It can be seen that the data is actually less noisy than data_raw, so the /imu/data of the px4 has been processed by a filter.
- Below is the imu message of zed2, data and data_raw are basically similar, but there are still some differences if you look carefully, you can think that data has a basic denoising process.
3. px4 flight control imu calibration, and problems encountered
补充：px4的内置有两个imu，选择imu数据的时候也是采用投票机制，具体可以参考下面的链接。关于能否用带有冗余imu机制的传感器作为vio中imu的数据来源，作者本来持怀疑态度，但是从论文中来看，px4很少出现，vins-mono用的大疆的N3飞控（没有imu冗余设计），但是《Robust Real-time LiDAR-inertial Initialization》这篇文章用的是px4-mini（有冗余的imu设计，和px4一样）作为lio的imu数据源。
Introduction of px4 sensor redundancy mechanism
There is a blog that uses the simulated imu data to compare the calibration results of kalibr_allan and imu_utils (link) . The result is that the Gaussian white noise and random walk of kalibr_allan are relatively accurate, while the calibration of the random walk error of imu_util (gaowenliang version) It is relatively poor, so it is recommended to use kalibr_allan.However, this blogger uses simulated data, which may have some deviations from the actual situation. I did not achieve satisfactory results in the process of using kalibr_allan myself. I do not recommend kalibr_allan (although it is written by uzh masters), and more Recommend mintar modified imu_utils .
kalibr_allan calibrates imu internal reference
There is a ros node in kalib_allan that converts bag files into mat files. You need to install matlab under ubuntu . After installation, you need to let cmake find matlab. You can refer to this https://blog.csdn.net/wuzuyu365/article/ details/52330830
In the following, I will use /mavros/imu/data to calibrate the internal parameters of imu.
- The first step is to record data from the resting state of the imu.
- Converting bag to mat
rosrun bagconvert bagconvert "bag文件位置" “imu的topic”
will generate a corresponding mat file in the directory location of the bag file. If the topic is incorrect, an error file of about 177 bytes will be generated. - Run the matlab script to generate the analysis picture of allan variance, you need to modify the directory location and imu frequency of the mat file in the m file , and the picture will be generated in the data folder.
question:
I recorded 2 hours of data before, and the result was that some parameters were Nan (as shown in the picture above, mainly the random walk of the gyroscope), but I recorded for 4 hours and found that it was still NAN, and then tried 10 hours, which was similar In the situation, the data was barely obtained after recording 12 hours of data, but the shape of the Allan diagram is not very standard, and the Allan diagram obtained from the 12-hour data is actually quite similar to the above picture, and there is no obvious 0.5 slope The straight line of can be fitted to obtain the random walk noise of the gyroscope.
4. Use the imu_utils modified by mintar to calibrate the zed2 camera imu
illustrate:
The imu_utils of gaowenliang seems to have a unit problem, but the master has not appeared for a long time. There is a discussion about the unit problem in the issue of github , and then a big guy named mintar modified the unit problem and changed the output value to The unit of continuous time is also open source, and the realsense camera is used to compare with the calibration results of allan_variance_ros (this open source algorithm is also recommended by Kalibr, and the comparison results are in the issue of imu_utils), and the results are very similar, so the algorithm should be more reasonable correct.
The following uses the mintar version of imu_utils to calibrate the imu in the zed2 camera.
The usage methods of the two versions are the same, so I won’t introduce them any more. This article recorded 4 hours of static imu data (in fact, only two hours of data was used in the algorithm), and then the calibration results are below (I calibrate both data and data_raw I don’t know which one vio should use):
| zed2_imu_data | acc_n | acc_w | gyro_n | gyro_w |
|---|---|---|---|---|
| /imu/date | 0.000972391498622108 | 0.0000161816136978825 | 0.000112059434444788 | 0.0000000377973509488189 |
| /imu/data_raw | 0.000972472149392801 | 0.0000161975724754375 | 0.000103903478028749 | 0.00000000748263828361598 |
This picture is the data of /imu/data drawn by the matlab code of imu_utils, the red line is the data of gyro, the blue line is the data of acc, the solid line should be the fitted data (from this point of view, in fact, kalibr_allan should not be fitted Fitting the curve to read the parameters, so I can’t read it out, I haven’t studied the source code, these are all guesses )? Circles and × are drawn from real data.
discuss
The data sets recorded during calibration are all recorded in a static state of the imu, but when we are doing imu-cam calibration or vio, the imu is in a state of dynamic motion, so directly using our calibrated parameters will cause problems. If there is a problem, there is a high probability that it will cause the system to crash. This problem is discussed in this github issue . Mintar gives some assumptions:
- The allan variance estimation methods (mintar/imu_utils and ori-drs/allan_variance_ros) estimate a model based on Q, N, B, K, R or at least N (“rate/acceleration white noise”), B (“bias instability”), K (“rate/acceleration random walk”). But all VIO packages and Kalibr just use N and K.
- The calibration is done under close to ideal circumstances in a static setup. In a dynamic setting, with other factors like temperature changes etc., the noise will be higher.
- The calibration packages take the average of the axes, but some IMUs have different gyros/accelerometers for different axes, so one should probably use the maximum and not the average to be on the safe side.
- In my setup, there’s no hardware synchronization between IMU and camera. Maybe using a higher standard deviation for the IMU prevents VINS from trusting the IMU too much and deviating when the real error is from a wrong time synchronization.
In addition, a note was made at the end of the introduction of Kalibr's imu noise model :
It is important to note that the IMU measurement error model used here is derived from a sensor which does not undergo motion, and at constant temperature. Hence scale factor errors and bias variation caused by temperature changes, for example, are not accounted for. So clearly, the model is optimistic. Particularly when using low-cost MEMS IMUs with Kalibr, you may have to increase the noise model parameters to “capture” these errors as well. In other words, if you use directly the “sigmas” obtained from static sensor data, Kalibr will tend to trust your IMU measurements too much, and its solution will not be optimal.
From our experience, for lowest-cost sensors, increasing the noise model parameters by a factor of 10 or more may be necessary. If you use Kalibr with such a device, please give us feedback, such that we can develop specific guidelines, device-specific parameter suggestions, or more advanced methods to determine these parameters.
So from the content of this discussion, the results of our calibration of the imu can not be directly used in the vio algorithm, at most it can only be used as a reference, and some amplification can be done on this basis. In other words, it doesn’t matter if we don’t calibrate the imu. For vio, when the effect of vio is not ideal, you can directly zoom in on the noise parameters of the imu for comparison. Including in the calibration process of the imu-cam, the noise parameters of the imu cannot directly use the results of calibration in the static state of the imu.
Someone explained this in the github issue, which I think is also very reasonable:
One additional factor—related to what was mentioned about calibrating in static vs running in dynamic conditions—might be that the IMU model used in all these VO / SLAM algorithms is practical, but still simplistic. I.e. it simply doesn’t model many of the effects on the physical device. I’m thinking of temperature-dependent bias, cross-axis sensitivity, etc. All this means that the errors in your model aren’t actually independent and bias-free and one way to deal with it is by increasing the measurement uncertainty to “mask” out the un-modelled behaviour.
But yes, it’s a valid question what’s the point of calibrating the IMU when you just hand-tune the values anyway. I think hand-tuning will always be needed. Calibration can still inform you about the relative quality of different IMUs and thus help when tuning the parameters (e.g. tell you if your values for a new IMU should be higher or lower than for some reference IMU that you know works well).
Next article: Joint calibration of imu-cam using Kalibr .