First of all, we define several important coordinate systems 1. The current coordinate system of the
base_link
mobile robot 2. The
odom
odometer coordinate system is generally calculated by the odometer motion model, but different places may have different calculation methods, such as some Probably an encoder calculation.
The characteristic of this coordinate system is that there will be accumulated errors, and it cannot be used as a long-term reference coordinate system, but the advantage is that it is continuous and has no jumps
. 3. The
map map coordinate system can be used as a long-term reference coordinate system, but it is not continuous. The reason is that in the positioning module, the current position of the robot is recalculated according to the observation value of the sensor, and the jump is generated while eliminating the drift, so it is discontinuous.
Coordinate transformation required for gmapping coordinate system
1. base_laser to base_link , here if the entire robot is a rigid body, that is, the distance between the radar and the center of the robot (base_link) will not change during the movement process, then this transformation can be seen Action is a static transformation.
2. base_link to odom , this piece is provided by the odometer motion model.
Posted Coordinate Transformation
1. map to odom
The picture below is a node of a simulated gmapping graph I run. There are five coordinate systems in the graph.
1. Note that the base_laser_link is probably above and in front of the base_link, but this picture may not be very clear, but the relationship between the two is static.
2. Among them, the coordinate system of base_footprint is coincident with base_link, and footprint is the outline of the robot. But it's worth noting here why we need these two coordinate systems. Because base_footprint refers to the coordinate system on the plane, that is, if the simulation is 3D, then the base_link will obviously be in the air, but the base_footprint is a projection on a certain plane.
3. The map and odom coordinate systems in the figure are also coincident, but these two are different. . The origin of the map refers to the origin of the map, and the origin of the odom is the starting point of the robot. However, odom will be elegant, and the cumulative error is always accumulated, so you can see that the map and odom do not always overlap in the subsequent walking , so this requires an algorithm such as gmapping to correct by publishing the transformation of map to odom
The tf tree of gmapping looks like this
The coordinate system of hector It is not difficult to understand the
required coordinate transformation
from base_laser to base_link , because hector does not depend on odometry, and the input of laserscan can be used to build a map. The
published coordinate transformation
map to odom is actually here. My understanding is this, this Coordinate transformation is not necessary for mapping, but in order to unify the external interface of the mapping algorithm, such a transformation is provided (remember, the above gmapping also provides such a transformation) in the
source code in order to publish the map to odom , is first lookup the transformation of base to odom, and then the map calculated by hector to base, and the two are multiplied to get map to odom before publishing.
Hector's tf tree is as follows, where nav is an artificially created coordinate system, which can be defined by itself for practical purposes
amcl's coordinate system
The picture above on the ros wiki is already very classic
In terms of implementation, it also publishes the transformation from map to odom. In the
source code from map to base is obtained by amcl, and then tf::TransformPose is converted into transformation from odom to map.