上QQ阅读APP看书，第一时间看更新

There's more…

In this section, we will provide more insight into ROS filesystem terminology, which includes the ROS workspace, package and metapackage, messages, and services. An experienced reader could jump to the next section, but it is recommended to run through this for a complete overview:

The ROS workspace: Practically, the workspace is a folder that contains packages, which contain source files and configuration information. Moreover, the workspace provides the mechanism for centralizing all of the development.

A typical workspace is shown in the following screenshot:

An explanation of the preceding workspace follows:

src: The source space src, contains packages, projects, clone packages, and so on. One of the most important files in this space is CMakeLists.txt, which is invoked by cmake when packages are configured in the workspace. Moreover, this file is created with the catkin_init_workspace command during workspace initialization.
build: In the build space, build, cmake, and catkin make tools keep the cache information, configuration, and other intermediate files for intended packages and projects.
devel: The development space, devel, is used to keep the compiled packages, which can be tested without the installation step.

Another interesting feature of the ROS workspace is its overlays feature. When we are working with any package of ROS, for example, turtlesim, we could have a precompiled installed version, or we could download the source file and compile it to use as a development version.

ROS permits us to use the development version of any package instead of the installed version. This is a very useful feature when we are working on an upgrade of an installed package. We might not understand the overlay utility at this moment, but, in the following chapters, we will use this feature to create our own plugins.

Usually, when we talk about packages, we refer to a typical structure of files and folders in the ROS system. This structure looks as follows:

The structure of a typical ROS package contains the following:

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 to keep the configuration files in it.
include: This folder consists of the headers of the libraries that need to be used inside the package.
scripts: These are executable scripts that can be in Bash, Python, or any other scripting language.
src: This is where the source files of our programs are present. We can create a folder for nodes and nodelets or organize as per convenient.
launch: This folder keeps the launch files that are used to launch one or more ROS nodes.
msg: This folder contains custom message type definitions.
srv: This folder contains the service type definitions.
action: This folder contains the action definition. We will look into more about actionlib in the upcoming sections.
package.xml: This is the package manifest file of this package.
CMakeLists.txt: This is the CMake build file of this package.

Metapackages are specialized packages in ROS that only contain one file, package.xml. It simply groups a set of multiple packages as a single logical package. In the package.xml file, the meta package contains an export tag. The ROS navigation stack is a good example of metapackages. We can locate the navigation metapackage using the following command:

$ rosstack find navigation $ roscd navigation $ gedit package.xml

In the following screenshot, we can see the content from the package.xml file in the navigation metapackage. We can also see the <export> tag and the <run_depend> tag. These are necessary in the package manifest, which is also shown in the following screenshot:

Screenshot of package.xml

ROS uses a simplified message description language to describe the data values that ROS nodes publish. These datatype descriptions can be used to generate source code for the appropriate message type in different target languages such as C++, Python, Java, MATLAB, and so on.

The data type description of ROS messages is stored in the .msg files in the msg subdirectory of a ROS package. The message definition can consist of two types—fields and constants. The field is split into field types and field name. The field type is the data type of the transmitting message and the field name is its name. The constants define a constant value in the message file.

An example of an .msg file is as follows:

int32 id
float32 speed
string name

In ROS, we can find a set of standard types to use in messages, as shown in the following table:

A special type of ROS message is message headers, which can carry information such as a time or stamp, a frame of reference or frame_id, and a sequence number or seq. Using this information, ROS messages can be transparent to the ROS nodes that are handling them.

The rosmsg command tool can be used to get the information about the message header:

$ rosmsg show std_msgs/Header

We can get the following outputs:

uint32 seq time stamp string frame_id

In the upcoming sections, we will look into how to create messages with the right tools.

ROS uses a simplified service description language to describe ROS service types. This is built directly upon the ROS msg format to enable request-response communication between nodes. Service descriptions are stored in the .srv files in the srv subdirectory of a package.

An example service description format is as follows:

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

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

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