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.

ROS nodes are a process that perform computation using ROS client libraries such as roscpp and rospy. One node can communicate with other nodes using ROS Topics, Services, and Parameters.

A robot might contain many nodes, for example, one node processes camera images, one node handles serial data from the robot, one node can be used to compute odometry, and so on.

Using nodes can make the system fault tolerant. Even if a node crashes, an entire robot system can still work. Nodes also reduce the complexity and increase debug-ability compared to monolithic codes because each node is handling only a single function.

All running nodes should have a name assigned to identify them from the rest of the system. For example, /camera_node could be a name of a node that is broadcasting camera images.

There is a rosbash tool to introspect ROS nodes. The rosnode command can be used to get information about a ROS node. Here are the usages of rosnode:

We will see example nodes using the roscpp client and will discuss the working of ROS nodes that use functionalities such ROS Topics, Service, Messages, and actionlib.

ROS nodes communicate with each other by publishing messages to a topic. As we discussed earlier, messages are a simple data structure containing field types. The ROS message supports standard primitive datatypes and arrays of primitive types.

Nodes can also exchange information using service calls. Services are also messages, the service message definitions are defined inside the srv file.

We can access the message definition using the following method. For example, to access std_msgs/msg/String.msg, we can use std_msgs/String. If we are using the roscpp client, we have to include std_msgs/String.h for the string message definition.

In addition to message data type, ROS uses an MD5 checksum comparison to confirm whether the publisher and subscriber exchange the same message data types.

ROS has inbuilt tools called rosmsg to get information about ROS messages. Here are some parameters used along with rosmsg:

ROS topics are named buses in which ROS nodes exchange messages. Topics can anonymously publish and subscribe, which means that the production of messages is decoupled from the consumption. The ROS nodes are not interested to know which node is publishing the topic or subscribing topics, it only looks for the topic name and whether the message types of publisher and subscriber are matching.

The communication using topics are unidirectional, if we want to implement request/response such as communication, we have to switch to ROS services.

The ROS nodes communicate with topics using TCP/IP-based transport known as TCPROS. This method is the default transport method used in ROS. Another type of communication is UDPROS, which has low-latency, loose transport, and is only suited for teleoperation.

The ROS topic tool can be used to get information about ROS topics. Here is the syntax of this command:

When we need a request/response kind of communication in ROS, we have to use the ROS services. ROS topics can't do this kind of communication because it is unidirectional. ROS services are mainly used in a distributed system.

The ROS services is defined using a pair of messages. We have to define a request datatype and a response datatype in a srv file. The srv files are kept in a srv folder inside a package.

In ROS services, one node acts as a ROS server in which the service client can request the service from the server. If the server completes the service routine, it will send the results to the service client.

The ROS service definition can be accessed by the following method, for example, if my_package/srv/Image.srv can be accessed by my_package/Image.

In ROS services also, there is an MD5 checksum that checks in the nodes. If the sum is equal, then only the server responds to the client.

There are two ROS tools to get information about the ROS service. The first tool is rossrv, which is similar to rosmsg, and is used to get information about service types. The next command is rosservice, which is used to list and query about the running ROS services.

The following explain how to use the rosservice tool to get information about the running services:

A bag file in ROS is for storing ROS message data from topics and services. The .bag extension is used to represent a bag file.

Bag files are created using the rosbag command, which will subscribe one or more topics and store the message's data in a file as it's received. This file can play the same topics as they are recorded from or it can remap the existing topics too.

The main application of rosbag is data logging. The robot data can be logged and can visualize and process offline.

The rosbag command is used to work with rosbag files. Here are the commands to record and playback a bag file:

Here are more details about this command:

http://wiki.ros.org/rosbag/Commandline

There is a GUI tool to handle record and playback of bag files called rqt_bag. Go to the following link to know more about rqt_bag:

http://wiki.ros.org/rqt_bag

ROS Master is much like a DNS server. When any node starts in the ROS system, it will start looking for ROS Master and register the name of the node in it. So ROS Master has the details of all nodes currently running on the ROS system. When any details of the nodes change, it will generate a call-back and update with the latest details. These node details are useful for connecting with each node.

When a node starts publishing a topic, the node will give the details of the topic such as name and data type to ROS Master. ROS Master will check whether any other nodes are subscribed to the same topic. If any nodes are subscribed to the same topic, ROS Master will share the node details of the publisher to the subscriber node. After getting the node details, these two nodes will interconnect using the TCPROS protocol, which is based on TCP/IP sockets. After connecting to the two nodes, ROS Master has no role in controlling them. We might be able to stop either the publisher node or the subscriber node according to our wish. If we stop any nodes, it will check with ROS Master once again. This same method is for the ROS services.

The nodes are written using the ROS client libraries such as roscpp and rospy. These clients interact with ROS Master using XMLRPC (XML Remote Procedure Call) based APIs, which act as the backend of the ROS system APIs.

The ROS_MASTER_URI environment variable contains the IP and port of ROS Master. Using this variable, ROS nodes can locate ROS Master. If this variable is wrong, the communication between nodes will not take place. When we use ROS in a single system, we can use the IP of localhost or the name localhost itself. But in a distributed network, in which computation is on different physical computers, we should define ROS_MASTER_URI properly, only then, the remote node could find each other and communicate with each other. We need only one Master, in a distributed system, and it should run on a computer in which all other computers can ping it properly to ensure that remote ROS nodes can access the Master.

The following diagram shows an illustration of how ROS Master interacts with a publishing and subscribing node, the publisher node publishing a string type topic with a "Hello World" message and the subscriber node subscribes to this topic.

Figure 8: Communication between ROS Master and Hello World publisher and subscriber

When the publisher node starts publishing the "Hello World" message in a particular topic, ROS Master gets the details of the topic and details of the node. It will search whether any node is subscribing the same topic. If there are no nodes subscribing the same topic at that time, both nodes remain unconnected. If the publisher and subscriber nodes run at the same time, ROS Master exchanges the details of the publisher to the subscriber and they will connect and can exchange data through ROS messages.

While programming a robot, we might have to define robot parameters such as robot controller gain such as P, I, and D. When the number of parameters increases, we might need to store it as files. In some situation, these parameters have to share between two or more programs too. In this case, ROS provides a parameter server, which is a shared server in which all ROS nodes can access parameters from this server. A node can read, write, modify and delete parameter values from the parameter server.

We can store these parameters in a file and load them into the server. The server can store a wide variety of data types and can even store dictionaries. The programmer can also set the scope of the parameter, that is, whether it can be accessed by only this node or all the nodes.

The parameter server supports the following XMLRPC datatypes, which include:

We can also store dictionaries on the parameter server. If the number of parameters is high, we can use a YAML file to save it. Here is an example of the YAML file parameter definitions:

/camera/name : 'nikon'   #string type
/camera/fps : 30         #integer    
/camera/exposure : 1.2   #float 
/camera/active : true    #boolean

The rosparam tool used to get and set the ROS parameter from the command line. The following are the commands to work with ROS parameters:

The parameters can be changed dynamically during the execution of the node that uses these parameters, using the dyamic_reconfigure package (http://wiki.ros.org/dynamic_reconfigure).

Before getting started with ROS and trying the code in this book, the following prerequisites should be met:

Before running any ROS nodes, we should start ROS Master and the ROS parameter server. We can start ROS Master and the ROS parameter server using a single command called roscore, which will start the following programs:

The rosout node will collect log messages from other ROS nodes and store them in a log file, and will also rebroadcast the collected log message to another topic. The topic /rosout is published by ROS nodes working using ROS client libraries such as roscpp and rospy and this topic is subscribed by the rosout node which rebroadcasts the message in another topic called /rosout_agg. This topic has an aggregate stream of log messages. The command roscore is a prerequisite before running any ROS node. The following screenshot shows the messages printing when we run the roscore command in a terminal.

The following is a command to run roscore on a Linux terminal:

$ roscore

Figure 9 : Terminal messages while running the roscore command

The following are explanations of each section when executing roscore on the terminal:

The following is the content of roscore.xml:

<launch>
  <group ns="/">
    <param name="rosversion" command="rosversion roslaunch" />
    <param name="rosdistro" command="rosversion -d" />
    <node pkg="rosout" type="rosout" name="rosout" respawn="true"/>
  </group>
</launch>

When the roscore command is executed, initially, the command checks the command line argument for a new port number for the rosmaster. If it gets the port number, it will start listening to the new port number, otherwise it will use the default port. This port number and the roscore.xml launch file will pass to the roslaunch system. The roslaunch system is implemented in a Python module, it will parse the port number and launch the roscore.xml file.

In the roscore.xml file, we can see the ROS parameters and nodes are encapsulated in a group XML tag with a "/" namespace. The group XML tag indicates that all the nodes inside this tag have the same settings.

The two parameters called rosversion and rosdistro store the output of the rosversion roslaunch and rosversion -d commands using the command tag, which is a part of the ROS param tag. The command tag will execute the command mentioned on it and store the output of the command in these two parameters.

The rosmaster and parameter server are executed inside roslaunch modules by using the ROS_MASTER_URI address. This is happening inside the roslaunch Python module. The ROS_MASTER_URI is a combination of the IP address and port in which rosmaster is going to listen. The port number can be changed according to the given port number in the roscore command.

$ rostopic list

/rosout
/rosout_agg

$ rosparam list

/rosdistro
/roslaunch/uris/host_robot_virtualbox__51189
/rosversion
/run_id

$ rosservice list

/rosout/get_loggers
/rosout/set_logger_level

The ROS packages are the basic unit of the ROS system. We can create the ROS package, build it and release it to the public. The current distribution of ROS we are using is Jade/Indigo. 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 CMake (Cross Platform Make). This has lot of advantages such as porting the package into other operating system, such as Windows. If an OS supports CMake and Python, catkin based packages can be easily ported into it.

The first requirement in creating ROS packages is to create a ROS catkin workspace. Here is the procedure to build a catkin workspace.

Build a workspace folder in the home directory and create a src folder inside the workspace folder:

$ mkdir ~/catkin_ws/src

Switch to the source folder. The packages are created inside this package:

$cd ~/catkin_ws/src

Initialize a new catkin workspace:

$ catkin_init_workspace

We can build the workspace even if there are no packages. We can use the following command to switch to the workspace folder:

$ cd ~/catkin_ws

The catkin_make command will build the following workspace:

$ catkin_make

After building the empty workspace, we should set the environment of the current workspace to be visible by the ROS system. This process is called overlaying a workspace. We should add the package environment using the following command:

$ echo "source ~/catkin_ws/devel/setup.bash" >> ~/.bashrc 
$ source ~/.bashrc

This command will source a bash script called setup.bash inside the devel workspace folder. To set the environment in all bash sessions, we need to add a source command in the .bashrc file, which will source this script whenever a bash session starts.

This is the link of the procedure http://wiki.ros.org/catkin/Tutorials/create_a_workspace.

The build folder in the CMake build files mainly contains executables of the nodes that are placed inside the catkin workspace src folder. The devel folder contains bash script, header files, and executables in different folders generated during the build process. We can see how to make ROS nodes and build using catkin_make.

#include "ros/ros.h"
#include "std_msgs/Int32.h"
#include <iostream>
int main(int argc, char **argv)
{
  ros::init(argc, argv,"demo_topic_publisher");
  ros::NodeHandle node_obj;
  ros::Publisher number_publisher = node_obj.advertise<std_msgs::Int32>("/numbers",10);
  ros::Rate loop_rate(10);
  int number_count = 0;
  while (ros::ok())
  {
    std_msgs::Int32 msg;
    msg.data = number_count;
    ROS_INFO("%d",msg.data);
    number_publisher.publish(msg);
    ros::spinOnce();
    loop_rate.sleep();
    ++number_count;
  }
  return 0;
}

#include "ros/ros.h"
#include "std_msgs/Int32.h"
#include <iostream>

  ros::init(argc, argv,"demo_topic_publisher");

  ros::NodeHandle node_obj;

  ros::Publisher number_publisher = node_obj.advertise<std_msgs::Int32>("/numbers",10);

  ros::Rate loop_rate(10);

  while (ros::ok())
  {

     std_msgs::Int32 msg;
    msg.data = number_count;

  ROS_INFO("%d",msg.data);

    number_publisher.publish(msg);

    ros::spinOnce();

    loop_rate.sleep();

#include "ros/ros.h"
#include "std_msgs/Int32.h"
#include <iostream>
void number_callback(const std_msgs::Int32::ConstPtr& msg)
{
  ROS_INFO("Received  [%d]",msg->data);
}
int main(int argc, char **argv)
{

  ros::init(argc, argv,"demo_topic_subscriber");
  ros::NodeHandle node_obj;
  ros::Subscriber number_subscriber = node_obj.subscribe("/numbers",10,number_callback);
  ros::spin();
  return 0;
}

#include "ros/ros.h"
#include "std_msgs/Int32.h"
#include <iostream>

void number_callback(const std_msgs::Int32::ConstPtr& msg)
{
  ROS_INFO("Recieved  [%d]",msg->data);
}

  ros::Subscriber number_subscriber = node_obj.subscribe("/numbers",10,number_callback);

  ros::spin();

Building the nodes

We have to edit the CMakeLists.txt file in the package to compile and build the source code. Navigate to chapter_1_codes/mastering_ros_demo_package/CMakeLists.txt to view the existing CMakeLists.txt file. The following code snippet in this file is responsible for building these two nodes:

include_directories(
  include
  ${catkin_INCLUDE_DIRS}
  ${Boost_INCLUDE_DIRS}
)
#This will create executables of the nodes
add_executable(demo_topic_publisher src/demo_topic_publisher.cpp)
add_executable(demo_topic_subscriber src/demo_topic_subscriber.cpp)

#This will generate message header file before building the target
add_dependencies(demo_topic_publisher mastering_ros_demo_pkg_generate_messages_cpp)
add_dependencies(demo_topic_subscriber mastering_ros_demo_pkg_generate_messages_cpp)

#This will link executables to the appropriate libraries 
target_link_libraries(demo_topic_publisher ${catkin_LIBRARIES})
target_link_libraries(demo_topic_subscriber ${catkin_LIBRARIES})

We can add the preceding snippet to create a new a CMakeLists.txt file for compiling the two codes.

The catkin_make command is used to build the package.

We can first switch to workspace:

$ cd ~/catkin_ws

Build mastering_ros_demo_package as follows:

$ catkin_make mastering_ros_demo_package

We can either use the preceding command to build a specific package or just caktin_make to build the entire workspace.

This will create executables in ~/catkin_ws/devel/lib/<package name>.

If the building is done, we can execute the nodes.

First start roscore:

$ roscore

Now run both commands in two shells.

In the running publisher:

$ rosrun mastering_ros_demo_package demo_topic_publisher 

In the running subscriber:

$ rosrun mastering_ros_demo_package demo_topic_subscriber

We can see the output as shown here:

Figure 11 : Running topic publisher and subscriber

The following diagram shows how the nodes communicate with each other. We can see the demo_topic_publisher node publish the /numbers topic and subscribe by then demo_topic_subscriber node.

Figure 12 : Graph of the communication between publisher and subscriber nodes.

We can use the rosnode and rostopic tools to debug and understand the working of two nodes:

• $ rosnode list: This will list the active nodes
• $ rosnode info demo_topic_publisher: This will get the info of the publisher node
• $ rostopic echo /numbers: This will display the value sending through the /numbers topic
• $ rostopic type /numbers: This will print the message type of the /numbers topic

In this section, we can see how to create custom messages and services definitions in the current package. The message definitions are stored in a .msg file and service definition 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 use them in our code.

The first step is to edit the package.xml file of the current package and uncomment the lines <build_depend>message_generation</build_depend> and <run_depend>message_runtime</run_depend>.

Edit the current CMakeLists.txt and add the message_generation line as follows:

find_package(catkin REQUIRED COMPONENTS
  roscpp
  rospy
  std_msgs
 actionlib 
  actionlib_msgs
  message_generation
)

Uncomment the following line and add the custom message file:

 add_message_files(
   FILES
   demo_msg.msg
 )
## Generate added messages and services with any dependencies listed here
 generate_messages(
   DEPENDENCIES
   std_msgs
   actionlib_msgs
 )

After these steps, we can compile and build the package:

$ cd ~/catkin_ws/
$ catkin_make

To check whether the message is built properly, we can use the rosmsg command:

$ rosmsg show mastering_ros_demo_pkg/demo_msg

If the content shown by the command and the definition are the same, the procedure is correct.

If we want to test the custom message, we can build a publisher and subscriber using the custom message type named demo_msg_publisher.cpp and demo_msg_subscriber.cpp. Navigate to the chapter_1_codes/mastering_ros_demo_pkg/src folder for these codes.

We can test the message by adding the following lines of code in CMakeLists.txt:

add_executable(demo_msg_publisher src/demo_msg_publisher.cpp)
add_executable(demo_msg_subscriber src/demo_msg_subscriber.cpp)

add_dependencies(demo_msg_publisher mastering_ros_demo_pkg_generate_messages_cpp)
add_dependencies(demo_msg_subscriber mastering_ros_demo_pkg_generate_messages_cpp)

target_link_libraries(demo_msg_publisher ${catkin_LIBRARIES})
target_link_libraries(demo_msg_subscriber ${catkin_LIBRARIES})

Build the package using catkin_make and test the node using the following commands.

The publisher node publishes a string along with an integer, and the subscriber node subscribes the topic and prints the values. The output and graph are shown as follows:

Figure 13 : Running publisher and subscriber using custom message definitions.

The topic in which the nodes are communicating is called /demo_msg_topic. Here is the graph view of two nodes:

Figure 14 : Graph of the communication between message publisher and subscriber

Next, we can add srv files to the package. Create a new folder called srv in the current package folder and add a srv file called demo_srv.srv. The definition of this file is as follows:

string in
---
string out

Here, both the Request and Response are strings.

In the next step, we need to uncomment the following lines in package.xml as we did for the ROS messages:

<build_depend>message_generation</build_depend>
<run_depend>message_runtime</run_depend>

Take CMakeLists.txt and add message_runtime in catkin_package():

catkin_package(
  CATKIN_DEPENDS roscpp rospy std_msgs actionlib actionlib_msgs message_runtime 
)

We need to follow the same procedure in generating services as we did for the ROS message. Apart from that, we need additional sections to be uncommented as shown here:

## Generate services in the 'srv' folder
 add_service_files(
   FILES
   demo_srv.srv
 )

After making these changes, we can build the package using catkin_make and using the following command we can verify the procedure:

$ rossrv show mastering_ros_demo_pkg/demo_srv

If we see the same content as we defined in the file, we can confirm it's working.

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 chapter_1_codes/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();
  ROS_INFO("From Client  [%s], Server says [%s]",req.in.c_str(),res.out.c_str());
  return true;
}

int main(int argc, char **argv)
{
  ros::init(argc, argv, "demo_service_server");
  ros::NodeHandle n;
  ros::ServiceServer service = n.advertiseService("demo_service", demo_service_callback);
  ROS_INFO("Ready to receive from client.");
  ros::spin();
  return 0;
}

Let's see the explanation of the code:

#include "ros/ros.h"
#include "mastering_ros_demo_pkg/demo_srv.h"
#include <iostream>
#include <sstream>

Here, we included ros/ros.h, which is a mandatory header for a ROS CPP node. The mastering_ros_demo_pkg/demo_srv.h header is a generated header, which contains our service definition and can use this in our code. The sstream.h is for getting string streaming classes:

bool demo_service_callback(mastering_ros_demo_pkg::demo_srv::Request  &req,
         mastering_ros_demo_pkg::demo_srv::Response &res)
{

This is the server callback function executed when a request is received on the server. The server can receive the request from clients having a message type of mastering_ros_demo_pkg::demo_srv::Request and sends the response in the mastering_ros_demo_pkg::demo_srv::Response type:

  std::stringstream ss;
  ss << "Received  Here";
  res.out = ss.str();

In this code, the string data "Received Here" is passing to the service Response instance. Here, out is the field name of the response that we have given in the demo_srv.srv. This response will go to the service client node:

  ros::ServiceServer service = n.advertiseService("demo_service", demo_service_callback);

This creates a service having a name as demo_service and a callback function is executed when a request comes to this service. The callback function is demo_service_callback, which we saw in the preceding section.

Next, we can see how the demo_service_client.cpp is working.

Here is the definition of this code:

#include "ros/ros.h"
#include <iostream>
#include "mastering_ros_demo_pkg/demo_srv.h"
#include <iostream>
#include <sstream>
using namespace std;

int main(int argc, char **argv)
{
  ros::init(argc, argv, "demo_service_client");
  ros::NodeHandle n;
  ros::Rate loop_rate(10);
  ros::ServiceClient client = n.serviceClient<mastering_ros_demo_pkg::demo_srv>("demo_service");
  while (ros::ok())
  {
    mastering_ros_demo_pkg::demo_srv srv;
    std::stringstream ss;
    ss << "Sending from Here";
    srv.request.in = ss.str();
    if (client.call(srv))
    {

      ROS_INFO("From Client  [%s], Server says [%s]",srv.request.in.c_str(),srv.response.out.c_str());

    }
    else
    {
      ROS_ERROR("Failed to call service");
      return 1;
    }

  ros::spinOnce();
  loop_rate.sleep();

  }
  return 0;
}

Let's explain the code:

  ros::ServiceClient client = n.serviceClient<mastering_ros_demo_pkg::demo_srv>("demo_service");

This line creates a service client that has message type mastering_ros_demo_pkg::demo_srv and communicates to a ROS service named demo_service:

    mastering_ros_demo_pkg::demo_srv srv;

This line will create a new service object instance:

    std::stringstream ss;
    ss << "Sending from Here";
    srv.request.in = ss.str();

Fill the request instance with a string called "Sending from Here":

    if (client.call(srv))
    {

This will send the service call to the server. If it is sent successfully, it will print the response and request, if it failed, it do nothing:

      ROS_INFO("From Client  [%s], Server says [%s]",srv.request.in.c_str(),srv.response.out.c_str());

If the response is received, then it will print the request and the response.

After discussing the two nodes, we can discuss how to build these two nodes. The following code is added to CMakeLists.txt to compile and build the two nodes:

add_executable(demo_service_server src/demo_service_server.cpp)
add_executable(demo_service_client src/demo_service_client.cpp)

add_dependencies(demo_service_server mastering_ros_demo_pkg_generate_messages_cpp)
add_dependencies(demo_service_client mastering_ros_demo_pkg_generate_messages_cpp)

target_link_libraries(demo_service_server ${catkin_LIBRARIES})
target_link_libraries(demo_service_client ${catkin_LIBRARIES})

We can execute the following commands to build the code:

$ cd ~/catkin_ws
$ catkin_make

To start nodes, first execute roscore and use the following commands:

$ rosrun mastering_ros_demo_pkg demo_service_server
$ rosrun mastering_ros_demo_pkg demo_service_client

Figure 15 : Running ROS service client and server nodes.

We can work with rosservice using the rosservice command:

#goal definition
int32 count
---
#result definition
int32 final_count
---
#feedback
int32 current_number

#include <actionlib/server/simple_action_server.h>
#include "mastering_ros_demo_pkg/Demo_actionAction.h"

class Demo_actionAction
{ 

actionlib::SimpleActionServer<mastering_ros_demo_pkg::Demo_actionAction> as;

mastering_ros_demo_pkg::Demo_actionFeedback feedback;

mastering_ros_demo_pkg::Demo_actionResult result;

Demo_actionAction(std::string name) :
    as(nh_, name, boost::bind(&Demo_actionAction::executeCB, this, _1), false),
    action_name(name)

as.registerPreemptCallback(boost::bind(&Demo_actionAction::preemptCB, this));

  void executeCB(const mastering_ros_demo_pkg::Demo_actionGoalConstPtr &goal)
  {
  if(!as.isActive() || as.isPreemptRequested()) return;

  for(progress = 0 ; progress < goal->count; progress++){
    //Check for ros
    if(!ros::ok()){

    if(!as.isActive() || as.isPreemptRequested()){
      return;
    }  

    if(goal->count == progress){
      result.final_count = progress;
      as.setSucceeded(result);
    }

  Demo_actionAction demo_action_obj(ros::this_node::getName());

#include <actionlib/client/simple_action_client.h>
#include <actionlib/client/terminal_state.h>
#include "mastering_ros_demo_pkg/Demo_actionAction.h"

actionlib::SimpleActionClient<mastering_ros_demo_pkg::Demo_actionAction> ac("demo_action", true);

  ac.waitForServer();

  mastering_ros_demo_pkg::Demo_actionGoal goal;
  goal.count = atoi(argv[1]);
  ac.sendGoal(goal);

  bool finished_before_timeout = ac.waitForResult(ros::Duration(atoi(argv[2])));

  ac.cancelGoal();

Building the ROS action server and client

After creating these two files in the src folder, we have to edit the package.xml and CMakeLists.txt to build the nodes.

The package.xml file should contain message generation and runtime packages as we did for ROS service and messages.

We have to include the Boost library in CMakeLists.txt to build these nodes. Also, we have to add the action files that we wrote for this example:

find_package(catkin REQUIRED COMPONENTS
  roscpp
  rospy
  std_msgs
 actionlib 
  actionlib_msgs
  message_generation
)

We should pass actionlib, actionlib_msgs, and message_generation in find_package():

## System dependencies are found with CMake's conventions
find_package(Boost REQUIRED COMPONENTS system)

We should add Boost as a system dependency:

## Generate actions in the 'action' folder
 add_action_files(
   FILES
   Demo_action.action
 )

We need to add our action file in add_action_files():

## Generate added messages and services with any dependencies listed here
 generate_messages(
   DEPENDENCIES
   std_msgs
   actionlib_msgs
 )

We have to add actionlib_msgs in generate_messages():

catkin_package(
  CATKIN_DEPENDS roscpp rospy std_msgs actionlib actionlib_msgs message_runtime 
)

include_directories(
  include
  ${catkin_INCLUDE_DIRS}
  ${Boost_INCLUDE_DIRS}
)

We have to add Boost to include the directory:

##Building action server and action client

add_executable(demo_action_server src/demo_action_server.cpp)
add_executable(demo_action_client src/demo_action_client.cpp)

add_dependencies(demo_action_server mastering_ros_demo_pkg_generate_messages_cpp)
add_dependencies(demo_action_client mastering_ros_demo_pkg_generate_messages_cpp)

target_link_libraries(demo_action_server ${catkin_LIBRARIES} )
target_link_libraries(demo_action_client ${catkin_LIBRARIES})

After catkin_make, we can run these nodes using the following commands:

• Run roscore:

  $ roscore
  

• Launch the action server node:

  $rosrun mastering_ros_demo_pkg demo_action_server
  

• Launch the action client node:

  $rosrun mastering_ros_demo_pkg demo_action_client 50 4
  

The output of these process is shown as follows:

Figure 16 : Running ROS actionlib server and client

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 of that, we can write all nodes inside a 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 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 and subscribing an integer value. We keep the launch files in a launch folder, which is inside the package:

$ roscd mastering_ros_demo_pkg
$ mkdir launch
$ cd launch
$ gedit demo_topic.launch

Paste the following content into the file:

<launch>
  <node name="publisher_node" pkg="mastering_ros_demo_pkg" type="demo_topic_publisher" output="screen"/>

  <node name="subscriber_node" pkg="mastering_ros_demo_pkg" type="demo_topic_subscriber" output="screen"/>
</launch>

Let's discuss what is in the code. The <launch></launch> tags are the root element in a launch file. All definitions will be inside these tags.

The <node> tag specifies the desired node to launch:

  <node name="publisher_node" pkg="mastering_ros_demo_pkg" type="demo_topic_publisher" output="screen"/>

The name tag inside <node> indicates the name of the node, pkg is the name of the package, and type is the name of executable we are going to launch.

After creating the launch file demo_topic.launch, we can launch it using the following command:

$ roslaunch mastering_ros_demo_pkg demo_topic.launch

Here is the output we get if the launch is successful:

Figure 17 : Terminal messages while launching the demo_topic.launch file

We can check the list of nodes using:

$ rosnode list

We can also view the log messages and debug the nodes using a GUI tool called rqt_console:

$ rqt_console

We can see the logs generated by two nodes in this tool as shown here:

Figure 18 : Logging using the rqt_console tool

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 areas where we use these methods:

Most of the 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 are an important constraint in all software especially open source application. 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 at https://github.com/qboticslabs/mastering_ros_demo_pkg

After uploading the code in GitHub, we can see what the procedures are to release our current package to ROS.

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 before releasing the package are as follows:

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/qboticslabs/mastering_ros_demo_pkg.

Create an empty repository in Git for the release package. This repository is called the release repository. We have created a package called demo_pkg-release. This package is at https://github.com/qboticslabs/demo_pkg-release.

After meeting these prerequisites, we can start to create the release of the package. Navigate to the mastering_ros_demo_pkg local repository where we push our package code to Git. Open a terminal inside this local repository and execute the following command:

$ catkin_generate_changelog

The purpose of this command is, it will create a CHANGELOG.rst file inside the local repository. After executing this command it will show this option:

Continue without -all option [y/N]. Give y here

It will create a CHANGELOG.rst in the local repository.

After the creation of the log file, we can update the Git repository by committing the changes:

$ git add -A
$ git commit -m 'Updated CHANGELOG.rst'
$ git push -u origin master

$ catkin_prepare_release

Releasing our package

The following command starts the release. The syntax of this command is as follows:

bloom-release --rosdistro <ros_distro> --track <ros_distro> repository_name
$ bloom-release --rosdistro indigo --track indigo mastering_ros_demo_pkg

When this command is executed, it will go to the rosdistro (https://github.com/ros/rosdistro) package repository to get the package details. The rosdistro package in ROS contains an index file, which contains a list of all the packages in ROS. Currently, there is no index for our package because this is our first release, but we can add our package details to this index file called distributions.yaml.

The following message will be displayed when there is no reference of the package in rosdistro:

Figure 19 : Terminal messages when there is no reference of the package in rosdistro

We should give the release repository in the terminal that is marked in red in the preceding screenshot. In this case, the URL was https://github.com/qboticslabs/demo_pkg-release.

Figure 20 : Inputting the release repository URL

In the upcoming steps, the wizard will ask for the repository name, upstream, URL, and so on. We can give these options and finally, a pull request to rosdistro will be submitted, which is shown in the following screenshot:

Figure 21 : Sending a pull request to rosdistro

The pull request for this package can be viewed at https://github.com/ros/rosdistro/pull/9662.

If it is accepted, it will merge to indigo/distribution.yaml, which contains the index of all packages in ROS.

The following screenshot displays the package as an index in indigo/distribution.yaml:

Figure 22 : The distribution.yaml file of ROS Indigo

After this step, we can confirm that the package is released and officially added to the ROS index.

Creating a Wiki page for your ROS package

ROS wiki allows users to create their own home pages to showcase their package, robot, or sensors. The official wiki page of ROS is wiki.ros.org. Now, we are going to create a wiki page for our package.

Tip

Downloading the example code

You can download the example code files from your account at http://www.packtpub.com for all the Packt Publishing books you have purchased. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you. You can also download chapter codes from https://github.com/qboticslabs/mastering_ros.git.

The first step is to register in wiki using your mail address. Go to wiki.ros.org, and click on the login button as shown in the screenshot:

Figure 23 : Locating the login option from ROS wiki

After clicking on Login, you can register or directly login with your details if you are already registered. After login, press the user name link on the right side of the wiki page as shown in the screenshot:

Figure 24 : Locating the user account button from ROS wiki

After clicking on this link, you will get a chance to create a home page for your package; you will get a text editor with GUI to enter data into. The following screenshot shows you the page we created for this demo package:

Figure 25 : Creating a new wiki page

The wiki page of this package can be viewed at http://wiki.ros.org/qboticslabs.