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 a topic missed in this chapter, it will be covered in a corresponding later chapter.
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:
Figure 6: The ROS filesystem level
As you can see from the figure, 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 together 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 on 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 unit of ROS. A package may consist of ROS nodes/processes, datasets, and configuration files, 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 required of the package. Thepackage.xmlfile 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
.msgextension. These files are called message files. We are following a convention that the message files are kept underour_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.
The ROS computation graph is the peer-to-peer network of the ROS process, and it processes the data together. The ROS computation graph concepts are nodes, topics, messages, master, parameter server, services, and bags:
Figure 7: The ROS computational graph concept diagram
The preceding figure shows the various concepts in the ROS computational graph. Here is a short description of each concept:
Nodes: ROS nodes are simply a process that is using 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 scans, and localization and mapping. We can create ROS nodes using ROS client libraries such as
roscppandrospy, 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 the details about all nodes running in the ROS environment. It will exchange details of one node with another in order to establish a connection between them. After exchanging the 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 methods, nodes send and receive data in the form of ROS messages. The ROS message is a data structure 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 an other node can read from the topic by subscribing to it.
Services: Services are another kind of communication method, like 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 can copy the bag file to other computers to inspect data by playing it back.
The community level comprises the ROS resources for sharing software and knowledge:
Figure 8: ROS community level diagram
Here is a brief description of each section:
Distributions: ROS distributions are versioned collections of ROS packages, like Linux distribution.
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.
The ROS Wiki: The ROS community wiki is the knowledge center of ROS, in which anyone can create documentation for their packages. You can find standard documentation and tutorials about ROS from the ROS wiki.
Mailing lists: Subscribing to the 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).
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).
Let's see how two nodes communicate with each other using ROS topics. The following diagram shows how it happens:
Figure 9: Communication between ROS nodes using topics
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, and the listener node is subscribed to this topic. Let's see what happens at each stage, marked (1), (2), and (3):
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 first connect to the ROS Master and exchange the publishing topic details with the master. This includes topic name, message type, and publishing node URI. The URI of the master is a global value, and all nodes can connect to it. The master maintains tables of the publisher connected to it. Whenever a publisher's details change, the table updates automatically.
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.
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 connect with each other and exchange data. After they've connected with each other, there is no role for the master. The data is not flowing through the master; instead, the nodes are interconnected and exchange messages.