q: diff between rmw and dds QoS functionality?

[liamstask]

I'm trying to determine roughly what the diff is between QoS functionality available via rmw interfaces vs dds itself. From a read through rmw/{types, qos_profiles, rmw}.h it looks like there are some diffs:

• reliability: seems to just specify reliable/best effort, could not find mention of things like ordering, max_blocking_time
• ownership: with respect to ability of DataWriters to write to a topic/object, could not find mention of this
• liveliness: determine writer is present independent of rxed data

i think there are others as well, but wanted to check to see what is intended/planned.

[jacquelinekay]

Correct, the rmw interface offers only a subset of DDS QoS at the moment.

Your perusal of the code base led you to the correct files. For the complete set of DDS QoS policies, I generally reference this page, which is categorizes the QoS policies nicely: http://www.opendds.org/qosusages.html

As you can see, the DDS QoS space is large and complicated. After some discussion, we decided not to expose the entire QoS space in ROS 2 for now, to keep the API simple and to keep the possibility of supporting a middleware besides DDS. We are adding QoS settings to the rmw API as we discover aspects that are necessary to implement expected behavior (for example, we introduced Durability so that services would work reliably for the "ROS 1" usage pattern).

It is still possible to set QoS policies in some DDS implementations outside of ROS 2 and see their effect in ROS 2. For example, in Opensplice there is an xml configuration file in which the user can specify the full QoS space. I believe in our current implementation that configuration is the default behavior, but the settings specified in the ROS 2 API, such as reliability, can override certain values. (Policies not specified in the ROS 2 API are not overridden.)

Are there particular QoS policies that you would like to see introduced into the ROS 2 API? I'm guessing the ones you mentioned here are important; I'd be interested to hear more about how they relate to your use cases.

[liamstask]

thanks. that makes sense, i agree it's probably not necessary to expose the entire QoS config matrix.

a couple options that would be interesting for use cases i have in mind (and also seem generally valuable):

• ttl or max_blocking_time on reliable packets: for things like button presses or other events that really want retries, but are not generally valid after a certain period of time. i.e., if it doesn't get there in 500ms, don't bother.
• time_based_filter/lifespan: important to ensure that nodes can subscribe with configurations appropriate to their connection/bandwidth properties. i.e., a node with a local connection can request high frequency telemetry, while remote monitoring/display nodes can request a lower rate, making sure the remote link is not flooded with data at the rate requested by the local node.
• writer ownership: for cases in which the control stream for a single destination might come from one of several sources. a way to specify which source is active, and for other sources to know that they're inactive would be quite handy.
• liveliness: not sure it's required to expose this via DDS, as perhaps the ROS life cycle APIs would be sufficient, but providing a way to determine the presence of nodes, distinct from rxed data will be important. i'm thinking of ui implications (i.e., presenting to a user whether a component is connected/alive) as well as routing/failover (i.e., component goes away, how does system adapt?)

i haven't used DDS much other than poking around and doing some eval, so these requests are mostly an attempt to map some requirements onto my understanding of DDS functionality (which is likely imperfect!).

these are the options that seem most valuable, i wouldn't mind too much whether they are implemented by relying on DDS or some other layer.

[mikaelarguedas]

thanks @liamstask, I'm going to close this in favor of a meta-ticket tracking the exposure of additional QoS settings. #115

Feel free to comment there with your wishlist of QoS settings