Publish combined message.

[bprevost]

I propose that a 'combined' message is published, containing the amplitude image, xyz_image, temperature, and uptime, etc. so that a client node needs only 1 callback to access the camera, and so that there is a guarantee as to which images are paired with each other. We already have the code available for this and it is available upon request.

[theseankelly]

Hi @bprevost -- My initial impression is it's redundant to publish data on multiple topics, but I do understand the reason behind this suggestion. It feels like this is a job for DDS QoS but I'd have to research the possibilities to lockstep pub/subs -- have you done any research on that topic?

[bprevost]

Our research indicates that just because the TOF publishes the multiple topics near-simultaneously, we do not have a guarantee on the receiving end (due to queuing, etc) which amplitude message goes with which xyz message, etc. Also, it's easier to process a single topic callback from the TOF, rather than handle amplitude, xyz, confidence, etc. and have to match them together.

[tpanzarella]

The way this is typically done in ROS1 is to use message_filters and in your case, you specifically want the Time Synchronizer I have not used these in ROS2 yet, but it looks like they have been ported and also available as binaries since crystal:

$ apt-cache search message-filters
libmessage-filters-dev - Development files for Robot OS message-filters
libmessage-filters1d - Library for Robot OS message-filters
python-message-filters - Python library for Robot OS message-filters
ros-melodic-fkie-message-filters - Improved ROS message filters
ros-melodic-fkie-message-filters-dbgsym - debug symbols for ros-melodic-fkie-message-filters
ros-melodic-message-filters - A set of message filters which take in messages and may output those messages at a later time, based on the conditions that filter needs met.
ros-melodic-message-filters-dbgsym - debug symbols for ros-melodic-message-filters
ros-crystal-message-filters - A set of ROS2 message filters which take in messages and may output those messages at a later time, based on the conditions that filter needs met.
ros-crystal-message-filters-dbgsym - debug symbols for ros-crystal-message-filters
ros-dashing-message-filters - A set of ROS2 message filters which take in messages and may output those messages at a later time, based on the conditions that filter needs met.
ros-dashing-message-filters-dbgsym - debug symbols for ros-dashing-message-filters
ros-eloquent-message-filters - A set of ROS2 message filters which take in messages and may output those messages at a later time, based on the conditions that filter needs met.
ros-eloquent-message-filters-dbgsym - debug symbols for ros-eloquent-message-filters

Alternatively, and specific to ifm3d_ros2 and the case you mention above (synchronizing the Cartesian and Amplitude data), the published PointCloud has a point type of XYZI where the "intensity" is the amplitude data. So, while this data structure is not cv::Mat it is another option you can contemplate to solve your specific problem. Not sure what other constraints you are under, so I offer it as a suggestion.

HTH.

[theseankelly]

Thanks @tpanzarella!

@bprevost does this solve your needs? If so I'll mark this 'wontfix' and close.

[bprevost]

Yes, thank-you. We'll look at message_filters or investigate/make an alternative in ROS2.