ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A
Ask Your Question

project structure question concerning dynamic reconfigure and the parameter server

asked 2012-09-07 05:14:11 -0500

updated 2012-09-07 05:16:03 -0500

I have a system with many nodes, some written in C++, and some in Python. When devising the original "block diagram" for the system, I defined a parameter /operating_condition that is basically like a system-wide global variable. It is just an integer value used to tell many of the nodes what the system is currently doing. Often in callbacks, I will poll the parameter server to get an updated value for this parameter, and then respond accordingly.

I later found that as the number of nodes went up, and hence, the number of calls to the parameter server, I started getting large delays randomly cropping up. I eventually read on this page that this was a bad idea, and I switched almost all of these calls to use getParamCached(). That fixed the problem, but it is clearly not quite the right solution, more of just a temporary fix. As the project has evolved, I have been forced into writing more and more Python nodes, and there is no equivalent to getParamCached() (see this page). Using the dynamic_reconfigure package doesn't seem quite right either.

What is the right solution? A topic subscription with a callback in each node? Write my own service handler that can handle requests from each node? Just don't use "global" variables?

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

answered 2012-09-07 05:36:42 -0500

dornhege gravatar image

getParamCached seems like the right solution to me. You might be able to build that in python.

An alternative would be to publish /operating_condition using a latched publisher. I guess this is low-frequency data, so using a latched publisher should work well and later connecting nodes do get the data. The disadvantage would obvisouly be: If the publisher goes down, the information is lost.

edit flag offensive delete link more



I think a latched topic is the right solution since it's something you expect to change. If you're really worried about the node that publishes it going down, you could store it in the parameter server so that node has it when it comes back up.

Dan Lazewatsky gravatar image Dan Lazewatsky  ( 2012-09-07 07:04:27 -0500 )edit

I really like that idea actually. Some serious code refactoring is required, but it seems like quite a good solution!

jarvisschultz gravatar image jarvisschultz  ( 2012-09-07 07:55:09 -0500 )edit

answered 2012-09-07 07:22:15 -0500

joq gravatar image

updated 2012-09-07 07:23:59 -0500

Practices like this are rather subjective. Tastes vary.

Personally, I prefer to minimize use of global state variables, or at least reduce their scope to smaller parts of the system.

I recommend the latched publisher approach already mentioned by Christian and Dan. That is easy to implement and should scale well. It is also easy to understand.

I don't normally use the parameter server for mutable global data. But, Dan's idea of using it for restarting the latched publisher (if necessary) makes sense. That actually makes it local to the publisher node ("initial state").

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2012-09-07 05:14:11 -0500

Seen: 773 times

Last updated: Sep 07 '12