In this article by Enrique Fernández, Luis Sánchez Crespo, Anil Mahtani, and Aaron Martinez, authors of the book Learning ROS for Robotics Programming – Second Edition, you will see the different levels of filesystems in ROS.

(For more resources related to this topic, see here.)

When you start to use or develop projects with ROS, you will see that although this concept can sound strange in the beginning, you will become familiar with it with time.

Similar to an operating system, an ROS program is divided into folders, and these folders have files that describe their functionalities:

• Packages: Packages form the atomic level of ROS. A package has the minimum structure and content to create a program within ROS. It may have ROS runtime processes (nodes), configuration files, and so on.
• Package manifests: Package manifests provide information about a package, licenses, dependencies, compilation flags, and so on. A package manifest is managed with a file called package.xml.
• Metapackages: When you want to aggregate several packages in a group, you will use metapackages. In ROS Fuerte, this form for ordering packages was called Stacks. To maintain the simplicity of ROS, the stacks were removed, and now, metapackages make up this function. In ROS, there exist a lot of these metapackages; one of them is the navigation stack.
• Metapackage manifests: Metapackage manifests (package.xml) are similar to a normal package but with an export tag in XML. It also has certain restrictions in its structure.
• Message (msg) types: A message is the information that a process sends to other processes. ROS has a lot of standard types of messages. Message descriptions are stored in my_package/msg/MyMessageType.msg.
• Service (srv) types: Service descriptions, stored in my_package/srv/MyServiceType.srv, define the request and response data structures for services provided by each process in ROS.

The workspace

Basically, the workspace is a folder where we have packages, edit the source files or compile packages. It is useful when you want to compile various packages at the same time and is a good place to have all our developments localized.

A typical workspace is shown in the following screenshot. Each folder is a different space with a different role:

• The Source space: In the Source space (the src folder), you put your packages, projects, clone packages, and so on. One of the most important files in this space is CMakeLists.txt. The src folder has this file because it is invoked by CMake when you configure the packages in the workspace. This file is created with the catkin_init_workspace command.
• The Build space: In the build folder, CMake and catkin keep the cache information, configuration, and other intermediate files for our packages and projects.
• The Development (devel) space: The devel folder is used to keep the compiled programs. This is used to test the programs without the installation step. Once the programs are tested, you can install or export the package to share with other developers.

You have two options with regard to building packages with catkin. The first one is to use the standard CMake workflow. With this, you can compile one package at a time, as shown in the following commands:

$ cmake packageToBuild/

$ make

If you want to compile all your packages, you can use the catkin_make command line, as shown in the following commands:

$ cd workspace

$ catkin_make

Both commands build the executables in the build space directory configured in ROS.

Another interesting feature of ROS are its overlays. When you are working with a package of ROS, for example, Turtlesim, you can do it with the installed version, or you can download the source file and compile it to use your modified version.

ROS permits you to use your version of this package instead of the installed version. This is very useful information if you are working on an upgrade of an installed package.

Packages

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

• include/package_name/: This directory includes the headers of the libraries that you would need.
• msg/: If you develop nonstandard messages, put them here.
• scripts/: These are executable scripts that can be in Bash, Python, or any other scripting language.
• src/: This is where the source files of your programs are present. You can create a folder for nodes and nodelets or organize it as you want.
• srv/: This represents the service (srv) types.
• CMakeLists.txt: This is the CMake build file.
• package.xml: This is the package manifest.

To create, modify, or work with packages, ROS gives us tools for assistance, some of which are as follows:

• rospack: This command is used to get information or find packages in the system.
• catkin_create_pkg: This command is used when you want to create a new package.
• catkin_make: This command is used to compile a workspace.
• rosdep: This command installs the system dependencies of a package.
• rqt_dep: This command is used to see the package dependencies as a graph. If you want to see the package dependencies as a graph, you will find a plugin called package graph in rqt. Select a package and see the dependencies.

To move between packages and their folders and files, ROS gives us a very useful package called rosbash, which provides commands that are very similar to Linux commands. The following are a few examples:

• roscd: This command helps us change the directory. This is similar to the cd command in Linux.
• rosed: This command is used to edit a file.
• roscp: This command is used to copy a file from a package.
• rosd: This command lists the directories of a package.
• rosls: This command lists the files from a package. This is similar to the ls command in Linux.

The package.xml file must be in a package, and it is used to specify information about the package. If you find this file inside a folder, probably this folder is a package or a metapackage.

If you open the package.xml file, you will see information about the name of the package, dependencies, and so on. All of this is to make the installation and the distribution of these packages easy.

Two typical tags that are used in the package.xml file are <build_depend> and <run _depend>.

The <build_depend> tag shows what packages must be installed before installing the current package. This is because the new package might use a functionality of another package.

Metapackages

As we have shown earlier, metapackages are special packages with only one file inside; this file is package.xml. This package does not have other files, such as code, includes, and so on.

Metapackages are used to refer to others packages that are normally grouped following a feature-like functionality, for example, navigation stack, ros_tutorials, and so on.

You can convert your stacks and packages from ROS Fuerte to Hydro and catkin using certain rules for migration. These rules can be found at http://wiki.ros.org/catkin/migrating_from_rosbuild.

In the following screenshot, you can see the content from the package.xml file in the ros_tutorials metapackage. You can see the <export> tag and the <run_depend> tag. These are necessary in the package manifest.

If you want to locate the ros_tutorials metapackage, you can use the following command:

$ rosstack find ros_tutorials

The output will be a path, such as /opt/ros/hydro/share/ros_tutorials.

To see the code inside, you can use the following command line:

$ vim /opt/ros/hydro/share/ros_tutorials/package.xml

Remember that Hydro uses metapackages, not stacks, but the rosstack find command line works to find metapackages.

Messages

ROS uses a simplified message description language to describe the data values that ROS nodes publish. With this description, ROS can generate the right source code for these types of messages in several programming languages.

ROS has a lot of messages predefined, but if you develop a new message, it will be in the msg/ folder of your package. Inside that folder, certain files with the .msg extension define the messages.

A message must have two principal parts: fields and constants. Fields define the type of data to be transmitted in the message, for example, int32, float32, and string, or new types that you have created earlier, such as type1 and type2. Constants define the name of the fields.

An example of a msg file is as follows:

int32 id

float32 vel

string name

In ROS, you can find a lot of standard types to use in messages, as shown in the following table list:

Primitive type	Serialization	C++	Python
bool (1)	unsigned 8-bit int	uint8_t(2)	bool
int8	signed 8-bit int	int8_t	int
uint8	unsigned 8-bit int	uint8_t	int(3)
int16	signed 16-bit int	int16_t	int
uint16	unsigned 16-bit int	uint16_t	int
int32	signed 32-bit int	int32_t	int
uint32	unsigned 32-bit int	uint32_t	int
int64	signed 64-bit int	int64_t	long
uint64	unsigned 64-bit int	uint64_t	long
float32	32-bit IEEE float	float	float
float64	64-bit IEEE float	double	float
string	ascii string (4)	std::string	string
time	secs/nsecs signed 32-bit ints	ros::Time	rospy.Time
duration	secs/nsecs signed 32-bit ints	ros::Duration	rospy.Duration

A special type in ROS is the header type. This is used to add the time, frame, and so on. This permits you to have the messages numbered, to see who is sending the message, and to have more functions that are transparent for the user and that ROS is handling.

The header type contains the following fields:

uint32 seq

time stamp

string frame_id

You can see the structure using the following command:

$ rosmsg show std_msgs/Header

Thanks to the header type, it is possible to record the timestamp and frame of what is happening with the robot.

In ROS, there exist tools to work with messages. The rosmsg tool prints out the message definition information and can find the source files that use a message type.

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

Services

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

To call a service, you need to use the package name, along with the service name; for example, you will refer to the sample_package1/srv/sample1.srv file as sample_package1/sample1.

There are tools that exist to perform functions with services. The rossrv tool prints out the service descriptions and packages that contain the .srv files, and finds source files that use a service type.

If you want to create a service, ROS can help you with the service generator. These tools generate code from an initial specification of the service. You only need to add the gensrv() line to your CMakeLists.txt file.

Summary

In this article, we saw the different types of filesystems present in the ROS architecture.

Resources for Article:

---

Further resources on this subject:

• Building robots that can walk [article]
• Avoiding Obstacles Using Sensors [article]
• Managing Test Structure with Robot Framework [article]

---