Coordinate the relationship between the cartographer and ROS

 Reference defined: backpack_3d.lua
    Local slam the Map Frame is a process of origin. But now cartographer support Incremental mapping. global map is a map of the entire origin, local map is built every map origin.
    map_frame = "map": cartographer global coordinate system used, it is best to keep the default, otherwise the ROS Rviz do not know other definitions, making it impossible to visualize map building process.
    tracking_frame = "base_link": the robot center coordinate system, other sensors are based on the insertion of data is based, it is the core of the entire coordinate system SLAM; cartographer_ros which has a tf_bridge class is designed to query the other coordinate systems conversion relationship of this coordinate system.
    = published_frame "base_link"
    odom_frame = "Odom": published_frame odom_frame used in conjunction with, if the parameter provide_odom_frame = true then the final visualization, published messages converted from published_frame-> odom_frame-> map_frame, i.e. without the calculated internal cartographer FIG local loop detection coordinate conversion relationship between global coordinates to FIG optimized and released out. When the two-dimensional example of a backpack running after net around the map coordinates have been beating odom is this stuff.

1.3 ROS coordinate specification

    ROS coordinates specification: REP (naming convention defines the coordinate system and the respective meanings)

    base_link (机器人底盘坐标系)
        The coordinate frame called base_link is rigidly attached to the mobile robot base. The base_link can be attached to the base in any arbitrary position or orientation; for every hardware platform there will be a different place on the base that provides an obvious point of reference.

    base_laser
        laser radar coordinate system, related to the installation spot of the laser radar, which is fixed tf base_link.

    odom (用于短期局部参考)
        The coordinate frame called odom is a world-fixed frame. The pose of a mobile platform in the odom frame can drift over time, without any bounds. This drift makes the odom frame useless as a long-term global reference. However, the pose of a robot in the odom frame is guaranteed to be continuous, meaning that the pose of a mobile platform in the odom frame always evolves in a smooth way, without discrete jumps.
        In a typical setup the odom frame is computed based on an odometry source, such as wheel odometry, visual odometry or an inertial measurement unit.
        The odom frame is useful as an accurate, short-term local reference, but drift makes it a poor frame for long-term reference.

    map (用于长期全局参考)
        The coordinate frame called map is a world-fixed frame, with its Z-axis pointing upwards. The pose of a mobile platform, relative to the map frame, should not significantly drift over time. The map frame is not continuous, meaning the pose of a mobile platform in the map frame can change in discrete jumps at any time.
        In a typical setup, a localization component constantly re-computes the robot pose in the map frame based on sensor observations, therefore eliminating drift, but causing discrete jumps when new sensor information arrives.
        The map frame is useful as a long-term global reference, but discrete jumps in position estimators make it a poor reference frame for local sensing and acting.

    earth (用于多个机器人的场景)
        The coordinate frame called earth is the origin of ECEF.
        This frame is designed to allow the interaction of multiple robots in different map frames. If the application only needs one map the earth coordinate frame is not expected to be present. In the case of running with multiple maps simultaneously the map and odom and base_link frames will need to be customized for each robot. If running multiple robots and bridging data between them, the transform frame_ids can remain standard on each robot if the other robots’ frame_ids are rewritten.
        If the map frame is globally referenced the publisher from earth to map can be a static transform publisher. Otherwise the earth to map transform will usually need to be computed by taking the estimate of the current global position and subtracting the current estimated pose in the map to get the estimated pose of the origin of the map.
        In case the map frame’s absolute positon is unknown at the time of startup, it can remain detached until such time that the global position estimation can be adaquately evaluated. This will operate in the same way that a robot can operate in the odom frame before localization in the map frame is initialized.

    The relationship between the coordinate system of
        each coordinate system is only one parent coordinate system, the coordinate system may have multiple sub-
        tree structure between the coordinate system as follows:
        Earth -> Map -> Odom -> base_link
        with only one robot environment, in the starting position, map coordinate system with odom coincide. With the passage of time is not coincident, and deviation is cumulative error odometer. That map-> odom of tf how to get? Some correction is in cooperation sensor calibration package such as gmapping will give a location estimate (localization), which can be map-> base_link the tf, it is estimated that the deviation position and the position of the odometer that is odom and map coordinate system deviation. So, if you calculate the odom no errors, then the map-> odom of tf is 0.

    Axis Orientation (坐标轴方向)
        In relation to a body the standard is:
            x forward
            y left
            z up
           

Guess you like

Origin www.cnblogs.com/long5683/p/11562823.html