Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
ROS 2 Launch System #163
I don't mind comments now, but it's not "ready" for review yet. I'm trying to push out a completed document as soon as possible, at which point I will solicit feedback actively, first on the pr and then on discourse. But until then, feel free to discuss, though I might not get back to you right away.
Good morning :), I pushed a set of changes for the "context" section where it compares it to ROS 1 and considers what might be different. I'm close but not quite finished with the system description and event sections, at which I think it will be in a relatively good place to start discussion on the pr (not quite ready for discourse still though).
@jack-oquin I'll try to respond to your comments asap, but I'll have to switch gears a bit before I have time to do that.
Configuring the Quality of Service for Connections (reliable, unreliable, ...)
In ROS1 you could only do this in the code itself. It would have been awesome if you could configure this at the launch level. You could rewire connections, but could not reconfigure the kind of connection. That always struck me as odd.
We did however, manage to get by on workarounds. If it was our code, we parameterised the node to provide QoS configuration. If it wasn't, we got by with relays. Though for the product, we wrote specialised nodes to handle a conglomeration of relays with various capabilities (subsampling, QoS, ...) to minimise the impact of so many extra processes. We even had ghosts on the server to manage the unreliable connections to the robot and present a an api to the rest of the server that was always 'up'.
How hard would this be to do for ROS2's launch system? In scope?
So, DDS does have a way to do this with XML files which can affect the QoS of entities in a program or globally. And we could do something similar.
However, I personally dislike this kind of runtime configuration, because when the person writing the code originally is not the person doing the system integration, changing QoS settings might break expectations.
As an example, a developer might create a node with a publisher which expects certain blocking behavior from the
Another example of this might be that a developer creates a program which pre-allocates 10 messages and sets the publish history to keep last and depth 10. If you externally change that to say 100, then maybe that breaks the program because now the history is larger than the resources pre-allocated by the developer.
Remapping of topic names is similar, and so the previous paragraphs might sound hypocritical, but I would argue that the important difference is that changing a topic name doesn't change the behavior of any of the API's in ways that might cause the program to break (as far as I can imagine).
I actually very much prefer this approach of having developer defined configurations which system integrators can tweak. By only allowing changes to settings the developer exposes, the developer can assume the others are not changing under their feet (so it avoids the subtle changes in behavior when QoS changes) and for the ones they expose then they can also put constraints on them, e.g. if the developer wanted to make the depth configurable, then they could expose a ROS parameter for that, and then constrain it to be within the range 10-100.
As for relays which rename, throttle, or downsample, I think the approach of having these are reusable nodes which can be added to the process of other user defined nodes is a better approach. In ROS 1 you had to have a separate process for each and that caused a lot of overhead.
So that's a bit opinionated from me about the way systems should be constructed, but I'm open to being convinced that runtime configuration of QoS is a good idea.
It would be hard as described because we have no way to control this right now in the C++/Python API. Like if a developer hard codes the history depth to 10 with keep last, then we have no way to intercept that and change it as it is being created. We could add that, it just isn't planned as far as I know.
I do think this out of scope for the launch system because the only impact it would have on the launch system is whether or not it's represented in the launch description and if so how it is communicated to the process containing the node. So I'd mention here after we decide to support that use case, but I'd put it in the same bucket as static remapping and parameters which are mentioned here but not part of the actual launch system itself.
Going to take a step back and say I completely agree with you. That feature thought was from a few years ago, yet when working on the product, we aggressively found ways to very carefully manage robot-server connections using a variety of methods, only some of which I have mentioned above. If I think to where we might apply roslaunch QoS configuration, it would be for almost trivial situations and not for where the critical problems lie.