Question about time shift between images and IMU

[LiuSnake7788]

Thanks for your awesome work! I‘m using your app to record SLAM dataset, which includes images and IMU data
But my data works so bad in ORB-SLAM3 that I doubt whether the data collected is good enough for SLAM.
Could you plz tell me is there potential time shift between image and IMU when captured?

[JzHuai0108]

There may be some time offset between images and IMU data, but it is usually less than 15 ms as shown in our MARS logger paper. Also you should examine the timestamps of images and IMU data to make sure they are more or less similar without a huge time offset.

[JzHuai0108]

I will close this inactive issue for now.

[CanCanZeng]

Hi, I find that the number of timestamp does not always equal to video frame number, there might be one frame lost in the beginning, so the time shift will be larger than 10ms. How to ensure that the time in the timestamp file corresponds one-to-one with each frame of the image in the video？ @JzHuai0108

[JzHuai0108]

According to here, are you comparing the number of frames of frame_timestamps.txt and movie.mp4?

[CanCanZeng]

Sorry @JzHuai0108 , it's my mistake, the number of frames in frame_timestamps.txt and movie.mp4 are the same. I made the mistake because there is one line comment in the beginning of frame_timestamps.txt.
But I still suspect that there is a frame lost in video beginning, since for my collected dataset, most of them has 11ms time shift, but some of them has 44ms time shift, and time duration of one video frame is 33.3ms, it's too coincidental. My phone is HuaWei P40.

[JzHuai0108]

How do you measure the time shift? What does the time shift refer to? The time offset between the camera and the IMU?

[CanCanZeng]

I do not use calibr to calibrate the time shift between camera and IMU, but use VINS-mono to do online estimation, it might be wrong, but I think it's too coincidental. By the way, the VINS-mono still runs well even if it estimates the time shift to be 44ms.
The definition of time shift is readed image clock + td = real image clock (IMU clock) from VINS-mono.

[JzHuai0108]

I think you are right. VINS Mono usually gives pretty good time offset estimates because the time offset affects much the measurement alignment. It may be true that a frame is dropped out somehow, but I can't imagine such a situation under the constraint that the number of frames and the number of timestamps are the same. The mars logger records one timestamp for a frame.