Rosanswers logo

In ROS1 there you can read params from node namespace (prefixing param name with "~") and global namespace (prefixing param name with "/")

If understand the tutorials




correctly, for ROS2 every node has its own param server and name space. Params can be adjusted via launch file or command line. However, regardles of the prefix in cpp code, the node will query its own namespace.

Now, what would be the recommended pattern if 2 cpp nodes shall share a common parameter that must be known to both of them? Is there any way to avoid having 2 parameters in different namespaces with the same value?

Originally posted by Wolf on ROS Answers with karma: 7555 on 2020-12-27

Post score: 3


2 Answers 2


Rosanswers logo

The parameter can be queried from a remote node. So you can choose one node to be the primary one and then query the remote parameter from that node from the other nodes.

Originally posted by tfoote with karma: 58457 on 2020-12-27

This answer was ACCEPTED on the original site

Post score: 0

Original comments

Comment by gvdhoorn on 2020-12-28:
What if there is no logical choice for a primary node?

Comment by tfoote on 2020-12-28:
That's outside the scope of the question where they "shall share a common parameter that must be known to both of them". But for completeness if they can both operate independently then I wouldn't consider the parameters redundant and then you should be willing to set them both.

Comment by gvdhoorn on 2020-12-29:
Two nodes sharing a common parameter does not necessarily mean there is a natural choice for a primary node. They could both (or there could be more) duplicates, none of which is the primary one.

I don't understand how this is out-of-scope here, as you suggested "choose one node to be the primary one", on which your answer hinged. My question seems to follow logically: what if that's not possible.

From your comment it would appear you suggest setting all shared parameters on all nodes in that case.

That's ok, but would seem to be a different answer and something the OP seems to like to avoid having to do.

Comment by tfoote on 2021-05-22:
"There's no logical choice" is a hypothetical catch 22, if there's no logical solution there cant be a solution. However if they are indistinguishable or equal then you as the deployer can choose one to be primary. You don't have to make A reference B and B reference A and be fully symmetrical.

If there are two nodes which are exact duplicates you can choose to make one primary, which is the one you'll address and the other one secondary which will reference the primary one.

Alternatively you could choose to have a third node which manages the common parameters specifically for the original two nodes to share references to. This third node would need to have the semantics of the parameters understood, but it could also understand more of the semantics of the coordination too which might be different than running the nodes in standalone settings.

There's no one answer that fits all situations.


Rosanswers logo

There can be two ways you can do this.

  1. By creating a Global Parameter Server, which is essentially just another ROS2 Node that loads all the parameters, accepts all the changes made to its parameters, and stays there until the entire application is shut down. This node can be queried to get/set the parameters loaded locally inside this node. You can also see this method as 'Creating your own Global parameter server.

You can read up on it more here: ROS2 Global Parameters

  1. Or, if your application is not too complex, you can simply use Wildcards in your YAML file. Wildcards will enable you to define the parameters in the YAML file, but will not associate them with any ROS2 node. This method is comparatively simpler.

You can read up on it more here: Using Wildcards in YAML file

Originally posted by Raza Rizvi with karma: 95 on 2022-01-24

This answer was NOT ACCEPTED on the original site

Post score: 3


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.