Revision history [back]

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 --

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.