In the previous section, we learned about important elements in the ROS computational network to start with. Following that, in this section, we will warm up using these elements. Let's get started with practicing with the ROS master.

ROS master works much like a DNS server. Whenever any node starts in the ROS system, it will start looking for ROS master and register the name of the node with ROS master. Therefore, ROS master has information about all the nodes that are currently running on the ROS system. When information about any node changes, it will generate a call back and update with the latest information.

The node will provide the details of the topic, such as its name and data type, to ROS master before the node starts publishing that topic. ROS master will check whether any other nodes are subscribed to the same topic. If any nodes are subscribed to the same topic, ROS master will share the node details of the publisher to the subscriber node. After receiving the node details, these two nodes will interconnect using the TCPROS protocol, which is based on TCP/IP sockets, and ROS master will relinquish its role in controlling them. In the future, we might stop either the publisher node or the subscriber node, according to our requirements. Whenever the state of a node changes, it will check with ROS master once again. The ROS service also uses the same method. The nodes are written using the ROS client libraries such as roscpp and rospy. These clients interact with ROS master using XML Remote Procedure Call (XMLRPC) based APIs, which act as the backend of the ROS system APIs.

However, in a distributed network, in which different physical computers participate in a ROS computational network, ROS_MASTER_URI should be defined properly. Thereupon, the remote nodes can find each other and communicate with each other. A ROS system must have only one master, even in a distributed system, and it should run on a computer that is reachable by all other computers to ensure that remote ROS nodes can access the master.

The following diagram shows an illustration of how ROS master interacts with a publishing and subscribing node:

Now, let's look at practicing with ROS nodes.

ROS nodes are processes that perform computation using ROS client libraries such as roscpp and rospy. One node can communicate with other nodes using ROS topics and services and a parameters server.

Moreover, using nodes in ROS provides fault tolerance and separates the code and functionalities, making the system simpler and robust. A robotic application might contain several nodes, where one node processes camera images, the next one handles serial data from the robot, another one can be used to compute odometry, and so on. Also, nodes reduce complexity and increase debugability compared to monolithic codes.

There is a rosbash tool for introspecting ROS nodes. The rosnode tool is a command-line tool used to display information about nodes, such as listing the currently running nodes.

In upcoming sections, we will discuss the working of ROS nodes that use functionalities such as ROS topics, services, and messages.

Let's look at practicing with ROS topics.

ROS topics are named buses through which ROS nodes exchange messages that can anonymously publish and subscribe, which means that the production of messages is decoupled from the consumption. In fact, the ROS nodes are not interested in knowing which node is publishing the topic or subscribing to topics, they only look for the topic name and whether the message types of the publisher and subscriber match.

A topic can have various subscribers and can also have various publishers, but we should be careful when publishing the same topic with different nodes as it can create conflicts. However, each topic is strongly typed by the ROS message type used to publish it, and nodes can only receive messages from a matching type. A node can subscribe to a topic only if it has the same message type.

The ROS nodes communicate with topics using TCP/IP-based transport known as TCPROS. This method is the default transport method used in ROS. Another type of communication is UDPROS, which has low-latency, loose transport, and is only suited for teleoperation.

ROS has a tool to work with topics called rostopic. It is a command-line tool that gives us information about the topic or publishes data directly on the ROS computational network.

We will learn how to use this command-line tool in upcoming sections.

For practicing with ROS messages, see the following:

• ROS nodes communicate with each other by publishing messages to a topic. As discussed earlier, messages are simple data structures that use standard types or custom types developed by the user.
• Message types use the following standard ROS naming convention: the name of the package, then / and then the name of the .msg file. For example, std_msgs/ msg/String.msg has the std_msgs/String message type. In addition to message data type, ROS uses an MD5 checksum comparison to confirm whether the publisher and subscriber exchange the same message data types.

• ROS has inbuilt tools called rosmsg for getting information about ROS messages.

Let's see practicing with ROS services:

• When we need a request-response kind of communication in ROS, we have to use  ROS services. ROS topics can't do this kind of communication because it is unidirectional. ROS services are mainly used in a distributed system.
• The ROS service is defined using a pair of messages, a request datatype, and a response datatype in a srv file. The srv files are kept in an srv folder inside a package.
• In ROS services, one server node acts as a ROS server, in which the client nodes can request for a specific service. If the server completes the service request, it will send the results to the client.
• Similar to topics, services have an associated service type that is the package resource name of the .srv file. As with other ROS filesystem-based types, the service type is the package name and the name of the .srv file. For example, the chapter2_tutorials/srv/chapter2_srv.srv file has the chapter2_tutorials/chapter2_srv service type. In ROS services also, there is an MD5 checksum that checks in the nodes. If the sum is equal, then only the server responds to the client.
• ROS has two command-line tools to work with services, rossrv and rosservice. The first tool is rossrv, which is similar to rosmsg, and is used to get information about service types. The next command is rosservice, which is used to list and query the running ROS services.

Now, let's move on to the next one, practicing with the ROS parameter server:

• The parameter server is a shared, multivariable dictionary that is accessible through the ROS computational network. Nodes use this server to store and retrieve parameters at runtime.
• A parameter server is implemented using XMLRPC and runs inside the ROS master, which means that its API is accessible through normal XMLRPC libraries. XMLRPC is an RPC protocol that uses XML to encode its calls and HTTP as a transport mechanism.

The parameter server supports the following XMLRPC datatypes:

• 32-bit integers
• Booleans
• Strings
• Doubles
• ISO 8601 dates
• Lists
• Base64-encoded binary data

ROS has the rosparam tool for working with parameter servers. The parameters can be changed dynamically during the execution of the node that uses these parameters by using the dyamic_reconfigure package. We will discuss this further in an upcoming section.

Let's practice with ROS bags:

• A bag is a file created by ROS with the .bag format to save all of the information of the messages, topics, services, and others. We can use this data later to visualize what has happened; we can play, stop, rewind, and perform other operations with it.
• Bag files are created using the rosbag command. The main application of rosbag is data logging. The logged ROS computational data can be visualized and processed offline.