ROS Terminologies 02
Publisher (and Publish)
A “publisher” is a ROS node that keeps publishing a message into a topic. If we redefine topic we can say that a topic is a channel that acts as a pipe, where other nodes can publish or read information. Similarly, the term “publish” means transmitting relative messages corresponding to the topic. The publisher node registers its own information and topic with the master and sends a message to subscriber nodes that are interested in the same topic.
Subscriber (and Subscribe)
A “subscriber” is a ROS node that reads information from a topic. Similarly, the term “subscribe” means receiving relative messages corresponding to the topic. Like in the case of publisher node, the subscriber node registers its own information and topic with the master, and receives publisher information from the master for relative topic. Based on received publisher information, the subscriber node directly requests connection to the publisher node and receives messages from the connected publisher node.
Service
Though most of the work can be done using topics. However, the topic communication is an asynchronous communication based on publisher and subscriber, where topic continuously transmits and receives stream of messages once connected. It is useful for sensors that must periodically transmit data. However, sometimes we need synchronous communication based on request and response mechanism.
For this, ROS provides a message synchronization method called ‘service’.
The communication process includes service server and service client. We can define it as “the service is a synchronous bidirectional communication between the service client that requests a service regrading a particular task and the service server that responds to the requests”. When ROS program calls a service, it cannot continue until it receives a response from the service.
Service Server
The “service server” is a server in the service message communication that receives a “request” as an input and transmits a “response” as an output. Both request and response are in the form of messages.
Service Client
The “service client” is a client in the service message communication that requests service to the server and receives a response as an input. As already said, both request and response are in the form of messages. Later, we will see the structure of service messages.
Action
The “action” is another message communication method used for bidirectional communication. Unlike services (which are synchronous), actiions are asynchronous. It’s like launching a new thread. When the ROS program calls an action, the program can perform other tasks while the action is being performed in another thread.
Action is used where it takes longer time to respond after receiving a request and there are also intermediate responses until the result is returned.
The structure of action file is similar to that of service. However, it also adds a feedback data section for intermediate responses. The “request” and “response” in service message are replaced with “goal” and “result” in action message. We will see the structure of action message in detail later.
Action Server
The “action server” receives goal from the client and responds with “status”, “feedback” and “result”. Once the server receives “goal” from the client, it performs predefined task.
Action Client
The “action client” transmits the goal to the server and receives result or feedback data as inputs from the action server. The client can also send “cancel” to abort the process.
Parameter
The term “parameter” in ROS refers to parameters used in the node. Default values are set in the parameter and can be read or written if required. The configured values can also be modified in real-time.
Parameter Server
The parameters (in the package), are registered with the parameter server which is loaded in the master.
Catkin
The term “catkin” refers to the build system of ROS. It uses CMake to build; and the build environment is described in the “CMakeLists.txt” file in the package folder. The Catkin build system makes it easy to use ROS-related builds, package management, and dependencies among packages. Previously, “rosbuild” was used as a build system of ROS, however now it is recommended to use catkin instead of rosbuild.
roscore
“roscore” is the command that runs ROS master. At one time, only one roscore should be running in the network, except for special case that supports multiple roscore. As the master runs (and the user has not set the environment variables), the current local IP address is used as the URI address and port number 11311 is used which is a default port number for the master.
rosrun
“rosrun” is the basic execution command of ROS. It is used to run a single node in the package.
rouslaunch
Unlike rosrun (which execute only one node), “roslaunch” executes multiple nodes. It is a specialized ROS node execution command with additional functions such as changing parameters or node names, configuring namespace of nodes, setting ROS_ ROOT and ROS_PACKAGE_PATH, and changing environment variables. “roslaunch” uses the ‘*.launch’ file to define which nodes to be executed. The “.launch” file is based on XML (Extensible Markup Language) and gives a variety of options in the form of XML tags.
bag (or rosbag)
The data from the ROS messages can be recorded in “bag” file format. Extension “.bag” is used for this purpose. In ROS, bag can be used to record messages and play them back when it is required to reproduce the same environment when messages are recorded. For example, you have a very expensive real robot and it performs an experiment using a sensor. The sensor values can be stored in the message form using the bag. Next time, when you need to perform the same experiment, you can reproduce the same environment by playing the saved bag file. You do not need to physically use the same sensor again and again. “Record” and “play” functions of “rosbag” are especially useful while developing an algorithm with frequent program modifications.