Failed to split propagation(running on custom dataset)

[cmakelabs]

Thank you for your efforts, I am facing this issue while trying to run it on my custom dataset:
[ WARN] [1718225318.764554291]: Last IMU time: 1695304207.518885182 [ WARN] [1718225318.864593672]: Failed to split propagation, skipping CFAR detections.
What could be the cause of this issue?
You guidance is sincerely appreciated

[rikba]

This happens when the timestamp of the arriving radar message is more recent than the last IMU time stamp. This happened in our experiments in the following cases.

1. Heavy CPU load causing ROS message transport scramble. The message is spammed quite often then (critical!)
2. Occasional ROS message transport scramble (not critical, can be ignored)

I can also imagine this happening if you replay a bag with sorted time stamps, but I'm not so sure. In general, it should not happen because the radar has a much longer processing time than the IMU and should always arrive a bit delayed. Possibly you can correct the radar time stamp by the chirp / CFAR duration. Or you would need to change the code to buffer radar messages and process them again once the current IMU arrives.

The warning is called here: https://github.com/ethz-asl/rio/blob/main/src/rio.cpp#L264-L270

[cmakelabs]

Thanks, I cannot determine the exact reason, but I would really appreciate it, if you could elaborate more on how to correct the radar time stamp by the CFAR duration or making a temporary buffer for radar messages, for the buffer it seems to be a simple solution but I cannot determine the particular mechanism to do it so that they get processed at the arrival of the IMU

[rikba]

At the moment, the CFAR detections are handled immediately in the radar callback function. If they don't meet the acceptance criteria, i.e., the current IMU message has not been processed yet, the radar message gets rejected. What you could do instead is

1. Create a buffer member for radar messages, e.g., a queue. It is important to handle them FIFO as the other case is not implemented in the optimization at the moment.
2. fill the buffer in the radar callback
3. In the radar callback, instead of handling a single radar message, work yourself through the buffer. Remove messages older than `propagation_.getFirstState().imu->header()
   (optional; you could also process the buffer at the end of the IMU callback)

[cmakelabs]

Thank you very much

[rikba]

No problem. If you implement this, I will be happy to review a pull request.