Ask Your Question
1

ROS Nodes and topics - are nodes really decoupled?

asked 2015-02-14 10:21:04 -0500

Anton Belev gravatar image

updated 2015-02-15 02:11:08 -0500

gvdhoorn gravatar image

http://wiki.ros.org/ROS/Technical%20O...

Note how the two sides are decoupled. All the hokuyo_node node does is publish scans, without knowledge of whether anyone is subscribed. All the rviz does is subscribe to scans, without knowledge of whether anyone is publishing them. The two nodes can be started, killed, and restarted, in any order, without inducing any error conditions.

We all know these statements that using topics, decouples ROS nodes. However reading the documentation on how the connection between the nodes established makes me question this statement. However in the transport section states the following:

Given a publisher URI, a subscribing node negotiates a connection, using the appropriate transport, with that publisher, via XMLRPC. The result of the negotiation is that the two nodes are connected, with messages streaming from publisher to subscriber.

Each transport has its own protocol for how the message data is exchanged. For example, using TCP, the negotiation would involve the publisher giving the subscriber the IP address and port on which to call connect. The subscriber then creates a TCP/IP socket to the specified address and port. The nodes exchange a Connection Header that includes information like the MD5 sum of the message type and the name of the topic, and then the publisher begins sending serialized message data directly over the socket.

So my question is, are the publisher and the subscriber really decoupled? After all in order the subscriber to get a message it has to open TCP/IP connection the the publisher port. And if the publishers are n the subscriber needs to open n connections. This means that it's not completely true that the subscriber won't be bothered if one of the publishers fails. So what exactly is meant by that statement that the nodes are decoupled?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
8

answered 2015-02-14 11:43:22 -0500

gvdhoorn gravatar image

updated 2015-02-15 02:13:13 -0500

tl;dr: yes, there are direct connections between nodes (so they need to know each others 'names' (IP addresses)), but that is only for efficiency reasons, and any dropped TCP connections between nodes will be gracefully handled by the ROS middleware (and thus invisible to nodes at the application/user level of the API).


While you are correct that there are TCP connections between nodes, I don't think that that is what the decoupled in the first quote you included refers to.

The following is an excerpt from the paper The Many Faces Of Publish/Subscribe by Patrick Eugster, et al., which for me is the clearest description of decoupling I know (you can read event service here as being equivalent to a middleware):

The decoupling that the event service provides between publishers and subscribers can be decomposed along the following three dimensions (Figure 2):

  • Space decoupling: The interacting parties do not need to know each other. The publishers publish events through an event service and the subscribers get these events indirectly through the event service. The publishers do not usually hold references to the subscribers, neither do they know how many of these subscribers are participating in the interaction. Similarly, subscribers do not usually hold references to the publishers, neither do they know how many of these publishers are participating in the interaction.
  • Time decoupling: The interacting parties do not need to be actively participating in the interaction at the same time. In particular, the publisher might publish some events while the subscriber is disconnected, and conversely, the subscriber might get notified about the occurrence of some event while the original publisher of the event is disconnected.
  • Synchronization decoupling: Publishers are not blocked while producing events, and subscribers can get asynchronously notified (through a callback) of the occurrence of an event while performing some concurrent activity. The production and consumption of events do not happen in the main flow of control of the publishers and subscribers, and do not therefore happen in a synchronous manner.

It appears that the ROS middleware does not implement these aspects on all levels, as you mentioned. At the application level (where you interact with the ROS C++/Python/X API), nodes do not care about the names of other nodes, only about topics. There we have space decoupling.

But the data will have to get to subscribers in some way. ros_comm uses TCP for that (in the case where TCPROS is used) and for efficiency reasons does that by direct connections between nodes (otherwise data would have to be copied from publisher to intermediate entity, then to each subscriber). So at the message transport level in ROS, there is no space decoupling (with the default TCPROS).

ROS does not currently seem to support time decoupling, as subscribers and publishers need to be running for messages to be exchanged. This seems a consequence of the direct TCP connections between nodes: if one of the endpoints of those connections isn't "up", messages will ...

(more)
edit flag offensive delete link more

Comments

Fabulous answer, much appreciated, @gvdhoorn!

Anton Belev gravatar imageAnton Belev ( 2015-02-14 12:27:49 -0500 )edit

The only question that arise in your answer is - since nodes are establishing TCP/IP Connection to each other to improve efficiency, this implies that a given subscriber has to open n TCP/IP connections in order to get messages from n publishers. Then the Space decoupling is also questionable.

Anton Belev gravatar imageAnton Belev ( 2015-02-14 12:34:28 -0500 )edit

Well yes, it implies that you need n connections if you have n subscriptions to different publishers. But as I wrote: you need to get the data across somehow.

gvdhoorn gravatar imagegvdhoorn ( 2015-02-15 01:53:45 -0500 )edit

There have been experiments with other message transports (ROS terminology), such as UDP multicast and shared memory (see ethzasl_message_transport fi), and although these don't use n connections, they have their own drawbacks (routability, etc).

gvdhoorn gravatar imagegvdhoorn ( 2015-02-15 01:57:01 -0500 )edit

@gvdhoorn If they need to make direct connection, it means that they will know about each other info/reference, so it is not space decoupling? Also, when making/opening connections, the publisher will know how many subscribers by the number of connections. Please explain , thanks

alienmon gravatar imagealienmon ( 2016-08-09 20:31:32 -0500 )edit

@gvdhoorn you wrote "Space decoupling: The interacting parties do not need to know each other", but if they make connection then they know each other. I'm new to ROS, so I'm a bit confused here. pls explain :)

alienmon gravatar imagealienmon ( 2016-08-09 20:35:54 -0500 )edit

I believed I had explained that in my answer (did you click (more)?) but: yes, at some level, there is some space coupling in ROS, as the TCP/IP connections will need to be established somehow. At the abstraction level where it matters though (user code), there is none.

gvdhoorn gravatar imagegvdhoorn ( 2016-08-10 00:55:13 -0500 )edit

And: the Eugster et al. article (that I only quoted from) is not specific to ROS, and the dimensions of decoupling proposed in it work for all (?) middlewares making use of the considered interaction styles. So you'll find (some of) the same 'problems' in OROCOS, YARP, etc. Also in DDS and OPC-UA.

gvdhoorn gravatar imagegvdhoorn ( 2016-08-10 00:58:04 -0500 )edit

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

Stats

Asked: 2015-02-14 10:21:04 -0500

Seen: 780 times

Last updated: Feb 15 '15