A typical structure of a ROS package is shown here:

Figure 3 : Structure of a typical ROS package

We can discuss the use of each folder as follows:

We need to know some commands to create, modify, and work with the ROS packages. Here are some of the commands used to work with ROS packages:

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:

The definition of package.xml of a typical package is shown as follows:

Figure 4 : Structure of package.xml

The package.xml file consists of the package name, version of the package, the package description, author details, package build dependencies, and runtime dependencies. The <build_depend></build_depend> tag includes the packages that are necessary to build the source code of the package. The packages inside the <run_depend></run_depend> tag are necessary during runtime of the package node.

Meta packages are specialized packages in ROS that only contain one file, that is, a package.xml file. It doesn't contain folders and files similar to a normal package.

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

    <export>
        <metapackage/>
    </export> 

Also, in meta packages, there are no <buildtool_depend> dependencies for catkin, there are only <run_depend> dependencies, which are the packages grouped in the meta package.

The ROS navigation stack is a good example of meta packages. If ROS is installed, we can try the following command, by switching to the navigation meta package folder:

$ roscd navigation

Open package.xml using gedit text editor

$ gedit package.xml

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

Figure 5 : Structure of meta-package package.xml

The ROS nodes can publish data having a particular type. The types of data are described using a simplified message description language, also called ROS messages. These datatype descriptions can be used to generate source code for the appropriate message type in different target languages.

The data type description of ROS messages are stored in .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. Field types is the data type of the transmitting message and field name is the name of it. The constants define a constant value in the message file.

Here is an example of message definitions:

int32 number
string name
float32 speed

Here, the first part is the field type and 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 for accessing the value of the number from the message.

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

A special type of ROS message is called message headers. Headers can carry information such as time, frame of reference or frame_id, and sequence number. Using headers, we will get numbered messages and more clarity in who is sending the current message. The header information is mainly used to send data such as robot joint transforms (TF). Here is an example of the message 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 to view the message header of a particular message:

$ rosmsg show std_msgs/Header

This will give you an output like the preceding example message header. We can see more about the rosmsg command and how to work with custom message definitions in the upcoming sections.

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

Similar to the message definitions using the .msg file, we have to define the service definition in another file called .srv, which has to be kept inside the srv sub directory of the package. Similar to the message definition, a service description language is used to define the ROS service types.

An example service description format is as follows:

#Request message type
string str
---
#Response message type
string str

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

In the upcoming sections, we can see how to work with ROS services.