QoS profile files proposal

[ivanpauno]

Fixes #280.

I have written down the ideas I have in a document, and I have included the points that were raised in previous discussions.

[jacobperron]

Thanks for starting a proposal!

I've left some thoughts and wording suggestions. In addition to the feedback below, I think we should consider other proposed solutions. For example, using a well-known set of ROS parameters was proposed. We should consider (and document in this design doc) the pros/cons of this approach versus a QoS specific file.

Also, what about providing individual QoS settings on the command-line (instead of bundling them in a file)? The idea is similar to what is possible with parameters; using parameters as a back-bone would give us the implementation for free. I haven't thought about it too much yet, but seems like it's worth considering.

[jacobperron]

Here's another round of review. After that, I think we can request review from a larger audience. It's probably worth making a post on Discourse to invite community feedback.

[gbiggs]

Is it possible to have a default profile that applies to everything, no matter what topic or service?

[ivanpauno]

I imagine:

<publisher topic_name="/**">

I didn't think about something that works for different kind of entities.

[gbiggs]

@ivanpauno What's your plan for moving forward with this? Do you plan to open it up to wider comments as a proposal, or are you going to take it as a design document and begin prototyping an implementation? If the latter, then I think you need to make it more concrete first. There are still a lot of coulds and shoulds in it.

[ivanpauno]

@ivanpauno What's your plan for moving forward with this? Do you plan to open it up to wider comments as a proposal, or are you going to take it as a design document and begin prototyping an implementation?

That's a great question.
I'm planning to do the following:

• Create a post in ROS discourse asking for feedback (probably today ...)
• Ask for feedback in the middleware working group meeting (next week)
• Refine details in the current design doc (next week)
• Start working on a prototype (hopefully, in 2 weeks)

If the latter, then I think you need to make it more concrete first. There are still a lot of coulds and shoulds in it.

I agree.
I tend to left a lot of coulds and shoulds, but it's confusing for the reader.

I will reorganize the document before starting a prototype.

[gbiggs]

I think refining those coulds and shoulds into musts and shalls while you produce the prototype is a fine approach. I don't think there's a need for a perfect document before starting to implement something to confirm decisions.

[ros-discourse]

This pull request has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/configuring-qos-profiles-from-an-external-file-proposal/15991/1

[fujitatomoya]

I think that this feature is useful and productive, we would use Named QoS Profile especially.

[fujitatomoya]

(just a comment) So do I, I don't see we necessarily use XML at the moment.

[fujitatomoya]

I was thinking opposite. It would be hard for node authors to make decision since this is dependent on what application requires. (i think that i am gonna find difficulty to make decision so maybe i am gonna just enables it.) even with the same node, topics and services, we'd like to adjust the QoS based on the use cases.

[budrus]

I would vote for node author opt-in. Otherwise you can end up in out of spec situations with strange behavior that is maybe not obvious when debugging

[ivanpauno]

@wjwwood can you share your thoughts on the matter?

[dabonnie]

As discussed in the middleware WG meeting, are you aware of the QoS policy definitions in rosbag2?

• https://index.ros.org/doc/ros2/Tutorials/Ros2bag/Overriding-QoS-Policies-For-Recording-And-Playback/
• https://github.com/ros2/rosbag2#overriding-qos-profiles
• Use QoS for subscription, recording, and playback rosbag2#125

this feature allows a user to specify the QoS settings for any recorded topic.

[ivanpauno]

As discussed in the middleware WG meeting, are you aware of the QoS policy definitions in rosbag2?

I wasn't aware of that particular feature.
I was aware of other ad-hoc mechanisms in different repositories, I've listed all of them in:
bd5b4d3

I think that the community will be benefited if we have a single and standard mechanism to allow configuring QoS profiles.
There might be some places where ad-hoc mechanisms still become handy, e.g.: configuring QoS of gazebo ros plugins in the sdf might still be useful.

---

The ros1_bridge also has an issue related to QoS configurability, and the idea was not to add another ad-hoc mechanism but wait until we add a general one (see here).

[ivanpauno]

I'm copying notes from the middleware working group meeting, thanks everybody for the feedback!
If some of the notes are wrong, please let me know and I will correct them.
I would like to receive more input about the topic.

Notes:

• @wjwwood

  What makes using parameters difficult for applying the same settings to multiple entities? Can we address that?

  • We would need a way to apply the same group of parameters to different places. I think that there are other issues with parameters:
    • You have one parameter callback for each of them, and not one for the whole profile. See answer to next item.
    • Parameters can be reconfigured. Allowing to reconfigure QoS profiles on the fly has a lot of drawbacks, and I haven't seen the need of that until now (neither I have heard people claiming that would be useful).
• @wjwwood

  What about letting the user mutually exclude settings, like reliable with history <= 10 is ok, but otherwise has to be best effort? Parameters let you do this, for example.

  • I don't think that would be possible with parameter callbacks, as each policy will be a different parameter and each of them will have its own callback.
  • This proposal includes a callback to accept/reject a parameter, so that's easy to do.
• @dabonnie

  What about the QoS Settings in rosbag2? Similar feature: https://index.ros.org/doc/ros2/Tutorials/Ros2bag/Overriding-QoS-Policies-For-Recording-And-Playback/

  • I wasn't aware of that mechanism. I think that that format isn't powerful enough to be used everywhere, but it can be a good start to implement this.
• @dejanpan

  How is it conceptually different from any other parameter you’d set on the node, e.g. publish rate or IP for camera device

  • I think there are a few differences:
    • Having to configure QoS profiles is a problem that needs to be solved in all nodes. Parameters are better for ad-hoc configurations of a node.
    • The current parameters API isn't great for representing a "group" of things, e.g.: There's no parameter callback to check if the group is consistent or not. One parameter cannot represent the whole QoS profile.
    • Parameters are reconfigurable, QoS profiles don't need to be so (and allowing so would be quite complex).
• @dejanpan

  We already have several different ways to configure things, this seems like adding more.

  • I'm not sure if we have several ways of configure QoS profiles. The only one that you can always apply is to specify the QoS profile in code. DDS profiles file can be used in DDS based rmw implementations but:
    • They are not applicable to all rmw implementations. There might also be slight differences between DDS vendor formats.
    • It's only possible to configure the "default QoS profile". As mentioned in the meeting (by @MiguelCompany I think) there was a proposal in fastrtps to allow more flexibility (PR). The proposal is still tied only to DDS based rmw implementations, it wouldn't be a native ROS mechanism.
  • The proposed format can be merged with the current parameters file format, so it wouldn't be a new file.
• @wjwwood

  should be opt-in, in his opinion

  • The proposal is opt-in 😉.
• @clalancette

  If you put it all in parameters, you run the risk of mixing “user” parameters, with things happening under the “node” level.

• @GerardoPardo

  there is a feature in the DDS XML standard for this

---

@wjwwood About using parameters, I would like to see a concrete proposal that can satisfy the following requirements:

• The same QoS profile can be applied to different entities without the need of copy-pasting.
• The name of the parameter can be inferred from the node name, topic/service name, qos policy to be configured.
  This requirement is important so that the mechanism can be baked into the ros API itself, and people don't need to write their own parameter name and parse its value.
• It's easy to configure a qos profile externally.
• The QoS profile can be accepted/rejected by the node, including checking conditions like reliable with history depth <= 10 ok, otherwise reliability must be best effort.
• The mechanism can easily be opted-in.

[dejanpan]

@ivanpauno replying to #296 (comment):

Having to configure QoS profiles is a problem that needs to be solved in all nodes. Parameters are better for ad-hoc configurations of a node.

I am not sure that I understand what you mean by that. Are you saying that there are nodes that do not need any parameterization? If yes I agree with that but what is the penalty if all nodes get parameterizied with the QoS profiles?

The current parameters API isn't great for representing a "group" of things, e.g.: There's no parameter callback to check if the group is consistent or not. One parameter cannot represent the whole QoS profile.

I would first like that we agree that QoS settings in a node are no different than any other parameter that the node might have. Namely as an example, a camera node that sets the frequency at which an image is published out of the node, is almost the same thing as setting the reliability at which this node sends out those same images. Or consider Deadline - that is a totally node specific configuration that will be different for a camera node publishing messages at 25Hz and lidar node publishing messages at 10Hz.

Now if I am able to convince you that, then I would like to say that there are definitely use cases for parameterizing a "group" of things in the nodes. For instance, if you have 4 cameras on your robot car and you are processing the data from these 4 cameras. The downstream nodes will use the same configuration for queue size, debayerization, rectification, image size, ... With this logic, if "parameters API isn't great for representing a "group" of things", then that is really a flaw that should be fixed in the implementation of ROS 2 parameters.

Parameters are reconfigurable, QoS profiles don't need to be so (and allowing so would be quite complex).

We implemented the read only parameters: https://github.com/ros2/rclcpp/pull/495/commits.

We already have several different ways to configure things, this seems like adding more.

I'm not sure if we have several ways of configure QoS profiles. The only one that you can always apply is to specify the QoS profile in code. DDS profiles file can be used in DDS based rmw implementations but:

What I mean is that we already have 3 different ways to configure ROS 2 applications which you list in the design document:

• Command line arguments
• ROS parameters
• Combining system default QoS with vendor specific QoS profiles.

Now you are adding the fourth one and this complicates things in that the other 3 ways will not go away and it is also impossible to prohibit users to not use the above 3 ways to also configure QoS settings via them.

Look what user now needs to do in their application to get through the configuration phase:

1. parse command line arguments
2. declare/get parameter
3. check DDS settings as set externally by the underlying DDS implementation
4. Some logic to check whether QoS settings were set via your approach and then to read them out (for e.g. printing or checking if the QoS settings are correct)

I think that this is insanely complicated and exactly error prone because there is too many knobs to turn.

[ivanpauno]

I am not sure that I understand what you mean by that. Are you saying that there are nodes that do not need any parameterization?

What I mean is that all nodes need some parameterization of QoS policies. Particularly: history kind, history depth and reliability should quite frequently be parameterized (I think we're saying the same thing).

If yes I agree with that but what is the penalty if all nodes get parameterizied with the QoS profiles?

The proposed issue is opt-in and by default it is not enabled, so there shouldn't be any surprises except the node's author consciously activated the feature.
After the feature is enabled, I don't think it will be any "runtime" penalty nor anything like that. The file will be loaded when init is called, and then an easy look-up in a data structure will be done when creating a pub/sub/etc.
I'm not sure if the question was referring to that.

---

About the difference between parameters and QoS settings:

It's true that qos settings can be considered as any other parameter. The main issue with using parameters is that you cannot make them look ergonomic, or at least, I haven't come up with something that is ergonomic. More on that later ...

Now if I am able to convince you that, then I would like to say that there are definitely use cases for parameterizing a "group" of things in the nodes
With this logic, if "parameters API isn't great for representing a "group" of things", then that is really a flaw that should be fixed in the implementation of ROS 2 parameters.

I was thinking the same while I was writing my original comment, but I don't think that solving that problem will be enough.

We implemented the read only parameters: https://github.com/ros2/rclcpp/pull/495/commits.

Yeap!

---

About the current ways of configuring QoS settings:

Command line arguments
ROS parameters

I don't think it will be confusing to have a mechanism specifically targeted to solve the QoS settings parameterization problems + this two "general" mechanisms to parameterize other things, but it might be arguable.

Combining system default QoS with vendor specific QoS profiles.

I think this doesn't solve the problem.
If your node has publisher A and publisher B and you set both to the system default QoS profile, then both will have the same QoS settings.

If we make this mechanism more powerful, following the ideas of ros2/rmw_fastrtps#335, I don't think that will look ergonomic.
If the standard mechanism to parameterize QoS settings is a DDS QoS profiles, our middleware abstraction would be too leaky.
Unfortunately when you want to tweak your system, you have to learn some details of your rmw implementation and be able to understand and tweak it. But if you need DDS specifics to do something that is frequently needed, I think we would be leaking details that we're trying to abstract away too early (if you only know ros, what is the data reader QoS?).

This mechanism cannot be applied to non-DDS rmw implementations, which I think it's not ideal.

IMO having DDS profile files as the only mechanism to solve the problem ergonomically is not an option, but I understand others might disagree.

Look what user now needs to do in their application to get through the configuration phase:

If we never use arguments and parameters to configure QoS, that won't be in the list of things you need to check.
There are a few ad-hoc mechanisms to configure QoS here and there, but most places lack a way to parameterize QoS settings.
Ideally, you would only need to check points 3. and 4. (and not points 1. and 2.).

---

I think that I need a more compelling argument about why I think that to manually parameterize QoS settings (i.e. not having a standard mechanism for it) don't work and why using parameters (even with the automatic creation of a known parameter subset) don't look ergonomic. I will try to write a full post about that.

[ivanpauno]

Ok I will try to answer why I think that we need an standard "built-in" mechanism to parameterize QoS settings and why parameters doesn't look ergonomic.

The need of a built-in mechanism

Suppose a node needs to parameterize the reliability/history kind/history depth of a publisher or subscription (which are required to be parameterized quite often):

So node A has only one publisher and one subscription, and the node uses the following parameters:

• is_publisher_reliable (boolean)
• publisher_depth (integer)
• does_publisher_keep_all (boolean)
• ... similar named parameters for the subscription

node B has also only one publisher and one subscription, and that nodes uses the following parameters:

• <pub_topic_name>_reliability (string)
• <pub_topic_name>_depth (integer)
• <pub_topic_name>_history (string)
• ... similar named parameters for the subscription

I think those kind of differences will create a usability problem.
This was a simple example with only two nodes and one publisher and subscription each. Imagine this in a real world use case, it will look bad.
It will also need a lot of repeated code in many places, so at least a set of helper functions will be needed to avoid inconsistencies.

Ergonomics of a solution based on parameters

I will suppose that the parameters API is more powerful than now:

• You have a way to define a group of parameters in parameter files, and apply them in different places (I will use yaml anchors in the following example).
• You have callbacks that allows the user to reject/accept a group of parameters (thus, allowing to check the consistency of them).

Based on that, I imagine that the best we can come up is something like this:

/**:
    ros__parameters:
        qos_profiles:  # group for all the qos settings
            # Using '/' will create problems with ros URLs to address parameters, thus a replacement is needed.
            # Using nested groups will create inconsistencies (and it would be a bit confusing).
            # We need a character that is not accepted in topic names but accepted in parameter names
            # I think both '/' and '#' aren't accepted in parameter or topic names currently (but we could fix that for parameters).
            'my#fully#qualified#topic#name#here': 
                publisher: &my_profile
                    reliability: reliable
                    history_depth: 100
                    history: keep_last
/my_ns/nested_ns/my_node:
    ros__parameters:
        qos_profiles:
            'my#fully#qualified#topic#name#here':
                publisher:
                    <<: *my_profile,
                    reliability: best_effort  # yeah, yaml anchors allow this :)

Maybe, it doesn't look that but after all ...
If we add support to:

• anchors in parameter yaml files (or a similar mechanism to reuse profiles, maybe we already support this (?))
  • edit: we do not support anchors currently
• Callbacks to accept/reject a group of parameters (i.e.: being able to check consistency of the profile in a callback)
  • edit: after revisiting the parameters API, I think that the only thing we need is a declare_parameters_atomically function or similar, that should solve the problem.
• Use const parameters for all qos policies.
• An API is provided to easily opt-in the feature (thus you don't need to manually declare the parameters neither parse their values). This should probably be extra arguments in pub/sub/etc options. There could be a node option to make the declaration automatic in all subentities, and in that case it should still be possible to opt-out the feature.
• Solve the problem of having / in topic names and not being allowed in parameters.

I think I will be happy with a solution based on parameters with all that solved ... (I have to put a bit more of thought on the parameters alternative, but it seems to be solvable).

[ros-discourse]

This pull request has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/ros-2-tsc-meeting-agenda-2020-09-17/16464/1

[budrus]

So the profile ID provides the matching between entities in the code and in the QoS configuration. I'm wondering if maybe there will be other configurations for entities in future and if it would make sense to have a more generic entity ID.

[ivanpauno]

So the profile ID provides the matching between entities in the code and in the QoS configuration. I'm wondering if maybe there will be other configurations for entities in future and if it would make sense to have a more generic entity ID.

The concept of ID would apply to subscription/publishers/etc, I'm not sure if I understand the question.

[budrus]

So the profile ID provides the matching between entities in the code and in the QoS configuration. I'm wondering if maybe there will be other configurations for entities in future and if it would make sense to have a more generic entity ID.

The concept of ID would apply to subscription/publishers/etc, I'm not sure if I understand the question.

I more thought of other non-QoS topics. Maybe there will be things in future where you have to configure something per entity and a differentiation is needed.
One example that just comes in my mind would be priorities for callbacks of subscribers. Imagine there is an executor that supports this and can also be configured similar to your QoS settings. Then you could also have two different subscribers on the same topic that shall be handled differently and must be uniquely identified (Maybe a crazy example).
My point is, if you have to introduce an ID to solve this uniqueness issue for QoS, would it maybe make sense to introduce this more generally? Then it could be reused if other use cases come up where this is needed

[ivanpauno]

Ah, I see your point now.
I think it could be available for other things, there's nothing restricting that.
I wouldn't make that "id" introspectable in the graph though.

[budrus]

I would vote for node author opt-in. Otherwise you can end up in out of spec situations with strange behavior that is maybe not obvious when debugging

[ivanpauno]

I opened a new proposal, this time based on using const parameters #300.
I think that it addresses most of the concerns that were raised before.

cc @gbiggs @dejanpan @budrus

[ivanpauno]

Closing in favor of #300.
Thanks everybody for the feedback here!