Get most compatibility QoS policies given QoS for multiple endpoints

[jacobperron]

Feature request

Feature description

In the presence of multiple publishers, with potentially different QoS settings, it is useful to automatically setup a subscription with a QoS that is compatible with the majority (if not all) of the publishers. Presumably, what it means for two QoS profiles to be compatible depends on the RMW implementation. Therefore, it makes sense to offer an API that, given one or more endpoints, returns a QoS profile that is compatible with the most endpoints.

Immediately useful in the following tools:

• ros2topic for choosing QoS based on existing publishers/subscriptions (Try to autodetect matching QoS in ros2 topic pub/echo ros2cli#594)
• rosbag2 for choosing QoS for recording and playback
• ros1_bridge (for example, Add hardcoded QoS for the /tf_static topic for parameter bridge ros1_bridge#304)
• domain_bridge for bridging multiple publishers on the same topic

Implementation considerations

Given the non-symmetric nature of publisher and subscription QoS policies, it may make sense to add two API's: one for getting a publisher QoS and one for getting a subscription QoS.

There already exists an implementation for DDS RMWs in rosbag2, see related issue about moving logic to a common place: ros2/rosbag2#601

I'm proposing we actually move the logic to the RMW layer, since it may vary depending on the RMW implementation.
Perhaps moving this logic to RMW is overkill, as the existing QoS policies are fairly specific to DDS. Alternatively, we could hard-code the compatibility rules in rcl.

[jacobperron]

@mjeronimo @ivanpauno @gonzodepedro Follow up from our conversation today.

[emersonknapp]

I can see this being an RMW function - with an implementation in rmw_dds_common that dds-based RMWs can all use, to avoid duplication. It does make sense that other implementations may have other rules (such as ignoring all qos so all is compatible)

[ivanpauno]

The feature sounds good to me!

Given the non-symmetric nature of publisher and subscription QoS policies, it may make sense to add two API's: one for getting a publisher QoS and one for getting a subscription QoS.

👍 you actually need the two functions, only one won't work.

I'm proposing we actually move the logic to the RMW layer, since it may vary depending on the RMW implementation.

IMO when we added the concept of QoS to ROS 2 we kind of accepted the DDS endpoint matching logic.
i.e.: it feels ok to me to just have a method in rcl.

I'm not against a rmw function though.

[mjeronimo]

Being able to get a publishing QoS when there are multiple subscriptions could come in handy for apps that republish messages, such as rosbag2 and rqt_bag. A related issue over in rosbag2: ros2/rosbag2#629