Big drift and ROS_WARN: wait for imu, only should happen at the beginning

[marooncn]

When I use my device to run your code. It can compile and run, but the result is wierd and unstable with big drift. (Actually, I just move my device slowly around) My device parameter lists as below. Camera frequency: 20HZ IMU frequency: 400HZ (20HZ between two frames) the offset: 3ms (as the picture shows) I pay attention to this issue, maybe we have the same reason and I highly expect your test result @qintony . And another problem is the ROS_WARN: wait for imu, only should happen at the beginning We have tested that the imu data can be converted to the node to deal with without lost. So what's the problem? Thank you in advance.

[maciejmatuszak]

What's the hardware, software spec of the machine you running it on. Have you look at this issue #1? I am trying to run it on TX2 but no luck so far: #64 @qintony I think you will have to put something very specific on README file that the performance or ability run stable is linked to capability of the hardware.

[marooncn]

@maciejmatuszak My software and computer configuration is as mentioned in #60 . The device is customized.

[guanglun]

Pay attention to two points: The unit of acc and gyro. acc :m/s^2; gyro:rad/s;

[marooncn]

@guanglun , Thank for your response, but the units have been transformed to be metric.

[marooncn]

Solution: The problem is finally solved. There are four points.

1. ensure the device synchronous, if not , try to revise the device's driver.
2. [revised] In thesis, the static gyro data is assumed to zero mean. So you'd better calculate the actual mean and minus it. you can use bias_calculator.cpp to calculate the bias mean. [original] In thesis, the gyro bias is assumed to zero mean. ..
3. In config file, the projection_parameters means camera intrinsic matrix parameters. When you use ros camera_calibration package to calibrate the camera, there is a projection and camera matrix, you should use camera matrix as projection_parameters rather than projection.
4. [revised] If your device is not very reliable, be careful of setting estimate_extrinsic to 1 or 2. My IMU is ICM20602, when I set estimate_extrinsic to 1 or 2, the result is very bad. [original] Warning: Don't set estimate_extrinsic to 1 or 2. I think there is bug in the extrinsic parameter algorithm, hoping the author can check it. @shaojie @qintony.

[qintonguav]

Thanks for your work. Some points which I have different ideas.

2. The gyro bias is not assumed to zero mean. We calibrate is online. The gyro scope noise is assumed to be zero mean. You can check the gyr bias estimation result on EuRoC result.

4 . You can test "set estimate_extrinsic to 1 or 2" with EuRoC dataset. In fact, I always use 1 on my own sensors. Sometimes I use 2, since I am lazy to do extrinsic parameter offline calibration.

[marooncn]

@qintony Thanks for your response.

2. maybe my expression is not right. My original thought is the gyro mean when it's static.
3. I set estimate_extrinsic to 2 with EuRoC dataset to run the demo and find it's truly right. But for my dataset, it's invalid just as the below pictures show. estimate_extrinsic : 0 [the path: 47.9x30.2] estimate_extrinsic : 1 [the path: 6.5x14.5] estimate_extrinsic : 2 [it's totally wrong]

One key difference between my dataset and EuRoC is the IMU. My device's IMU is ICM20602($5.72) and they use ADIS16448($670.82). Maybe their device is more reliable and the optimization algorithm is based on much reliable data. And I revise the 4. Another question is the scale. We find the scale is much smaller than the actual when we run the code outdoors just as picture 1 shows (the actual: 79x52).

[qintonguav]

Yes. The second question shows that your IMU is unsynchronized or in low quality. That also explains that 4 fails with your sensor set. In fact, I find out even the most cheapest IMU (mpu6050), if well synchronized (https://www.seeedstudio.com/Loitor-Cam2pc-Visual-Inertial-SLAM-p-2873.html), can run VINS well.

[marooncn]

@qintony Thank you, I'll try to continue revise the driver if possible ! And what about the scale, do you ever test the code outdoors with big scale, is it OK in the scale?

[marooncn]

@qintony I test with Loitor in the afternoon and find it truly works well even though I set estimate_extrinsic to 1 or 2 except the scale is a little smaller than the actual (when estimate_extrinsic = 0, the scale is right). I am so weird that ICM20602 is more expensive than MPU6050, but why does the MPU6050 works much better? And our device is according to the device getting EuRoC dataset to make sure the synchronization. I pay attention to that MPU6050 uses DMP to deal with the original data, is something with it? Because we don't deal with the original data from IMU . And if we use filter to deal with it, does it effect the synchronization?

[qintonguav]

Sorry, I know little about hardware level. I don't know how IMU works... Sorry about that.

What I know is that I fully test the time offset between IMU and camera in Loitor. The time offset is stable and small, 3-5 ms.

The test method is that the camera look at chess board, meanwhile I rotate the device. We can get two ratation, one is from vision (chess board), one is from IMU propagation. We can find a time offset which can minimize these two rotations. You can test your device by this way.

[guanglun]

@marooncn @qintony The IMU Ros node is include acc_xyz,gyro_xyz.That's true.But are the orientation is useful?I found The EuRoC dataset orientaion is 1 0 0 0 always. About the synchronized.Because I use the hardware of mine:MT09V034 and MPU6000(MPU6000 is same as MPU6050).The hardware is same as loitor.I use an 1ms timer to add up.Each IMU or image data send with an time-stamp.The synchronized is good I think.But I can't work well. Next is the log of time-stamp:

1755 is sec,946000000 is nsec. I can't found what's problem with it.I will be happy to hear your advices.

[qintonguav]

Orientation is not useful. Orientation is the result fused by IMU itself. We don't what fusion method is used and we don't how accurate it is.

[qintonguav]

Timestamp looks ok. But is the timestamp accurate? May transmission delay, trigger delay, exposure time influence this timestamp?