1. 为什么我最终把主力建图设备换成了Mid-360差不多两年前我还在为巡检机器人底盘选建图方案发愁。当时手里有一台16线机械式雷达配LOAM系算法跑室内小场景还行一到室外或者稍大一点的环境就开始闹脾气点云稀疏导致转角处墙体扭曲机械旋转结构在颠簸路面上容易出问题而且整个设备体积不小装在小车顶部总担心撞到门框。后来换了Livox Mid-360搭配FAST-LIO2这才算真正把“点云采集到高精度建图”这条链路走顺了。这套组合并不神秘但网上能查到的资料大多是官方文档式的干条条真正实操里的坑很少有人系统讲。这篇东西就按我实际跑过的流程来从设备特性、算法原理、环境编译、采集习惯、参数调优到点云后处理把整条线捋一遍。适合正在折腾Mid-360建图、或者打算入坑FAST-LIO2的朋友哪怕你之前没碰过激光雷达SLAM照着走也能少踩一半的坑。1.1 它不是机械雷达非重复扫描到底改了什么Mid-360是一台混合固态激光雷达这一点如果没理解透后面很多操作都会走弯路。传统的16线、32线机械雷达靠电机带动激光头旋转一帧点云里每条扫描线在水平方向上是均匀分布的所以直接给到后续算法就能拿到结构完整的扫描帧。Mid-360完全不是这个逻辑。它在内部用三个固态激光模块拼接出水平360度的覆盖范围激光束的指向通过棱镜控制扫描轨迹是一种花瓣状的密集曲线。带来的结果就是单帧点云的分布非常不均匀中心区域密集、边缘稀疏同一片区域盯住看几秒钟点云会越来越密这就是非重复扫描的核心特性。这个特性直接影响算法选型。传统的特征提取类SLAM算法比如LOAM系要求每帧点云里有稳定可提取的角点和面点但Mid-360单帧点云在某些角度上可能稀疏到提取不出足够的特征。FAST-LIO2就没有这个问题它不做特征提取直接拿原始点云和地图匹配点云稠密反而更好。所以Mid-360和FAST-LIO2这套组合不只是“能跑”而是原理上就合拍。下面这个表是Mid-360的关键参数玩这个设备最好背下来参数数值实际意义水平视场角360°无盲区适合室内外巡检垂直视场角70.4°上63.4°/下7°仰视能力很强俯视很弱测距量程40m80%反射率实际可靠距离约30m点频200,000点/秒单帧约2万点10Hz测距精度±2cm建图几何精度的下限内置IMUBMI088含加速度计和陀螺仪别小看这个内置IMU。FAST-LIO2是激光惯性紧耦合算法雷达和IMU的数据时序是否对齐、外参标定是否准确直接决定地图质量。Mid-360把IMU集成在设备内部出厂时雷达和IMU已经做了固件级同步这等于帮我们省掉了外挂IMU的硬件安装误差是这套组合能跑出稳定地图的重要原因。1.2 FOV的坑往上能“看天”往下却有个死角Mid-360垂直视场是向上63.4度、向下7度这个分布和常见的机械雷达差别很大。机械雷达一般是上下对称15度到25度所以很多用惯了机械雷达的人拿到Mid-360后第一反应是“怎么看不到地面”。实际使用中向下7度意味着如果雷达水平安装正下方会形成一个很大的盲区。手持设备时脚下大约1到2米范围的扇形区域是点云缺失的。解决办法一般有两个一个是把雷达稍微倾斜安装让视场偏向地面另一个是在建图时注意扫描姿态不要全靠雷达朝下而是通过设备运动让两侧地面进入视场。还有一个容易被忽略的点Mid-360向上视场很大安装在小车上时顶部扫到的常常是天花板、树干、屋檐这类东西这些特征对定位其实是好东西因为高层特征不容易被行人、车辆遮挡。但如果雷达上方正好被支架挡住相当于浪费了半个视场。我见过有人把雷达装在金属壳里只露出侧面一圈建图效果大打折扣后来拆掉外壳立刻就好了。另外说一句盲区处理。08年接触lidar的人都知道激光雷达近距离都有盲区Mid-360在10到30厘米范围内会有一些不稳定的近距离噪点。FAST-LIO2的配置里有个blind参数就是用来忽略这些近距离点的后面调参部分我再细讲。2. FAST-LIO2到底在算什么紧耦合与ikd-Tree算法黑箱是最容易让人翻车的地方。很多人用FAST-LIO2跑出图来但不知道为什么有时候稳如老狗、有时候突然飞掉。要真正驾驭这套系统至少要把两件事搞明白紧耦合的数学含义以及ikd-Tree在地图维护里扮演的角色。2.1 紧耦合是数学上的紧不是后补的“配准滤波”很多SLAM框架是“前端配准、后端滤波”两条线比如先通过ICP算出两帧之间的位姿再扔给卡尔曼滤波做平滑。这种松耦合方案里前端一旦算错后端只能被动接受错误。FAST-LIO2不同。它的状态估计核心是迭代误差状态卡尔曼滤波IESKFIMU数据负责状态传播激光点云数据负责更新修正。IMU的预测和激光的观测在同一个数学框架里交替迭代每一轮激光迭代都会重新评估IMU传播过来的状态这就是“紧耦合”的准确含义。更关键的是FAST-LIO2不做特征提取。它把每一帧点云里的点直接和ikd-Tree里的地图点做最近邻匹配用点到面的残差去更新状态。这意味着算法对点云密度的利用是充分的Mid-360那种非重复扫描形成的稠密点云在它手里是优势而非负担。我在实际测试中发现同样的传感器套件FAST-LIO2跑出来的地图比LOAM系干净很多尤其在墙面、柱子这类平面结构上厚度能控制在5厘米以内。对应用户来说这个原理带来的行为特征就是FAST-LIO2对“特征缺失”比“点云稀疏”更敏感。走在一条又长又直的走廊里两侧墙壁平行雷达能看到的几何约束退化成单一方向这时候即使点云再密算法也容易在走廊方向上产生漂移。这不是算法垃圾是观测信息本身的物理局限。理解了这一点才能理解为什么采集时一定要多走“8”字。2.2 ikd-Tree增量维护地图解决“边建边查”的瓶颈地图匹配这种操作本质上是“新来一帧点云要去一个庞大的点云库里找最近邻”。如果地图里有几十万个点每帧都重新建一棵kd-tree计算量会爆炸。早期很多建图方案跑大场景越来越卡就是因为这个。ikd-Tree的核心贡献是增量更新。新点云插入地图后树结构只需做局部重平衡而不是全局重建同时它还支持按范围删除体素这样地图规模可以被控制住不会无限膨胀。FAST-LIO2能在大范围环境里保持实时性整个系统在普通工控机上跑到20Hz以上毫无压力ikd-Tree功不可没。这里牵出一个实操概念FAST-LIO2的地图不是“建完就完”而是在整个运行过程中始终保持着一个局部地图或全局地图具体配置取决于场景。如果做几十米的小场景维护全局地图没什么问题但如果是长距离的园区巡检地图点数量会迅速增长即使有ikd-Tree计算负载也会上来。这时候可以考虑调小det_range让算法只维护雷达周围30米内的地图既有足够的局部约束又避免远点拖慢速度。我见过最典型的错误就是把det_range设成雷达标称的40米甚至60米结果地图建着建着开始卡顿、甚至无故跳变。原因就是远处点云里混入大量低置信度的噪声点地图被它们污染了。这类参数不是越大越好后面调参章节还会展开。3. 环境搭建与驱动联调最容易翻车也最值得花时间很多朋友拿到设备第一步就是git clone、catkin_make结果被一堆依赖和版本问题卡了一整天。这块我建议按顺序来别跳步。3.1 接线、供电与TimeSync同步Mid-360通过网口输出数据支持PoE供电所以链路很简单雷达网口直接插到工控机的千兆网口上如果工控机网口不带PoE就需要在中间串一个PoE供电模块。网络配置这一环不少人卡在IP上。Mid-360支持广播自动发现一般装好Livox Viewer后它会自己找到设备不需要手工改默认IP。但你工控机网卡需要配到同一网段最稳妥的做法是设置静态IP比如192.168.1.50子网掩码255.255.255.0。如果Liveox Viewer发现不了设备第一反应不是重装驱动而是先ping一下设备地址再检查防火墙。Ubuntu上偶尔会遇到防火墙拦截广播包的问题直接关掉或放行即可。TimeSync时间同步是重头戏。FAST-LIO2对雷达和IMU的时间戳一致性要求很高如果时间不对齐最典型的症状是建图过程中地图出现周期性扭曲或者抖动。Livox驱动里有一个time_sync_en的选项打开后系统会通过PTP等方式同步设备时钟和主机时钟。我的建议是只要跑FAST-LIO2就把时间同步打开不要图省事关掉。还有一个容易忽略的供电问题PoE模块选质量好一点的电压不稳时雷达会掉线或点云出现大量空洞。我开始用了一个杂牌PoE分离器建图建到一半雷达就失联排查了半天才发现是供电不足。这种问题和你跑什么算法无关纯粹是硬件链路的坑。3.2 编译FAST-LIO2时的版本问题编译环境我以Ubuntu 20.04 ROS Noetic为例这套组合目前是社区里最成熟的。如果用的Ubuntu 18.04 ROS Melodic操作也类似注意Eigen版本别太低。sudo apt update sudo apt install ros-noetic-pcl-ros ros-noetic-pcl-conversions ros-noetic-eigen-conversions mkdir -p ~/catkin_ws/src cd ~/catkin_ws/src git clone https://github.com/hku-mars/FAST_LIO.git git clone https://github.com/Livox-SDK/livox_ros_driver2.git cd ~/catkin_ws catkin_make source devel/setup.bash编译过程中最常遇到的坑有两个。第一个是Eigen版本陈旧导致编译报错建议先确认一下Eigen3的版本不低于3.3.7。第二个是livox_ros_driver2和老版本livox_ros_driver的冲突如果之前装过老版驱动最好先卸载干净否则会出现接口不匹配导致FAST-LIO2订阅不到点云话题。FAST-LIO2里关于激光雷达类型需要确认一下。它支持Livox和标准点云两种输入如果是用Mid-360就要确保配置里lidar_type正确设置为Livox对应值以及点云话题是/livox/lidarIMU话题是/livox/imu。如果话题没对上运行起来会发现RVIZ里没有任何点云实际上就是下游根本没收到数据。3.3 先用官方数据集跑通再上真机这一步强烈建议新手不要跳过。真机调试涉及供电、网络、运动姿态、环境特征一堆变量一旦地图没出来你根本分不清是哪里出了问题。先跑官方bag文件把算法链路验证通了再去碰真机排查范围能缩小一半。Livox官方和一些开源项目都提供了包含Mid-360点云和IMU数据的bag文件。启动方式很简单roslaunch fast_lio mapping_mid360.launch然后再找个终端播放bagrosbag play your_bag.bag看到RVIZ里出现实时构建的地图说明编译、驱动、话题、参数基本都没问题。我一般会盯着看两三分钟确认地图稳定不飘、不跳变再拔掉bag换真机。这一步还有一个隐藏价值你可以把官方bag当成一个固定的“测试基准”。以后改参数、换环境、升代码都拿同一个bag跑一遍对比地图质量就能快速判断改动是变好还是变坏。没有这个基准你会陷入“改了参数但环境变了所以不确定有没有改善”的困境里。4. 实机建图从采集习惯到实时地图诊断链路通了下一步就是拿真机跑。很多人到了这一步反而最容易翻车因为算法能跑起来不代表能建出高质量地图。我发现建图质量的下限往往不是由算法决定而是由采集习惯决定的。4.1 采集动作规范怎么走决定了地图会不会飘建图前的第一步是静止初始化。设备上电后让雷达和IMU保持静止3到5秒这段时间IMU会完成零偏估计和重力方向的初始对齐。没有这一步算法开局就带着一个错误的重力估计后面地图整体倾斜都不是怪事。静止完还不能马上进入正式采集建议先做一段“8”字运动。绕“8”字的意义在于它同时包含平移和旋转激励能把IMU的三种轴都激活起来滤波器才能准确估计各项状态。我一般会先在周围走一个半径3米左右的“8”字持续10到15秒再开始正式建图路线。正式采集时记住几个原则匀速慢走别急加速急转弯遇到长走廊有条件就走完再折返不要只走单程经过已走过的区域时尽量形成闭环。为什么强调闭环因为FAST-LIO2本身没有回环检测和全局优化它靠的是局部帧间匹配的累积。如果整个路线从头到尾都不闭合误差就会一路积累最后地图首尾对不上。走个闭环至少可以让累积误差不往无限方向发展。手持采集和车载采集还有个小区别手持时手部抖动会带来高频运动IMU容易激励过头车载时车身减震会滤掉高频但如果路面太颠簸又会有大量冲击。无论哪种运动尽量平滑都是第一原则。4.2 实时观测RVIZ里哪些现象说明状态不对跑起来之后不要只顾着截图发朋友圈要学会看RVIZ里的实时状态。最核心的观测目标是地图点云是否干净。正常建图时墙体应该呈现为清晰的平面边缘锐利地面应该是一条平直的面没有厚厚一层“雾”。如果地图里有明显的重影、墙壁双层、地面反复说明当前帧和地图之间的匹配出现了问题算法在错误的位姿上不断累积。另一个观测点是路径轨迹。RVIZ里通常会显示雷达的运动轨迹轨迹应该是平滑的。如果轨迹出现瞬移、跳变、锯齿状说明状态估计在某个时刻发生了严重异常可能是外参错误、时间同步有问题也可能是运动太剧烈导致IMU饱和。还有一个容易被忽略的信号地图突然朝某一方向偏移并持续下去。这通常是IMU零偏没有收敛好或者某一帧点云匹配上了错误的地图区域比如跑到镜子旁边镜面把点云反射到错误位置。一旦发现地图在实时画面上就有问题不要妄想后期能修复先把数据采集停下来排查。4.3 地图重影、断层与漂移的现场排查我整理了一张排查顺序表按优先级排列现象最可能原因先查什么地图重影/双层墙时间同步未开启或外参错误time_sync_en是否打开、外参数值地面厚厚一层/断层blind参数过小、近处噪点未过滤blind值调到4m以上轨迹跳变/空中漂移IMU激励不足、外参不准是否做过“8”字初始化地图整体缓慢倾斜重力初始化失败上电后是否静止足够久大场景首尾不闭合无回环约束路线是否成环、是否走重复路径重影这个问题最值得展开。有一次帮朋友调试他们的小车在走廊里来回跑地图每经过一个来回就开始出现双层墙。第一反应改外参改了半天没用。后来我查了一下他们的驱动配置发现time_sync_en根本没有打开点云和IMU的时间戳差了上百毫秒。开启时间同步后重影立刻消失。这个坑太典型了所以我把时间同步列为排查优先级的第一位。漂移问题则是另一种情况。长距离大范围的场景无论FAST-LIO2多强没有回环检测就一定有累积误差。这种情况我能给的实用建议是建图时多折返、多闭合或者在关键转折点稍微停留几秒让算法充分收敛。后期如果还漂可以用后半程的点云后处理和全局配准来补救这一点放在第六章讲。5. 高精度调优外参、噪声参数与场景适配跑通是第一步把地图精度从“能看”提升到“能用”就要进到参数调优阶段。FAST-LIO2最关键的几个配置都集中在yaml文件里很多人不敢动也有很多人乱动乱动的结果就是地图越调越飘。5.1 lidar到IMU外参标定高精度的命门外参是雷达坐标系和IMU坐标系之间的旋转和平移用外参矩阵描述。Mid-360内置IMU的优势在于雷达和IMU之间是固定刚性连接没有安装松动问题。但出厂给的默认外参只能作为参考实际上每一台设备的装配都存在微小差异。对于高精度建图建议至少做一次标定并验证它。FAST-LIO2自身支持外参在线估计。在mid360.yaml里把extrinsic_est_en改成true跑一段包含充分运动的数据算法会实时估算外参。我的建议是用这个方式跑完一整段数据后看估算值是否收敛如果收敛到一个稳定值就把这个值固化到extrinsic_T和extrinsic_R里然后把extrinsic_est_en设回false。固定外参跑状态估计的稳定性通常优于在线估计。平移外参的单位是米旋转外参一般用3x3旋转矩阵表示yaml里写的是按行展开的9个数字。修改时要特别小心顺序我曾经看到一个用户把旋转矩阵的行列顺序搞反导致地图整个翻转。确认顺序最直接的办法是看官方示例文件里的注释或者跑一段已知几何结构的数据去验证。5.2 噪声参数别乱改理解acc_cov和gyr_covFAST-LIO2配置里的acc_cov和gyr_cov分别是加速度计和陀螺仪的测量噪声方差接下来的b_gyr_cov和b_acc_cov是零偏随机游走噪声。这些参数的本质是告诉滤波器“你认为IMU的数据有多可信”。如果把噪声设得很小滤波器会极度信任IMU短时间内轨迹预测很平滑但如果实际IMU噪声没那么低长时间运行误差会越积越大最终导致地图扭曲甚至发散。反过来噪声设得太大滤波器又会过度依赖激光点云地图会表现出明显的帧间抖动。对Mid-360内置的BMI088来说FAST-LIO2默认的acc_cov0.1、gyr_cov0.1是经过大量测试的经验值大多数场景下直接用是没问题的。我建议除非有明确的物理依据比如实际传感器数据方差明显不同否则不要随意改这两个值。真正值得去调的是零偏随机游走那一组它们在长时间运行中影响更大。5.3 几类典型场景的参数基准与体验值以我自己的实测数据为基础给几个典型场景的参数配置参考场景det_rangeblindacc_covgyr_cov备注室内小空间20m4-6m0.10.1点云充足参数宽容室内大厂房30m6-8m0.10.1避免远处噪声污染室外园区30m4m0.20.2阳光干扰时适当放宽噪声长直走廊/隧道25m5m0.050.05更信任IMU以抑制退化漂移这里有一个取舍逻辑在特征退化场景长直走廊中激光提供的约束不可靠此时稍微调小IMU噪声让滤波器更依赖IMU的短期预测能明显抑制漂移。但代价是如果实际IMU噪声偏大长时间运行反而更容易发散。所以这一招要谨慎使用每次调整后都要用同一段bag去对比验证。另外多说一句fov_degree这个参数决定了点云被用于匹配的水平范围。Mid-360本身是360度视场默认设360没毛病。但如果你的安装环境里身后有遮挡或干扰可以把它缩小只让雷达面向运动方向的180度点云参与匹配反而能提高稳定性。前提是你的算法工作条件允许这种非对称观测。6. 点云后处理建完图之后的最后一公里地图建完很多人的工作就停了。但实际上原始输出的点云地图往往不能直接给下游用。要么是坐标系不对要么是噪声太多要么是文件格式不兼容。这一章讲讲建完图之后的处理流程。6.1 从ROS bag到PCD文件保存与转换FAST-LIO2提供了地图保存功能在mid360.yaml里把pcd_save_en设为true就能够在程序结束时把地图保存为PCD文件。需要留意的是保存路径一般默认指向~/.ros/目录文件名通常带一长串时间戳。跑完后可以去这个目录找找看别到别的地方瞎翻。如果建图过程中没有开启pcd_save_en也没关系。你只要有ROS bag随时可以回放再启动一个pcl_ros的节点把PointCloud2话题录下来转成PCD。比较常见的转换方法是rosrun pcl_ros pointcloud_to_pcd input:/cloud_registered这个命令会持续接收话题上的每一帧点云并把它们分别保存为一个个PCD文件。需要注意的是它保存的是每一帧点云不是拼接后的全局地图。如果你要的是完整的建图结果最好用FAST-LIO2自带的保存功能或者在建图结束后单独触发一次全局地图的发布与录制。保存出来的PCD文件可以用CloudCompare直接打开。CloudCompare这个工具我要认真推荐一下它是我见过最顺手的点云可视化与处理工具跨平台、免费、功能全解决点云后处理的大部分需求。6.2 CloudCompare里的配准、去噪与栅格化建图过程中如果采集了几段独立的数据最后需要把片段对齐成一张完整地图。CloudCompare里可以做手动配准也可以做ICP自动配准。手动配准的思路是先选3组以上的同名点对让两片点云大致对齐然后再用ICP精配准。实操时注意同名点要选在几何特征明显的角落、柱子的根部这类位置别选在大平面上否则对齐效果会很差。去噪是另一个高频操作。雷达扫描在边缘处很容易产生离散噪点CloudCompare里的SORStatistical Outlier Removal滤波很实用。它的原理是统计每个点的近邻距离分布把偏离平均值过大的点标记为离群点并删除。参数方面邻域点数设6到10阈值设在1到2个标准差之间效果都还不错。有朋友问过我CloudCompare怎么把点云保存成tif格式这其实是用栅格化功能实现的。操作路径是Tools Projection Rasterize选择要生成的方向通常是Z轴设置好网格分辨率云生成带有高程信息的GeoTIFF或普通TIF。栅格化之前最好先把点云地面部分滤除否则高程会被地面点拉平细节全丢。如果你要的是包含强度信息的tif也可以选强度作为栅格化值具体取决于下游需求。6.3 给下游用的坐标变换和地面去除点云地图最终通常是给导航、路径规划或三维重建用的。这些下游模块对坐标系的约定往往不同所以坐标变换是绕不开的一步。最简单的做法是在CloudCompare里手工施加变换矩阵Edit Apply transformation里输入3x3旋转加3x1平移。如果地图方向混乱可以先在CloudCompare里用“Edit Rotate”大致转到水平再做一次精确的平面拟合校准。平面校准有一个小技巧用Tools Fit Plane选地面上的点拟合出一个平面看平面的法向量是否接近(0,0,1)如果不是就按偏差手动转回去。这个方法我用了很多次非常可靠。地面去除通常用CSFCloth Simulation Filtering算法CloudCompare的插件库里直接有。它的思路很巧妙把点云倒扣过来模拟一块布料落到地形上贴合地面的部分就是地面点其余的就是非地面点。处理城市道路、园区这类场景效果很好参数默认就能用。地面去除之后地图会更干净导航的代价地图生成也会更容易。7. 写在最后几件让我少走弯路的小事顺着这套流程走下来大部分人都能把Mid-360和FAST-LIO2跑起来建出一张像模像样的图。最后再补几个我踩过、别人也大概率会踩的小细节。第一建图过程中工控机最好用固态硬盘而且保持足够的剩余空间。录bag很占存储一张十几分钟的数据就要好几个GB。我遇到过一次跑着跑着中途磁盘写满bag没录完整地图也保存失败白干一场。第二网络稳定性别忽视。雷达通过网口传数据网线和接口质量不好可能表现为点云帧率不稳、偶尔断流。如果你发现建图时地图某个区域突然缺了一块先怀疑网络而不是算法。第三Mid-360长时间连续运行外壳会明显发热。温度升高后测距噪声和抖动会有一定幅度的上升。如果做长时间采集建议每两小时左右让设备休息一下这也是我自己的习惯。第四也是最想强调的一点建图数据和算法版本要对应。同一个bag用不同版本的FAST-LIO2跑结果会有差异。所以做实验对比时尽量固定代码版本和参数否则你很难判断地图变好变坏到底是参数引起的还是代码升级带来的。从最开始一个多月的折腾到现在基本能做到“采集完一跑就出图”Mid-360加FAST-LIO2这套组合确实帮团队节省了大量时间。希望这篇东西能让你少走点弯路把精力花在真正有价值的事情上。 1. 为什么我最终把主力建图设备换成了Mid-360差不多两年前我还在为巡检机器人底盘选建图方案发愁。当时手里有一台16线机械式雷达配LOAM系算法跑室内小场景还行一到室外或者稍大一点的环境就开始闹脾气点云稀疏导致转角处墙体扭曲机械旋转结构在颠簸路面上容易出问题而且整个设备体积不小装在小车顶部总担心撞到门框。后来换了Livox Mid-360搭配FAST-LIO2这才算真正把“点云采集到高精度建图”这条链路走顺了。这套组合并不神秘但网上能查到的资料大多是官方文档式的干条条真正实操里的坑很少有人系统讲。这篇东西就按我实际跑过的流程来从设备特性、算法原理、环境编译、采集习惯、参数调优到点云后处理把整条线捋一遍。适合正在折腾Mid-360建图、或者打算入坑FAST-LIO2的朋友哪怕你之前没碰过激光雷达SLAM照着走也能少踩一半的坑。1.1 它不是机械雷达非重复扫描到底改了什么Mid-360是一台混合固态激光雷达这一点如果没理解透后面很多操作都会走弯路。传统的16线、32线机械雷达靠电机带动激光头旋转一帧点云里每条扫描线在水平方向上是均匀分布的所以直接给到后续算法就能拿到结构完整的扫描帧。Mid-360完全不是这个逻辑。它在内部用三个固态激光模块拼接出水平360度的覆盖范围激光束的指向通过棱镜控制扫描轨迹是一种花瓣状的密集曲线。带来的结果就是单帧点云的分布非常不均匀中心区域密集、边缘稀疏同一片区域盯住看几秒钟点云会越来越密这就是非重复扫描的核心特性。这个特性直接影响算法选型。传统的特征提取类SLAM算法比如LOAM系要求每帧点云里有稳定可提取的角点和面点但Mid-360单帧点云在某些角度上可能稀疏到提取不出足够的特征。FAST-LIO2就没有这个问题它不做特征提取直接拿原始点云和地图匹配点云稠密反而更好。所以Mid-360和FAST-LIO2这套组合不只是“能跑”而是原理上就合拍。下面这个表是Mid-360的关键参数玩这个设备最好背下来参数数值实际意义水平视场角360°无盲区适合室内外巡检垂直视场角70.4°上63.4°/下7°仰视能力很强俯视很弱测距量程40m80%反射率实际可靠距离约30m点频200,000点/秒单帧约2万点10Hz测距精度±2cm建图几何精度的下限内置IMUBMI088含加速度计和陀螺仪别小看这个内置IMU。FAST-LIO2是激光惯性紧耦合算法雷达和IMU的数据时序是否对齐、外参标定是否准确直接决定地图质量。Mid-360把IMU集成在设备内部出厂时雷达和IMU已经做了固件级同步这等于帮我们省掉了外挂IMU的硬件安装误差是这套组合能跑出稳定地图的重要原因。1.2 FOV的坑往上能“看天”往下却有个死角Mid-360垂直视场是向上63.4度、向下7度这个分布和常见的机械雷达差别很大。机械雷达一般是上下对称15度到25度所以很多用惯了机械雷达的人拿到Mid-360后第一反应是“怎么看不到地面”。实际使用中向下7度意味着如果雷达水平安装正下方会形成一个很大的盲区。手持设备时脚下大约1到2米范围的扇形区域是点云缺失的。解决办法一般有两个一个是把雷达稍微倾斜安装让视场偏向地面另一个是在建图时注意扫描姿态不要全靠雷达朝下而是通过设备运动让两侧地面进入视场。还有一个容易被忽略的点Mid-360向上视场很大安装在小车上时顶部扫到的常常是天花板、树干、屋檐这类东西这些特征对定位其实是好东西因为高层特征不容易被行人、车辆遮挡。但如果雷达上方正好被支架挡住相当于浪费了半个视场。我见过有人把雷达装在金属壳里只露出侧面一圈建图效果大打折扣后来拆掉外壳立刻就好了。另外说一句盲区处理。08年接触lidar的人都知道激光雷达近距离都有盲区Mid-360在10到30厘米范围内会有一些不稳定的近距离噪点。FAST-LIO2的配置里有个blind参数就是用来忽略这些近距离点的后面调参部分我再细讲。2. FAST-LIO2到底在算什么紧耦合与ikd-Tree算法黑箱是最容易让人翻车的地方。很多人用FAST-LIO2跑出图来但不知道为什么有时候稳如老狗、有时候突然飞掉。要真正驾驭这套系统至少要把两件事搞明白紧耦合的数学含义以及ikd-Tree在地图维护里扮演的角色。2.1 紧耦合是数学上的紧不是后补的“配准滤波”很多SLAM框架是“前端配准、后端滤波”两条线比如先通过ICP算出两帧之间的位姿再扔给卡尔曼滤波做平滑。这种松耦合方案里前端一旦算错后端只能被动接受错误。FAST-LIO2不同。它的状态估计核心是迭代误差状态卡尔曼滤波IESKFIMU数据负责状态传播激光点云数据负责更新修正。IMU的预测和激光的观测在同一个数学框架里交替迭代每一轮激光迭代都会重新评估IMU传播过来的状态这就是“紧耦合”的准确含义。更关键的是FAST-LIO2不做特征提取。它把每一帧点云里的点直接和ikd-Tree里的地图点做最近邻匹配用点到面的残差去更新状态。这意味着算法对点云密度的利用是充分的Mid-360那种非重复扫描形成的稠密点云在它手里是优势而非负担。我在实际测试中发现同样的传感器套件FAST-LIO2跑出来的地图比LOAM系干净很多尤其在墙面、柱子这类平面结构上厚度能控制在5厘米以内。对应用户来说这个原理带来的行为特征就是FAST-LIO2对“特征缺失”比“点云稀疏”更敏感。走在一条又长又直的走廊里两侧墙壁平行雷达能看到的几何约束退化成单一方向这时候即使点云再密算法也容易在走廊方向上产生漂移。这不是算法垃圾是观测信息本身的物理局限。理解了这一点才能理解为什么采集时一定要多走“8”字。2.2 ikd-Tree增量维护地图解决“边建边查”的瓶颈地图匹配这种操作本质上是“新来一帧点云要去一个庞大的点云库里找最近邻”。如果地图里有几十万个点每帧都重新建一棵kd-tree计算量会爆炸。早期很多建图方案跑大场景越来越卡就是因为这个。ikd-Tree的核心贡献是增量更新。新点云插入地图后树结构只需做局部重平衡而不是全局重建同时它还支持按范围删除体素这样地图规模可以被控制住不会无限膨胀。FAST-LIO2能在大范围环境里保持实时性整个系统在普通工控机上跑到20Hz以上毫无压力ikd-Tree功不可没。这里牵出一个实操概念FAST-LIO2的地图不是“建完就完”而是在整个运行过程中始终保持着一个局部地图或全局地图具体配置取决于场景。如果做几十米的小场景维护全局地图没什么问题但如果是长距离的园区巡检地图点数量会迅速增长即使有ikd-Tree计算负载也会上来。这时候可以考虑调小det_range让算法只维护雷达周围30米内的地图既有足够的局部约束又避免远点拖慢速度。我见过最典型的错误就是把det_range设成雷达标称的40米甚至60米结果地图建着建着开始卡顿、甚至无故跳变。原因就是远处点云里混入大量低置信度的噪声点地图被它们污染了。这类参数不是越大越好后面调参章节还会展开。3. 环境搭建与驱动联调最容易翻车也最值得花时间很多朋友拿到设备第一步就是git clone、catkin_make结果被一堆依赖和版本问题卡了一整天。这块我建议按顺序来别跳步。3.1 接线、供电与TimeSync同步Mid-360通过网口输出数据支持PoE供电所以链路很简单雷达网口直接插到工控机的千兆网口上如果工控机网口不带PoE就需要在中间串一个PoE供电模块。网络配置这一环不少人卡在IP上。Mid-360支持广播自动发现一般装好Livox Viewer后它会自己找到设备不需要手工改默认IP。但你工控机网卡需要配到同一网段最稳妥的做法是设置静态IP比如192.168.1.50子网掩码255.255.255.0。如果Liveox Viewer发现不了设备第一反应不是重装驱动而是先ping一下设备地址再检查防火墙。Ubuntu上偶尔会遇到防火墙拦截广播包的问题直接关掉或放行即可。TimeSync时间同步是重头戏。FAST-LIO2对雷达和IMU的时间戳一致性要求很高如果时间不对齐最典型的症状是建图过程中地图出现周期性扭曲或者抖动。Livox驱动里有一个time_sync_en的选项打开后系统会通过PTP等方式同步设备时钟和主机时钟。我的建议是只要跑FAST-LIO2就把时间同步打开不要图省事关掉。还有一个容易忽略的供电问题PoE模块选质量好一点的电压不稳时雷达会掉线或点云出现大量空洞。我开始用了一个杂牌PoE分离器建图建到一半雷达就失联排查了半天才发现是供电不足。这种问题和你跑什么算法无关纯粹是硬件链路的坑。3.2 编译FAST-LIO2时的版本问题编译环境我以Ubuntu 20.04 ROS Noetic为例这套组合目前是社区里最成熟的。如果用的Ubuntu 18.04 ROS Melodic操作也类似注意Eigen版本别太低。sudo apt update sudo apt install ros-noetic-pcl-ros ros-noetic-pcl-conversions ros-noetic-eigen-conversions mkdir -p ~/catkin_ws/src cd ~/catkin_ws/src git clone https://github.com/hku-mars/FAST_LIO.git git clone https://github.com/Livox-SDK/livox_ros_driver2.git cd ~/catkin_ws catkin_make source devel/setup.bash编译过程中最常遇到的坑有两个。第一个是Eigen版本陈旧导致编译报错建议先确认一下Eigen3的版本不低于3.3.7。第二个是livox_ros_driver2和老版本livox_ros_driver的冲突如果之前装过老版驱动最好先卸载干净否则会出现接口不匹配导致FAST-LIO2订阅不到点云话题。FAST-LIO2里关于激光雷达类型需要确认一下。它支持Livox和标准点云两种输入如果是用Mid-360就要确保配置里lidar_type正确设置为Livox对应值以及点云话题是/livox/lidarIMU话题是/livox/imu。如果话题没对上运行起来会发现RVIZ里没有任何点云实际上就是下游根本没收到数据。3.3 先用官方数据集跑通再上真机这一步强烈建议新手不要跳过。真机调试涉及供电、网络、运动姿态、环境特征一堆变量一旦地图没出来你根本分不清是哪里出了问题。先跑官方bag文件把算法链路验证通了再去碰真机排查范围能缩小一半。Livox官方和一些开源项目都提供了包含Mid-360点云和IMU数据的bag文件。启动方式很简单roslaunch fast_lio mapping_mid360.launch然后再找个终端播放bagrosbag play your_bag.bag看到RVIZ里出现实时构建的地图说明编译、驱动、话题、参数基本都没问题。我一般会盯着看两三分钟确认地图稳定不飘、不跳变再拔掉bag换真机。这一步还有一个隐藏价值你可以把官方bag当成一个固定的“测试基准”。以后改参数、换环境、升代码都拿同一个bag跑一遍对比地图质量就能快速判断改动是变好还是变坏。没有这个基准你会陷入“改了参数但环境变了所以不确定有没有改善”的困境里。4. 实机建图从采集习惯到实时地图诊断链路通了下一步就是拿真机跑。很多人到了这一步反而最容易翻车因为算法能跑起来不代表能建出高质量地图。我发现建图质量的下限往往不是由算法决定而是由采集习惯决定的。4.1 采集动作规范怎么走决定了地图会不会飘建图前的第一步是静止初始化。设备上电后让雷达和IMU保持静止3到5秒这段时间IMU会完成零偏估计和重力方向的初始对齐。没有这一步算法开局就带着一个错误的重力估计后面地图整体倾斜都不是怪事。静止完还不能马上进入正式采集建议先做一段“8”字运动。绕“8”字的意义在于它同时包含平移和旋转激励能把IMU的三种轴都激活起来滤波器才能准确估计各项状态。我一般会先在周围走一个半径3米左右的“8”字持续10到15秒再开始正式建图路线。正式采集时记住几个原则匀速慢走别急加速急转弯遇到长走廊有条件就走完再折返不要只走单程经过已走过的区域时尽量形成闭环。为什么强调闭环因为FAST-LIO2本身没有回环检测和全局优化它靠的是局部帧间匹配的累积。如果整个路线从头到尾都不闭合误差就会一路积累最后地图首尾对不上。走个闭环至少可以让累积误差不往无限方向发展。手持采集和车载采集还有个小区别手持时手部抖动会带来高频运动IMU容易激励过头车载时车身减震会滤掉高频但如果路面太颠簸又会有大量冲击。无论哪种运动尽量平滑都是第一原则。4.2 实时观测RVIZ里哪些现象说明状态不对跑起来之后不要只顾着截图发朋友圈要学会看RVIZ里的实时状态。最核心的观测目标是地图点云是否干净。正常建图时墙体应该呈现为清晰的平面边缘锐利地面应该是一条平直的面没有厚厚一层“雾”。如果地图里有明显的重影、墙壁双层、地面反复说明当前帧和地图之间的匹配出现了问题算法在错误的位姿上不断累积。另一个观测点是路径轨迹。RVIZ里通常会显示雷达的运动轨迹轨迹应该是平滑的。如果轨迹出现瞬移、跳变、锯齿状说明状态估计在某个时刻发生了严重异常可能是外参错误、时间同步有问题也可能是运动太剧烈导致IMU饱和。还有一个容易被忽略的信号地图突然朝某一方向偏移并持续下去。这通常是IMU零偏没有收敛好或者某一帧点云匹配上了错误的地图区域比如跑到镜子旁边镜面把点云反射到错误位置。一旦发现地图在实时画面上就有问题不要妄想后期能修复先把数据采集停下来排查。4.3 地图重影、断层与漂移的现场排查我整理了一张排查顺序表按优先级排列现象最可能原因先查什么地图重影/双层墙时间同步未开启或外参错误time_sync_en是否打开、外参数值地面厚厚一层/断层blind参数过小、近处噪点未过滤blind值调到4m以上轨迹跳变/空中漂移IMU激励不足、外参不准是否做过“8”字初始化地图整体缓慢倾斜重力初始化失败上电后是否静止足够久大场景首尾不闭合无回环约束路线是否成环、是否走重复路径重影这个问题最值得展开。有一次帮朋友调试他们的小车在走廊里来回跑地图每经过一个来回就开始出现双层墙。第一反应改外参改了半天没用。后来我查了一下他们的驱动配置发现time_sync_en根本没有打开点云和IMU的时间戳差了上百毫秒。开启时间同步后重影立刻消失。这个坑太典型了所以我把时间同步列为排查优先级的第一位。漂移问题则是另一种情况。长距离大范围的场景无论FAST-LIO2多强没有回环检测就一定有累积误差。这种情况我能给的实用建议是建图时多折返、多闭合或者在关键转折点稍微停留几秒让算法充分收敛。后期如果还漂可以用后半程的点云后处理和全局配准来补救这一点放在第六章讲。5. 高精度调优外参、噪声参数与场景适配跑通是第一步把地图精度从“能看”提升到“能用”就要进到参数调优阶段。FAST-LIO2最关键的几个配置都集中在yaml文件里很多人不敢动也有很多人乱动乱动的结果就是地图越调越飘。5.1 lidar到IMU外参标定高精度的命门外参是雷达坐标系和IMU坐标系之间的旋转和平移用外参矩阵描述。Mid-360内置IMU的优势在于雷达和IMU之间是固定刚性连接没有安装松动问题。但出厂给的默认外参只能作为参考实际上每一台设备的装配都存在微小差异。对于高精度建图建议至少做一次标定并验证它。FAST-LIO2自身支持外参在线估计。在mid360.yaml里把extrinsic_est_en改成true跑一段包含充分运动的数据算法会实时估算外参。我的建议是用这个方式跑完一整段数据后看估算值是否收敛如果收敛到一个稳定值就把这个值固化到extrinsic_T和extrinsic_R里然后把extrinsic_est_en设回false。固定外参跑状态估计的稳定性通常优于在线估计。平移外参的单位是米旋转外参一般用3x3旋转矩阵表示yaml里写的是按行展开的9个数字。修改时要特别小心顺序我曾经看到一个用户把旋转矩阵的行列顺序搞反导致地图整个翻转。确认顺序最直接的办法是看官方示例文件里的注释或者跑一段已知几何结构的数据去验证。5.2 噪声参数别乱改理解acc_cov和gyr_covFAST-LIO2配置里的acc_cov和gyr_cov分别是加速度计和陀螺仪的测量噪声方差接下来的b_gyr_cov和b_acc_cov是零偏随机游走噪声。这些参数的本质是告诉滤波器“你认为IMU的数据有多可信”。如果把噪声设得很小滤波器会极度信任IMU短时间内轨迹预测很平滑但如果实际IMU噪声没那么低长时间运行误差会越积越大最终导致地图扭曲甚至发散。反过来噪声设得太大滤波器又会过度依赖激光点云地图会表现出明显的帧间抖动。对Mid-360内置的BMI088来说FAST-LIO2默认的acc_cov0.1、gyr_cov0.1是经过大量测试的经验值大多数场景下直接用是没问题的。我建议除非有明确的物理依据比如实际传感器数据方差明显不同否则不要随意改这两个值。真正值得去调的是零偏随机游走那一组它们在长时间运行中影响更大。5.3 几类典型场景的参数基准与体验值以我自己的实测数据为基础给几个典型场景的参数配置参考场景det_rangeblindacc_covgyr_cov备注室内小空间20m4-6m0.10.1点云充足参数宽容室内大厂房30m6-8m0.10.1避免远处噪声污染室外园区30m4m0.20.2阳光干扰时适当放宽噪声长直走廊/隧道25m5m0.050.05更信任IMU以抑制退化漂移这里有一个取舍逻辑在特征退化场景长直走廊中激光提供的约束不可靠此时稍微调小IMU噪声让滤波器更依赖IMU的短期预测能明显抑制漂移。但代价是如果实际IMU噪声偏大长时间运行反而更容易发散。所以这一招要谨慎使用每次调整后都要用同一段bag去对比验证。另外多说一句fov_degree这个参数决定了点云被用于匹配的水平范围。Mid-360本身是360度视场默认设360没毛病。但如果你的安装环境里身后有遮挡或干扰可以把它缩小只让雷达面向运动方向的180度点云参与匹配反而能提高稳定性。前提是你的算法工作条件允许这种非对称观测。6. 点云后处理建完图之后的最后一公里地图建完很多人的工作就停了。但实际上原始输出的点云地图往往不能直接给下游用。要么是坐标系不对要么是噪声太多要么是文件格式不兼容。这一章讲讲建完图之后的处理流程。6.1 从ROS bag到PCD文件保存与转换FAST-LIO2提供了地图保存功能在mid360.yaml里把pcd_save_en设为true就能够在程序结束时把地图保存为PCD文件。需要留意的是保存路径一般默认指向~/.ros/目录文件名通常带一长串时间戳。跑完后可以去这个目录找找看别到别的地方瞎翻。如果建图过程中没有开启pcd_save_en也没关系。你只要有ROS bag随时可以回放再启动一个pcl_ros的节点把PointCloud2话题录下来转成PCD。比较常见的转换方法是rosrun pcl_ros pointcloud_to_pcd input:/cloud_registered这个命令会持续接收话题上的每一帧点云并把它们分别保存为一个个PCD文件。需要注意的是它保存的是每一帧点云不是拼接后的全局地图。如果你要的是完整的建图结果最好用FAST-LIO2自带的保存功能或者在建图结束后单独触发一次全局地图的发布与录制。保存出来的PCD文件可以用CloudCompare直接打开。CloudCompare这个工具我要认真推荐一下它是我见过最顺手的点云可视化与处理工具跨平台、免费、功能全解决点云后处理的大部分需求。6.2 CloudCompare里的配准、去噪与栅格化建图过程中如果采集了几段独立的数据最后需要把片段对齐成一张完整地图。CloudCompare里可以做手动配准也可以做ICP自动配准。手动配准的思路是先选3组以上的同名点对让两片点云大致对齐然后再用ICP精配准。实操时注意同名点要选在几何特征明显的角落、柱子的根部这类位置别选在大平面上否则对齐效果会很差。去噪是另一个高频操作。雷达扫描在边缘处很容易产生离散噪点CloudCompare里的SORStatistical Outlier Removal滤波很实用。它的原理是统计每个点的近邻距离分布把偏离平均值过大的点标记为离群点并删除。参数方面邻域点数设6到10阈值设在1到2个标准差之间效果都还不错。有朋友问过我CloudCompare怎么把点云保存成tif格式这其实是用栅格化功能实现的。操作路径是Tools Projection Rasterize选择要生成的方向通常是Z轴设置好网格分辨率云生成带有高程信息的GeoTIFF或普通TIF。栅格化之前最好先把点云地面部分滤除否则高程会被地面点拉平细节全丢。如果你要的是包含强度信息的tif也可以选强度作为栅格化值具体取决于下游需求。6.3 给下游用的坐标变换和地面去除点云地图最终通常是给导航、路径规划或三维重建用的。这些下游模块对坐标系的约定往往不同所以坐标变换是绕不开的一步。最简单的做法是在CloudCompare里手工施加变换矩阵Edit Apply transformation里输入3x3旋转加3x1平移。如果地图方向混乱可以先在CloudCompare里用“Edit Rotate”大致转到水平再做一次精确的平面拟合校准。平面校准有一个小技巧用Tools Fit Plane选地面上的点拟合出一个平面看平面的法向量是否接近(0,0,1)如果不是就按偏差手动转回去。这个方法我用了很多次非常可靠。地面去除通常用CSFCloth Simulation Filtering算法CloudCompare的插件库里直接有。它的思路很巧妙把点云倒扣过来模拟一块布料落到地形上贴合地面的部分就是地面点其余的就是非地面点。处理城市道路、园区这类场景效果很好参数默认就能用。地面去除之后地图会更干净导航的代价地图生成也会更容易。7. 写在最后几件让我少走弯路的小事顺着这套流程走下来大部分人都能把Mid-360和FAST-LIO2跑起来建出一张像模像样的图。最后再补几个我踩过、别人也大概率会踩的小细节。第一建图过程中工控机最好用固态硬盘而且保持足够的剩余空间。录bag很占存储一张十几分钟的数据就要好几个GB。我遇到过一次跑着跑着中途磁盘写满bag没录完整地图也保存失败白干一场。第二网络稳定性别忽视。雷达通过网口传数据网线和接口质量不好可能表现为点云帧率不稳、偶尔断流。如果你发现建图时地图某个区域突然缺了一块先怀疑网络而不是算法。第三Mid-360长时间连续运行外壳会明显发热。温度升高后测距噪声和抖动会有一定幅度的上升。如果做长时间采集建议每两小时左右让设备休息一下这也是我自己的习惯。第四也是最想强调的一点建图数据和算法版本要对应。同一个bag用不同版本的FAST-LIO2跑结果会有差异。所以做实验对比时尽量固定代码版本和参数否则你很难判断地图变好变坏到底是参数引起的还是代码升级带来的。从最开始一个多月的折腾到现在基本能做到“采集完一跑就出图”Mid-360加FAST-LIO2这套组合确实帮团队节省了大量时间。希望这篇东西能让你少走点弯路把精力花在真正有价值的事情上。