9. Cartographer mapping algorithm

Cartographer: https://google-cartographer.readthedocs.io/en/latest/

Cartographer ROS: https://google-cartographer-ros.readthedocs.io/en/latest/

map_server: https://wiki.ros.org/map_server

9.1. Introduction

Cartographer is a 2D and 3D SLAM (simultaneous localization and mapping) library supported by Google's open source ROS system. A graph-building algorithm based on graph optimization (multi-threaded backend optimization, problem optimization of ceiling construction). Data from multiple sensors (such as LIDAR, IMU, and cameras) can be combined to simultaneously calculate the sensor's position and map the environment around the sensor.

The source code of cartographer mainly includes three parts: cartographer, cartographer_ros and ceres-solver (back-end optimization).

image-20220224150737767

image-20220224150754195

Cartographer uses the mainstream SLAM framework, which is a three-stage structure of feature extraction, closed-loop detection, and back-end optimization. A certain number of LaserScans form a submap, and a series of submaps constitute the global map. The cumulative error in the short-term process of using LaserScan to construct a submap is not large, but the long-term process of using a submap to construct a global map will have a large cumulative error. Therefore, closed-loop detection is needed to correct the positions of these submaps. The basic unit of closed-loop detection is submap, closed-loop detection uses the scan_match strategy. The focus of cartographer is the creation of submap subgraphs that integrate multi-sensor data (odometry, IMU, LaserScan, etc.) and the implementation of the scan_match strategy for closed-loop detection.

The cartographer_ros package runs under ROS and can accept various sensor data in the form of ROS messages. After processing, it can be published in the form of messages to facilitate debugging and visualization.

9.2. Use

Note: When building a map, the slower the speed, the better the effect (note that the rotation speed should be slower). If the speed is too fast, the effect will be poor.

According to different models, you only need to set the purchased model in [.bashrc], X1 (normal four-wheel drive) X3 (Mailun) Take X3 as an example

Open the [.bashrc] file

Find the [ROBOT_TYPE] parameters and modify the corresponding car model

To replace the configuration file, copy the launch file and lua file required by cartographer to the specified directory. It is configured before leaving the factory.

9.2.1. Start

Start the command (robot side). For the convenience of operation, this section takes [mono + laser + yahboomcar] as an example.

Mapping command (robot side)

<PI5 needs to open another terminal to enter the same docker container

image-20240408144126098

Turn on the visual interface (virtual machine side)

image-20220224152311916

The gap at the back of the robot is due to the obstruction caused by the installation position of the display screen, so a certain range of radar data is blocked. The shielding range can be adjusted, or it can not be blocked according to the actual situation. For specific operations, see [01. Radar Basic Course].

9.2.2. Controlling the robot

Make the robot cover the area to be mapped and the map should be as closed as possible.

There may be some scattered points during the mapping process. If the mapping environment is well closed, relatively regular, and the movement is slow, the scattering phenomenon will be much smaller.

9.2.3. Map saving

The map will be saved to the ~/yahboomcar_ws/src/yahboomcar_nav/maps/ folder, a pgm image and a yaml file.

map.yaml

Parameter analysis:

9.2.4. Node View

image-20220224150737767

9.2.5. View tf tree

image-20220224150737767

9.3. Configuration parameters

lua file

ParametersDescription
map_framemap coordinate system
tracking_frameConvert all sensor data to this coordinate system
published_frameThe coordinate system pointed to by map
odom_frameDo you provide odom's tf? If it is true, the tf tree is map->odom->footprint; if it is false, the tf tree is map->footprint
provide_odom_frameIf true, the local, non-loop-closed, continuous pose will be published as odom_frame in map_frame?
publish_frame_projected_to_2dIf enabled, published poses will be restricted to pure 2D poses (no roll, pitch or z-offset)
use_odometryWhether to use odometer, if required, you must have odom tf
use_nav_satWhether to use gps
use_landmarksWhether to use landmarks
num_laser_scansWhether to use single-line laser data
num_multi_echo_laser_scansWhether to use multi_echo_laser_scans data
num_subdivisions_per_laser_scan1 frame of data is divided into several times for processing, usually 1
num_point_cloudsWhether to use point cloud data
lookup_transform_timeout_secTimeout when looking up tf
submap_publish_period_secTime interval for publishing submap (seconds)
pose_publish_period_secThe time interval for publishing pose, when the value is 5e-3, it is 200HZ
trajectory_publish_period_secThe time interval for publishing trajectory markers (trajectory nodes), the value is 30e-3 is 30ms
rangefinder_sampling_ratioFixed sampling frequency for lidar messages
odometry_sampling_ratioFixed sampling frequency of odometry messages
fixed_frame_pose_sampling_ratioFixed sampling frequency of fixed coordinate system messages
imu_sampling_ratioFixed sampling frequency of IMU messages
landmarks_sampling_ratioFixed sampling frequency of landmark messages