we would like to hear some comments on this. any idea will do good, so let us hear what you guys are thinking about this. also any milestone for extension are planned or not.
currently any parameter events such as changed or deleted parameter using ParameterEvent.msg will be notified via “parameter_events”. this single topic will be used for all of parameter activities.
it is really simple enough to use only single topic to notify parameter events, but from user perspective we like to receive the event that we are interested in only. we can filter the event from parameter_events topic but we must receive all of the events anyway. we do not actually want to receive the event if not necessary.
there would be some options i guess,
all parameter events via single topic “parameter_events” (current)
parameter events via topics for each node (user can specify whose parameter is interesting)
each parameter via each topic (user can specify which parameter is interesting)
This would seem to be a similar situation as with TF: clients receive all broadcasts, but may only be interested in a subset. Clients are shielded from this by the listeners and buffers in TF, to which the filtering you mention is delegated (sort-of: the Buffer does store everything that comes in, but clients only query the buffer for information they are interested in when they have a need).
This reminds me of the bus vs channel communication patterns. Either you receive everything and filter yourself (bus), or you make connections with just those entities producing messages you are (certain you are) interested in. Both are limiting you, as you cannot easily switch.
To avoid implementing something like the TF client library for parameter events, and looking just at DDS, perhaps content-based subscriptions could be used. They would allow you to express interest in only subsets of messages published on certain topics. Filtering would be delegated to DDS, and callbacks would only be called whenever the filter predicate matches.
I think content-based filtering at the DDS level would be the most efficient way to handle this, but a nice API at the parameter/node level would make it more user-friendly and future-proof.
thanks for the thoughts, i think that DDS contents filtered topic would work too.
the question is any DDS implementation supports “contents filtered topic”?
as far as i know, contents filtered topic is one of the extension, so not sure what vendor supports that feature right now.
From user perspective I believe the best would be to have a node which I can roslaunch in only in case I need parameter updates (events). So this node can be configurable on start and send events only for those parameters I’m interested in
e.g. roslaunch prameter_events default.launch update_list:=param1,param2
I had submitted a PR to the rclcpp repository to add a ParameterEventsSubscriber class which I’d hoped would address some of the issues mentioned here. Namely, the class subscribes to one or more parameter events topics (on either your current namespace or remote namespace), can filter events by parameter name and node, and can set a custom callback per parameter.
i think that we need to consider DDS contents filter topic to see if we can actually do what we want to do. and then bring up those interfaces up to ROS generic common API, so that parameter_events can be modified with new nice API. that is just idea and keep posted if we got anything.
I’m somewhat hesitant about content filtered topics, as they introduce quite a lot of complexity in the rmw layer. The mechanism for expressing filters is complex and would be a huge burden for non-DDS rmw implementations.
I’m not 100% convinced about the motivation, as I do not think the bus approach (receiving all and filtering for what you want) is going to be problematic in practice. It’s actually worse for tf as data is usually streaming continuously (especially before tf_static and with things like moving robot arms). Though it is not disallowed nor technically wrong, I don’t foresee parameters change so much that you cannot subscribe to all events and filter down. It will be most intense during startup of a large system occurs. And I don’t think many things will need to subscribe to this topic (mostly logging tools and introspection tools).
Additionally, there are other ways to address this problem which may not be as elegant, but are still sufficient in my opinion. For instance, we could have a composable node that you could attach to any process which would subscribe intra-process to /parameter_events and then filter as you configured it to do, and republish it on a new topic for external consumption. This solution keeps the middleware simple (and therefore more portable), and it should achieve similar performance to the content filtered topics.
Also, though many of the implementations support content filtered topics, I believe many will not do publish side filtering (this is not a requirement of the feature in DDS, AFAIK). And therefore it will simply be doing what you the user could do (or a library on your behalf) and receiving all data, but filtering it before delivering it to you.
That all being said, some significant value could be gained by using content filtered topics with keys and instances. We do technically allow key’ed types via IDL now, but we lack the API support to make use of this effectively right now.
So it’s worth investigating still, but I just wanted to temper the interest in content filtered topics slightly, and/or prepare you guys for the fact that adding them to the middleware API is a significant undertaking.
And I don’t think many things will need to subscribe to this topic
but as long as parameters are there, user wants to do something via parameter events. i believe that this is reasonable. and mostly user is interested in specific parameter for each node, it will receive all of the parameter events anyway. of course that is always depending on use cases.
would be a huge burden for non-DDS rmw implementations.
possibly, yes
I’m not 100% convinced about the motivation
me neither, we are just trying to figure out what is suitable for.
I believe many will not do publish side filtering
So do I, but this is the key for improvement we want.
including this, i believe that it is worth to investigate the feasibility.
ParameterEventsSubscriber is introduced in Add ParameterEventsSubscriber
i think that we could improve that using Contents Filtered Topics base on ParameterEventsSubscriber.
We tried to use ContentFilteredTopic with opensplice, i see this could be really useful to optimize /parameter_events to be filtered with user interests. opensplice supports ContentFilteredTopic but only on DataReader side filtering which is not efficient enough for network transport.
Does anyone have plan to support ContentFilterTopic on DataWriter side with multiple expressions and array types? i just trying to get more information around here.
All DDS implementations support partitions, and there are quite a few tricks one can play with them (you can publish in multiple partitions, subscribe in multiple partitions and use wildcards, too). Currently ROS2 doesn’t rely on partitions so one would think there is a way to use them for this. It’d be worth a try at least.