Data timestamp issues

[wsjpla]

Thanks for your great work of the ECMD dataset!

But I found some timestamp issues when using ECMD dataset.

The following figure shows the image of left industial camera, the time surface map of left DVXplorer camera and the middle LiDAR pointclouds with very close timestamps, but it seems that the timestamps of DVXplorer has a large timeshift (the image of industial camera and LiDAR pointclouds indicate that there is still some distance left before the car enters the tunnel, but the the DVXplorer indicate that the car has already entered the tunnel). Besides, the timeshift varies in different sequences. In some sequences, the timeshift is not that obvious.

[cpymaple]

Hi, Thanks for your interest.

1. Which sequences did you use so that I can check it?
2. It could also be related to the performance of your computer. The process of switching from compressed to standard images can be very CPU-intensive, and subscribing to three topics at the same time with a large amount of data can lead to time desynchronization.
3. The calculation of the time surface may also take up high computing resources, you can try to visualize the raw events.
4. We have already visualized all sequences in the following link, maybe you can try to find the corresponding sequence: https://www.bilibili.com/video/BV1Km4y157KC/?spm_id_from=333.999.0.0

[wsjpla]

Thanks for your kindly reply!

1. The sequence we tested is _Tunnel_easyc.
2. We determine msgs/header/stamp in data processing to ensure synchronization.
3. And we also use mutex lock and set large queue size to ensure that data processing won't cause desynchronization. The visualization of raw events after determining msgs/header/stamp also has the same issue.
4. There is nothing wrong when just playing the rosbag to visualize the squence.

I'm sorry if I didn't express my problem clearly. My problem is about msg's header/stamp. Playing the bag to visualize the sequence just indicate the time when the msgs were recorded in rosbag, not the real timestamp header/stamp in msgs. We determine msgs' header/stamp in data processing and found that the timestamps seem to have abvious timeshift. And the timeshift is only obvious in event cameras' msgs.

As shown in the following figure from _rqtbag, these two msgs, one from DVXplore and another from industrial camera, should have very close header/stamp but the timeshift seems to be more than 1s.

[cpymaple]

Thanks for your kindly reply!

1. The sequence we tested is _Tunnel_easy_c_.

2. We determine **_msgs/header/stamp_** in data processing to ensure synchronization.

3. And we also use mutex lock and set large queue size to ensure that data processing won't cause desynchronization. The visualization of raw events after determining **_msgs/header/stamp_**  also has the same issue.

4. There is nothing wrong when just playing the rosbag to visualize the squence.

I'm sorry if I didn't express my problem clearly. My problem is about msg's header/stamp. Playing the bag to visualize the sequence just indicate the time when the msgs were recorded in rosbag, not the real timestamp header/stamp in msgs. We determine msgs' header/stamp in data processing and found that the timestamps seem to have abvious timeshift. And the timeshift is only obvious in event cameras' msgs.

As shown in the following figure from _rqtbag, these two msgs, one from DVXplore and another from industrial camera, should have very close header/stamp but the timeshift seems to be more than 1s.

Thanks for your reminder.

1. You are right, in Tunnel_easy_c sequence, there exists timeshifts between DVXplorer and industrial camera timeshift. Event cameras exhibit acute sensitivity to environmental changes and potentially produce heavy data loads in an instant. When we collect this sequence, the enclosed environment of the vehicle leads to the situation of elevated temperatures in the SSD, which may reduce the transmission rate of the system. Therefore, when you use this sequence, you can manually add the timeshifts to DVXplorer event data.

2. We further randomly sampled other sequences in which there was no problem with time synchronization, so you might also consider using other sequences instead.

[wsjpla]

Thanks for your timely reply. I have tried other sequences and most of them don't have such obvious timeshifts.