0
$\begingroup$

Rosanswers logo

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?


Originally posted by jarvisschultz on ROS Answers with karma: 9031 on 2012-09-07

Post score: 3

$\endgroup$

2 Answers 2

0
$\begingroup$

Rosanswers logo

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.


Originally posted by dornhege with karma: 31395 on 2012-09-07

This answer was ACCEPTED on the original site

Post score: 4


Original comments

Comment by Dan Lazewatsky on 2012-09-07:
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.

Comment by jarvisschultz on 2012-09-07:
I really like that idea actually. Some serious code refactoring is required, but it seems like quite a good solution!

$\endgroup$
0
$\begingroup$

Rosanswers logo

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").


Originally posted by joq with karma: 25443 on 2012-09-07

This answer was NOT ACCEPTED on the original site

Post score: 3

$\endgroup$

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.