General Concepts

The basic building blocks of ROS software framework are Packages.
ROS works as a groub of programs every one is called Node.
Every Package contains a collection of Nodes.
ROS starts with the ROS Master node. The Master node allows all other ROS pieces of software (Nodes) to find and talk to each other.
Every Node communicate with each others through Messages.

Packages: The ROS packages are the most basic unit of the ROS software.
It contains the ROS runtime process (nodes), libraries, configuration files, and so on, which are organized together as a single unit.
Packages are the atomic build item and release item in the ROS software.

Package manifest: The package manifest file is inside a package that contains information about the package, author, license, dependencies, compilation flags, and so on. The package.xml file inside the ROS package is the manifest file of that package.

Structure of a typical ROS package:
package.xml: This is the package manifest file of this package.
CMakeLists.txt: This is the CMake build file of this package.
msg: This folder contains custom message definitions.
srv: This folder contains the service definitions.
include/package_name: This folder consists of headers and libraries that we need to use inside the package.
scripts: This folder keeps executable Python scripts.
src: This folder stores the C++ source codes.

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:

$catkin_create_pkg : This command is used to create a new package 

$rospack : This command is used to get information about the package in the file system 

$catkin_make : This command is used to build the packages in the workspace 

$rosdep : This command will install the system dependencies required for this package 

Messages (.msg): The ROS messages are a type of information that is sent from one ROS process to the other.
We can define a custom message inside the msg folder inside a package(my_package/msg/MyMessageType.msg).
The extension of the message file is .msg .
Nodes communicate with each other using messages.
Messages are simply data structure containing the typed field, which can hold a set of data and that can be sent to another node.
There are standard primitive types (integer, floating point, Boolean, and so on) and these are supported by ROS messages.
ROS has inbuilt tools called rosmsg to get information about ROS messages.
Here are some parameters used along with rosmsg :

$rosmsg show [message] : This shows the message description

$rosmsg list : This lists all messages 

$rosmsg package [package_name] : This lists messages in a package 

$rosmsg packages [package_1] [package_2] : This lists packages that contain messages. 

Services (.srv): The ROS service is a kind of request/reply interaction between processes(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.
The reply and request data types can be defined inside the srv folder inside the package (my_package/srv/MyServiceType.srv).
In some robot applications, a publish/subscribe model will not be enough if it needs a request/response interaction.
The publish/subscribe model is a kind of one-way transport system and when we work with a distributed system, we might need a request/response kind of interaction. ROS Services are used in these case.
We can define a service definition that contains two parts; one is for requests and the other is for responses. Using ROS Services, we can write a server node and client node.
The server node provides the service under a name, and when the client node sends a request message to this server, it will respond and send the result to the client. The client might need to wait until the server responds.
The ROS service interaction is like a remote procedure call.

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

$rosservice call /service args : This tool will call the service using the given arguments

$rosservice find service_type : This command will find services in the given service type 

$rosservice info /services : This will print information about the given service 

$rosservice list : This command will list the active services running on the system 

$rosservice type /service : This command will print the service type of a given service.

$rosservice uri /service : This tool will print the service ROSRPC URI. 

Topics: Each message in ROS is transported using named buses called topics.
When a node sends a message through a topic, then we can say the node is publishing a topic.
When a node receives a message through a topic, then we can say that the node is subscribing to a topic.
The publishing node and subscribing node are not aware of each other's existence. We can even subscribe a topic that might not have any publisher.
In short, the production of information and consumption of it are decoupled.
Each topic has a unique name, and any node can access this topic and send data through it as long as they have the right message type.

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

$rostopic bw /topic : This command will display the bandwidth used by the given topic.

$rostopic echo /topic : This command will print the content of the given topic. 

$rostopic find /message_type : This command will find topics using the given message type. 

$rostopic hz /topic : This command will display the publishing rate of the given topic. 

$rostopic list : This command will list all active topics in the ROS system.

$rostopic pub /topic message_type args : This command can be used to publish a value to a topic with a message type. 

$rostopic type /topic : This will display the message type of the given topic . 

Next skip_next