table of Contents
4 ROS communication architecture
4.1.1 Start the master: roscore
4.1.2 启动 node: rosrun, roslaunch
4 ROS communication architecture
Node:
In the ROS world, the smallest unit of process is a node. There can be multiple executable files in a software package. After the executable file is run, it becomes a process. This process is called a node in ROS. From Cheng
From a procedural point of view, node is an executable file (usually an executable file generated by C ++ compilation, a Python script)
Is executed and loaded into memory; from a functional point of view, usually a single individual responsible for a node robot
Features. Since the function module of the robot is very complicated, we often do not concentrate all functions on a node, and
Will use a distributed approach. For example, there is a node to control the movement of the chassis wheels, a node to drive the camera to obtain images, a node to drive the lidar, and a node to plan the path based on the sensor information ...
Master:
The master is equivalent to the management center in the entire network communication architecture, managing each node. The node is first registered at the master, and then the master will include the node in the entire ROS program. The communication between nodes is also first "pulled" by the master, so that point-to-point communication can be carried out in pairs. When the ROS program starts, the first step is to start the master first, and the node manager processes the nodes and starts them in turn.
4.1 Start the master and node
4.1.1 Start the master: roscore
When starting ROS, first enter the command roscore to start the master:
$ roscore
At this time, the ROS master is started, and rosout and parameter server are also started.
A node of the log output, its role is to inform the user of the current system status, including the output system error, warning, etc.
Etc., and log in the log file; parameter server is the parameter server, it is not a node
It is a server that stores parameter configurations. Every time we run the ROS node, we need to start the master, so that the node can be started and registered.
4.1.2 启动 node: rosrun, roslaunch
You can use rosrun, roslaunch
The detailed usage of the rosrun command is as follows:
$ rosrun [--prefix cmd] [--debug] pkg_name node_name [ARGS]
rosrun will look for the executable program named EXECUTABLE under PACKAGE and pass in the optional parameter ARGS.
roslaunch command:
roslaunch pkg_name file_name.launch
The master and multiple nodes can be started at once. The roslaunch command will automatically detect whether the roscore of the system is running, that is, to confirm whether the node manager is running, if the master is not started, then roslaunch will start the master first Then follow the rules of launch.
4.1.3 rosnode command
- rosnode list lists the currently running node information
- rosnode info node_name shows detailed information of node
- rosnode kill node_name end a node
- rosnode ping test connection node
- rosnode machine lists nodes running on a specific machine or list machine
- rosnode cleanup clears registration information of unreachable nodes
rosnode help to see the usage of the rosnode command.
4.2 ROS communication method
The communication method of ROS is the core concept of ROS. There are four kinds of communication methods of ROS:
- Topic
- Service
- Parameter Service
- Actionlib Action library
4.2.1 Topic
Among the communication methods in ROS, topic is a commonly used one. For real-time, periodic messages, using topic to transmit is the best choice. Topic is a kind of point-to-point one-way communication method, where "point" refers to node, which means that information can be transferred between nodes through topic. The topic has to go through the initialization process of the following steps: First, both the publisher node and the subscriber node must register with the node manager, then the publisher will publish the topic, and the subscriber will subscribe to the topic under the command of the master, thereby establishing Communication. Note that the entire process is one-way. Subscriber will process the message when it receives it. Generally, this process is called callback. The so-called callback is to define a processing function in advance (written in the code), when there is a message will trigger the processing function, the function will process the message.
Topic communication is a one-way asynchronous communication method.
The schematic diagram of its structure is shown below;
4.2.1.1 rostopic command:
- rostopic list lists all current topics
- rostopic info topic_name displays the attribute information of a topic
- rostopic echo topic_name displays the content of a topic
- rostopic pub topic_name ... Publish content to a topic
- rostopic bw topic_name View the bandwidth of a topic
- rostopic hz topic_name View the frequency of a topic
- rostopic find topic_type find a type of topic
- rostopic type topic_name View the type of a topic (msg)
4.2.1.2 msg file
Message is the data type of topic content, also known as the format standard of topic. Defined in the file with the suffix .msg.
The basic msg data types include bool, int8, int16, int32, int64 (and uint), float, float64, string, time, duration, header, variable-length array array [], and fixed-length array array [C].
We use a specific msg to understand, such as msg sensor_msg / image, the location is stored in sensor_msgs / msg / image.msg, its structure is as follows:
std_msg/Header header
uint32 seq
time stamp
string frame_id
uint32 height
uint32 width
string encoding
uint8 is_bigendian
uint32 step
uint8 [] date
4.2.1.3 rosmsg command:
- rosmsg list lists all msgs on the system
- rosmsg show msg_name display the content of a msg
4.2.2 Service
Service communication is bidirectional, it can not only send messages, but also have feedback. Therefore, the service includes two parts, one is the requester (Clinet), and the other is the responder / service provider (Server). At this time, the requester (Client) will send a request, wait for the server to process, and return a reply, so that the entire service communication is completed through a mechanism similar to "request-response".
The schematic diagram of this communication method is as follows: Node B is a server (responder), which provides a service interface called / Service. We generally use the string type to specify the name of the service, similar to topic. Node A initiated a request to Node B, and received feedback after processing.
Service is a synchronous communication method. The so-called synchronization means that Node A will wait for a reply in place after issuing a request until it reaches
After Node B processes the request and completes the reply, Node A will continue to execute. Node A is in the process of waiting
Blocked communication. This communication model has no frequent messaging, no conflicts and high system resource occupation, and only performs services when accepting requests, which is simple and efficient.
4.2.2.1 topic VS service
4.2.2.2 rosservice command
- rosservice list display service list
- rosservice info Print service information
- rosservice type
- rosservice uri print service ROSRPC uri
- rosservice find Find service by service type
- rosservice call uses the provided args to call the service
- rosservice args print service parameters
4.2.2.3 srv file
The srv file is used to describe the service (service data type, the data format of the service communication is defined in * .srv. It declares a service, including the request (request) and response (reply) two parts.
The format declaration is as follows: Examples:
msgs_demo/srv/DetectHuman.srv
bool start_detect
---
my_pkg / HumanPose [] pose_data
msgs_demo / msg / HumanPose.msg
std_msgs/Header header
string uuid
int32 number_of_joints
my_pkg/JointPose[]joint_data
msgs_demo/msg/JointPose.msg
string joint_name
geometry_msgs/Pose pose
floar32 confidence
The srv file format is very fixed, the first line is the requested format, separated by --- in the middle, and the third line is the format of the response. In this example, the request is whether to start detection, the response is an array, and each element of the array is a person's gesture (HumanPose). As for the human gesture, it is actually a msg, so srv can be nested in msg, but it cannot be nested in srv.
4.2.2.4 rossrv command
- rossrv show show service description
- rossrv list List all services
- rossrv md5 display service md5sum
- rossrv package lists the services in the package
- rossrv packages lists packages containing services
4.2.3 Parameter server
A parameter server can also be said to be a special "communication method". The special point is that the parameter server is where nodes store parameters, used to configure parameters, and share parameters globally. The parameter server uses Internet transmission and runs in the node manager to realize the entire communication process.
Parameter server, as another data transmission method in ROS, is different from topic and service, it is more static. The parameter server maintains a data dictionary, which stores various parameters and configurations.
There are three ways to maintain the parameter server:
- Command line maintenance
- Read and write in launch file
- Node source code
4.2.3.1 Command line maintenance: rosparam
- rosparam set param_key param_value Set parameters
- rosparam get param_key display parameters
- rosparam load file_name load parameters from file
- rosparam dump file_name save parameters to file
- rosparam delete delete parameter
- rosparam list lists parameter names
load&&dump文件
Load and dump files need to comply with the YAML format. Specific examples of YAML format are as follows:
name: 'Zhangsan'
age:20
gender:'M'
score{Chinese:80,Math:90}
score_history:[85,82,88,90]
4.2.3.2 Read and write in launch file
There are many tags in the launch file, and there are only two tags related to the parameter server, one is <param> and the other
It is <rosparam>.
4.2.3.3 node source code
ROS source code, that is, use the API to operate the parameter server. We will introduce the specific content after studying the following chapters.
4.2.4 Action
Actionlib is a very important library in ROS. Similar to the service communication mechanism, actionlib is also a request response mechanism.
Communication method, actionlib mainly makes up for a shortcoming of service communication, that is, when the robot performs a long-term task
At the time, if the service communication method is used, then the publisher will not receive the reply for a long time, causing the communication to receive
Hinder. When service communication can not complete the task well, actionlib can be more suitable for long-term communication.
Process, the actionlib communication process can be viewed at any time, the progress of the process can also be terminated, such a feature makes it
It has high efficiency in some special mechanisms.
4.2.4.1 The working principle of Action
The working principle of Action is client-server mode, which is also a two-way communication mode. Communicating parties in ROS
Under the Action Protocol, data exchange and communication are carried out through messages. client and server provide users with a simple
API to request the target (on the client side) or execute the target through function calls and callbacks (on the server side).
The schematic diagram of the working mode is as follows:
The client will send the target instruction and the cancel action instruction to the server, and the server can send real-time status information, result information, feedback information, etc. to the client, thus completing the part that the service cannot do.
4.2.4.2 action file
Use the action library for request response. The content format of the action should include three parts: goal, feedback, and result.
- aims
When the robot performs an action, it should have clear moving target information, including the setting of some parameters, direction, angle, speed, etc. So that the robot can complete the motion task.
- Feedback
In the course of the action, there should be real-time status information feedback to the server implementer, telling the implementer the completion status of the action, so that the implementer can make an accurate judgment to modify the command.
- result
When the movement is completed, the action server sends the result data of the exercise to the client, so that the client can get all the information of the action, for example, may include the length of the robot's movement, the final posture, and so on.
The suffix name of the Action specification file is .action, and its content format is as follows:
# Define the goal
uint32 dishwasher_id # Specify which dishwasher we want to use
---
# Define the result
uint32 total_dishes_cleaned
---
# Define a feedback message
float32 percent_complete
