Add design document on configuring QoS at startup time

[jacobperron]

It is not uncommon to have a node provide a topic publisher or subscription that could be have different valid QoS settings depending on the application. In these situations, we see node authors offering ways to configure the QoS (typically in the form of a ROS parameter). For example,

ros-perception/image_pipeline#521
ros-drivers/ros2_ouster_drivers#26
ros-simulation/gazebo_ros_pkgs#1079

I think it would be valuable to have a common mechanism for configuring QoS at runtime. Having a consistent interface for node authors and integrators to use would hopefully make their lives easier.

See ros-simulation/gazebo_ros_pkgs#1079 for some early discussion.

(edit by @ivanpauno) Early discussion in ros2/rclcpp#239.

[ros-discourse]

This issue has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/transport-priority-qos-policy-to-solve-ip-flow-ambiguity-while-requesting-5g-network-qos/15332/2

[gbiggs]

This is possibly something that can be done via a set of well-known parameters. Maybe have the node base implementation check for those parameters when it creates publishers and subscribers, and use the QoS values from them if they exist?

I strongly agree with this comment about whether nodes should allow overriding or not. The node author is responsible for defining the allowable range of behaviour of their node, and that includes what range of QoS values it can support. They need to be able to prevent certain values being set. This is also something that the parameters mechanism could be leveraged to support, with its ability to reject certain parameter values.

Although a dedicated API that hides how it is being done could be useful.

[ivanpauno]

I've renamed the issue from runtime to startup time.
Re-configuring QoS profiles at runtime is much harder, and not what the original issue was aiming for (the three linked workarounds are for startup qos configuration).

The idea is to have a way to externally configure the QoS settings when reusing a node someone else has written.
For different use cases, different QoS profiles may be desired.

This also matches what DDS allows.

[jacobperron]

A design doc was added in #300.
And subsequently implemented in ros2/rclcpp#1408 and ros2/rclpy#635