The ROS packages are the basic unit of the ROS system. We can create a ROS package, build it, and release it to the public. The current distribution of ROS we are using is kinetic. We are using the catkin build system to build ROS packages. A build system is responsible for generating 'targets' (executable/libraries) from a raw source code that can be used by an end user. In older distributions, such as Electric and Fuerte, rosbuild was the build system. Because of the various flaws of rosbuild, catkin came into existence, which is basically based on Cross Platform Make (CMake). This has a lot of advantages, such as porting the package into another operating system, such as Windows. If an OS supports CMake and Python, catkin -based packages can be easily ported into it.

The first requirement work with ROS packages is to create a...

In this section, we will look at how to create custom messages and services definitions in the current package. The message definitions are stored in a .msg file and the service definitions are stored in a .srv file. These definitions inform ROS about the type of data and name of data to be transmitted from a ROS node. When a custom message is added, ROS will convert the definitions into equivalent C++ codes, which we can include in our nodes.

We can start with message definitions. Message definitions have to be written in the .msg file and have to be kept in the msg folder, which is inside the package. We are going to create a message file called demo_msg.msg with the following definition:

string greeting 
int32 number 

Until now, we have worked only with standard message definitions. Now, we have created our own definitions and can see how to...

In this section, we are going to create ROS nodes, which can use the services definition that we defined already. The service nodes we are going to create can send a string message as a request to the server and the server node will send another message as a response.

Navigate to mastering_ros_demo_pkg/src, and find nodes with the names demo_service_server.cpp and demo_service_client.cpp.

The demo_service_server.cpp is the server, and its definition is as follows:

#include "ros/ros.h" 
#include "mastering_ros_demo_pkg/demo_srv.h" 
#include <iostream> 
#include <sstream> 
using namespace std; 
 
bool demo_service_callback(mastering_ros_demo_pkg::demo_srv::Request &req, 
     mastering_ros_demo_pkg::demo_srv::Response &res) { 
 std::stringstream ss; 
 ss << "Received Here"; 
 res.out = ss.str(); 
...

The launch files in ROS are a very useful feature for launching more than one node. In the preceding examples, we have seen a maximum of two ROS nodes, but imagine a scenario in which we have to launch 10 or 20 nodes for a robot. It will be difficult if we run each node in a terminal one by one. Instead, we can write all nodes inside an XML-based file called launch files and, using a command called roslaunch, we can parse this file and launch the nodes.

The roslaunch command will automatically start the ROS Master and the parameter server. So, in essence, there is no need to start the roscore command and individual node; if we launch the file, all operations will be done in a single command.

Let's start creating launch files. Switch to the package folder and create a new launch file called demo_topic.launch to launch two ROS nodes that are publishing...

Topics, services, and actionlib are used in different scenarios. We know topics are a unidirectional communication method, services are a bidirectional request/reply kind of communication, and actionlib is a modified form of ROS services in which we can cancel the executing process running on the server whenever required.

Here are some of the areas where we use these methods:

• Topics: Streaming continuous data flow, such as sensor data. For example, stream joypad data to teleoperate a robot, publish robot odometry, publish video stream from a camera.
• Services: Executing procedures that terminate quickly. For example, save calibration parameter of sensors, save a map generated by the robot during its navigation, or load a parameter file.
• Actionlib: Execute long and complex actions managing their feedback. For example, navigate towards...

Most ROS packages are maintained using a Version Control System (VCS) such as Git, Subversion (svn), Mercurial (hg), and so on. A collection of packages that share a common VCS can be called a repository. The package in the repository can be released using a catkin release automation tool called bloom. Most ROS packages are released as open source with the BSD license. There are active developers around the globe who are contributing to the ROS platform. Maintaining packages is important for all software, especially open source applications. Open source software is maintained and supported by a community of developers. Creating a version control system for our package is essential if we want to maintain and accept a contribution from other developers.
The preceding package is already updated in GitHub, and you can view the source code of the project...

After creating a ROS package in GitHub, we can officially release our package. ROS provides detailed steps to release the ROS package using a tool called bloom (http://ros-infrastructure.github.io/bloom/). Bloom is a release automation tool, designed to make platform-specific releases from the source projects. Bloom is designed to work best with the catkin project.

The prerequisites for releasing the package are as follows:

• Install the Bloom tool
• Create a Git repository for the current package
• Create an empty Git repository for the release

The following command will install bloom in Ubuntu:

$ sudo apt-get install python-bloom  

Create a Git repository for the current package. The repository that has the package is called the upstream repository. Here, we already created a repository at https://github.com/jocacace/mastering_ros_demo_pkg.

Create an empty...