Non-monotonic Timestamps of Sensors

[qiank10]

Hello authors,

I checked the timestamps of the sensors (e.g., radar, lidar, and GPS) and found that they are not non-monotonic. For example, the figure below shows the elapsed time between successive radar frames in city_1_0. Ideally, all values should be around 0.25s. But there are some negative values and very large positive values.

Then I played the radar frames and verified that they are continuous. I am wondering if it is possible to correct the timestamps from the raw data or manual correction is required for all sensors in the dataset?

Thank you and looking forward to your reply!

[kungfrank]

Same issue here.

[pglira]

Same issue here. There seems also to be a large time delay between the sensor timestamps, e.g. radar and lidar.

[pglira]

One of the issues is that leading zeros have been omitted in the timestamps file.

An Example from Navtech_Cartesian.txt.

Original:

Frame: 000001 Time: 1549880486.86608439 <---
Frame: 000002 Time: 1549880486.350291660
Frame: 000003 Time: 1549880486.583499066
Frame: 000004 Time: 1549880486.834471068
Frame: 000005 Time: 1549880487.91805455 <---
Frame: 000006 Time: 1549880487.347586459
Frame: 000007 Time: 1549880487.588126144
Frame: 000008 Time: 1549880487.838894144
Frame: 000009 Time: 1549880488.84418525 <---
Frame: 000010 Time: 1549880488.336436979
Frame: 000011 Time: 1549880488.592239363
Frame: 000012 Time: 1549880488.831495160
Frame: 000013 Time: 1549880489.88239966 <---
Frame: 000014 Time: 1549880489.338935159
Frame: 000015 Time: 1549880489.581734960
Frame: 000016 Time: 1549880489.827028679
Frame: 000017 Time: 1549880490.93279195 <---
Frame: 000018 Time: 1549880490.332600953

Corrected:

Frame: 000001 Time: 1549880486.086608439 <---
Frame: 000002 Time: 1549880486.350291660
Frame: 000003 Time: 1549880486.583499066
Frame: 000004 Time: 1549880486.834471068
Frame: 000005 Time: 1549880487.091805455 <---
Frame: 000006 Time: 1549880487.347586459
Frame: 000007 Time: 1549880487.588126144
Frame: 000008 Time: 1549880487.838894144
Frame: 000009 Time: 1549880488.084418525 <---
Frame: 000010 Time: 1549880488.336436979
Frame: 000011 Time: 1549880488.592239363
Frame: 000012 Time: 1549880488.831495160
Frame: 000013 Time: 1549880489.088239966 <---
Frame: 000014 Time: 1549880489.338935159
Frame: 000015 Time: 1549880489.581734960
Frame: 000016 Time: 1549880489.827028679
Frame: 000017 Time: 1549880490.093279195 <---
Frame: 000018 Time: 1549880490.332600953

[Afreshbird]

Have you solved the problem?

[pglira]

Well yes, but only by checking the numbers of digits after the comma and adding a leading zero if necessary.

However, generally, I lost interest in this dataset as it is buggy (see e.g. my complaint above about non-synchronized sensors) and also there is no support by the publishers.

[Afreshbird]

Well, thank you.