You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
These issues should be addressed by #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
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
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.The text was updated successfully, but these errors were encountered: