Revision history [back]

Given the types of data you mention, I would suggest to use the ROS parameter server for this.

The roslaunch rosparam tag in combination with .yaml files makes for a very convenient way to store and load settings of a ROS application.

Whether you load those parameters in the private namespace of nodes, or put them in a separate namespace and then have nodes load "their section" from that namespace would be a design decision only you can make (the former would reduce coupling though, so might perhaps be a better approach).

One thing I'm still wondering about: if you have to edit multiple files "when things change", this may be an indication of a violation of separation of concerns (ie: too many nodes/classes/functions need to be aware of various details to be able to do their work). It may be good to investigate whether all those entities actually need all that information, or whether they could get it from somewhere else (as part of a service request coming in, fi).

Given the types of data you mention, I would suggest to use the ROS parameter server for this.

The roslaunch rosparam tag in combination with .yaml files makes for a very convenient way to store and load settings of a ROS application.application. Example:

camera:
  device: /dev/video0
robot:
  ip_address: 1.2.3.4
workspace:
  area: [0.1, 0.3, 0.2, 0.4]
bins:
 - id: 1
   area: [0.1, 0.3, 0.2, 0.4]
 - id: 4
   ...

etc.

Whether you load those parameters in the private namespace of nodes, or put them in a separate namespace and then have nodes load "their section" from that namespace would be a design decision only you can make (the former would reduce coupling though, so might perhaps be a better approach).

One thing I'm still wondering about: if you have to edit multiple files "when things change", this may be an indication of a violation of separation of concerns (ie: too many nodes/classes/functions need to be aware of various details to be able to do their work). It may be good to investigate whether all those entities actually need all that information, or whether they could get it from somewhere else (as part of a service request coming in, fi).