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

Why cannot we communicate with nodes and receive a reply using topics?

asked 2017-02-25 11:01:23 -0500

SarSam gravatar image

updated 2017-02-25 11:01:45 -0500

I'm reading "Learning ROS for Robotic Programming" by Aaron Martinez and Enrique Fernandez.
In Chapter#2, Pg#36, under the heading 'Services', it is written that:

"When you need to communicate with nodes and receive a reply, you cannot do it with topics; you need to do it with services"

Why is this not possible? Is this not possible that Node1 publishes a topic that Node2 subscribes and then Node2 publishes a topic that Node1 subscribes?

(Please reply from a beginners' perspective)

edit retag flag offensive close merge delete

Comments

Why not just use a service? This is exactly what services do.

jayess gravatar image jayess  ( 2017-03-26 02:24:57 -0500 )edit

@jayess I can use but that's not the question. I am asking the explanation of that statement.

SarSam gravatar image SarSam  ( 2017-03-27 07:53:31 -0500 )edit

4 Answers

Sort by » oldest newest most voted
3

answered 2017-03-31 00:35:39 -0500

jayess gravatar image

Like the others have said, you can use topics to send information from Node1 to Node2 and then reply along that topic from Node2 back to Node1 But, topics are many-to-many communication channels so there could be many different nodes publishing along that topic and sending replies along that topic as well. Also, topics only carry one data type (message) along them so that means that the message would have to include the communication and response both ways.

For example, let's say that you want to send a message saying "hi" from Node1 to Node2, then a response saying "hello" from Node2 back to Node1. If there's only Node1 and Node2, this isn't such a big deal because it's only a string and that same message type can be used to communicate back and forth. This simple message can have a simple definition:

string greeting

Now, if there's also Node3, Node4, Node5, ...,NodeN then you're going to have issues because they're all using the same topic to greet each other. How is each node supposed to know where the greeting came from and what its destination is? You're going to have to increase the complexity of the message:

string source
string destination
string greeting

This is already problematic because you're potentially tripling the bandwidth of your topic and adding the burden of filtering the messages to make sure that the nodes don't get unwanted greetings. Not to mention that this topic is kept open even if nothing is being sent.

This example is trivial, but imagine that you have several robots running at the same time and you need to send a command telling only one of the robots where to go. This will require you to send the command and also include some sort of identifier.

PoseStamped destination
string name
bool acknowledgement

Again, you have the problem with needing to keep the channel open and having to send the same message back and forth (request and response). What if you're send images? Images consume a large amount of bandwidth (even compressed) and now you're going to have to send an image back and forth. If you were using a service this would be much easier. The service is always available, but not necessarily consuming the band width plus there's an entire request/response cycle. A service client sends a request (take a picture, go over there, etc.) and the server sends a response (acknowledgement, a picture, etc). The entire message isn't sent, first the request, then the response such as

Image image
---
bool acknowledgement

The top portion, Image image, is the request and the bottom portion, bool acknowledgement, is the response. (This is a custom srv by the way.)

So, you can use nodes to send information along with responses, but it can be done better depending on your situation and what you're trying to accomplish. Also, as @NEngelhard mentioned, there's also actions ... (more)

edit flag offensive delete link more

Comments

Thank you for the explanation

SarSam gravatar image SarSam  ( 2017-03-31 15:49:29 -0500 )edit

No problem, glad to help.

jayess gravatar image jayess  ( 2017-03-31 16:05:40 -0500 )edit
1

answered 2017-02-25 11:34:50 -0500

NEngelhard gravatar image

updated 2017-02-25 11:35:03 -0500

You are right that it is perfectly possible to do this with topics. The best argument for this is that the actionlib completely relies on topics for communication. For every action, a set of topics (e.g. for goal, feedback and result) are created and handled internally so that the user can concentrate on the fun part and does not have to care about the internals.

The book does only talk about actions in the move_base example on p. 269ff, ('action' is not even listed in the index!) which is imho a red flag for a book about ROS. So you are right and the part you quoted is simply wrong.

edit flag offensive delete link more

Comments

Took too long to post my answer.

I think the quote isn't necessarily wrong, it's a bit too vague and relies on previous knowledge on the part of the reader to be understood correctly. There is definitely a difference between pub-sub and services, and I think that is what the quote refers to.

gvdhoorn gravatar image gvdhoorn  ( 2017-02-25 12:02:52 -0500 )edit

@NEngelhard Thank you!

SarSam gravatar image SarSam  ( 2017-03-31 15:50:24 -0500 )edit
1

answered 2017-02-25 12:00:25 -0500

gvdhoorn gravatar image

tl;dr: yes, that would certainly be possible.


The long version basically still remains "yes, that is definitely possible", but also has to do with semantics (publish-subscribe is a very different sort of communication pattern from request-reply).

If you're interested, I could expand a little, but for now see #q203129 for some background.

edit flag offensive delete link more

Comments

Yes please whenever you could do. Please also expand on why "it isn't necessarily wrong".

SarSam gravatar image SarSam  ( 2017-02-25 13:01:42 -0500 )edit

Just in case you forgot, I'm still waiting for you to expand on that!

SarSam gravatar image SarSam  ( 2017-03-29 08:02:03 -0500 )edit
3

answered 2017-03-31 01:37:57 -0500

This is because of how Ros is developed to work... Ros communication is intended to offer a decoupled communication

image description

this means node 1 can publish info about topic X and node2 can subscribe to topic x

if node2 doenst exist in the graph, then there is no problem, node 1 can still live and publish topicX, this means node1 is just publishing for fun since noone will hear his info...

if node1 doenst exist in the graph, then there is no problem, node 2 can still live and subcribe to topicX, this means node 2 is ther waiting for a node that gives it information it needs....

on the other hand, IF YOU NEED TO TALK TO A NODE AND GET FEEDBACK from it, then you need to implement a service,

something similiar to RPC(remote procedure calls) see image below:

image description

edit flag offensive delete link more

Comments

Thank you for the explanation

SarSam gravatar image SarSam  ( 2017-03-31 15:49:20 -0500 )edit

Question Tools

2 followers

Stats

Asked: 2017-02-25 11:01:23 -0500

Seen: 2,804 times

Last updated: Mar 31 '17