From "bubble robot Slam" public number original column: http://mp.weixin.qq.com/s/LdbFp-Zvkr02-_25ILb16g "author blog" http://remyspot.blog.51cto.com/ This article summarizes the theory of cartographer and briefly combs the logic of its open source implementation code, aiming to play a role in providing reference for selective research related theories and implementations. 1.Cartographer theory Overview The main theory of cartographer is to eliminate the cumulative error generated by the composition process by closed-loop detection [1]. The basic unit for closed-loop detection is submap. A submap is composed of a certain number of laser scan. When a laser scan is inserted into its corresponding submap, the best position in the Submap is estimated based on submap existing laser scan and other sensor data. The creation of Submap in a short period of time is considered to be small enough to accumulate error. Over time, however, as more and more submap are created, the error accumulation between the submap becomes larger. Therefore, it is necessary to optimize the position and posture of these submap through closed-loop detection to eliminate these accumulated errors, which will transform the problem into a pose optimization problem. When a Submap build is complete, and no new laser scan is inserted into the Submap, the Submap is added to the closed-loop detection. Closed-loop detection takes into account all completed Submap created. When a new laser scan is added to the map, if the estimated posture of the laser scan is closer to the position of one of the Submap's laser scan in the map, the closed loop will be found through some sort of scan match strategy. The scan match strategy in cartographer takes a window near the estimated pose of the new map's laser scan, and in that window looks for a possible match for that laser scan, and if a good match is found, The matching closed-loop constraint is added to the position optimization problem. The focus of cartographer is the implementation of local submap creation of fusion Multisensor data and the scan match strategy for closed-loop detection. 2. Open source Logic Google's Open source code contains two parts: Cartographer[2] and cartographer_ros[3]. Cartographer is primarily responsible for processing data from radar, IMU and odometer and building maps based on these data, which is the cartographer theoryThe underlying implementation. Cartographer_ros is based on the ROS communication mechanism to obtain the sensor data and convert them into cartographer defined in the format passed to cartographer processing, at the same time the cartographer processing results are published for display or save , is based on the upper-level application of cartographer. 3.cartographer Code Structure Common: Defines the basic data structure and the interfaces used by some tools. Sensor: Defines data structures related to radar data and point clouds. Transform: Defines the data structure of the pose and its related transformations. Kalman_filter: The fusion of IMU, odometer and estimation posture based on radar data is accomplished mainly by Kalman filter, and the position and posture of the new laser scan are estimated. Mapping: Defines the interface of the upper application call interface and the local submap construction and the posture optimization based on the closed-loop detection. Mapping_2d and Mapping_3d: Different implementations of the mapping interface. 4.mapping_2d Code Logic 4.1 cartographer::mapping_2d:: globaltrajectorybuildercartographer::mapping_2d:: The Globaltrajectorybuilder class mainly implements the main interface to receive the sensor data transmitted by the upper application: (1) The addimudata is used to receive IMU data for processing the upper application. (2) Addodometerpose is used to receive mileage meter data for processing upper-level applications. (3) Addhorizontallaserfan is used to receive radar data for processing upper-layer applications. It contains important object members: (1) The object local_trajectory_builder_ of the Cartographer::mapping_2d::localtrajectorybuilder class is used to complete the construction of the local submap. (2) The object Sparse_pose_graph_ of Cartographer::mapping_2d::sparseposegraph class is used to complete the closed-loop detection and global posture optimization. In the implementation of the Addimudata and Addodometerpose functions, the corresponding sensor data received is passed to the Local_trajectory_builder_ object for processing. In the implementation of the Addhorizontallaserfan function, the newly-entered laser fan is passed to the Local_trajector_buThe Ilder_ object is used for local submap builds, and if the laser fan is successfully inserted into a submap, then the relevant information of the laser fan being inserted is passed to the Sparse_pose_graph_ object for global posture optimization based on closed-loop detection. 4.2 cartographer::mapping_2d::localtrajectorybuildercartographer::mapping_2d:: The Localtrajectorybuilder class mainly completes the construction of local submap. It provides a public function to receive processing sensor data: (1) Addimudata is used to process IMU data. (2) Addodometerpose is used to process mileage meter data. (3) Addhorizontallaserfan is used to process radar data. and contains some important private members: (1) The Scanmatch member function estimates the position of the current laser fan in submap based on Submap's existing laser fan. (2) Cartographer::kalman_filter: The object of the:P Osetracker class pose_tracker_ is used to fuse the local estimation posture, IMU data and odometer data of laser fan based on radar data, Then the better position of laser fan is estimated. The IMU data and odometer data are passed to the Pose_tracker_ for processing in the Addimudata and Addodometerpose functions. The Pose_tracker UKF constantly integrates IMU and odometer data to update the current pose, thus obtaining a better initialization value for the estimated posture of the current laser fan through the pose_tracker. Further, in the Addhorizontallaserfan function will be called Scanmatch,scanmatch function in the Submap by the local match obtained by the current laser fan's estimated posture is pose_tracker_ Used to adjust the initialization value of the laser fan. In this way, Pose_tracker_ can estimate the position and posture of the laser fan by fusing multisensor data. The 4.3 Cartographer::mapping_2d::sparseposegraphcartographer::mapping_2d::sparseposegraph class mainly completes the global Posture optimization based on closed-loop detection. It provides the receiving processing of the newly inserted lase into the SubmapThe public function of the r fan-related information: (1) Addscan closed-loop detection of the newly-entered laser fan and global optimization at the appropriate time. And some important private members: (1) Computeconstraintsforscan The new laser fan information and starts the closed loop detection of the scan match and calculates its constraints, thus adding constraints to the position optimization target. (2) Addworkitem binds the laser fan to the Computeconstraintsforscan and joins the task into the queue. (3) Handlescanqueue Schedule the tasks in the queue accordingly. (4) Sparse_pose_graph::constraintbuilder Constraint_builder_ is used to complete the scan match and constraint calculation of the laser fan. (5) Runoptimization optimization target. In the Addscan function, the laser fan-related information is bound to the Computeconstraintsforscan function and the bound task is added to the queue through the Addworkitem function. The Handlescanqueue function dispatches the tasks in the queue in turn. The Computeconstraintsforscan task is started directly when Addworkitem is first called, and the Handlescanqueue schedule is started when the task is computeconstraintsforscan for the first time. In Computeconstrainsscan, scan match and constraint calculations for closed-loop detection are done through the Constraint_builder_ object. When all constraint calculations are complete, the Runoptimization optimization target is performed. The scan match policy in 4.4 scan Matchlocaltrajectorybuilder is different from the scan match policy in sparseposegraph. The former uses scan_matching::realtimecorrelativescanmatcher, while the latter uses Scan_matching::fastcorrelativescanmatcher. The goal optimization of both is done by Scan_matching::ceresscanmatcher. 5. Summing up the principle of cartographer and the implementation of the detailed explanation is not just 2000 words can be completed. Therefore, this paper summarizes the theory of cartographer andBriefly combing the logic of cartographer source code, the purpose is to play a role, and thus conducive to selective research related theories and implementation. Cartographer's focus is on local submap creation of fusion Multisensor data and the scan match strategy for closed-loop detection. Key content corresponding to the implementation is: 1) based on UKF multi-sensor data fusion corresponding to the Cartographer/kalman_filter directory file; 2) scan match policy corresponds to Cartographer/mapping_2d/scan_ Files under the matching directory. Follow-up opportunities will also be on these key content and implementation of detailed carding.  REFERENCE:[1] Wolfgang Hess., Damon Kohler., Holgerrapp., Daniel. Andor. Real-time loop closure in 2D LiDAR slam. ICRA, 2016. [2] https://github.com/googlecartographer/cartographer[3] Https://github.com/googlecartographer/cartographer_ros "Author blog" http://remyspot.blog.51cto.com/
"Turn" "Bubble Robot Original column-cartographer" Cartographer Theory and realization analysis
