ROS Learning Series and ros Learning Series

ROS Learning Series and ros Learning Series

We have already discussed how to use URDF to build a robot car and display it in the simulation environment of Rviz, but the car is still. The following describes how to make it work in Rviz and clarify the relationship between URDF, TF and odom.

1. Relationship between base_link, odom, fixed_frame, target_frame, and map in ROS

Base_link is usually defined in the urdf file, which represents the backbone of the robot. All other frames are defined and pasted together with base_link. They move relative to map, so that the robot moves is to publish geometry_msgs: TransformStamped message to the tf to notify the tf Conversion Relationship Between ros base_linke and map. Let's take a look at the definitions of these concepts in ros:

Map

Map is a fixed frame in the virtual world. Its Z axis points to the upper side, that is, the sky. The posture of a mobile robot at a time point should not obviously Drift Relative to map. If a map is discontinuous and stable, it means that the robot's position will change at any point in time.

Generally, devices such as the laser Position meter continuously calculate the location of the map, thus causing instability. This also makes it not a good reference frame.

Odom

Odom is a good fixed-world reference frame. The robot's posture is often variable over time compared to odom, so it is not a good global reference system in the long term. However, at a certain point in time, the robot's position remains unchanged.

TypicalOdomFrame is calculated by motion sources, such as wheel motion and visual offset.

OdomThe accuracy of frame makes it very useful in the local frame. But it is not suitable for cooperation.

Base_link

Base_linkThe frame is closely attached to any position and angle on the base of the mobile robot.

Frames relationships

Frames are organized in a tree structure. Therefore, each frame has only one parent node and any number of child nodes. The relationship between the above frames:

Map-->Odom-->Base_link

Frame Authorities

OdomToBase_linkCoordinates are calculated from the motion source for broadcast.

MapToBase_linkThe coordinates are calculated by the positioning module, but the positioning module is not released.MapToBase_linkOn the contrary, it first acceptsOdomToBase_link Conversion, And then calculate and broadcastMapToOdom.

The world identified in fixed_frameRViz is fixed_frame.
Target_frame

In Rviz, the visual tracking frame is target_frame.

2. How does RViz dynamically determine the coordinate transformation between frames?

Let's take a look at the launch file for starting RViz, which must contain the parameters that serve RViz and node

<launch>    <arg name="model" />    <arg name="gui" default="False" />    <param name="robot_description" textfile="$(arg model)" />    <param name="use_gui" value="$(arg gui)"/>    <node name="joint_state_publisher" pkg="joint_state_publisher" type="joint_state_publisher" />    <node name="robot_state_publisher" pkg="robot_state_publisher" type="state_publisher" />    <node name="rviz" pkg="rviz" type="rviz" args="-d $(find sp1s)/urdf.rviz" required="true" /></launch>

The "robot_description" parameter defines the URL of the urdf file, which is used by the robot_state_publisher node. The node parses the urdf file and releases the status of each frame to tf. Therefore, in rviz, the tf conversion between frames (LINKS) is displayed as OK. Otherwise, the system displays warning.

The "joint_state_publisher" Node obtains the rotate link defined in urdf and releases the coordinate conversion to tf. otherwise, the system displays the warning. note: "joint_state_publisher" is written in python. It only supports ascii encoding and does not support Unicode. If RViz is found, the following error is reported:

"No transform from [front_left] to [base_link]"

This is because the urdf file is Unicode encoded.

3. The role of the geometry_msgs/TransformStamped message and the geometry_msgs/TransformStamped mechanism notify the tf Conversion Relationship Between the two frames of ROS. When the relationship between two frames changes frequently, such as wheel movement and arm joint movement, you need to write a node for real-time release. View the message structure:

<span style="font-size:18px;">rosmsg show -r geometry_msgs/TransformStamped# This expresses a transform from coordinate frame header.frame_id# to the coordinate frame child_frame_id## This message is mostly used by the # <a href="http://www.ros.org/wiki/tf">tf</a> package. # See its documentation for more information.Header headerstring child_frame_id # the frame id of the child frameTransform <strong><span style="color:#FF0000;">transform</span></strong></span>

In Transform, transform is the tf conversion relationship we are concerned about, child_frame_id is "base_link", header. frame_id is 'ocuse'. View geometry_msgs/transform:

rosmsg show -r geometry_msgs/Transform# This represents the transform between two coordinate frames in free space.Vector3 <strong><span style="color:#FF0000;">translation</span></strong>Quaternion rotationrosmsg show -r Vector3[geometry_msgs/Vector3]:# This represents a vector in free space. float64 xfloat64 yfloat64 z 

Here, x, y, and z define the tf Conversion Relationship between two frames.

4. in RViz, how to define the tf coordinate transformation between the base_link and odom requires a mobile robot to send a geometry_msgs/TransformStamped message to the tf to notify the tf Conversion Relationship Between ros base_linke and map, that is to say, it indicates that the base_link of the ROS motion is offset from the unchanged odom position. The odom frame cannot be defined in the urdf file. It is a virtual object. We only need RViz to know that fixed_frame is odom. Therefore, the virtual odom is defined in the urdf. rviz file as follows:

<span style="font-size:18px;">Global Options:    Background Color: 48; 48; 48    Fixed Frame: <strong><span style="color:#FF0000;">/odom</span></strong>    Target Frame: <Fixed Frame>    Frame Rate: 30</span>

If you start RViz now to observe the Robot:

<span style="font-size:18px;">roslaunch sp1s display.launch model:=urdf/sp1s.urdf </span>

An error warning is returned, and the complete robot cannot be displayed in RViz:

"No transform from [odom] to [base_link]"

This error is easy to understand. There is no place to define the tf relationship between odom and base_link. They are continuously changing. Of course we cannot write a fixed offset to define tf transform anywhere.

However, we can write a node to continuously send geometry_msgs/TransformStamped messages. The sent object is tf. ROS officially has an example of how to release the transformation from odom to base_link. The Code instance is directly copied and compiled locally. In this example, messages are sent continuously to the odom topic to change the displacement between odom and base_link. the trajectory of the displacement is a circle. This node is named odom_publisher. It actually does two things:

1. Send the geometry_msgs/TransformStamped message to tf to make the robot move.

2. Send nav_msgs/Odometry navigation messages to the odom topic to report the angular velocity, line speed, and cruise angle. This part of the code is not required in this article.

Like "joint_state_publisher" node, "odom_publisher" needs to be started before RViz starts and add its startup Item. The modified dispaly. launch file:

<launch><arg name="model" /><arg name="gui" default="False" /><param name="robot_description" textfile="$(arg model)" /><param name="use_gui" value="$(arg gui)"/>        <strong><span style="color:#FF0000;"><node name="odom_publisher" pkg="sp1s" type="odom_publisher" /></span></strong>        <node name="joint_state_publisher" pkg="joint_state_publisher" type="joint_state_publisher" /><node name="robot_state_publisher" pkg="robot_state_publisher" type="state_publisher" /><node name="rviz" pkg="rviz" type="rviz"  args="-d  $(find sp1s)/urdf.rviz" required="true"/></launch></span>

Open RViz again:

roslaunch sp1s display.launch model:=urdf/sp1s.urdf 

This time we can see that the robot is doing a Regular circular motion in the map space! RViz receives the coordinate conversion content sent by odom_publisher to tf.

4. Observe the moving track in RViz

The nav_msgs/Odometry navigation message is also published to the odom topic in "odom_publisher" to display the motion track in RViz. Click 'add' in RViz, select Odometry, and set the topic of dispaly to "odom" to see The Changing Motion Track. This is because nav_msgs/Odometry contains the line speed, angular velocity, and cruise angle, so RViz can be displayed.

5. odom frame and odom topic

These two completely different things are easy to confuse. One is a reference frame on a map, and the other is used by a topic to receive navigation input. The same name is a coincidence!