Allow qos to be changed externally

[gerkey]

Suggestion from @stonier: allow the qos setting on a topic to be changed externally at startup, similar to how we do topic remapping (e.g., do it on the command-line using appropriate syntax).

[gerkey]

To keep the syntax manageable, we might just allow profiles to be picked.

[wjwwood]

Notes from the API review in March 2020:

Notes from 2020-03-19:

• (wjwwood) it depends on the QoS setting, but many don't make sense, mostly because they can change some of the behaviors of underlying API
• (dirk) Should developers expose a parameter instead?
• (multiple) should be a feature that makes configuring them (after opt-in) consistent
• (jacob) customers feedback was that this was expected, surprised it was not allowed
• (karsten) could limit to profiles

[stonier]

Oh, hanging out in the attic. This is old :)

Given the potential change in behaviour that can happen when changing QoS, I'd retract the comparison with topic remapping. Apples and oranges.

My revised thoughts are mostly in line with @wjwwood's. Reason being that certainty in complex systems is valuable. Certainty about what is to be delivered, what can be expected and what is going wrong. This creates much needed clarity at all stages. If permitting external QoS configuration, the only way of achieving this would be if every developer tested against every QoS configuration possible. Nice goal, but ... we're all mere humans :) Practically, I feel like this would be akin to opening a can of worms.

Probably obvious I've been on a journey going from 'getting something working asap' to 'make damn sure it works as well'.

The original motivation was mostly concerning switching channels from reliable to unreliable. It would certainly be convenient to just flick a switch as needed, but it's not necessary, there are other approaches, albeit more labour intensive, that can work.

I'd be fine with, as @dirk-thomas suggested, a custom parameter being provided by a developer to flip the behaviour on a particular topic. I've actually done this. That way the promise between developer and user on what is permitted and what can be expected is explicit and does avoid having to write multiple versions of the same code (e.g. reliable and unreliable camera publishing node). In fact, I think this would be a nice informal convention to have where relevant.

What is standard practice in DDS communities? Do they generally permit QoS configuration in the system integration (e.g. ros launch) phase?

[clalancette]

The original motivation was mostly concerning switching channels from reliable to unreliable. It would certainly be convenient to just flick a switch as needed, but it's not necessary, there are other approaches, albeit more labour intensive, that can work.

Could you elaborate on what other approaches you've been trying out, and what has been working for you? I can imagine ways to do it, but most of the ones I've come up with are kind of ugly (essentially writing "bridging" nodes between reliable and best-effort).

I'd be fine with, as @dirk-thomas suggested, a custom parameter being provided by a developer to flip the behaviour on a particular topic. I've actually done this. That way the promise between developer and user on what is permitted and what can be expected is explicit and does avoid having to write multiple versions of the same code (e.g. reliable and unreliable camera publishing node). In fact, I think this would be a nice informal convention to have where relevant.

I think the problem with that is that it ends up being a lot of boilerplate inside of each ROS node that is created, and likely the authors would all do it slightly differently. I think I'd rather have the ROS 2 core have some of this functionality.

In point of fact, we already have something like this. If you create your publisher/subscriber with QoSSystemDefaults, then the underlying RMW allows you to reconfigure the topic using the DDS-vendor specific configuration file. There are a few problems with this scheme:

• Each vendor has a different configuration file format.
• In a classic ROS system, you take nodes from many different places and hook them together. If they haven't all opted-in to QoSSystemDefaults, then you can only reconfigure parts of your system.

What is standard practice in DDS communities? Do they generally permit QoS configuration in the system integration (e.g. ros launch) phase?

As far as I can tell, yes. All 3 of the vendors I'm familiar with (Fast-RTPS, Cyclone, Connext), support loading in an external configuration file that has QoS profiles. I'm less certain whether they can change all aspects of the QoS; I've only played around with them a bit.

Just as an FYI, there is a somewhat parallel discussion going on in ros2/design#296 (though that design discussion somewhat assumes we want this feature, and is talking about how to make it available).

[wjwwood]

I still think having the developer opt into what options can be changed at runtime (startup only, not during runtime) is the best option. One way to do that today is to create parameters to control this behavior. As pointed out this is labor intensive and produces a lot of boilerplate code. That being said, I think it is the best approach (this is a very opinionated stance), but for the reasons that @stonier just mentioned about managing the scope of what you need to test as the developer of a reusable component, i.e. one set of QoS, versus a few variations limited by the developer, versus all possible QoS variations.

I think having something to make this easier in the ROS 2 API is the right solution, maybe a way to indicate as a developer "create this publisher and let the reliability be reliable or best effort and default to best effort". Which would use best effort by default and create parameters automatically which the user could address using a well known naming scheme. Or something similar to this. This is essentially how the QoS XML configuration works in DDS, but importantly the developer opts into it and can limit the scope of it.

The problem with just leaning on QoSSystemDefaults is that you cannot default to something in your program that deviates from QoSSystemDefaults without using the XML file. For example, if you create a publisher with QoSSystemDefaults, then its reliability is dictated by the middleware, but will most likely be reliable (IIRC, but which it is doesn't really matter), and so you cannot express as the developer that you want it to default to best effort in the case that there is no user configuration provided.

Yes, I think ros2/design#296 came about after the API review, and would essentially close this issue if accepted. So discussion should probably be directed there. Or to the issue about this topic on the design site: ros2/design#280 (comment)

[gbiggs]

What is standard practice in DDS communities? Do they generally permit QoS configuration in the system integration (e.g. ros launch) phase?

In DDS, specifying QoS is generally considered a system-level thing. The spec allows a fair amount of freedom to configure QoS externally to a participant. However my impression is that it is expected that the person who writes the application's code is the same person who does the system-level integration. I don't think this is the same in ROS, where we have a much higher emphasis on re-use of nodes by people other than the original author.

[wjwwood]

However my impression is that it is expected that the person who writes the application's code is the same person who does the system-level integration. I don't think this is the same in ROS, where we have a much higher emphasis on re-use of nodes by people other than the original author.

Exactly this, my experience has been that the DDS user base historically is very vertically integrated, so dealing with these issues is easier, and you don't have the need to develop something that needs to work in a variety of scenarios. Of course there are exceptions to this, but just as general observation.

[stonier]

Could you elaborate on what other approaches you've been trying out, and what has been working for you? I can imagine ways to do it, but most of the ones I've come up with are kind of ugly (essentially writing "bridging" nodes between reliable and best-effort).

We almost never bridged. As you say, kind of ugly, costly too either in terms of latency or compute bandwidth. In development, we stopped doing things like rviz debugging over wifi and instead ensured our robots had ethernet ports that we could hard wire into. That was a good decision regardless of the reliable/unreliable inflexibility. For product over robot-robot or robot-server connections, we generally stopped designing middleware channels as we would for control inside a robot (pub-sub'ing everything) and adopted a more network-centric approach bundling and ferrying data across non-blocking request-response services combined with a process on the other side that would emulate continuous operation (~robot ghost) for other services that expected a continuous presence. For things like video streaming / logging we'd use (or planned to use in some cases) dedicated non-ros software to handle those problems.

More esoterically, we canned some robot-robot communications (always difficult) and adopted human style non-verbal communications by sending visual or bluetooth cues to sensors. This was much simpler and more reliable.

Not necessarily ROS software solutions but solutions nonetheless and I still feel they were the right choices for our use cases. Of course, there's a great deal of other use cases out there :)

[stonier]

For the record, I like the idea of a) permit external configuration by default with option to suppress by the node developer or b) suppress by default with option to open up by the node developer.

Permits certainty when needed while at the same time allowing for flexibility in the wild west :)

[ivanpauno]

Closing in favor of ros2/design#280.
Feedback in the current proposal is really welcomed ros2/design#296!!