Strange IMU stamp time

asked 2015-02-19 03:21:22 -0600

169 ●10 ●14 ●18 http://www.ltu.se/staf...

updated 2015-02-20 10:39:25 -0600

Hello, I was recording the IMU data into text file using rostopic echo with -p parameter to use it in matlab. When i was inspecting the recorded data I figured out that the time stamp data is not correct! The following are the first records:

'2847249825529000000'
'2847249825558000000'
'2847249825577000000'
'2847249825589000000'
'2847249825617000000'
'2847249825638000000'
'2847249825650000000'
'2847249825670000000'
'2847249825699000000'
'2847249825719000000'
'2847249825730000000'
'2847249825751000000'
'2847249825779000000'
'2847249825799000000'
'2847249825810000000'
'2847249825830000000'
.
.
.

It is clear that there is no fixed sample time! The time difference for these time staps is absolutely not fixed!

Is there anything i can do to fix this problem?

Update: I am using the android_sensors_driver to publish the IMU data from my Android mobile phone.

Update: The header sequence is shown below, it is changing with the sample time:

'%time'              'field.header.seq' 'field.header.stamp'
'2847249825529000000'   '63303'  '2847249825529000000'
'2847249825558000000'   '63307' '2847249825558000000'
'2847249825577000000'   '63308' '2847249825577000000'
'2847249825589000000'   '63312' '2847249825589000000'
'2847249825617000000'   '63315' '2847249825617000000'
'2847249825638000000'   '63319' '2847249825638000000'
'2847249825650000000'   '63321' '2847249825650000000'
'2847249825670000000'   '63323' '2847249825670000000'
'2847249825699000000'   '63327' '2847249825699000000'
'2847249825719000000'   '63329' '2847249825719000000'
'2847249825730000000'   '63332' '2847249825730000000'
'2847249825751000000'   '63336' '2847249825751000000'
'2847249825779000000'   '63338' '2847249825779000000'
'2847249825799000000'   '63341' '2847249825799000000'
'2847249825810000000'   '63345' '2847249825810000000'
'2847249825830000000'   '63347' '2847249825830000000'

answered 2015-02-19 04:29:51 -0600

Martin Günther

11816 ●82 ●159 ●198 https://www.dfki.de/en...

updated 2015-02-20 04:46:43 -0600

These time stamps are strange indeed. Keep in mind that the format is "nanoseconds since the epoch (1970-01-01)", so your time stamps correspond to Tuesday, March 23, 2060. It's a bagfile from the future!

Apart from that, the difference between samples varies between 0.011 s and 0.029 s; it's not a totally fixed sampling time, but the absolute difference is not that big (0.02 s). Without knowing which IMU driver you used to record this data, it's hard to be specific, but my guess is that the IMU driver timestamps the messages on the PC instead of using the time stamp from the IMU (if there is one). Either the IMU really has a irregular sampling time, or (more likely) the variations are caused by USB jitter, delays in processing the data etc. If you know for sure that the IMU's sampling rate is more regular, this should be fixed in the driver.

Update: Thanks for the additional details.

Actually the zeros at the end of each time stamp is an indication that the driver some how is rounding the sample time.

Yes, it's rounding the sample time to milliseconds, but do you really need a higher resolution?

Regarding your original question about the non-fixed sample time: The driver is doing the best it can to publish the correct time, and there is simply a bit of variation. That's compounded by the fact that the driver has to combine three different sensor readings (with different time stamps) into one message (with only one time stamp). Does your application really require accuracy > 0.02 s?

Regarding the wrong timestamp: Since your timestamp is almost exactly twice the actual value, I suspect that ImuPublisher.java#L173-L175 are responsible. The code assumes that event.timestamp is in nanoseconds of uptime, but some devices (e.g., the Nexus 4) instead put the exact timestamp (since 1970-01-01) in there. You could open a new issue, but I'm not sure whether android_sensors_driver is still actively maintained. (Update: This fork has seen some activity recently, so maybe open an issue there: https://github.com/chadrockey/android... ).

edit flag offensive delete link

Comments

Thanks for your answer. Actually the zeros at the end of each time stamp is an indication that the driver some how is rounding the sample time. I updated the question for more details.