Understanding the basic working of ROS and its terminology can help you understand existing ROS applications and build your own. This section will teach you important concepts that we are going to use in the upcoming chapters. If you find that a topic is missing in this chapter, then rest assured that it will be covered in a corresponding chapter later.

There are three different concepts in ROS. Let's take a look at them.

The filesystem level explains how ROS files are organized on the hard disk:

As you can see from the preceding diagram, the filesystem in ROS can be categorized mainly as metapackages, packages, package manifest, messages, services, codes, and miscellaneous files. The following is a short description of each component:

• Metapackages: Metapackages group a list of packages for a specific application. For example, in ROS, there is a metapackage called navigation for mobile robot navigation. It can hold the information of related packages and helps install those packages during its own installation.
• Packages: The software in ROS is mainly organized as ROS packages. We can say that ROS packages are the atomic build units of ROS. A package may consist of ROS nodes/processes, datasets, and configuration files, all organized in a single module.
• Package manifest: Inside every package will be a manifest file called package.xml. This file consists of information such as the name, version, author, license, and dependencies that are required of the package. The package.xml file of a metapackage consists of the names of related packages.

• Messages (msg): ROS communicates by sending ROS messages. The type of message data can be defined inside a file with the .msg extension. These files are called message files. Here, we are going to follow a convention where we put the message files under our_package/msg/message_files.msg.
• Service (srv): One of the computation graph level concepts is services. Similar to ROS messages, the convention is to put service definitions under our_package/srv/service_files.srv.

This sums up the ROS filesystem.

The ROS computation graph is a peer-to-peer based network that processes all the information together. The ROS graph concept constitutes nodes, topics, messages, master, parameter server, services, and bags:

The preceding diagram shows the various concepts in the ROS computational graph. Here is a short description of each concept:

• Nodes: ROS nodes are simply processes that use ROS APIs to communicate with each other. A robot may have many nodes to perform its computations. For example, an autonomous mobile robot may have a node each for hardware interfacing, reading laser scan, and localization and mapping. We can create ROS nodes using ROS client libraries such as roscpp and rospy, which we will be discussing in the upcoming sections.
• Master: The ROS master works as an intermediate node that aids connections between different ROS nodes. The master has all of the details about all the nodes running in the ROS environment. It will exchange details of one node with another to establish a connection between them. After exchanging this information, communication will start between the two ROS nodes.
• Parameter server: The parameter server is a pretty useful thing in ROS. A node can store a variable in the parameter server and set its privacy, too. If the parameter has a global scope, it can be accessed by all other nodes. The ROS parameter runs along with the ROS master.
• Messages: ROS nodes can communicate with each other in many ways. In all the methods, nodes send and receive data in the form of ROS messages. The ROS message is a data structure that's used by ROS nodes to exchange data.
• Topics: One of the methods to communicate and exchange ROS messages between two ROS nodes is called ROS topics. Topics are named buses in which data is exchanged using ROS messages. Each topic will have a specific name, and one node will publish data to a topic and another node can read from the topic by subscribing to it.
• Services: Services are another kind of communication method, similar to topics. Topics use publish or subscribe interaction, but in services, a request or reply method is used. One node will act as the service provider, which has a service routine running, and a client node requests a service from the server. The server will execute the service routine and send the result to the client. The client node should wait until the server responds with the results.
• Bags: Bags are a useful utility in ROS for the recording and playback of ROS topics. While working on robots, there may be some situations where we need to work without actual hardware. Using rosbag, we can record sensor data and copy the bag file to other computers to inspect data by playing it back.

This sums up the computational graph concept.

The ROS community has grown more now compared to the time it was introduced. You can find at least 2,000+ packages being supported, altered, and used by the community actively. The community level comprises the ROS resources for sharing software and knowledge:

Here is a brief description of each section:

• Distributions: ROS distributions are versioned collections of ROS packages, such as Linux distributions.
• Repositories: ROS-related packages and files depend on a Version Control System (VCS) such as Git, SVN, and Mercurial, using which developers around the world can contribute to the packages.
• ROS Wiki: The ROS community wiki is the knowledge center of ROS, in which anyone can create documentation of their packages. You can find standard documentation and tutorials about ROS on the ROS wiki.
• Mailing lists: Subscribing to ROS mailing lists enables users to get new updates regarding ROS packages and gives them a place to ask questions about ROS (http://wiki.ros.org/Mailing%20Lists?action=show).
• ROS Answers: The ROS Answers website is the stack overflow of ROS. Users can ask questions regarding ROS and related areas (http://answers.ros.org/questions/).
• Blog: The ROS blog provides regular updates about the ROS community with photos and videos (http://www.ros.org/news).

Now, let's learn how communication is carried out in ROS in the next section.

Let's learn how two nodes communicate with each other using ROS topics. The following diagram shows how this happens:

As you can see, there are two nodes named talker and listener. The talker node publishes a string message called Hello World into a topic called /talker, while the listener node is subscribed to this topic. Let's see what happens at each stage, marked (1), (2), and (3) in the preceding diagram:

1. Before running any nodes in ROS, we should start the ROS Master. After it has been started, it will wait for nodes. When the talker node (publisher) starts running, it will connect to the ROS Master and exchange the publishing topic details with the master. This includes the topic name, message type, and publishing node URI. The URI of the master is a global value, and all the nodes can connect to it. The master maintains the tables of the publisher connected to it. Whenever a publisher's details change, the table updates automatically.

2. When we start the listener node (subscriber), it will connect to the master and exchange the details of the node, such as the topic going to be subscribed to, its message type, and the node URI. The master also maintains a table of subscribers, similar to the publisher.
3. Whenever there is a subscriber and publisher for the same topic, the master node will exchange the publisher URI with the subscriber. This will help both nodes to connect and exchange data. After they've connected, there is no role for the master. The data is not flowing through the master; instead, the nodes are interconnected and exchange messages.

More information on nodes, their namespaces, and usage can be found here: http://wiki.ros.org/Nodes.

Now that we know the fundamentals of ROS, let's look at a few ROS client libraries.