用 Mid360 跑 LIO-SAM 给四足机器狗做室外建图，最近问的人很多。这个组合最容易被误解的地方，是大家以为装上驱动、把 LIO-SAM 跑起来，就能复刻网上那种漂亮的彩色点云图。实际上从雷达上电、IP 配置、驱动版本、坐标外参，到机器狗跑动时的抖动和回环，每一步都可能让建图从“能用”变成“没法看”。这篇文章把我调试这类方案时的高频问题、检查顺序和判断标准整理出来，适合已经有一台机器狗和 Mid360、准备做室外地图的读者。如果你刚拿到雷达，也可以先按这套流程把点云和 IMU 验证通过，再上 LIO-SAM。
1. 先搞清楚 mid360 配 LIO-SAM 到底解决什么问题
1.1 mid360 是什么，为什么适合机器狗
Mid360 是 Livox 出的一个 360 度非重复扫描激光雷达，水平视野 360 度，垂直视野大约 60 度左右，量程在几十米级别，近距离盲区小。相比传统 16 线机械雷达，它没有旋转电机，重量轻、体积小，装到四足机器狗上不会明显破坏机身平衡。机器狗在行走时身体会俯仰和滚转，传统机械雷达的大惯量旋转部件在这种平台上反而容易引入额外扰动。Mid360 这类固态雷达的扫描方式是非重复的，静止时点云会随时间越积越密，运动时则需要 SLAM 前端把连续帧拼起来。这个特性会影响特征提取和配准策略，不能完全按照机械雷达的思路去调参数。
1.2 为什么是 LIO-SAM，而不是 FAST-LIO 或直接录点云
LIO-SAM 是“激光惯性里程计 + 因子图优化”的框架，前端做激光帧间配准和 IMU 预积分，后端用 GTSAM 做全局优化，还带回环检测。它对“一张能长期用的地图”这个目标比较友好。Fast-LIO / FAST-LIO2 更轻量，实时性好，适合在线定位，但全局一致性需要自己补。Mid360 社区里用 FAST-LIO 的人也很多，因为流程短、容易跑通。
我的建议是：如果目标是室外建图，以后还要做导航和路径规划，优先考虑 LIO-SAM；如果目标是实时定位、算力又有限，那别硬上 LIO-SAM，选 Fast-LIO 类方案更合适。先想清楚你要地图还是里程计，再选框架。
1.3 这个组合的能力和边界
能用：园区道路、建筑周边、草地缓坡、停车场这类有结构特征，又不容易被完全遮挡的室外场景。
不太适合：大面积无遮挡空场、重复结构的长走廊、高速奔跑。
这里还要提醒一点：Mid360 只能提供雷达和内置 IMU，真正让地图不飘的，是后端回环优化和机器狗在运动中的稳定性。雷达只负责看见世界，算法负责理解世界，底盘负责不给算法添乱。
2. 上车前，先把环境装到“能出点云”这一步
2.1 硬件连接：网口、IP、供电
Mid360 走网口输出原始数据，不是 USB。接线分两路：一个以太网口传数据，一个电源口单独供电。第一次调试最常见的失败原因是 IP 没设置好。Livox 雷达在出厂时有一个默认 IP，电脑需要和它在同一网段。我一般先把雷达通电，看网口是否 up，再用 Livox Viewer 或驱动工具确认能不能发现设备。这一步没通过之前，不要碰任何 SLAM 代码。
供电也要重点看。四足机器狗的电机瞬间电流很大，急停、跳跃、上坡都会引起电源波动。如果雷达和电机驱动器共用一条不靠谱的电源线，雷达可能掉线丢包。先确认雷达供电稳定，不要以为是算法问题。我建议单独一路稳压电源，或者在电源入口加滤波和保护。
2.2 软件栈：ROS 版本、驱动、LIO-SAM 分支
Mid360 的官方驱动是 livox_ros_driver2，ROS1 和 ROS2 都有支持。LIO-SAM 原始仓库主要面向 ROS1，和 Velodyne、Ouster 这类驱动搭配比较多。Mid360 接入 LIO-SAM，常见有两种方案：一种是把 livox 的点云转成 PointCloud2，同时把内置 IMU 话题接到 LIO-SAM 的 IMU topic；另一种是直接用社区里已经适配过 Livox 的 LIO-SAM 分支。
如果你的环境是 Ubuntu 20.04 + ROS Noetic，我建议优先找带 Mid360 适配的分支，省掉中间转换的麻烦；如果是 ROS2，先确认分支支持哪个 ROS2 版本，不要盲目 clone 最新代码。依赖方面，GTSAM、PCL、OpenCV 这些是常规依赖。版本不是越新越好，我遇到过 OpenCV 版本和旧代码冲突的情况。最稳妥的做法是：先在一台干净的 Ubuntu 机器上把 ROS 和依赖装好，别把开发机和实验机混在一起。
2.3 验证标准：点云和 IMU 都在，再谈建图
装完驱动后，先确认这几件事：
- 点云话题存在，比如 /livox/lidar，实时画面能看到雷达点。
- 点云话题类型明确，是 livox 自定义消息还是 PointCloud2，这决定 LIO-SAM 怎么接。
- IMU 话题存在，比如 /livox/imu，能读到角速度和加速度。
- 如果后面要外接 IMU，每个 IMU 消息的时间戳和 frame_id 都要一致。
可以用下面这组命令做基础检查：
# 看驱动是否发布话题 rostopic list | grep livox # 查看点云话题类型 rostopic info /livox/lidar # 查看 IMU 发布频率 rostopic hz /livox/imu # 手动打印几帧 IMU 数据 rostopic echo /livox/imu -n 5如果点云有、IMU 没有，先查驱动配置里 IMU 是否使能；如果两者都有但时间戳对不上，先解决时间同步，再做 SLAM。很多建图漂移，根子其实在时间戳和 frame_id 上。
3. 机器狗上的坐标、外参和 IMU 配置不要照抄别人
3.1 雷达安装位置和机身坐标系
机器狗运动时身体是不断俯仰滚转的，雷达装在哪里，直接影响机身坐标系和雷达坐标系的转换。常见位置是机头正上方、背部中央、尾部支架。从建图角度讲，越靠近机身几何中心和 IMU 越好，外参平移量越小，配准对旋转越敏感。
安装支架要有足够刚度，不能用软连接。雷达在跑动中如果自己晃，IMU 估计的机身姿态和雷达实际看到的点云对不上，地图就会出现抖动和重影。我一般用角铝做 L 型支架，固定在机架原有螺丝孔上，尽量避免双面胶和塑料卡扣。
3.2 雷达到 IMU 的外参标定
LIO-SAM 需要雷达坐标系到 IMU 坐标系的旋转和平移。Mid360 内部集成了 IMU，直接用它最省事，但内置 IMU 的噪声和零偏水平只能算“够用”。如果你为了更高精度外接一个 IMU，那就必须自己标定外参，不能拿单位矩阵或者别人的数值硬填。
外参不准的典型表现是：静止时地图正常，一走路位姿就往一边偏；或者原地转圈时地图被拧掉。标定外参可以先用安装图量出粗值，再用手旋转雷达观察 odometry 方向对不对。对大多数室外场景，旋转外参比平移外参敏感得多，先把旋转方向搞对。
3.3 参数文件里最容易出错的字段
不同分支的参数文件名不一样，但核心字段类似。下面这个表格是我调参时会逐项检查的，不是让你照抄数值：
| 字段或关注点 | 常见错误 | 检查方式 |
|---|---|---|
| IMU 话题名 | 大小写、命名空间不一致 | rostopic echo 确认实际话题 |
| 雷达坐标系 frame_id | 与驱动里定义不一致 | 检查 TF 和参数文件 |
| 雷达到 IMU 旋转外参 | 方向反了，地图翻转或反向漂移 | 静止转雷达，看 odometry 方向 |
| 雷达到 IMU 平移外参 | 数值与安装位置差太多 | 用卡尺量偏移后填入 |
| 扫描周期和帧率 | 和驱动实际参数不符 | 用 rostopic hz 看发布频率 |
| 地图保存路径 | 目录不存在或权限不足 | 保存后检查 PCD 文件大小 |
配置文件的写法以你实际使用的分支为准，常见结构类似：
# 示例字段，具体名称以你使用的 LIO-SAM 分支为准 imuTopic: "/livox/imu" lidarFrame: "livox_frame" baselinkFrame: "base_link" extrinsicRot: [1, 0, 0, 0, 1, 0, 0, 0, 1] extrinsicTrans: [0.0, 0.0, 0.0]这里有一个很重要的工程习惯：每改一个参数，就把原来的配置文件备份一份，记录改了哪一行。SLAM 调试经常是多个参数耦合在一起，没有版本记录，你很难知道地图变好变坏是哪一次修改造成的。
3.4 frame_id 统一
再单独强调一次 frame_id。base_link、body、livox_frame、imu_link 这些名字在不同代码里叫法不同。LIO-SAM 启动后会维护一个 TF 树，如果 lidar 帧和 IMU 帧的 frame_id 跟参数文件不一致，常见结果是“启动不报错，但 odometry 一直没有输出”。排查的时候先看 TF 树有没有完整发布，再查参数。
4. 室外建图实操：从单条记录到完整闭环
4.1 第一次测试：小场景，慢速走
第一次不要直接去复杂园区。找一个小范围广场或停车场，边界清楚，有建筑物、树木、路沿，不要有太多人和车
