ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

best practices: when to use parameter server and when not?

asked 2018-03-21 14:33:08 -0600

2ROS0 gravatar image

updated 2018-03-23 11:33:44 -0600


I was wondering what experiences people have had from using the parameter server...

  1. What cases must you use the parameter server? What types of data would you not read through the parameter server?
  2. What cases should you use some other methods, like a shared memory file?
  3. When should you use command line arguments?
  4. What other options do you have in addition to these?

Thank you

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2018-03-21 15:27:10 -0600

I use the parameter server for most configuration variables of my applications. The documentation mentions that it's too slow to really use it as 'random access memory' (and the documentation is right), but it's the perfect way to have a uniform configuration over the whole application. For calibrations, I often use separate files (the same way the camera_calibration package does it), but you can do that using the parameter server too (although you should probably think about writing them to disk). Variables I use all the time (or which are used on time-critical paths in the application) are read from the parameter server during initialisation and stored in class members.

I use command line arguments (Boost program-options) only for things that link a general node to a specific device (e.g. a camera node for the left/right/top camera) and for things I want to change while debugging (e.g. log directories, graphical debugging output...). That's a personal thing, but it allows me to use different settings while debugging without accidentally checking in a debug parameter file.

I use the parameter server, calibration files and command line options for configuration and publishers and subscribers, services and actions to pass other data around. Shared memory is an option, but I prefer to avoid it (after some years programming Erlang/OTP, I love how message passing makes concurrent applications much easier to debug than shared memory). Of course, you can also dump data to disk and read it from there or set up your own network or network-like connections.

edit flag offensive delete link more



Summarising: see the parameter server as a replacement for the classical configuration files that you would read from disk, only now their contents is accessible over a network connection (which is transparently handled for you by ROS).

Do not use it for any sort of (highly) dynamic data exchange.

gvdhoorn gravatar image gvdhoorn  ( 2018-03-22 06:07:13 -0600 )edit

Question Tools



Asked: 2018-03-21 14:33:08 -0600

Seen: 909 times

Last updated: Mar 23 '18