Feature Request: More granular control of Quality of Service (QoS)

[hello-amal]

Issue Description

As far as I can tell, currently realsense_ros only allows users to set one of the discrete quality of service (QoS) presets for its topics (code here). Those presets are defined in rmw, here.

However, there are cases where users may want a QoS not amongst those discrete presets. For example, I have a use case where I want a reliability of BEST_EFFORT and a history of KEEP_LAST with a depth of 1. None of the preset QoS's match that -- the closest I can get is using the preset for sensor data, which has a depth of 5. The only way around this is by changing the system default, which depends on the RMW implementation one is using.

Hence, it would be great to allow users to specify their desired QoS with more granularity than is currently allowed. I'd propose having one parameter per dimension of a QoS policy (e.g., history, depth, reliability, durability, etc.), which are initially set to reasonable defaults but can each be overriden. This will provide the user full control over the QoS used by realsense_ros publishers.

[MartyG-RealSense]

Hi @hello-amal Thanks very much for your feature request. Let's keep the issue open for a time to give other RealSense ROS users the opportunity to comment whether they would also like this feature to be implemented.

[norakon]

Hi @MartyG-RealSense,
I support this feature request!. I have a use-case where I need to set the qos_profile.deadline property, but none of the QoS presets actually configure the deadline to be anything other than Infinite. It would be of immense help to specify that single property but keep the rest of the QoS settings to the default values.
At this current state, the QoS deadline property is useless.

[MartyG-RealSense]

Hi @norakon Thanks very much for your seconding of the request for more granular control of QoS. I will highlight this issue to my Intel RealSense colleagues on the ROS team.

[MartyG-RealSense]

Hi @norakon Regarding the feature request of more granular control over QoS, it is an idea that my colleagues on the ROS team were interested in.

They suggested that if RealSense users want the feature in the near future then a user could implement it themselves as a Pull Request (PR) and my colleagues can help them to integrate the changes. In this way, the power of open-source development is leveraged.