search

marcelsheeny / radiate_sdk

SDK developed to access data from RADIATE dataset
MIT License
89 stars 32 forks source link

Non-monotonic Timestamps of Sensors #5

Open qiank10 opened 3 years ago

qiank10 commented 3 years ago

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.

image

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 commented 3 years ago

Same issue here.

pglira commented 3 years ago

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

pglira commented 3 years ago

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 commented 1 year ago

Have you solved the problem?

pglira commented 1 year ago

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 commented 1 year ago

Well, thank you.