ROS2 QoS Reliability Issue

@ciandonovan

I have a couple of comments, i might be mistaken…

there is seemingly no functional difference between the two policies - both act as a reliable subscriber

i think this is the situation that you see with your environment? i am not even sure what this means…

using tools such as RViz over WiFi can cause a robot to stall

this is the problem that you want to solve?

Does it make sense if we have following feature to address this issue?

Rate Control Subscription

Rate Control Subscription can provide rate control on subscription side, even if many publishers are sending with high frequency rate.

The expected use case is that publishers are come from 3rd party application, then we cannot control the rate from subscriber.

This feature controls that subscriber application take the execution time for itself to keep the rate to take the message or issue the application callback based on the user specified rate on that subscription.

I introduced this feature at ROSCon JP 2022 Sony Keynote page 17, only this feature name.

more details for DDS are following.

Time Based Filter

This policy allows a DataReader to indicate that it does not necessarily want to see all values of each instance published under the Topic.

Rather, it wants to see at most one change every minimum_separation period.

Description

This is one of the QosPolicy TIME_BASED_FILTER that user application can apply it on DataReader.

Filter that allows a DataReader to specify that it is interested only in (potentially) a subset of the values of the data.

The filter states that the DataReader does not want to receive more than one value each minimum_separation, regardless of how fast the changes occur.

It is inconsistent for a DataReader to have a minimum_separation longer than its DEADLINE period.

By default minimum_separation=0 indicating DataReader is potentially interested in all values.

This QoS policy allows you to optimize resource usage (CPU and possibly network bandwidth) by only delivering the required amount of data to different DataReaders.

Details

  • minimum_separation parameter can be changeable during runtime.

  • This setting allows a DataReader to further decouple itself from the DataWriter objects. This means that even multiple DataWriter exists minimum_separation is decoupled from them.

Other Related Note

  • It is inconsistent for a DataReader to have a DEADLINE period less than its TIME_BASED_FILTER’s minimum_separation.

  • This does not make sense, so disallow this to be set is fine. So that QoS inconsistency event will be notified for user application.

  • RTI Connext DDS supports this feature.

  • DDS v1.4 specification does not explicitly describe either DataWriter or DataReader is responsible this filtering process. That means this leaves room for implementation specification.

3 Likes