Try to autodetect matching QoS in `ros2 topic pub/echo`

Feature request

It could be a great usability improvement if ros2 topic echo would make an effort to use a matching subscription QoS, and similarly for pub. For a previous discussion, see #156. The basic idea would be (talking about echo but the same applies to pub):

• When all publishers have the same/similar enough QoS, it could be possible to find a matching QoS profile and use that.
• When there are multiple QoS, the user has to make a choice.
• This should probably work in combination with the --qos flags, which would fix the specified parameters and let the others be deduced
• It should be made the default behavior, if there are no big downsides

But that only talks about a single point in time, whereas for a long-running echo command publishers can come and go. That raises the questions:

• Should the subscription “recalculate” its QoS when a new subscription/publisher on the other side joins? That would mean checking that there is a QoS that’s consistent with the publishers and if that is not the current QoS, applying that to itself.
  • If the answer is “no”, note that it would be very unintuitive to get different output when you run two publishers, depending on which one started first (pub1, echo, pub2 vs pub2, echo, pub1). If I understand correctly, there are warnings about this now, which help somewhat.
  • If the answer is “yes”, should it prompt the user when there is no consistent QoS, or just exit with a message?
• What should the QoS be when there is nothing to match with yet?
  • This is related to the previous question: If the QoS is recalculated, that “default” QoS profile is meaningless anyway

[jacobperron]

1. Should this be circunscribed only to QoS profiles that come with ros2? or should it handle other possible combinations of QoS parameters?

I think it should handle any possible combination of QoS policies. I.e. we shouldn’t limit ourselves to the preset profiles as users are free to create custom profiles.

1. With current default QoS parameters (best_effort, volatile), the echo subscriber should be able to receive messages from any publisher. But if the publisher is transient_local, then older messages won’t be received. The idea would be to implement a logic that when all the publishers are transient_local, then make the subscriber transient_local as well, in order to receive older messages. Is that a step in the right direction?

I think that sounds reasonable.

1. I cannot find a reasonable way to detect when a new publisher joins, and to change QoS settings without risking to loose messages sent while the QoS change takes place. Any thoughts?

Maybe we don’t have to detect when a new publisher joins exactly, rather we can detect when there’s a new publisher with an incompatible QoS. There is a callback API that can let us know when a new incompatible publisher is detected (see this example).

Another case to consider is when publishers drop from the graph. It’s possible that if a publisher is gone, then the echo tool would be able to opt for a stricter QoS policy. E.g. consider the following:

• there are two publishers, one has best effort reliability and the other has reliable.
• “ros2 topic echo” subscribes with best effort since it matches with both publishers.
• the best effort publisher goes offline; now “ros2 topic echo” could change it’s QoS to be reliable, which would be a better match, though not required.

Of course we still have a similar problem of detecting when there is a change to the ROS graph. I think we can get notified that something in the graph has changed, but are not told what changed. So, we’d have to query the state of the graph whenever something changes, and re-evaluated the QoS settings. I’m not sure how expensive this would be. On top of this, I think a graph listener API is only currently available in rclcpp (there’s no Python equivalent).

---

I would say that as a first step, we could query all publishers at startup and pick QoS based on that; be a strict as possible while maintaining compatibility. Then, any time we get an “incompatible QoS” event, re-calculate the QoS of the subscription. Listening to graph events to detect dropped publishers is probably best to implement separately as I think it is a bit more involved.

[jacobperron]

The pub verb was resolved in https://github.com/ros2/ros2cli/pull/653