ethzasl_xsens_driver icon indicating copy to clipboard operation
ethzasl_xsens_driver copied to clipboard

Published 20 hours ago • verified publisher icon ethz-asl

issue on delaying timestamp at every specific sample.

Open lastflowers opened this issue 8 years ago • 9 comments

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.

untitled

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.

lastflowers avatar Oct 27 '17 10:10 lastflowers

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?

fcolas avatar Nov 28 '17 10:11 fcolas

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.

lastflowers avatar Nov 28 '17 11:11 lastflowers

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?

fcolas avatar Nov 28 '17 13:11 fcolas

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

xsenx_delay

facontidavide avatar Mar 22 '18 13:03 facontidavide

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?

fcolas avatar Mar 23 '18 12:03 fcolas

Sure, I will do it.

facontidavide avatar Mar 23 '18 13:03 facontidavide

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

fcolas avatar Mar 23 '18 13:03 fcolas

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.

lastflowers avatar Apr 09 '18 13:04 lastflowers

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

fcolas avatar Apr 10 '18 15:04 fcolas