企业官网建设流程全解析

说实话，这大半年我在移动机器人平台上来回折腾了不少雷达方案，最后留在车上没拆下来的就是 MID360。倒不是说别的雷达不行，而是在室内外切换、无人机起降、小车导航这种混合场景里，MID360 的 360 度视角加内置 IMU 真的太省心了。配合 FAST-LIO（社区一般叫 fastlio）做实时建图和里程计，一套组合拳下来，基本能满足绝大多数定位建图需求。

这篇笔记算是我从零开始到稳定跑通整个流程的记录。不是官方文档的复读，而是把我在驱动安装、外参标定、launch 文件修改、建图调试中踩过的坑，以及最终跑通的配置方式，原原本本整理出来。如果你正在用 MID360，或者刚入手准备跑 FAST-LIO，这篇文章应该能帮你少走不少弯路。

1. 硬件认知与方案选型思路

1.1 MID360 到底是什么定位的雷达

MID360 是 Livox 推出的一款混合固态激光雷达，外观上像个大号的圆柱体，但内里是棱镜扫描方案。它最核心的特点是水平方向 360 度全覆盖，垂直方向视场角能达到 -7 度到 52 度，这个 FOV 设计很取巧，正好覆盖了机器人前方地面、正前方、以及上方可能出现的障碍物。

我把它用在底盘式机器人上，雷达水平安装时，52 度的仰角能清楚看到天花板特征，-7 度的俯角又能扫到脚边地面，对回环检测和地面约束非常有帮助。和传统机械式雷达相比，MID360 没有旋转电机外壳，整体可靠性更高，体积也小很多。

一个比较亮眼的参数是它的量程：反射率 90% 的物体最远测到 40 米，10% 低反射率物体也能测到 20 米左右。对室内建图来说 20 米已经绰绰有余，室外园区环境下 40 米也能提供足够的提前量。再加上 2 厘米左右的测距精度和 20 万点每秒的点频，作为 FAST-LIO 的输入完全够用。

1.2 和同系列雷达对比，为什么我推荐 MID360

Livox 旗下还有 Mid-40、Mid-70、Avia 这些型号。Avia 主打轻量化和高精度，适合无人机，但价格贵不少；Mid-70 是非重复扫描但视角只有 70.4 度，单台覆盖范围太窄。MID360 是 Livox 里面唯一一个天生带 360 度水平覆盖的型号，在同类产品里相当另类。

实际用下来，MID360 的生态也最让人省心，Livox 官方驱动直接支持它，FAST-LIO 官方仓库里甚至给了 MID360 对应的 launch 示例。这意味着你不需要从零写适配层，配置好话题名和 IMU 外参，基本就能直接跑起来。相比之下，Mid-70 做 360 度覆盖需要多台拼接，标定成本和对计算资源的消耗都不是一个量级。

1.3 为什么选 FAST-LIO 而不是其他方案

有人可能会问，同样是用 Livox 雷达，LOAM-Livox 和 LIO-SAM 也很流行，为什么我偏偏推荐 FAST-LIO。我的观点是，在雷达自带 IMU、然后需要稳健里程计的场景下，FAST-LIO 的紧耦合方案优势太明显了。

LOAM-Livox 本质上是松耦合，对 IMU 的利用不够充分，遇到快速旋转或剧烈颠簸时，里程计容易飘。LIO-SAM 需要帧间匹配加上因子图优化，表现也很好，但在算力有限的嵌入式平台上，跑起来比 FAST-LIO 吃力。FAST-LIO 用的是迭代误差状态卡尔曼滤波，把雷达观测和 IMU 预测做紧耦合，原始点云直接进滤波更新，不需要额外做特征提取，所以它在 CPU 占用和建图精度之间的平衡，目前用下来是最舒服的。

2. 环境准备与驱动安装全流程

2.1 推荐的基础环境组合

我实际跑通的组合是 Ubuntu 20.04 + ROS Noetic + Livox ROS Driver 2 + FAST-LIO 2。如果还在用 Ubuntu 18.04 和 ROS Melodic，理论上也能装，但部分依赖版本会比较旧，踩坑概率高，我不太建议新手上这个船。

硬件方面，我用的是一块英特尔 NUC 级别的工控机，CPU 是 i7 十代，16G 内存，跑 FAST-LIO 大约占用 1 到 1.5 个核，内存占用 2G 左右。如果你打算在 Jetson Orin Nano 这类 ARM 平台上跑，性能也够，但编译时需要注意 Eigen 和 PCL 的版本匹配。

ROS 安装这里不做展开，默认你已经装好了。需要额外确认的是 Eigen、PCL、CerES 这些基础库是否齐全，后面编译 FAST-LIO 会用到。

2.2 Livox 雷达驱动安装，从源码编译到验证

MID360 官方驱动是 livox_ros_driver2，注意不是老版的 livox_ros_driver。这两个仓库不一样，千万别下错。驱动安装最稳的方式是源码编译，典型的流程如下：

cd ~/catkin_ws/src git clone https://github.com/Livox-SDK/livox_ros_driver2.git cd livox_ros_driver2 # 切换到对应ROS版本分支，比如Noetic git checkout master cd ~/catkin_ws catkin_make source devel/setup.bash

编译过程中最容易遇到两个问题。一个是没有安装 Livox SDK，需要在 livox_ros_driver2 的 build 之前先编译安装 https://github.com/Livox-SDK/Livox-SDK2 这个项目，否则会报找不到 livox_sdk 头文件。另一个是 CMake 版本太低，建议用 CMake 3.16 以上，太老的版本对 CUDA 和 PCL 的 Find 模块支持不好。

驱动装好后，连接雷达的网口和 USB 线，给网卡配置一个静态 IP。MID360 出厂默认 IP 是 192.168.1.1xx 之类的，Livox 官网文档里有具体说明。我这里习惯把主机 IP 配成 192.168.1.50，子网掩码 255.255.255.0，把雷达接在同一个局域网内。

然后启动驱动：

roslaunch livox_ros_driver2 msg_MID360.launch

这时候如果一切正常，终端里会出现雷达固件信息，同时发布 /mid360/points 和 /mid360/imu 两个话题。可以用 rostopic list 检查，再用 RViz 添加 PointCloud2 来可视化实时点云。第一次看到点云的时候，你会注意到 MID360 的点云纹理和机械雷达不太一样，它的扫描线是花瓣状，感觉像是不断旋转的曲线，这是正常的，并不是雷达坏了。

2.3 验证 IMU 数据是否正常发布

我之前遇到过一种情况，点云话题正常，但 /mid360/imu 一直没数据。后来发现是因为驱动配置文件里默认没有使能 IMU 输出。解决办法是修改 livox_ros_driver2 的配置文件，在 config 目录下找到 MID360 的 config 文件，把 imu_enable 设置为 true，重启驱动。

另外推荐用下面这条命令简单看一下 IMU 频率和数值范围：

rostopic hz /mid360/imu rostopic echo /mid360/imu/header/stamp

IMU 频率在 200Hz 左右是正常的，如果频率掉到 100Hz 以下，优先检查 USB 供电和线材质量，劣质延长线很容易导致 IMU 数据丢帧。

3. FAST-LIO 源码编译与关键参数详解

3.1 源码获取和依赖安装

FAST-LIO 2 在 GitHub 上非常活跃，下载编译我按以下流程操作：

cd ~/catkin_ws/src git clone https://github.com/hku-mars/FAST_LIO.git cd .. catkin_make

编译过程中如果报找不到 ikd-Tree，那是 FAST_LIO 里通过源码直接包含的，一般不需要单独安装。如果报 Eigen 相关的对齐错误，多半是 Eigen 版本和 PCL 版本冲突，把 Eigen 升级到 3.4.0 及以上即可。

3.2 针对 MID360 修改 launch 文件

FAST-LIO 官方仓库里有 livox 相关的 launch 示例，比如 mapping_mid360.launch，但如果你用的是默认配置跑 MID360，经常会发现点位不吻合或者地图发散。原因多半是话题名和外参设置不对。

我最常用的修改方式是直接在 launch 文件里指定参数，不额外写 yaml。核心需要确认的几个参数：

<arg name="lidar_type" default="1" /> <arg name="point_filter_num" default="2" /> <arg name="imu_enable" default="true" /> <arg name="imu_topic" default="/mid360/imu" /> <arg name="lid_topic" default="/mid360/points" />

lidar_type 这个参数决定了 FAST-LIO 用哪种点云预处理方式，1 代表 Livox 定制模式，会启用 de-skew 和 lios 的旋转补偿，这对 MID360 非常关键。如果误设成 0，点云没有做去畸变，建图精度会肉眼可见地下降。

3.3 外参标定部分，千万别跳过

启动 FAST-LIO 前，launch 文件里还有一组默认外参：

<arg name="extrinsic_est_enable" default="true" /> <arg name="extrinsic_T" default="[0.04165, 0.02326, -0.0284]" /> <arg name="extrinsic_R" default="[1, 0, 0, 0, 1, 0, 0, 0, 1]" />

这组参数对应的是雷达坐标系到 IMU 坐标系的平移和旋转。MID360 自带的 IMU 在雷达内部，所以理论上外参非常小，但不代表可以随意填零。安装雷达时如果用了支架，或者雷达朝向和 IMU 的默认方向不一致，这组参数必须重新标定。

我偷懒的时候也会先把 extrinsic_est_enable 设为 true，让算法自动估计外参，跑一小段再固化到配置里。但说实话，自动标定只能作为粗标定，真正要求高精度建图时，还是应该用 Livox 官方提供的标定工具或者 Kalibr 做一次离线标定。

3.4 编译和运行过程中常见的坑

编译成功后，第一次启动 FAST-LIO 经常遇到一个问题：日志里一直打印 waiting for LiDAR data。这种情况下先确认驱动确实在发布 /mid360/points 话题，可以用下面命令：

rostopic info /mid360/points

如果话题存在，再看 FAST-LIO 的 launch 里 lid_topic 是否一致。还有一种情况是雷达已经休眠了，MID360 在长时间无连接后会自动进入待机状态，导致点云不更新。解决方法是拔插一次 USB 或者重启驱动进程。

另一个常见问题是 CPU 占用异常高，甚至建图线程卡死。这通常是因为点频太高，或者 point_filter_num 设置太小。默认设为 1 表示每 1 个点输入一个，若雷达点频是 200k，filter=1 对 CPU 压力非常大。我建议先用 2，如果建图效果变差再往下降，这样能大幅降低计算压力。

4. 建图实操全记录：从启动到点云地图输出

4.1 完整启动步骤与指令

到了这一步，驱动和 FAST-LIO 都已经就绪，建图操作就比较线性了。我的标准操作顺序是这样的：

先启动雷达驱动：

roslaunch livox_ros_driver2 msg_MID360.launch

开一个新终端，启动 FAST-LIO：

roslaunch fast_lio mapping_mid360.launch

如果一切正常，你会看到一个 RViz 窗口弹出，里面开始累积点云地图。这时候拿着遥控器或者推着载具缓慢移动，点云会实时拼接成完整的 3D 环境模型。

4.2 建图时怎么判断效果好不好

建图效果好不好，不能只看有没有点云。我一般从三个维度判断：

第一看地面是否平坦。在 RViz 中将视角切换到侧视，观察地面点云是否在一个平面上。如果地面像波浪一样明显起伏，大概率是外参没标好或者 IMU 时间戳没对准。

第二看墙体是否重叠。走到房间一角，来回走几趟，观察墙壁边缘有没有明显重影。重影严重的话，回环检测和位姿估计大概率出了问题。

第三看里程计是否漂移。可以故意走一个矩形路线回到起点，看地图里的起点和实际起点是否重合。偏差太大就得回头检查 IMU 零偏和雷达数据质量。

4.3 建图过程中如何保存地图

FAST-LIO 本身只负责里程计和实时建图预览，并不直接保存完整地图。建完图后，我通常使用 pcl_ros 工具把当前点云保存下来。最快的方式是监听 /cloud_registered 这个话题，在 RViz 里确认地图完整后，用下面的命令直接保存：

rosrun pcl_ros pointcloud_to_pcd input:=/cloud_registered

这个命令会把当前收到的点云保存为 pcd 文件。注意如果你希望得到一张完整地图，需要在移动过程中持续运行这个命令，或者等建图结束后再取最后一帧点云。建图结束后取最后一帧，通常地图质量最高，因为它包含了完整的更新。

4.4 不同场景下参数怎么调

室内小房间和室外大园区，对 FAST-LIO 的参数要求差别很大。我总结了一套自己的调整经验。

室内走廊场景，墙面特征多，反射点密集，点云数量容易过大。我会把 point_filter_num 调到 2 或 3，减少冗余点，让算法集中精力处理几何特征。外参不容易出错的时候，extrinsic_est_enable 可以关掉，固定外参能减少滤波收敛过程中的抖动。

室外大草坪或空旷场地，场景特征稀疏，需要保留更多点。point_filter_num 调回 1，同时把 max_iteration 适当提高，让滤波器有更多轮次收敛到合适位姿。另外如果你发现自己走了一圈地图明显变扭，可以适当降低帧率，把 scan_ratio 调低一点。

升降平台或者无人机场景，IMU 运动会比较剧烈，一定注意把 imu_enable 保持为 true，并且检查 IMU 频率是否足够高。每台 MID360 的 IMU 默认配置基本一致，但如果经历过剧烈撞击，最好重新做一次 IMU 标定，否则会在滤波状态预测里引入系统性偏差。

5. 常见问题排查与实用经验

5.1 问题速查表

5.2 我踩过的几个印象最深的坑

第一个坑是外参符号问题。有段时间我把雷达支架装歪了一点，当时想偷懒直接用自动标定，结果跑了半小时看地图，整个走廊都扭成了抛物线。后来老老实实把雷达拆下来，用直尺量出支架的偏转角度，手工把外参填进 launch 文件，地图立刻变干净了。这让我确认了一点：自动标定不是万能的，它的收敛结果强烈依赖初始值，初始值差太远很容易跑到局部最优。

第二个坑是点云时间戳不连续。有次我换了一根很长的 USB 延长线，点云话题的数据偶尔会跳动几百毫秒，FAST-LIO 的表现是地图突然跳变，然后整个位姿估计开始震荡。排查到最后发现是延长线质量有问题，换回短线或者用 USB 3.0 直连后问题彻底消失。这个案例给我一个教训：硬件链路里的任何一个薄弱点，最终都会在 SLAM 精度上暴露出来。

第三个坑和运行方式有关。我一开始在 FAST-LIO 跑起来后，习惯性打开多个 RViz 窗口去看点云，结果发现建图延迟很高。后来才知道 RViz 点云渲染非常消耗 GPU 和内存资源，尤其是在点云频率高的时候，多个窗口会挤压算法线程的资源。现在我只保留一个 RViz 窗口，并调低点云显示点数，建图流畅度提升了非常明显。

5.3 几条给新手的实在建议

如果你也是第一次用 MID360 跑 FAST-LIO，我个人建议按以下顺序来：

先不要急着做复杂场景试验，找一个简单的室内小房间，把地面和墙面扫一遍，确认地图平整、边界清晰。然后把设备搬到室外，找一条有建筑轮廓的道路，验证一下大场景下是否有漂移。最后再尝试做回环，检验回环检测和全局一致性的表现。

另外，整机供电和散热不能忽视。MID360 的功耗虽然不高，但 FAST-LIO 长时间运行时，工控机 CPU 温度很容易飙到 90 度以上。我在机箱外加了一个小型风扇，CPU 温度稳定在 70 度左右，建图稳定性也明显更好。温度降下来之后，至少在长时间运行中减少了很大的不确定性。

还有一个很容易被忽略的细节：雷达工作环境的光照和反射材料。对激光雷达来说，纯黑物体、镜面物体和透明玻璃都会导致测距点缺失。在建图时如果发现某个区域常年空洞，先别急着怀疑算法，用手电筒照一照，看看是不是物体本身材质有问题。

6. 后续还能怎么扩展

这套 MID360 + FAST-LIO 的组合稳定跑通之后，其实可以做的事情非常多。比如把 FAST-LIO 输出作为前端，接入 LIO-SAM 或者更大规模的后端优化框架，实现园区级别的闭环修正；也可以把它接到 move_base 的 costmap 更新链路中，直接为导航提供实时障碍物信息。

我自己目前在做的一件事，是把 FAST-LIO 输出的 /Odometry 和点云话题录制下来，配合 livox_ros_driver2 的 ROS bag 回放功能，实现建图过程的事后复现和参数调优。这个思路对调试特别管用，因为现场移动环境不能反复重来，但 ROS bag 回放可以在电脑上无限次重演，每次修改参数跑一遍，成本低得多。

录制 bag 的命令很简单：

rosbag record -O mid360_mapping.bag /mid360/points /mid360/imu /Odometry

需要回放时：

rosbag play mid360_mapping.bag

然后重新启动 FAST-LIO，它就会把同样的数据再处理一遍。整个过程就像又回到了现场一样，非常适合做算法调优和问题复现。

最后再分享一个小技巧。如果你发现 FAST-LIO 在某个固定场景里总是漂移，可以用 rqt_graph 看一下话题的转发链路，确认一下 IMU 和点云数据是否都经过了同一个时间同步机制。很多时候漂移不是算法问题，而是你录数据时漏了一条话题，或者把一帧旧数据混进了新的时间戳。

这套组合我前后用了差不多半年，中间换过底盘、换过计算平台，但 MID360 和 FAST-LIO 一直没换。对于中小型移动机器人，这确实是一套很能打的基础设施。希望这篇笔记也能让你少踩几个坑，尽快跑通自己的建图系统。