Message (message) is a form of data used for data exchange between nodes. The aforementioned topics, services, and actions all use messages. The message can be a simple data structure, such as integer, floating point, and boolean, or a simple data structure in which the message contains the message like "geometry_msgs/PoseStamped" 31, or it can be Message array structure like "float32[] ranges" or "Point32[10] points". In addition, the commonly used headers (header, std_msgs/Header) in ROS can also be used as messages. These messages consist of two types: field type (fieldtype) and field name (fieldname).
The field type should be filled with ROS data type, as shown in the following table. The field name should be filled with the name of the indicated data. For example, you can fill in the following two lines. This is just the simplest form of message. If you want to add more messages, you can use the field type as an array as shown in the following table, and often use the form that the message contains the message.
As mentioned earlier, the commonly used headers (header, std_msgs/Header) in ROS can be used as messages. More specifically, as described in the Header.msg file of std_msgs32, the serial number, timestamp, and frame ID are recorded, and they are used to record the message count and time calculation in the message.
The actual usage of the message in the program is as follows. In the example of the teleop_turtle_key node of the turtlesim function package executed in the ROS operation test, the rotation speed (meter/sec) and the rotation speed (radian/sec) of the turtlesim node are sent to turtlesim_node node. The turtle robot uses the received speed value to move on the screen. The message used at this time is the Twist33 message in geometry_msgs, which is in the following format.
It declares linear and angular in the form of Vector3 messages. It is a form in which the message contains a message, among which the Vector3 message is one of geometry_msgs34. This Vector335 has the following form.
In other words, the topics posted from the teleop_turtle_key node are linear.x, linear.y, linear.z, angular.x, angular.y, and angular.z. All of these are in float64 format, which is one of the basic types of ROS described above. Using it, the keyboard's arrows transmit messages with translation speed (meter/sec) and rotation speed (radian/sec) to drive TurtleBot.
The message-based topics, services, and actions described in the previous blog post all use messages. These messages are similar in form and concept, but are divided into three categories according to their usage. This will be discussed in more detail next.
1.msg file
The msg file is a message file used for topics, and the extension is *.msg. For example, the Twist36 message in the aforementioned geometry_msgs is representative. This kind of msg file contains only one field type and one field name.
2.srv file
The srv file is a message file used by the service, with the extension *.srv. For example, the SetCamera Info37 message of sensor_msgs is a typical srv file. The main difference with the msg file is that three hyphens (---) are used as separators. The upper message is a service request message, and the lower message is a service response message.
3.action file
The action message 38 file is the message file used in action 39, and it uses the *.action extension. Unlike msg and srv, it is not a relatively common message file, so there is no typical official message file, but you can use it like the following example. The main difference with msg and srv files is that three hyphens (---) are used as separators in two places. The first part is the goal message, the second part is the result message, and the third part is the feedback message. The biggest difference is the feedback information from the action file. The goal message and result message of the action file have the same roles as the request message and response message of the above-mentioned srv file, but the feedback message of the action file is used to transmit the midway value during the execution of the specified process. In the following example, when the start_pose of the robot and the position and posture of the target point goal_pose are transmitted as the requested value, the robot moves to the predetermined target position and will send the final position and posture of the result_pose. In addition, the percentage_complete message is used to periodically send the percentage of the process that has reached the target location.
