Best way of sharing parameters/flags among nodes which donot change much?

asked 2014-10-27 10:43:41 -0600

Mind_hunter
51 ●12 ●15 ●18

updated 2014-10-27 10:48:37 -0600

i have to share some flags which do not change much among 4-5 nodes .A node named SERVER is changing the flags and thats very rarely. I have to check the value of flags at the rate of 10hz in other nodes . So which is the best way of implementing it. I already thought about some options like :
1. Publishing of flags on a topic by SERVER at a frequency of 2-3 Hz.
2. Using service call to update the value of flags in the nodes which have their own copy of flags.
3. Using parameter server.
4 Shared memory.
I do not think 1st option is the good one.

I have some doubts regarding this:
a). If i used the second option,will cpu`s time be wasted in looking for queue for the message arrival?
b). Is third option good for getting the value of parameter frequently ?
c). What about shared memory? I have read that shared memory is the fastest mode of interprocess communication.

edit retag flag offensive close merge delete

Comments

2

Answers provided by @ahendrix and @dornhege are very good! I'd like to additionally add that I once asked a similar question and ended up using the latched topic scheme...

jarvisschultz ( 2014-10-27 12:37:54 -0600 )edit

... suggested by @joq and @Dan-Lazewatsky in my project, and it worked great.

jarvisschultz ( 2014-10-27 12:39:02 -0600 )edit

@jarvisschultz..Thanks.

Mind_hunter ( 2014-10-27 13:18:03 -0600 )edit

add a comment

6

answered 2014-10-27 12:19:22 -0600

ahendrix

47576 ●179 ●367 ●662 http://namniart.com/

4) ROS does not provide any tools for working with shared memory. ROS uses TCP sockets, which are almost as fast as shared memory when used on the same computer, and scale to using multiple computers.

2) Using service calls won't scale well to multiple clients - you'll have to ensure that each client has a unique service name, and that the server is configured with the proper service names for all clients.

Personally, I would use a latched topic for this sort of frequent parameter update. (Using latching ensures that new subscribers will get a copy of the parameters as soon as they start up, instead of waiting for the next update).

Using the parameter server frequently puts more load on the ROS master, and because parameter queries and updates require the negotiation of a new TCP connection for each operation, it will have significantly higher latency than using a topic, which is based on a persistent TCP connection.

edit flag offensive delete link

Comments

parameter update is not frequent ..but parameters are being used frequently inside loop.....If i use POSIX libraries for shared memory how would be that ..

Mind_hunter ( 2014-10-27 13:43:52 -0600 )edit

1

You don't need the speed of shared memory for your application, and any speed gains you might get will be negated by the difficulty of implementing, debugging and maintaining the system.

ahendrix ( 2014-10-27 14:08:30 -0600 )edit

If you want to use the POSIX libraries for shared memory, you'll have to go read their documentation.

ahendrix ( 2014-10-27 14:09:55 -0600 )edit

Thanks.....

Mind_hunter ( 2014-10-27 23:00:27 -0600 )edit

Could you give some background or experience on the "more load on the ROS master"? I was under the impression from the documentation that if the parameter is not set frequently that there is no load - somehow more like push notifications. I have never measured this nor checked the code though.

dornhege ( 2014-10-28 06:19:17 -0600 )edit

1

Every parameter update causes the ROS master to make a callback to all nodes that are subscribed to that parameter. This shouldn't be a problem for parameters are updated infrequently, but in the 1-100Hz range I would start to expect latency or load problems.

ahendrix ( 2014-10-28 12:37:02 -0600 )edit

add a comment

4

answered 2014-10-27 11:39:57 -0600

dornhege