image_pipeline getTopicQosProfile not reliable

In ros iron the QOS policy of the image proc nodes is currently determined by getTopicQosProfile with a default to the default sensor data qos policy. This is an issue, because during launch the incoming topic might not be available yet, so the sensor data qos policy is used. This causes downstream issues, because this qos policy is not compatible with reliable subscribers. So even if the input data has a reliable qos the output data might not in a non-deterministic way.

Mar 19 '24 17:03 Flova

Also overwrites don't seem to be honored.

Mar 19 '24 17:03 Flova

These issues should be addressed by https://github.com/ros-perception/image_pipeline/issues/847 - although only targeted at J-turtle currently. Backporting to Iron is going to be quite an effort since rolling/j-turtle have diverged so far from Iron at this point

Mar 19 '24 23:03 mikeferguson

Finally digging into this again (as part of 847) - and after examining the API interfaces we actually have available in image_transport - here's the solution I'm working on:

Subscribers will still have to use getTopicQosProfile since we can't pass QoS overriding to image_transport camera subscription function
Publishers should never have used this function, all the publishers should be defaulting to reliable and supporting the override mechanism

Aug 06 '24 00:08 mikeferguson

I had left this open to possibly backport the changes to Iron, but iron is now dead.

Dec 05 '24 17:12 mikeferguson