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

Is it possible to share global variables between nodes?

asked 2013-07-13 19:09:23 -0500

Toletum gravatar image

I'm in a situation where I need to track how many messages are in a Subscriber's Queue. Since there's no straightforward size() function for the queue, I need to track both the amount of publishing and the amount of subscribing. In other words, I am tracking how much one node -- let's call it PubNode -- can keep up with another node -- let's call it SubNode. I've tried to create a brand new node that will track both PubNode and SubNode, but in practice it seems to create unnecessary overhead.

To resolve this, I want to create a "PubNode counter" that SubNode can access. Is it possible to create global variables that two separate nodes can access? It seems that PubNode and SubNode would have to be linked, but I'm pretty sure this isn't possible.

edit retag flag offensive close merge delete

Comments

A more radical suggestion might be to simply use the callback to copy the incoming message to a local queue. If this is fast, then you shouldn't end up with (m)any messages on the subscriber queue. Then, you have direct access to the local queue. Of course, there's copy overhead.

Bill Smart gravatar image Bill Smart  ( 2013-07-15 09:44:09 -0500 )edit

Given that you now have your publisher listening to your subscriber, have you looked into using a service for the subscriber to request the next message? Another alternative, depending on the rest of your design specs, would be for the subscriber to implement a queue_size service.

lindzey gravatar image lindzey  ( 2013-07-15 18:06:46 -0500 )edit

8 Answers

Sort by ยป oldest newest most voted
4

answered 2013-07-15 12:14:54 -0500

Toletum gravatar image

Thank you for all the suggestions. In the end, I had my Subscriber publish a "confirmation message" back to the Publisher. That way, the Publishing Node could always keep track of both the number of messages sent as well as the number of messages that were received.

The difference of "sent minus received" then provides the current Queue size (unless of course the Queue overflows, but that's another matter entirely).

edit flag offensive delete link more

Comments

1

Sending acknowledgements is a reasonable design. Messages could get lost, so the answer may not be exact.

joq gravatar image joq  ( 2013-07-16 16:02:11 -0500 )edit
4

answered 2013-07-13 21:35:50 -0500

noonv gravatar image

it seems to me - no. Nodes - are different processes.

edit flag offensive delete link more
3

answered 2013-07-14 16:50:21 -0500

updated 2013-07-15 09:08:57 -0500

Maybe you can use the parameter server... "Nodes [...] communicate with one another using streaming topics, RPC services, and the Parameter Server."

EDIT: In order to mantain modularity and independent nodes, you can modify (increment?) a parameter '/pub_counter' everytime you publish on a topic. On the other side you can check this parameter within your callback function.

edit flag offensive delete link more
1

answered 2013-07-15 06:43:23 -0500

Bill Smart gravatar image

You could use a shared memory buffer if you really want to have a shared global state. Or, you could publish the number of messages published on a separate topic. Anyone interested could subscribe to that topic. In the callback, you would copy the number from the message into a local variable, and this should (most of the time) correspond to the actual number of sent messages, from which you can calculate the number in the queue.

edit flag offensive delete link more
1

answered 2013-07-14 01:55:17 -0500

Sentinal_Bias gravatar image

Maybe you could create a service call where the publisher can ask the subscriber how many items in your queue, but i am not sure how to check the size of the message buffer

edit flag offensive delete link more
0

answered 2013-11-01 23:24:48 -0500

The Node-architecture is imho not very suitable for a global variable. To keep track of a FIFO-load level you would typically go for a handshake protocol, like the proposal with the ack.

If you really want to have a shared memory my proposal would be to create an additional Node, let's call it "RAM", that offers a suitable set of services and topics to read/write to it. This way you have global storage for all your Nodes.

edit flag offensive delete link more
0

answered 2013-11-01 02:06:23 -0500

I have heard that global variables are bad and you better use "var" before the references. But is this a case where global variables are good?...

edit flag offensive delete link more
0

answered 2013-07-15 03:23:40 -0500

thebyohazard gravatar image

Perhaps the nodes could put their information in shared memory or mailboxes for message passing?

edit flag offensive delete link more

Question Tools

1 follower

Stats

Asked: 2013-07-13 19:09:23 -0500

Seen: 4,256 times

Last updated: Nov 01 '13