Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

getTopicQosProfile not reliable #962

Open
Flova opened this issue Mar 19, 2024 · 3 comments
Open

getTopicQosProfile not reliable #962

Flova opened this issue Mar 19, 2024 · 3 comments
Assignees
Labels

Comments

@Flova
Copy link

Flova commented Mar 19, 2024

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.

@Flova
Copy link
Author

Flova commented Mar 19, 2024

Also overwrites don't seem to be honored.

@mikeferguson
Copy link
Member

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

@mikeferguson mikeferguson self-assigned this Aug 6, 2024
@mikeferguson
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants