[ros-users] [Discourse.ros.org] [Next Generation ROS] Composition and Parameters: Best Practice Suggestions

William Woodall ros.discourse at gmail.com
Wed Dec 21 21:56:22 UTC 2016

The way you extended the example to include parameter client and service will work, but that's not the way I think you should do it. The idea of the manual_composition file is that you take existing nodes, instantiate them, add them to an executor, and run them, but nothing else. If I were you I would have added the parameter service and client to the node itself. (also I think the node automatically has a parameter service, so you should only need a client)

As for the parameter_event callback, that is a global event topic, meaning any change to any node will generate a message there. It was designed for tools to be able to notice any change to any parameter on the whole graph. We've talked about different ways of breaking that up, but for now it is an aggregate topic only. @rohbotics already opened an issue that these events cannot be associated to the node in question because the same topic is used by every node:


We haven't addressed that, I think, because we still had not gotten to parameter addressing and how namespacing will work with DDS. We covered the namespacing part, but we still haven't gotten to the parameter address scheme.

However, if all you want to know is when a parameter has changed on the current node, you can use the `Node::register_param_change_callback()` method, see:


[Visit Topic](https://discourse.ros.org/t/composition-and-parameters-best-practice-suggestions/1001/2) or reply to this email to respond.

More information about the ros-users mailing list