[ros-users] [Discourse.ros.org] [Next Generation ROS] Keys in msg

[William Woodall]

We've been talking at length to RTI about this topic as well as some of the other vendors, and they suggested two concrete ways of using keys in ROS 2:

- using keys implicitly under the hood to make our topics which have namespaces more efficient (sharing data readers and writers between otherwise unrelated subscriptions and publishers)
- exposing the feature to users like yourself so you can choose to use keys in specific situations

For the first point, I think we decided that this would be very difficult to do correctly and efficiently. There are a lot of technical points as to why, but @dirk-thomas alluded to one which is that keys are not part of discovery, so something like `rostopic list` becomes a lot less useful.

In the end, we imagined a new feature that DDS could have which provides the performance benefits of `instances` which you get when using keyed fields on a topic, but without having to have the key itself in the message definition. This new kind of key is something between keys and partitions, or another imperfect analogy is partitions which create instances. This is by no means a sure thing to happen, and even if it did we'd have to wait on the DDS standard to add it and adopt it. But what I took away from it is that: keys are not ideal in all cases and we would love to use instances to reduce overhead and discovery traffic but not at the expense of requiring key fields in our messages.

For the second point, there's no reason (as long as we're not using keys under the hood) that we could not allow users to use keys in their own way, perhaps in the way you described. The only hesitation we had was that this is a sophisticated feature, which really ties our API to DDS much more strongly. To be clear, we don't intend to support anything other than DDS for the foreseeable future, but we did take a lot of care to insulate our robot specific code from the communication system underneath. Perhaps this is not a realistic abstraction, but in our reference implementation of ROS 2 we're trying to provide it. Therefore, we're (or at least I am) wary of taking more and more complicated features into our middleware abstraction layer (rmw, see: https://github.com/ros2/rmw). It's not a deal breaker for key fields as a feature of ROS 2, but a consideration we have.

---

To disagree or correct my self, I previously said:

[quote="wjwwood, post:2, topic:1942"]
So unless there is a big use case which is not possible with namespaced topics, I think wed probably not expose it.
[/quote]

I can now express a use case where keys would be much more efficient, which is the case of the parameter events topic.

I'm speaking here about parameters as described for ROS 2, see: http://design.ros2.org/articles/ros_parameters.html, where they are decentralized and owned by nodes, and there is no "special" centralized parameter server. Global parameters are realized with a node that has a conventional name (like `global_parameter_server`) and accepts all changes.

So, every node publishes to the "parameter event topic" anytime a parameter it owns is changed ([CRUD](https://en.wikipedia.org/wiki/Create,_read,_update_and_delete)), then a tool can subscribe to the topic and monitor all changes to the parameter system.

Now, this could either be "every node publishes to the same `/parameter_events` topic" or "every node publishes to its own `~/parameter_events` topic". The benefit of the first is that a tool that wants to monitor all changes only needs to subscribe to one topic (this is the same use case as `rosout`, many producers, one consumer of all producers). However, if you want to monitor one node, or only a few nodes, then you need to receive all the data and discard what you don't want, which is inefficient. For that use case, the second option is better, since you can subscribe to only the nodes you want to monitor, but is very inefficient if you want to monitor them all, because you need to subscribe to N topics, where N is the number of nodes with parameters.

This is a perfect case where keys are optimal, because it gives granularity but also efficiency when doing a mass subscription. However, I think simply exposing the keyed fields feature would allow us to do this, we don't need to put it under the hood of our namespaced topics. Also, after thinking about it a lot, and looking for common patterns in ROS 1 which would benefit from keys, I come up with very few. Some of them are important, but I don't get the feeling that it would be a feature that could be applied all over the place to strict benefit. But that last part is just my opinion.





---
[Visit Topic](https://discourse.ros.org/t/keys-in-msg/1942/5) or reply to this email to respond.