Topic synchronization with no delay

[madsherlock]

Hello,

What is the best / recommended way to subscribe to several ifm3d-ros topics (eg. depth image and infrared image) at the same time?

I have a method which processes different O3D data types, assuming they are part of the same frame.

I tried using the TimeSynchronizer, but this seems to introduce a relatively large delay proportional to its queue size.

Would it be better to have separate callbacks and assume they will be called in the order in which ifm3d-ros publishes topics? If that is the case, I could wait for the callback of the topic that is published last for each frame.

Thanks, Mikael

[tpanzarella]

I am not aware of any ordering guarantees provided by the ROS 1.x middleware infrastructure. A better approach would be to compare the time stamps on the message headers and register the individual image types that way. A set of images acquired from the same frame on the camera will have the same time stamp in the current implementation of ifm3d-ros. This may change in the future as we are looking toward clock synchronization between the host and the camera and passing through time stamps from the camera so as to make the ROS message headers more accurately reflect the real world time when the image was acquired as opposed to when it was received by the host which carries greater-then-zero latency.

HTH.

[tpanzarella]

Unrelated, but none-the-less noteworthy as you seem to care about latency, in a forthcoming release, we will be converting our ifm3d-ros interface to a nodelet, similar to how we handle things in royale-ros. This is just an FYI.

[madsherlock]

Thanks for your swift response. My best method so far is to increment a counter upon the arrival of a message on each topic. When this counter reaches the number of topics I subscribe to, I check if the timestamps match. If they don't I decrement the counter and repeat until the timestamps match. This synchronizes the messages within a few frames, and reduces my queue size to 1.

I am pleased to hear you are looking toward clock synchronization, so that we can accurately estimate delays within software without requiring a hardware trigger input to the PC. As far as I understand, the frames from the ifm sensor all have the same timestamp (as in the current ifm3d-ros implementation), seeing as they are (simply?) different representations of the same phase measurements. While I am unsure how the ROS timestamp (secs and nsecs) is to be interpreted in relation to a std::chrono::system_clock::now() timestamp, I am sure there is a direct conversion method. Perhaps something to do with a duration_cast and a duration_cast of the remainder. I would love to find out... Would the different image types have different timestamps due to the camera firmware?

I am also glad to hear about the upcoming nodelet interface, so we can reduce the small image copying overhead to nothing :-)

[tpanzarella]

@madsherlock Take a look at 0.6.1 We can now sync system and camera clocks. Additionally we stamp the images with the camera timestamp if it looks reasonable. This is thanks to @Alabate

If what you were looking for is captured in 0.6.1, could you close this issue?