show QoS setting of pubs / subs, option to choose transient local

[dirk-thomas]

Since transient local doesn't get matched with non-transient local the command line tools might only work with some topics. It would be good if these QoS settings would be visible and an options added to use transient local in the tool in order to match with other transient local entities.

[stonier]

If possible, even better if, e.g. rostopic echo is able to detect the type of publisher and the subscriber configures itself to be compatible.

[dirk-thomas]

If possible, even better if, e.g. rostopic echo is able to detect the type of publisher and the subscriber configures itself to be compatible.

This might work if all publishers use the same QoS but if they are heterogeneous an option to choose is required.

[stonier]

Assuming the ros2 topic echo node can introspect on the QoS settings of the publisher, wouldn't it be just a matter of matching durability and reliability settings (as per tables here)?

[dirk-thomas]

wouldn't it be just a matter of matching durability and reliability settings

Are you implying to create multiple subscribers? If yes, how do you make sure to not receive duplicates?

[stonier]

Are you implying to create multiple subscribers?

1. Introspect the QoS settings of the publisher (if it's possible)
2. Configure QoS settings on the subscriber that are compatible

[dirk-thomas]

How about the scenario I mentioned above: two publishers with different QoS? There might be no QoS setting for a single subscriber which allows to receive messages from both.

[stonier]

Aye, sorry - makes sense. I was getting distracted fumbling in the dark with problems on pubs/subs that have different QoS.

So, learning that concept of a topic really is a more complex beast. Given that it can mask multiple, independent flows of data, both ros2 topic list and rqt_graph no longer tell the complete story about how data is moving around a runtime system. That complexity seems like a shame, but given the non-centralised and asynchronous connection handling, I can't see how you can eat that cake and get all the QoS goodies at the same time. Would be curious to learn what thoughts you had on this.

Nonetheless, it would still be easy to manually orchestrate a robot launch to separate topics for incompatible connections, e.g. /lidar/cloud/reliable and /lidar/cloud_unreliable and you'll get that simple architecture for free, but development/debugging tools on the command line would still be eminently useful.

Example use case that would have been useful for me recently (on topics):

• Introspect a running topic to determine the QoS settings of publishers (rostopic list, rostopic info)
• rostopic echo <topic_name> be automagically compatible when it can and falls back to ...
• rostopic echo <topic_name> interactively assisting (choose publisher to conform to?) if there is ambiguity
• rostopic echo <qos-settings> <topic_name> manually for bash scripts, or spinning up a subscriber in advance

[dirk-thomas]

both ros2 topic list and rqt_graph no longer tell the complete story about how data is moving around a runtime system.

In its current form no, but there is no reason both of these tools couldn't be updated to consider the QoS and provide more detailed accurate information.

Example use case that would have been useful for me recently (on topics):

:+1: