采用16线激光雷达和轮式里程计调用cartographer室内融合定位
之前有说过如何调用cartographer进行室内纯定位,但那是采用纯激光雷达进行定位的,我们知道,纯激光雷达存在长廊效果,如果室内场景特征不够明显,定位肯定是不行的。
那么要想不出现长廊效应,现有的办法就是融合定位,因为不管怎样,采用纯激光雷达都会出现长廊效应,但是融合定位可以很好的解决这个问题。
本次我将说明如何进行参数配置实现调用cartographer包进行融合定位。(本次采用的是激光雷达+轮式里程计融合定位)
首先就是revo_lds.lua配置文件,其中published_frame需要改成odom,然后tracking_frame如果不使用imu的话,则是base_link或者base_footprint,一般是base_link,如果采用imu的话则是imu_link。
下面的一系列true和false全改成false,除了use_odometry这一项是否使用里程计改成true。
主要是该文件的配置,其他的配置基本可以不改:
revo_lds.lua:
include "map_builder.lua"
include "trajectory_builder.lua"
options = {
map_builder = MAP_BUILDER,
trajectory_builder = TRAJECTORY_BUILDER,
map_frame = "map",
tracking_frame = "base_footprint",
published_frame = "odom",
odom_frame = "odom",
provide_odom_frame = false,
publish_frame_projected_to_2d = false,
use_odometry = true,
use_nav_sat = false,
use_landmarks = false,
num_laser_scans = 1,
num_multi_echo_laser_scans = 0,
num_subdivisions_per_laser_scan = 1,
num_point_clouds = 0,
lookup_transform_timeout_sec = 0.5,
submap_publish_period_sec = 0.3,
pose_publish_period_sec = 2e-2,
--启用将跟踪的姿势发布为geometry_msgs / PoseStamped到主题“ tracked_pose”。
--publish_tracked_pose_msg = true,
trajectory_publish_period_sec = 30e-3,
rangefinder_sampling_ratio = 1.,
odometry_sampling_ratio = 1.,
--如果有时间不一致问题odometry_sampling_ratio可以改为0.3或0.1,但未从根源上解决问题。
fixed_frame_pose_sampling_ratio = 1.,
imu_sampling_ratio = 1.,
landmarks_sampling_ratio = 1.,
}
--pure_localization
POSE_GRAPH.optimize_every_n_nodes = 0
MAP_BUILDER.num_background_threads = 4
POSE_GRAPH.global_sampling_ratio = 0.003
POSE_GRAPH.constraint_builder.sampling_ratio = 0.3
POSE_GRAPH.constraint_builder.min_score = 0.85
POSE_GRAPH.global_constraint_search_after_n_seconds = 30
--pure_localization end
-- POSE_GRAPH.optimization_problem.log_solver_summary = true
MAP_BUILDER.use_trajectory_builder_2d = true
TRAJECTORY_BUILDER_2D.submaps.num_range_data = 45
TRAJECTORY_BUILDER_2D.min_range = 0.05
TRAJECTORY_BUILDER_2D.max_range = 15.
TRAJECTORY_BUILDER_2D.missing_data_ray_length = 1.
TRAJECTORY_BUILDER_2D.use_imu_data = true
--重力常数
TRAJECTORY_BUILDER_2D.imu_gravity_time_constant = 9.7883
TRAJECTORY_BUILDER_2D.use_online_correlative_scan_matching = true
TRAJECTORY_BUILDER_2D.real_time_correlative_scan_matcher.linear_search_window = 0.1
--TRAJECTORY_BUILDER_2D.real_time_correlative_scan_matcher.angular_search_window = math.rad(45.)
TRAJECTORY_BUILDER_2D.real_time_correlative_scan_matcher.translation_delta_cost_weight = 10.
TRAJECTORY_BUILDER_2D.real_time_correlative_scan_matcher.rotation_delta_cost_weight = 1e-1
--扫描匹配器可以在不影响分数的情况下自由地前后移动匹配项。我们希望通过使扫描匹配器支付更多费用来偏离这种情况,
--从而对这种情况进行惩罚。控制它的两个参数是TRAJECTORY_BUILDER_2D.ceres_scan_matcher.translation_weight和
--rotation_weight。越高,将结果从先前移开,换句话说,就越昂贵:扫描匹配必须在要接受的另一个位置产生更高的分数。
--TRAJECTORY_BUILDER_2D.ceres_scan_matcher.translation_weight = 2e2
--TRAJECTORY_BUILDER_2D.ceres_scan_matcher.rotation_weight = 4e2
POSE_GRAPH.optimization_problem.huber_scale = 1e2
--odom
--POSE_GRAPH.optimization_problem.initial_pose_translation_weight = 1e5
--POSE_GRAPH.optimization_problem.initial_pose_rotation_weight = 1e5
--POSE_GRAPH.optimization_problem.odometry_translation_weight = 1e5
--POSE_GRAPH.optimization_problem.odometry_rotation_weight = 1e1
return options
然后就是在运行过程中可能会报错的问题,主要是时间不一致的问题,参考:
https://blog.csdn.net/weixin_44570248/article/details/118462631
最后附上我定位的图片:
这是刚启动rviz存在的定位偏差
这是在小车实际运行一段时间后的定位,可以看出效果还是有所改善的,不过也同样存在一点偏差。
最后说一些小提示:像这个定位的先验地图是很久之前建好的,个人建议在最初建图时将场景内的不确定因素可以先移出场景外,建一个“保质期”比较久的地图可以为后续的定位达到更好的效果。