I spent most of today experimenting with parameter events and the DynamicParamsClient from the nav2_dynamic_params package. I noticed some interesting behavior that should be addressed on node namespaces and duplicate parameter names across nodes.

Observations

• Nodes publish parameter events to the topic /namespace/parameter_events, where namespace is an optional argument upon construction of the node.
• By default, all nodes exist on same (empty) namespace and publish to /parameter_events
• Any parameter client to a node can register a callback which will subscribe to the topic /namespace/parameter_events under the namespace of the node the client was created from
• Thus, a callback on a parameter client will be triggered by any node on the same namespace, ignoring all other namespace events
• Inside a callback for an event, you can assume the namespace where the event came from but there is no event information to identify the source node (the node publishing the event)
• Parameter 'namespaces' kind of exist but apparently it is simply a prefix to a parameter, which I'm not sure if that's any more useful than using a unique identifier as of now

Impacts on DynamicParamsClient

• Fully scoped nodes with namespaces can be added by user, however to trigger all callbacks from any namespace, there needs to be a callback registered to a unique client on each namespace. I still believe it would be excessive to set a callback on multiple clients per namespace (would trigger multiple callbacks per one event)
• Dealing with duplicate parameter names across nodes remains a challenge, but because events on separate namespaces do not conflict, we can perhaps resolve the namespace of the event (though still not the node). This implies the code could be modified to manage one unique parameter key per namespace, though may lead to a more verbose user interface.
• Still unsure how to resolve duplicate parameter names by its source node. I would propose that the event msg include the host node name. That would resolve a lot.

If all parameters exist across multiple nodes in the same namespace, it may be the expectation that every parameter name is unique. However, in the original costmap_2d, for example, every plugin layer has a dynamic parameter enabled, where each layer exists as a node under the parent 'costmap' namespace. As is in ROS2, this pattern won't succeed because any trigger of the event callback can't resolve which enabled has changed. For now, we either make all parameters unique across all layers (currently in nav2_costmap_2d) or create them under their own separate namespaces. A proposal for the rclcpp code is to either allow parameter clients to subscribe callbacks to individual nodes (like the one they are already a client to) or include the node name (or fully scoped path) in the event message.

I welcome any thoughts on alternative approaches to deal with this situation, whether it should ultimately be resolved upstream with rclcpp, or feedback on desired use cases for dynamic parameters and callbacks.