issue on delaying timestamp at every specific sample.

[lastflowers]

Hello,
I have build your driver for imu data logging to have ROS timestamp along with stereo images
Since we are researching visual inertial odometry algorithm, timestamps on images and imu data are crucial.

Also we are using Mti-g 3rd generation legacy sensor,
https://www.xsens.com/products/mti-g/

When I draw timestamp rosbagged by Xsens_driver at 115200 bps, it shows like stairs, so I plotted delta t (interval between two adjacent timestamps), it shows substantial delay at every 7th data, but with coarsely correct number of samples per second. Below figure shows delta t at 100 Hz sampling rate and it should shows 0.01 second ideally.

It does not have any help with different sampling time setting, for example when I set sampling time as 12Hz then at every 5th sample, it showed delayed timestamp.

I think it is similar to jpapon's "Timestamp jitter" issue, and I tried some remedies you recommended, but still unsolved.

Could you give me some advice for the problem ?
Thanks in advance.

[fcolas]

It's not what I observe and I couldn't find a way to reproduce this issue. Does it happen only on a single bag? How are the IMU and stereo camera connected, are they both in USB? Does it happen also when you disconnect the cameras?
I guess you don't have access to a 4th generation IMU to compare?

[lastflowers]

It happened when connecting only with Mtig sensor, and I wired it through usb.
Also, it happened anytime, not on a specific bag.

So I tried the 3rd generation sensor with other laptop (ThinkPad W540) in Ubuntu 14.04 and it didn't show any remarkable delay.

Also, I tred the 4th generation sensor with the same laptop (Dell precision 5520, Ubuntu 16.04) posing the issue and it also did not show any remarkable delay.

I still don't know why only the combination of Dell & 3rd IMU shows huge delay at the sampling time.

[fcolas]

Can you check and compare the CPU load of the Dell and ThinkPad with the 3rd generation sensor? Is the driver using significantly different resources?
Also is the 4th gen IMU configured exactly in the same way as the 3rg gen., specifically using the legacy mode?

[facontidavide]

I am having exactly the same issue. I have a MTi-28A53G35 sensor and the load of the CPU is very low.

Could it be related to this ? https://github.com/ethz-asl/ethzasl_xsens_driver/blob/master/nodes/mtnode.py#L686

[fcolas]

I'm not sure, your graphs show that the delay you experience is less than this 0.1s delay so it doesn't seem to fit.
Could you try the time_debug branch and the topics as described in issue #52?

[facontidavide]

Sure, I will do it.

[fcolas]

If you can, you may also want to try with another cable (see #58).

[lastflowers]

Sorry for the late reply. Meanwhile, I've got 5th generation sensor, MTi-300, and no problem occurs in the timestamp issues in the dell laptop.

[fcolas]

Ok, no problem. Meanwhile, it would be great if you could test the support_gen_5 branch (see #63).