企业官网建设流程全解析

简介：激光SLAM技术是移动机器人自主导航的核心模块，其中LIO-SAM通过紧耦合激光雷达与IMU数据，结合因子图优化和回环检测，显著提升了复杂环境下位姿估计的鲁棒性。然而，将LIO-SAM从ROS1迁移到ROS2并接入导航链路，涉及诸多工程细节。Gazebo仿真环境为算法验证提供了低成本平台，但模拟传感器与真实传感器存在差异，需要针对点云强度、IMU坐标系、TF树、时间同步等问题进行适配。本文围绕ROS2环境下的LIO-SAM仿真实现，详细剖析了从传感器配置、源码迁移到参数调优的完整流程，并介绍了如何将LIO_SAM输出的地图与里程计数据无缝对接Nav2导航框架，最终实现从建图到自主导航的端到端闭环。针对仿真中的特征提取异常、回环检测位姿跳变、地图加载失败等典型问题，给出了具体解决方案，为移动机器人开发者提供了可复现的工程实践参考。 去年年底我在看移动机器人的导航方案选型时，一直纠结于要不要从传统2D激光SLAM切到3D激光惯性方案。2D方案在平坦室内场景确实稳定，但一旦遇到斜坡、起伏地形或者稍微复杂的室外环境，就明显吃力。后来决定试一下LIO_SAM，但直接上真机调试的成本太高，过程也慢，所以我先把整套系统搬进了Gazebo仿真环境里，在ROS2 Humble + Ubuntu 22.04 上跑通了一版适配仿真环境的改进版LIO_SAM，并成功接到了Nav2导航链路上。这篇文章就当是一个完整的过程记录，包含所有我踩过的坑和实际改过的代码配置，希望对想做激光惯性建图和导航的朋友有点帮助。

1. 这套系统核心链路拆解：LIO_SAM到底解决了什么问题

1.1 为什么选择LIO_SAM而不是其他SLAM方案

激光SLAM方案现在有不少，比如LOAM系列、Cartographer、ndt_omp等。LIO_SAM（Tightly-coupled Lidar Inertial Odometry via Smoothing and Mapping）的最大特点是它不像LOAM那样只做激光帧间配准，而是把激光里程计、IMU预积分、回环检测和因子图优化放在一个统一的图优化框架里。简单说，它有三个我很看重的点：

• 激光和IMU紧耦合，即使快速旋转或短暂遮挡，也不会立刻漂掉。
• 有回环检测，重新回到已建图区域时能修正累计漂移，这对大面积建图很关键。
• 输出的是带姿态的因子图轨迹，可以方便地产出干净的地图点云。

在仿真环境下，这些优势依然成立。唯一的问题是，原版LIO_SAM是面向ROS1和真实雷达传感器写的，直接拿过来在ROS2里跑仿真，会遇到不少兼容性问题。这也是我这篇文章要重点讲的部分。

1.2 完整导航系统的结构设计

这个项目的目标不只是建图，而是建图后还能直接导航。所以系统分成两大段：

第一段是建图段。Gazebo仿真环境中有一台搭载16线激光雷达和IMU的机器人底盘，激光点云和IMU数据喂给改进版LIO_SAM，实时输出位姿和点云地图。

第二段是导航段。建图完成后，把地图保存下来，为Nav2提供全局静态地图层，同时LIO_SAM继续作为里程计源，为局部代价地图和规划器提供实时位姿与速度信息。

两段的关系是：LIO_SAM是感知前端，Nav2是决策规划后端。只有前端输出的位姿稳定、地图准确，后端规划出来的路径才有可能靠谱。

1.3 仿真环境的价值与局限

我自己的体会是，仿真环境最大的价值不是替代真机测试，而是把算法链路打通、把参数体系的坑提前踩一遍。比如点云话题类型、IMU坐标系对齐、TF树缺变换这类问题，在仿真环境里暴露出来的逻辑跟真机是一样的，解决之后移植真机只需处理传感器噪声差异即可。

但仿真也有局限。Gazebo的物理引擎对接触力、轮胎摩擦的模拟始终偏理想，IMU数据和现实差距很大。所以仿真环境跑通的参数，到真机基本要重新调一遍。这个心理预期要有，否则容易产生"仿真跑得好，真机一定没问题"的错觉。

2. 仿真场景搭建：雷达、IMU与Gazebo模型的协同

2.1 机器人模型与传感器配置

我使用的是自己的四轮差速机器人URDF模型，核心配置如下：

• 16线激光雷达：模拟Velodyne VLP-16，水平360度扫描，垂直范围约±15度，扫描频率10Hz。
• 9轴IMU：三轴加速度计、三轴陀螺仪、三轴磁力计，输出频率200Hz。
• 底盘控制：差速驱动，最大线速度1.0m/s，最大角速度1.5rad/s。

URDF模型的关键是坐标系定义。我的机器人坐标系树如下：

<robot name="sim_robot"> <link name="base_link"/> <link name="laser_link"/> <link name="imu_link"/> <joint name="base_to_laser" type="fixed"> <parent link="base_link"/> <child link="laser_link"/> <origin xyz="0 0 0.3" rpy="0 0 0"/> </joint> <joint name="base_to_imu" type="fixed"> <parent link="base_link"/> <child link="imu_link"/> <origin xyz="0 0 0.1" rpy="0 0 0"/> </joint> </robot>

这里有个特别容易忽略的点：LIO_SAM的IMU坐标系定义是"前左上"还是"前右下"，很多版本之间存在差异。在Gazebo里我用的IMU Gazebo插件默认是ENU（东-北-天）坐标系，而LIO_SAM内部对IMU数据的处理是基于"前左上"的约定。如果不能确认，建议直接在源码里把IMU数据处理逻辑读一遍，确认acc和gyro的坐标轴方向对应的约定。否则建图会出现严重倾斜或发散。

2.2 雷达插件与点云输出

Gazebo的雷达插件有两种，一种是<gazebo_ros_ray_sensor>，输出的是LaserScan，另一种是<gazebo_ros_gpu_ray_sensor>，可以输出带有距离信息的PointCloud2。我强烈建议直接用gpu_ray传感器配PointCloud2输出，这样能绕开一次原始LaserScan到PointCloud2的转换步骤，也少一个中间节点。

<gazebo reference="laser_link"> <sensor type="gpu_ray" name="lidar_sensor"> <pose>0 0 0 0 0 0</pose> <visualize>false</visualize> <update_rate>10</update_rate> <ray> <scan> <horizontal> <samples>1800</samples> <resolution>1</resolution> <min_angle>-3.14159</min_angle> <max_angle>3.14159</max_angle> </horizontal> <vertical> <samples>16</samples> <resolution>1</resolution> <min_angle>-0.2618</min_angle> <max_angle>0.2618</max_angle> </vertical> </scan> <range> <min>0.5</min> <max>100.0</max> <resolution>0.01</resolution> </range> <noise> <type>gaussian</type> <mean>0.0</mean> <stddev>0.005</stddev> </noise> </ray> <plugin name="gazebo_ros_gpu_ray_plugin" filename="libgazebo_ros_gpu_ray_sensor.so"> <ros> <remapping>~/out:=/lidar_points</remapping> </ros> <output_type>sensor_msgs/msg/PointCloud2</output_type> <frame_name>laser_link</frame_name> </plugin> </sensor> </gazebo>

注意这里的<noise>配置。很多教程里不会加，但LIO_SAM对异常点很敏感。如果没有噪声，仿真点云过于完美，LIO_SAM在后续真机移植时反而会不适应。我测试下来，0.005m的高斯噪声是一个比较合理的仿真值。

2.3 IMU插件与噪声参数

IMU插件配置如下：

<gazebo reference="imu_link"> <sensor type="imu" name="imu_sensor"> <pose>0 0 0 0 0 0</pose> <update_rate>200</update_rate> <always_on>true</always_on> <plugin name="gazebo_ros_imu_plugin" filename="libgazebo_ros_imu_sensor.so"> <ros> <remapping>~/out:=/imu/data</remapping> </ros> <initial_orientation_as_reference>false</initial_orientation_as_reference> </plugin> </sensor> </gazebo>

LIO_SAM对IMU的要求是必须包含三轴加速度计和三轴陀螺仪的输出。Gazebo自带imu插件输出的消息类型是sensor_msgs/msg/Imu，这也正是LIO_SAM需要的。但有一点要注意：不要开initial_orientation_as_reference，否则输出的初始姿态会被强制对齐到世界坐标系Z轴，LIO_SAM接收到的是被"修正"后的姿态，和真实运动状态不一致，容易导致位姿解算异常。

2.4 仿真环境里最容易踩的时钟问题

整个建图导航系统对时间同步要求很高。在Gazebo仿真中，如果各节点没有统一使用仿真时间，就会出现一个非常诡异的症状：点云和IMU的时间戳错乱，LIO_SAM的状态估计会周期性跳变。

解决办法是在所有launch文件中显式设置：

<param name="use_sim_time" value="true"/>

这个参数不只是launch文件里要有，节点内部也要能正确读取。LIO_SAM的每个节点都通过NodeOptions设置parameter_overrides，我在启动脚本里统一把use_sim_time透传进去，保证所有节点的时钟源一致。

3. 源码适配：从ROS1思维迁移到ROS2的完整改动

3.1 基于lio_sam_ros2的迁移路线

原版LIO_SAM是ROS1项目，要在ROS2上跑，我有两条路：一是自己把ROS1代码中的roscpp、tf、pcl_ros等API逐行替换成ROS2版本；二是直接基于社区维护的lio_sam_ros2仓库进行二次开发。我选择了后者，原因很简单：社区仓库已经把大量ROS1到ROS2的机械性迁移做完了，比如消息类型、参数服务器、生命周期节点等，我只需要关注仿真环境特有的适配部分。

网上对这个仓库的评价是"能用，但不够稳定"。我的体验是，核心算法逻辑基本保留了原版的因子图框架，只要参数配好，效果还是能接受的。关键问题在于，默认版本里面有不少需要等待的锁机制和缓冲区，仿真环境下传感器数据频率如果和真机差异较大，容易出现队列积压或丢帧。我做了适量线程优先级和缓冲区大小的调整，这一点后面在调优部分详聊。

3.2 仿真环境的点云强度问题

这是我在仿真环境下遇到的第一个大坑，极其隐蔽，而且不仔细看日志根本发现不了。

LIO_SAM的特征提取中，对每个点是否有效有一个判断，会用到激光点云每个点的intensity。激光雷达传感器在仿真环境下的PointCloud2点云，intensity通道全部是空的或者0。而LIO_SAM的featureExtraction中，用intensity做地面点判断和部分特征的附加约束，如果全部为0，会直接影响特征角点和面点的提取结果，导致后续帧间配准时特征点数量不足，位姿解算精度下降。

最直接的解决办法是在拿到点云数据之后，补一个简单的后处理节点，把intensity填充一个合理的固定值：

for (size_t i = 0; i < msg.fields.size(); i++) { if (msg.fields[i].name == "intensity") { std::vector<float> intensity_values(size, 1.0); memcpy(&msg.data[msg.point_step * msg.width], intensity_values.data(), size * sizeof(float)); } }

因为仿真雷达没有反射率信息，这个固定值只要不是0，LIO_SAM的通道检测就能正常工作。之后我在后端验证，特征点数量恢复了正常水平。

3.3 去掉GPS因子和回环检测的仿真适配

LIO_SAM的因子图支持GPS因子、回环因子和IMU预积分因子。在仿真环境中，我没有GPS数据，如果不做处理，代码会在等待GPS消息时产生积压和警告。

我的做法是把gpsTopic参数置为空字符串，同时把config文件中gps_factor的开关关掉。此外，仿真环境如果场景不大，回环检测会非常频繁，尤其当机器人在小区域内反复转圈。回环检测会触发一次全局优化，而全局优化期间里程计会有短时间的位姿跳跃。如果你的场景本身比较小，可以考虑把回环检测的阈值调大，或者用参数控制到底多久做一次全局优化。

在我的场景里，室内区域大概30m x 30m，回环检测阈值设置为0.5m距离和15度角差，实际测试下来效果稳定。

3.4 修改launch文件时的节点生命周期处理

ROS2节点的生命周期机制和ROS1差别很大。LIO_SAM的某些节点默认是未激活状态，必须由launch文件显式调用生命周期切换，否则节点不进入工作状态。我遇到的情况是：雷达图像有了、IMU数据有了，但LIO_SAM的odometry就是不发。

排查了好一阵才发现，需要配置节点生命周期服务：

#!/usr/bin/env python3 from launch_ros.actions import Node from launch import LaunchDescription def generate_launch_description(): lio_sam_node = Node( package='lio_sam', executable='lio_sam_imuPreintegration', name='lio_sam_imuPreintegration', output='screen', parameters=[config_file], ) return LaunchDescription([lio_sam_node])

实际运行中，systemctl或者终端里手动调用也可以，但用launch做生命周期管理更干净：

ros2 lifecycle set /lio_sam_imuPreintegration configure ros2 lifecycle set /lio_sam_imuPreintegration activate

这两个命令要在节点启动后手动执行，或者写进脚本里，否则IMU预积分节点会一直处于unconfigured状态。这一点如果不做，你在Rviz里看到的画面就是"一切正常但没有任何输出"。

4. 地图与里程计输出：建图运行及调参技巧

4.1 一次正常的建图运行流程

在Gazebo仿真环境中完整跑一次建图，我的标准操作顺序是：

# 终端1：启动Gazebo世界和机器人模型 ros2 launch gazebo_ros gazebo.launch.py world:=/path/to/my_world.world # 终端2：启动机器人状态发布和传感器驱动 ros2 launch sim_robot robot_description.launch.py # 终端3：启动LIO_SAM ros2 launch lio_sam run.launch.py # 终端4：启动键盘遥控或自动巡线脚本 ros2 run teleop_twist_keyboard teleop_twist_keyboard # 终端5：可视化 rviz2 -d src/lio_sam/rviz/lio_sam.rviz

这个顺序是最小可行顺序。如果你发现LIO_SAM的map迟迟不更新，优先检查topic频率：

ros2 topic hz /lidar_points ros2 topic hz /imu/data

如果雷达频率和IMU频率都比配置低很多，很可能是因为Gazebo仿真步长太大或CPU占用过高。把仿真步长从1000Hz降到500Hz也能显著降低CPU压力，对传感器输出没有明显影响。

4.2 地图质量看哪些指标

建图跑完之后，除了肉眼看Rviz里的地图轮廓是否清晰，我还会做几个量化检查：

• 轨迹首尾是否重合：在仿真环境里，如果你能控制机器人回到起点，看轨迹首尾端是否有明显错位。LIO_SAM的回环检测应该能把累计漂移拉回来，如果首尾错位大于0.1m，说明后端优化没生效。
• 点云地图中的平面要素是否平整：比如墙壁、地面，如果出现大量重影、毛刺，大概率是特征提取或外参标定问题。
• IMU预积分的数据是否平滑：查看/lio_sam_imuPreintegration输出的imu预积分频率，理论上应该和IMU原始频率接近，如果差太多，预积分线程可能被其他进程阻塞。

4.3 仿真环境下参数调整的独特心得

仿真环境的传感器是理想模型，和真机最大的不同是：噪声小、无运动畸变、无标定误差。所以LIO_SAM在真机上跑，通常需要把点云降采样leaf size调大，因为真机点云噪声大，保留太多点反而让配准不稳定。但在仿真环境里，leaf size可以适当调小，保留更多细节，建图更清楚。

我的参数配置如下：

lio_sam: ros__parameters: use_sim_time: true # 雷达参数 sensor: "velodyne" N_SCAN: 16 Horizon_SCAN: 1800 downsampleRate: 1 lidarMinRange: 1.0 lidarMaxRange: 100.0 # IMU参数 imuTopic: "/imu/data" odomTopic: "/lio_sam_odometry/odom" # 外参 extrinsicTrans: [0.0, 0.0, -0.3] extrinsicRot: [1, 0, 0, 0, 1, 0, 0, 0, 1] # 回环检测 loopClosureEnableFlag: true loopClosureFrequency: 2.0

这里extrinsicTrans的值是根据URDF中laser_link相对base_link的位置来设置的，因为我用的是base_link作为LIO_SAM的body frame。很多人在这一步出问题，就是外参没和URDF对齐，导致LIO_SAM认为雷达在机器人的某个固定位置，但Gazebo提供的点云却是另一个坐标系，两者不一致，最终地图全乱。

4.4 TF树检查

LIO_SAM运行后，会发布一系列TF。我之前在排查建图异常时，发现很多问题其实都出在TF树上。推荐用自带工具检查：

ros2 run tf2_tools view_frames

正常状态下，关键TF应该是：

• map -> odom -> base_link -> laser_link
• map -> odom -> base_link -> imu_link

如果发现某个坐标系的父级关系不对，比如laser_link直接挂在map下，那说明URDF中没有正确建立base_link到laser_link的静态变换。这种情况下，LIO_SAM姿态解算会直接失败或地图产生严重畸变。

5. 从地图到导航：LIO_SAM输出如何无缝衔接Nav2

5.1 导航链路的数据流结构

Nav2的导航链路大致是：

map -> global_costmap -> global_planner odom -> local_costmap -> local_planner base_link -> robot controller

LIO_SAM在这里面的角色是同时提供全局地图和里程计数据。具体来说：

• 建图完成后，保存点云地图为PCD或渲染为二维栅格地图，作为Nav2全局代价地图的静态地图层。
• 运行阶段，LIO_SAM持续输出/lio_sam_odometry/odom话题，作为Nav2的里程计源。

关键问题来了：Nav2里全局坐标系和里程计坐标系的设定，必须和LIO_SAM的TF树设计匹配。否则导航规划器拿到错误的坐标，路径规划就会失败，比如出现"Failed to transform from base_link to map"这类经典报错。

5.2 坐标转换桥接的两种方案

我在实际工程中总结出两种可行的坐标桥接方案。

方案一：统一以LIO_SAM的map为全局坐标系，把LIO_SAM输出的odom作为map下的一个子坐标系。

具体做法是，在Nav2的参数文件中设置：

global_costmap: global_frame: map robot_base_frame: base_link local_costmap: global_frame: odom robot_base_frame: base_link

然后确保LIO_SAM发布的odom话题是odom这个坐标系下的数据。这要求LIO_SAM的map_to_odom变换被正确维护。LIO_SAM内部实际上会发布map -> odom的变换，用于表示建图过程中的修正。在LIO_SAM的config参数里，有一个mapFrame和odomFrame的设置：

mapFrame: map odomFrame: odom

这样LIO_SAM的TF树就变成map -> odom -> base_link，和Nav2需要的TF树完全一致。

方案二：如果LIO_SAM版本默认只输出map -> base_link的TF，没有单独的odom坐标系，就需要自己写一个小桥接节点，把map -> base_link拆成map -> odom和odom -> base_link两个变换。

这个桥接节点逻辑很简单：

tf2_ros::Buffer tfBuffer; tf2_ros::TransformListener tfListener(tfBuffer); geometry_msgs::msg::TransformStamped mapToBaseLink; mapToBaseLink = tfBuffer.lookupTransform("map", "base_link", rclcpp::Time(0)); // 发布 map -> odom 为单位变换，odom -> base_link 为 LIO_SAM 的输出 geometry_msgs::msg::TransformStamped mapToOdom; mapToOdom.header.stamp = now; mapToOdom.header.frame_id = "map"; mapToOdom.child_frame_id = "odom"; mapToOdom.transform = identity; geometry_msgs::msg::TransformStamped odomToBaseLink; odomToBaseLink.header.stamp = now; odomToBaseLink.header.frame_id = "odom"; odomToBaseLink.child_frame_id = "base_link"; odomToBaseLink.transform = mapToBaseLink.transform; tfBroadcaster.sendTransform({mapToOdom, odomToBaseLink});

我个人更推荐方案二，因为它对LIO_SAM的侵入最小，而且能随时切换坐标系关系，调试方便。

5.3 Nav2参数文件中必须对齐的坐标系和话题名

Nav2的参数文件里有几个关键项要和LIO_SAM完全对齐：

local_costmap: local_costmap: ros__parameters: robot_base_frame: base_link global_frame: odom odom_topic: /lio_sam_odometry/odom robot_radius: 0.25 obstacle_layer: observation_sources: lidar_scan lidar_scan: topic: /lidar_points data_type: PointCloud2 marking: true clearing: true

这里有个容易忽略的点：局部代价地图中global_frame设置成odom，而全局代价地图中global_frame设置成map。两个代价地图使用不同的坐标系是Nav2的常见做法，但前提是TF树里必须有map -> odom和odom -> base_link这两个变换同时存在。否则局部规划器拿到激光点云后无法正确投影到局部代价地图中。

同时注意，odom_topic要和LIO_SAM发布odom话题名严格一致。我遇到过因为命名空间中前缀不一致，Nav2拿不到odom，局部规划器一直报"Waiting for odom message"的问题。

5.4 静态地图的生成与全局路径规划

建图完成后，LIO_SAM输出的是三维点云地图。Nav2的全局代价地图默认使用二维占栅格地图，所以需要把点云地图投影成二维栅格地图。

我的做法是：

1. 保存点云地图为PCD文件。
2. 使用PCL或其他工具进行地面滤波，提取地面以上、机器人可通行高度范围内的点。
3. 将滤波后的点云投影到X-Y平面，并通过栅格化生成PGM格式的二维占用地图。
4. 同时生成对应的YAML文件，包含分辨率、原点、阈值等信息，供Nav2的map_server加载。

这个投影过程我写了一个简单的Python脚本：

import open3d as o3d import numpy as np from PIL import Image pcd = o3d.io.read_point_cloud("map.pcd") points = np.asarray(pcd.points) # 只保留地面以上0.05m到0.5m范围内的点 mask = (points[:, 2] > 0.05) & (points[:, 2] < 0.5) points = points[mask] # 投影到Z=0平面并栅格化 resolution = 0.05 w = int((points[:, 0].max() - points[:, 0].min()) / resolution) + 1 h = int((points[:, 1].max() - points[:, 1].min()) / resolution) + 1 occupancy = np.zeros((h, w), dtype=np.uint8) for x, y, _ in points: px = int((x - points[:, 0].min()) / resolution) py = int((y - points[:, 1].min()) / resolution) occupancy[h - 1 - py, px] = 254 Image.fromarray(occupancy, 'L').save("map.pgm")

这个脚本不复杂，但很实用。生成的map.pgm搭配map.yaml，在Nav2的map_server中直接加载就行。

这里有一个值得注意的细节：如果直接把所有点云都投影，不做高度过滤，那地图上会包含天花板、横梁等出现在机器人顶部的障碍物，导致规划的路径完全无法走通。我试过一次，地图上全是虚拟障碍，导航直接失败，花了半小时才发现是高度过滤没做。

5.5 导航测试的完整流程

按上面配置完成后，启动导航测试的顺序是：

# 终端1：启动Gazebo和机器人 ros2 launch sim_robot complete_simulation.launch.py # 终端2：启动LIO_SAM（实时建图和里程计） ros2 launch lio_sam run.launch.py # 终端3：加载点云地图并启动Nav2 ros2 launch nav2_bringup bringup_launch.py map:=/path/to/map.yaml use_sim_time:=true # 终端4：Rviz2指定初始位姿和目标点 rviz2

在Rviz2中，先通过"2D Pose Estimate"设置初始位姿，再通过"2D Goal Pose"给定目标点。观察规划器是否能成功规划出无障碍路径，并控制机器人沿路径行驶。

如果规划器和控制器同时启用，机器人在仿真环境里的运动基本能达到一分钟内完成10米距离的小场景导航目标。

6. 实测中的踩坑记录与解决过程

6.1 症状一：地图正常但Nav2无法规划

第一次完整测试时，地图在Rviz里看起来非常干净，但Nav2的全局规划器一直报"Failed to get a plan from planner server"。

排查过程：

• 先用ros2 run tf2_tools view_frames确认TF树完整。
• 再查global_costmap的robot_radius设置，发现我设成了0.25m，而机器人实际宽度为0.5m，直径0.5m，半径正好0.25m，这个没毛病。
• 最后把全局代价地图的静态地图图层显示打开，才看到问题：map_server加载的是三通道彩色PNG，而Nav2要求的是单通道PGM。由于加载失败，地图层全黑，代价地图也全黑，导致规划器认为地图里全是未知区域。

解决办法是把地图转为单通道PGM，同时把YAML文件中mode参数设为trinary。

这个案例提醒我：Rviz里看起来正常不代表数据结构正确，代价地图的数据源是否真正加载成功，一定要通过Nav2的可视化插件确认。

6.2 症状二：回环检测导致导航中位姿跳变

建图阶段回环检测是好事，但在导航阶段，如果LIO_SAM还在跑回环检测，当机器人回到之前建图区域时，全局优化会突然修正之前的漂移，表现为位姿跳变和路径闪断。

解决方法是导航阶段关闭回环检测，或者把回环检测频率降到极低：

loopClosureEnableFlag: false

在真实工程中，通常的做法是建图阶段和导航阶段使用两套不同的参数参数。建图阶段开回环，导航阶段只输出里程计，不进行全局优化。这样可以避免导航过程中的位姿突变。

6.3 症状三：IMU数据被持续丢弃

仿真环境中，IMU频率设置为200Hz，但LIO_SAM的IMU预积分线程实际处理能力跟不上时，会丢弃一部分数据。仿真中这通常不是计算能力问题，而是由于话题缓冲区太小导致的。

我在节点启动参数中增加了队列深度：

imuTopic: "/imu/data"

然后在LIO_SAM订阅IMU时设置队列长度：

imuSub = nh->subscribe<Imu>(imuTopic, 2000, &ImuPreintegration::imuHandler, this);

将队列长度从默认的10改到2000后，IMU数据不再丢失。这个调整在真机上也有参考意义：真机IMU频率可能更高，缓冲区设置不足同样会丢数据。

6.4 症状四：仿真时间不同步导致map_server加载超时

这是一个让我检查了很久的问题。Nav2的map_server加载静态地图时，如果use_sim_time设置为true，但map.yaml中的地图文件路径不正确，或者地图元数据时间戳异常，会导致加载过程一直等待，最终报超时。

最终解决办法是在launch文件中显式传入map参数和use_sim_time参数，同时确保map.yaml文件中的image: map.pgm路径是相对于map.yaml文件的，而不是相对于当前工作目录。

6.5 症状五：建图时特征点数量过少

仿真环境中的墙面往往非常平滑，LIO_SAM在均匀的墙面上提取的特征点确实会比真实环境少很多。这是因为仿真环境的几何特征比较单一，不像真实世界有各种纹理和结构。

解决方法是调整featureExtraction的曲率阈值：

# 降低角点提取阈值 featureExtraction: ros__parameters: edgeThreshold: 0.1 surfThreshold: 0.3

这样可以让更多点被识别为特征点。但注意不要调得太低，否则大量噪声点也会被当作特征点，反而降低配准精度。经过多次实验，我最终将edgeThreshold设为0.1，surfThreshold设为0.3，在仿真环境中能获得较稳定的特征点数量。

7. 后续扩展方向

仿真环境毕竟是一个虚拟验证平台，在把整套系统跑通之后，我还有几个可以继续深化的方向。

第一个方向是更换更真实的传感器模型。Gazebo的默认传感器噪声是高斯白噪声，但真实传感器的噪声往往是带时间相关的偏置和随机游走。可以通过增加IMU的随机游走噪声、给点云增加离群点，让仿真数据更接近真机，这样迁移到真机时参数变化会更小。

第二个方向是加上视觉传感器做视觉-激光-惯性融合。既然LIO_SAM的框架已经跑通，后续在这个框架上添加视觉特征点因子，或者直接换用LVI-SAM，难度不会太大。仿真环境下，视觉和激光的时间同步、坐标系对齐这些坑，又值得再写一篇总结了。

第三个方向是动态障碍物避障。目前的Nav2只是静态规划，在仿真世界里放置移动行人或车辆，测试局部代价地图的实时更新能力和局部规划器的避障效果，会很有实战价值。这部分的重点在costmap的障碍物层更新频率以及局部规划器的参数调节，和LIO_SAM本身的关联不大，但整条链路会变得更完整。

我个人的体会是，仿真环境的价值不在于"看起来像那么回事"，而在于把系统的接口、时序、容错逻辑全部打通。这个项目做完之后，我对LIO_SAM的因子图框架理解比之前看书、看文档深刻得多，特别是IMU预积分和回环检测在ROS2生命周期机制下的配合方式，只有真正调试过才会记牢。希望这篇记录能帮你少走一些弯路。

本文还有配套的精品资源，点击获取