search

ros2 / design

Design documentation for ROS 2.0 effort
http://design.ros2.org/
Apache License 2.0
215 stars 194 forks source link

Add design document on configuring QoS at startup time #280

Closed jacobperron closed 3 years ago

jacobperron commented 4 years ago

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,

https://github.com/ros-perception/image_pipeline/pull/521 https://github.com/SteveMacenski/ros2_ouster_drivers/pull/26 https://github.com/ros-simulation/gazebo_ros_pkgs/issues/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 https://github.com/ros-simulation/gazebo_ros_pkgs/issues/1079 for some early discussion.

(edit by @ivanpauno) Early discussion in https://github.com/ros2/rclcpp/issues/239.

ros-discourse commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

A design doc was added in https://github.com/ros2/design/pull/300. And subsequently implemented in https://github.com/ros2/rclcpp/pull/1408 and https://github.com/ros2/rclpy/pull/635