0
$\begingroup$

Rosanswers logo

Hi,

I have gone through almost all of ROS-1 wiki pages. And so, I am aware that in ROS-1 (I am yet to look into ROS-2), before 2 nodes start to communicate via pub-sub feature, both needs to register themselves with the Master. After which, both can then negotiate and establish one-to-one communication using, say TCPROS.

But a question that has been doing rounds in my mind is that "Why is there a Master? What is the need of Master? Why the things couldn't have been done without a Master?

Let's say I am going to work with 4 robots. So, I am aware about each others' IP addresses. Therefore, I can design things such that the 4 robots (NODES) can establish one-to-one communication with each other whenever they want. So, why should a Master come in between ? Why is it that, to establish a connection among the 4 robots via topics, these robots need to first register themselves with the master, and then go for one-to-one negotiating and establishing TCPROS connection ? Is the concept of Master really helpful in such cases where say, we have only 4 robots to deal with, and we know the IP addresses of all of them ?


Originally posted by Aakashp on ROS Answers with karma: 41 on 2020-12-23

Post score: 2


Original comments

Comment by gvdhoorn on 2020-12-23:
You're question is somewhat a duplicate of #q218783.

Comment by Aakashp on 2020-12-24:
I feel this question is a bit different than the tagged question #q218783 in the sense that I am aware that Master provides a nameservice (a lookup feature about the nodes in the ROS graph), but my question is about its necessity and why can't we have a ROS application without a Master.

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

But a question that has been doing rounds in my mind is that "Why is there a Master? What is the need of Master? Why can't things could have been done without a Master?

As the wiki/Master page explains, the Master provides name based lookup services. It functions like a switchboard operator or DNS system.

Its main function is to provide a mapping between names of nodes, topics, services and actions (also topics) and their IPs and TCP or UDP ports.

Let's say I am going to work with 4 robots. So, I am aware about each others' IP addresses.

This is a strong assumption: only if you've configured all robots yourself with a known IP -- and that IP address never changes will this work.

Therefore, I can design things such that the 4 robots (NODES) can establish one-to-one communication with each other whenever they want.

Of course. In this situation everything needed to directly communicate is known. Or at least, you imply everything is known in the nodes which need it. Note: just an IP address would not be sufficient. You'd also need TCP and/or UDP port numbers. But I assume that is what you meant to write.

So, why should a Master come in between ?

In this case? There would be no need for a Master.

Why is it that, to establish a connection among the 4 robots via topics, these robots need to first register themselves with the master, and then go for one-to-one negotiating and establishing TCPROS connection ? Is the concept of Master really helpful in such cases where say, we have only 4 robots to deal with, and we know the IP addresses of all of them ?

If you keep within the confines of the hypothetical situation you sketch, there would be no need for a Master: nodes could open sockets between each of them and use those to exchange data. Provided of course that you'd also know on which ports certain types of information is provided and services are offered.

Now if we leave your hypothetical situation, and:

  • accept that in most cases, IPs do change
  • IPs are not always known for all robots (fi on networks with DHCP or on cellular networks)
  • some applications have robots leaving and joining the ROS network while the application is running
  • we'd like to be able to start nodes on whichever robot without having to update the code of all the others
  • we'd like to be able to publish and subscribe to multiple topics, offer and use multiple services and offer and use multiple actions per node and robot
  • we'd like to use multiple PCs (or multiple NICs) per robot, and would not want to have to manually keep track of where (ie: on which PC) nodes are run (or via which NIC they connect to a network)
  • we may want to be able to start multiple instances of the same node (under different names of course)

and so on, the need for (or utility of) a Master should become clear.

It essentially functions as a central source of information about the running ROS application. And this information is updated during the runtime of the application as well (so is not static, as in your hypothetical setup).

So if a node creates a subscriber which wants to receive messages of type JointState on a topic called joint_states, it will somehow have to figure out where publishers are which publish JointState messages on the topic called joint_states. That is the kind of information the Master possesses (and is willing to share with nodes, if they ask nicely).

I am yet to look into ROS-2

One of the main differences between ROS 1 and ROS 2 is the absence of a Master(-like) entity in ROS 2 (see also #q287470).

So is a Master absolutely necessary? No. Not at all. See ROS 2. Is it needed in ROS 1: yes, as that's how ROS 1 has been designed and implemented.


Originally posted by gvdhoorn with karma: 86574 on 2020-12-23

This answer was ACCEPTED on the original site

Post score: 3


Original comments

Comment by gvdhoorn on 2020-12-23:
Related Q&A would be #q203129, which discusses how decoupled nodes really are in ROS.

Something else related to this subject: multimaster systems. An example packages would be multimaster_fkie.

Comment by gvdhoorn on 2020-12-23:
Could you please mark the question as answered by clicking the checkmark to the left of the answer if you feel it has been answered? It should turn green.

Comment by Aakashp on 2020-12-24:
@gvdhoorn: Thanks for your reply. However, I request you to clarify the below points:

So if a node creates a subscriber which wants to receive messages of type JointState on a topic called joint_states, it will somehow have to figure out where publishers are which publish JointState messages on the topic called joint_states. That is the kind of information the Master possesses (and is willing to share with nodes, if they ask nicely).

This kind of information, i.e. who is publishing what, and who is subscribing to what, can be maintained by the designer of the system (i.e. ROS application) as he/she would be aware that how many nodes / robots would be there. Let's say, the designer knows that at max 100 nodes would be there. And so, he can maintain the information that which node would be publishing what on which topic (same for subscribers). Please correct my understanding if I am missing something.

Comment by Aakashp on 2020-12-24:
Now, as ROS-2 does away with Master, could you please share a link to some information as to how ROS-2 manages without a Master ? @gvdhoorn

Comment by Aakashp on 2020-12-24:
@gvdhoorn: If we can have one-to-one communication between 2 nodes, then can we not have the below (taken from your response) without a Master ? :--

we'd like to be able to publish and subscribe to multiple topics, offer and use multiple services and offer and use multiple actions per node and robot

And how does Master help in this ? :--

we'd like to be able to start nodes on whichever robot without having to update the code of all the others

Comment by Aakashp on 2020-12-24:
@gvdhoorn: As you replied :

So is a Master absolutely necessary? No. Not at all. See ROS 2. Is it needed in ROS 1: yes, as that's how ROS 1 has been designed and implemented.

My question is that why Master is needed in ROS 1 ? Should I conclude that though the design of ROS 1 has provision for a Master, still we can have a ROS-1 application without any Master in it, as for the example where we just have 4 robots ?

Comment by gvdhoorn on 2020-12-24:
I think I can answer all your questions with a single comment: we have a Master as we don't want to maintain all that information ourselves, and we want to be able to create applications which change at runtime.

How would your designer put information in your system about nodes being created in response to certain events? How would your designer deal with changing IP addresses? How would your designer deal with there suddenly being 5 robots? Or 3?

Would you want to shutdown the complete system, change the code, and then start it again?

The reason the master exists is because it offers the advantage of being able to deal with all of the above, while still also being able to cater to situations where nothing changes during runtime.

Why would I manually keep track of on which IP address+TCP port a particular service server can be found, if I can have a machine do that for me? Do you open https://172.217.17.110:443 when browsing to Google, or https://google.com?

Comment by gvdhoorn on 2020-12-24:
And no, a Master is not strictly needed, but it's a design decision to include one. Just as it was a design decision to setup the Domain Name System. If the internet never changed, we could just hand out printed A4 papers with IP addresses to everyone who wants to browse the internet, and they'd lookup everything using those lists.

But the internet does change, so such printouts would go stale almost immediately.

ROS applications can be like that (and on the level of individual topics, services and actions they are like that, ie: often changing). So to cope with that you add a system which automatically tracks all those changes.

As to ROS 2: it was a design decision to work without a Master and make everything peer-to-peer, even discovery.

But such a design comes with its own set of trade-offs, see New Discovery Server for an interesting thread about that.

Comment by gvdhoorn on 2020-12-24:
Finally: no, you cannot really run a ROS 1 application without a Master.

I write "not really", as this is software, and anything is possible. But it'll be so much work that it won't be worth it. And it'll also be very brittle, as the system you describe would not be able to deal with any runtime changes at all.

Comment by Aakashp on 2020-12-24:
@gvdhoorn: Thank you very much for your detailed response to each and every query of mine. The answer is clear to me now.

$\endgroup$

Your Answer

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