Understanding the ROS filesystem level

ROS is more than a development framework. We can refer to ROS as a meta-OS, since it offers not only tools and libraries but even OS-like functions, such as hardware abstraction, package management, and a developer toolchain. Like a real operating system, ROS files are organized on the hard disk in a particular manner, as depicted in the following diagram:

Figure 1.1 – ROS filesystem level

Here are the explanations for each block in the filesystem:

• Packages: The ROS packages are a central element of the ROS software. They contain one or more ROS programs (nodes), libraries, configuration files, and so on, which are organized together as a single unit. Packages are the atomic build and release items in the ROS software.
• Package manifest: The package manifest file is inside a package and contains information about the package, author, license, dependencies, compilation flags, and so on. The package.xml file inside the ROS package is the manifest file of that package.
• Metapackages: The term metapackage refers to one or more related packages that can be loosely grouped. In principle, metapackages are virtual packages that don't contain any source code or typical files usually found in packages.
• Metapackages manifest: The metapackage manifest is similar to the package manifest, with the difference being that it might include packages inside it as runtime dependencies and declare an export tag.
• Messages (.msg): We can define a custom message inside the msg folder inside a package (my_package/msg/MyMessageType.msg). The extension of the message file is .msg.
• Services (.srv): The reply and request data types can be defined inside the srv folder inside the package (my_package/srv/MyServiceType.srv).
• Repositories: Most of the ROS packages are maintained using a Version Control System (VCS) such as Git, Subversion (SVN), or Mercurial (hg). A set of files placed on a VCS represents a repository.

The following screenshot gives you an idea of the files and folders of a package that we are going to create in the upcoming sections:

Figure 1.2 – List of files inside the exercise package

The goal of all the files and directories included in a ROS package will be discussed next.

ROS packages

The typical structure of a ROS package is shown here:

Figure 1.3 – Structure of a typical C++ ROS package

Let's discuss the use of each folder:

• config: All configuration files that are used in this ROS package are kept in this folder. This folder is created by the user and it is a common practice to name the folder config as this is where we keep the configuration files.
• include/package_name: This folder consists of headers and libraries that we need to use inside the package.
• script: This folder contains executable Python scripts. In the block diagram, we can see two example scripts.
• src: This folder stores the C++ source codes.
• launch: This folder contains the launch files that are used to launch one or more ROS nodes.
• msg: This folder contains custom message definitions.
• srv: This folder contains the services definitions.
• action: This folder contains the action files. We will learn more about these kinds of files in the next chapter.
• package.xml: This is the package manifest file of this package.
• CMakeLists.txt: This file contains the directives to compile the package.

We need to know some commands for creating, modifying, and working with ROS packages. Here are some of the commands we can use to work with ROS packages:

• catkin_create_pkg: This command is used to create a new package.
• rospack: This command is used to get information about the package in the filesystem.
• catkin_make: This command is used to build the packages in the workspace.
• rosdep: This command will install the system dependencies required for this package.

To work with packages, ROS provides a bash-like command called rosbash (http://wiki.ros.org/rosbash), which can be used to navigate and manipulate the ROS package. Here are some of the rosbash commands:

• roscd: This command is used to change the current directory using a package name, stack name, or a special location. If we give the argument a package name, it will switch to that package folder.
• roscp: This command is used to copy a file from a package.
• rosed: This command is used to edit a file using the vim editor.
• rosrun: This command is used to run an executable inside a package.

The definition of package.xml in a typical package is shown in the following screenshot:


Figure 1.4 – Structure of package.xml

The package.xml file also contains information about the compilation. The <build_depend></build_depend> tag includes the packages that are necessary for building the source code of the package. The packages inside the <run_depend></run_depend> tags are necessary for running the package node at runtime.

ROS metapackages

Metapackages are specialized packages that require only one file; that is, a package.xml file.

Metapackages simply group a set of multiple packages as a single logical package. In the package.xml file, the metapackage contains an export tag, as shown here:

  <export> 
    <metapackage/> 
  </export>  

Also, in metapackages, there are no <buildtool_depend> dependencies for catkin; there are only <run_depend> dependencies, which are the packages that are grouped inside the metapackage.

The ROS navigation stack is a good example of somewhere that contains metapackages. If ROS and its navigation package are installed, we can try using the following command by switching to the navigation metapackage folder:

roscd navigation  

Open package.xml using your favorite text editor (gedit, in the following case):

gedit package.xml  

This is a lengthy file; here is a stripped-down version of it:

Figure 1.5 – Structure of the package.xml metapackage

This file contains several pieces of information about the package, such as a brief description, its dependencies, and the package version.

ROS messages

ROS nodes can write or read data of various types. These different types of data are described using a simplified message description language, also called ROS messages. These data type descriptions can be used to generate source code for the appropriate message type in different target languages.

Even though the ROS framework provides a large set of robotic-specific messages that have already been implemented, developers can define their own message type inside their nodes.

The message definition can consist of two types: fields and constants. The field is split into field types and field names. The field type is the data type of the transmitting message, while the field name is the name of it.

Here is an example of message definitions:

int32 number 
string name 
float32 speed 

Here, the first part is the field type and the second is the field name. The field type is the data type, and the field name can be used to access the value from the message. For example, we can use msg.number to access the value of the number from the message.

Here is a table showing some of the built-in field types that we can use in our message:

ROS provides a set of complex and more structured message files that are designed to cover a specific application's necessity, such as exchanging common geometrical (geometry_msgs) or sensor (sensor_msgs) information. These messages are composed of different primitive types. A special type of ROS message is called a message header. This header can carry information, such as time, frame of reference or frame_id, and sequence number. Using the header, we will get numbered messages and more clarity about which component is sending the current message. The header information is mainly used to send data such as robot joint transforms. Here is the definition of the header:

uint32 seq 
time stamp 
string frame_id 

The rosmsg command tool can be used to inspect the message header and the field types. The following command helps view the message header of a particular message:

rosmsg show std_msgs/Header  

This will give you an output like the preceding example's message header. We will look at the rosmsg command and how to work with custom message definitions later in this chapter.

The ROS services

The ROS services are a type of request/response communication between ROS nodes. One node will send a request and wait until it gets a response from the other.

Similar to the message definitions when using the .msg file, we must define the service definition in another file called .srv, which must be kept inside the srv subdirectory of the package.

An example service description format is as follows:

#Request message type 
string req
--- 
#Response message type 
string res

The first section is the message type of the request, which is separated by ---, while the next section contains the message type of the response. In these examples, both Request and Response are strings.

In the upcoming sections, we will look at how to work with ROS services.