Using sensor sensor QOS profile.

[alluring-mushroom]

We have a Linux ROS2 system with a many sources of high bandwidth data, including several SICK LMS511. We are locking down our QOS policies. I have noticed that the sick driver use the default QOS policy.

We are converting many things that don't need to be reliable to best_effort, specifically rmw_qos_profile_sensor_data, and I'm curious what the general opinion on using this for the SICKs is, as they seem to be what this profile targets. Specifically, it seems unlikely anyone would need to catch every single instant of the resulting pointcloud. Perhaps this is a useful change, and could be implemented as an option to keep backawards compatibility?

Thank you for your time.

[rostest]

Thanks for your feedback. In general, we recommend that the network topology is designed to provide sufficient bandwidth for the transmission of the ROS messages when using the lidars.

We will include your request in our backlog and plan it for the next release. We are implementing it such that the QoS profile can be configured in the launch file. The next release is planned for the end of October 2022.

[alluring-mushroom]

Thank you for your consideration and prompt response 😄

[aiplemaSICKAG]

Hi,
in the mean time you can always change the QoS on the receiving side to best_effort, which will lead to best-effort data handling, as the chosen policy is negotiated between publisher and subscriber (see the section "QoS compatibilities" on the page that you refer to: https://docs.ros.org/en/humble/Concepts/About-Quality-of-Service-Settings.html#qos-compatibilities).

Best regards,
Manuel

[alluring-mushroom]

@aiplemaSICKAG
Oh, that is some useful advice. I knew they were compatible, but I assumed it would lead to the behaviour appearing to be reliable, with the publisher retrying (due to being reliable), and that not affecting the client, as it didn't care either way.

Thank you for this clarification!

[rostest]

The QoS can now be configured in the launchfiles by parameter ros_qos:

        <!-- Configuration of ROS quality of service: -->
        <!-- On ROS-1, parameter "ros_qos" sets the queue_size of ros publisher -->
        <!-- On ROS-2, parameter "ros_qos" sets the QoS of ros publisher to one of the following predefined values: -->
        <!-- 0: rclcpp::SystemDefaultsQoS(), 1: rclcpp::ParameterEventsQoS(), 2: rclcpp::ServicesQoS(), 3: rclcpp::ParametersQoS(), 4: rclcpp::SensorDataQoS() -->
        <!-- See e.g. https://docs.ros2.org/dashing/api/rclcpp/classrclcpp_1_1QoS.html#ad7e932d8e2f636c80eff674546ec3963 for further details about ROS2 QoS -->
        <!-- Default value is -1, i.e. queue_size=10 on ROS-1 resp. qos=rclcpp::SystemDefaultsQoS() on ROS-2 is used.-->
        <param name="ros_qos" type="int" value="-1"/>  <!-- Default QoS=-1, i.e. do not overwrite, use queue_size=10 on ROS-1 resp. qos=rclcpp::SystemDefaultsQoS() on ROS-2 -->

Please checkout the latest release 2.8.14 and rebuild. Thanks!