mid360+FAST-LIO2部署全攻略：从驱动编译到建图实战

简介本资源是一份面向机器人与自动驾驶领域初/中级开发者的技术集成指南聚焦于Livox MID-360激光雷达在Ubuntu 18.04平台上的完整部署与FAST-LIO2紧耦合定位系统验证。解决的核心问题是多组件协同适配难题——涵盖Livox SDK 2驱动层、Livox-ros-driver2 ROS中间件封装、以及FAST-LIO2的点云-IMU联合里程计实时建图能力落地。资源以单个HTML网页文件19KB形式提供内容结构清晰包含环境依赖检查、分步编译指令、参数配置说明、实机数据采集与rviz可视化验证全流程并附关键报错日志分析与典型调试技巧。已有276人学习下载适合需快速搭建高精度LiDAR惯性SLAM开发环境的研究人员与工程实践者可直接复用配置逻辑、规避常见兼容性陷阱显著缩短从驱动安装到算法跑通的周期。 去年我第一次把 mid360 接到工控机上跑 FAST-LIO2以为照着 GitHub 的 README 敲几行命令就能完事结果编译环境、驱动配置、坐标系对齐这三个环节每个都卡了将近一天。后来把所有步骤重新梳理了一遍才发现整套链路其实并不复杂难的是中间那些没人写在 README 里的依赖关系、版本匹配和配置细节。这篇教程就按我实际部署的顺序完整走一遍 mid360 Livox-SDK2 Livox-ros-driver2 FAST-LIO2 的搭建过程把每一步为什么这么做、常见坑在哪都讲清楚给准备用这套组合做建图或者跑 SLAM 的同学一个可以直接照做的参考。这套组合的特点很鲜明mid360 负责采集 360 度点云和内置 IMU 数据Livox-SDK2 负责和雷达通信Livox-ros-driver2 把点云封装成 ROS 话题FAST-LIO2 负责把点云和 IMU 数据融合成实时位姿并增量建图。四层各司其职只要每一层都正确安装和配置整条链路就能跑通。适合正在做机器人导航、无人机/机器狗建图、以及需要用固态激光雷达做实时定位的同学参考。1. 为什么是 mid360 和 FAST-LIO2这套组合的选型逻辑1.1 mid360 解决了什么问题mid360 是 Livox 推出的 360 度固态激光雷达它不是传统机械旋转雷达那种外部电机带动激光头旋转的结构而是内部通过棱镜扫描实现 360 度覆盖。这个设计带来的直接好处是体积小、重量轻、抗振动非常适合装在机器狗、无人机和轮式机器人上。它的关键参数值得先弄清楚因为后面配置参数的时候会反复用到参数数值说明水平视场角360°完整圆扫垂直视场角-7° ~ 52°非对称偏上扫探测距离40m 90% 反射率实际室内 20m 内效果更稳点频200,000 pts/s单回波点密度够用点云帧率10 Hz一圈一个点云帧内置 IMU 频率200 Hz硬件紧耦合时间同步方便最小探测距离0.05m近距盲区很小适合室内很多人选 mid360 而不是传统 16 线机械雷达最大原因就是它的近距盲区极小。机械雷达往往 0.3m 以内什么都看不到而 mid360 在 5cm 就能出点这在室内走廊、狭窄门洞场景里非常关键。我实测过贴着墙面走过去点云依然连续不会断。另外 mid360 内置 IMU 这一点对 FAST-LIO2 这种紧耦合激光惯性算法来说非常友好。IMU 频率 200Hz激光帧率 10Hz两者在硬件内部共享时钟源时间同步天然准确省掉了很多激光雷达外接 IMU 时对时间戳的麻烦。1.2 FAST-LIO2 为什么是首选建图算法FAST-LIO2 是港大 MaRS 实验室开源的激光惯性里程计算法相比第一版核心改进是使用 ikd-Tree 作为增量式点云地图数据结构避免了每帧全量匹配整张地图的开销。简单说它只在地图发生变化局部区域做调整而不是每次都从零开始扫描匹配所以计算量明显更低。它还有一个特点紧耦合的卡尔曼滤波把点云配准和 IMU 预测融在一起即使激光退化比如长走廊、空旷大厅只要 IMU 还在运动激励位姿就不会立刻飘掉。这套特性天然适合 mid360因为 mid360 的 10Hz 点云频率不算高如果只用纯激光匹配运动一快就容易丢但有了 200Hz IMU 支撑整体鲁棒性就上来了。在开源方案里和 FAST-LIO2 同类的竞争者主要是 LIO-SAM、LIO-SAM 的固态激光雷达适配版以及 LVI-SAM 这类视觉激光融合方案。FAST-LIO2 的明显优势是代码结构清晰、参数少、上手快而且官方仓库直接提供了 mid360 的 launch 和 yaml 模板几乎不用改代码就能跑这对新手太重要了。1.3 四层软件栈的关系我会习惯把整条链路分成四层来理解Livox-SDK2Livox 官方硬件通信库不依赖 ROS负责和雷达建立网络连接、发送控制指令、接收原始点云数据并解析成 Livox 自定义点云格式。Livox-ros-driver2ROS 驱动层把 SDK2 拿到的数据封装成 ROS 消息主要发布两个话题/livox/lidar输出激光点云/livox/imu输出雷达内置 IMU 数据。FAST-LIO2SLAM 算法层订阅激光和 IMU 话题输出实时位姿/Odometry、轨迹/path和建图点云/cloud_registered。RViz / 后期工具可视化验证层确认点云正常、位姿不发散。理解这四层关系后排查问题就变得很有条理哪一层的数据不对就先定位到哪一层。2. 环境规划Ubuntu、ROS 版本与软件栈的匹配是第一道坎2.1 我推荐的部署链路实际部署前先把系统版本定死别在这一步就埋雷。我踩过的最大坑就是系统版本和 ROS 版本不匹配导致依赖装不上后期反复折腾。当前最稳的组合我建议二选一链路操作系统ROS 版本构建工具FAST-LIO2 分支方案 A推荐Ubuntu 20.04ROS Noeticcatkin_makemaster/main方案 BUbuntu 22.04ROS2 HumblecolconROS2 分支如果你之前完全没接触过这套系统直接选方案 AUbuntu 20.04 ROS Noetic。FAST-LIO2 官方在这个组合下维护得最久网上可查到的报错和解决方案也最多。方案 B 适合你本身已经在用 ROS2、不想单独再装一套 ROS1 的情况。这里有个容易混淆的点Livox-ros-driver2 的仓库同一份代码同时支持 ROS1 和 ROS2编译时根据当前环境自动识别。也就是说不管方案 A 还是 B驱动代码本身不用换分支只是编译工具不同。FAST-LIO2 则需要区分分支ROS1 用默认分支ROS2 要切到ROS2分支。2.2 前置依赖准备无论是哪个方案先执行以下基础依赖安装sudo apt update sudo apt install -y build-essential cmake git如果是要在 ROS1 下编译确保已经完整安装了 ROS Noetic 桌面版如果是 ROS2 方案则是 ROS2 Humble 桌面版。判断 ROS 环境是否就绪最简单的方式是打开新终端分别执行# ROS1 echo $ROS_DISTRO # 输出 noetic 说明正常 # ROS2 echo $ROS_DISTRO # 输出 humble 说明正常FAST-LIO2 编译还会依赖 PCL 和 Eigen。虽然它源码里带了一部分第三方模块但系统层还是建议装好标准库sudo apt install -y ros-$ROS_DISTRO-pcl-ros ros-$ROS_DISTRO-tf2-geometry-msgs libeigen3-devEigen 在 Ubuntu 20.04 默认版本是 3.3.7满足 FAST-LIO2 的要求不需要额外升级。这一步很多人会忽略结果编译到一半报 Eigen 找不到反而浪费时间。2.3 关于编译目录的选择还有一个小建议把 Livox-ros-driver2 和 FAST-LIO2 放进同一个工作空间编译不要分开建两个 workspace。因为 FAST-LIO2 的 CMakeLists 里会查找 livox_ros_driver2 的消息头文件如果分属于不同工作空间编译 FAST-LIO2 时经常报找不到 livox_ros_driver2 的包。后面所有命令我都默认使用~/catkin_wsROS1或~/ros2_wsROS2这一个工作空间两个项目源码都放在 src 下一次编译完成。3. Livox-SDK2 与 Livox-ros-driver2 编译从源码到看到点云3.1 编译 Livox-SDK2先明确一下为什么要编译 SDK2。Livox 官方已经提供了预编译库吗其实没有SDK2 需要从源码编译但过程非常简单几乎不会出问题。cd ~ git clone https://github.com/Livox-SDK/Livox-SDK2.git cd Livox-SDK2 mkdir build cd build cmake .. -DCMAKE_BUILD_TYPERelease make -j$(nproc) sudo make install编译完成后库文件会被安装到/usr/local/lib头文件在/usr/local/include/livox。验证是否安装成功可以看/usr/local/lib下是否存在liblivox_sdk2.so之类的文件。这里补充一个容易踩坑的细节如果你的系统里同时装过旧版 Livox SDK第一代建议先卸载干净否则运行时可能出现库文件冲突。SDK2 和 SDK1 的头文件路径、库名不完全相同但某些老项目会默认链接旧库导致新版驱动运行时崩溃。3.2 编译与配置 livox_ros_driver2接下来把驱动源码放进 ROS 工作空间# ROS1 方案 mkdir -p ~/catkin_ws/src cd ~/catkin_ws/src git clone https://github.com/Livox-SDK/Livox-ros-driver2.git cd ~/catkin_ws catkin_make source devel/setup.bash # ROS2 方案 mkdir -p ~/ros2_ws/src cd ~/ros2_ws/src git clone https://github.com/Livox-SDK/Livox-ros-driver2.git cd ~/ros2_ws colcon build --packages-select livox_ros_driver2 source install/setup.bash编译完成后最关键的一步是修改雷达通信配置。配置文件在src/livox_ros_driver2/config/MID360_config.json这是整套链路上最容易被忽略、却最容易导致雷达连不上的地方。打开这个文件重点看两个字段{ user_config_ip: 192.168.1.50, device_list: [ { broadcast_code: 000000000000001, user_config_ip: 192.168.1.50, enable: true } ] }user_config_ip必须设置成你电脑网卡的 IP 地址不是雷达的 IP。mid360 默认 IP 是192.168.1.12具体以机身标签和设备手册为准你要把电脑网卡手动设为同网段比如192.168.1.50子网掩码255.255.255.0不使用 DHCP。broadcast_code是每台 mid360 唯一的广播码机身标签上印着。只接一台雷达时把广播码填对或留空让驱动自动发现都可以但如果机器上有多个网卡或接过多台雷达建议写死广播码避免驱动误连。配置修改完测试驱动# ROS1 roslaunch livox_ros_driver2 msg_MID360.launch # ROS2 ros2 launch livox_ros_driver2 msg_MID360.launch.py正常情况下终端会打印出雷达固件版本、广播码、IP 等信息并持续输出点云数据。3.3 验证点云用 RViz 确认数据流驱动起来后先别急着跑 FAST-LIO2这一步多花 5 分钟确认数据没问题能省后面大量排查时间。打开新终端用命令确认话题存在# ROS1 rostopic list | grep livox # 期望看到 /livox/lidar 和 /livox/imu # ROS2 ros2 topic list | grep livox # 期望看到 /livox/lidar 和 /livox/imu再确认话题是否有数据在发布# ROS1 rostopic hz /livox/lidar # 期望 10Hz 左右 rostopic hz /livox/imu # 期望 200Hz 左右 # ROS2 ros2 topic hz /livox/lidar ros2 topic hz /livox/imu如果你在 RViz 里添加 PointCloud2 话题还看不到点云最常见的原因不是驱动而是 Fixed Frame 设置不对把全局坐标系改成livox_frame或map再试。我把这一步单独拎出来讲是因为很多人习惯跳过验证直接跑建图结果建图一发散就以为是算法问题实际上从底层点云就是乱的。数据链路干净FAST-LIO2 才有正确输入。4. FAST-LIO2 编译、launch 定制与坐标系对齐4.1 编译 FAST-LIO2驱动验证通过后接着编译 FAST-LIO2。和前面目录规划一致我把 FAST-LIO2 也放进同一个工作空间# ROS1 方案 cd ~/catkin_ws/src git clone https://github.com/hku-mars/FAST_LIO.git cd ~/catkin_ws catkin_make source devel/setup.bash # ROS2 方案 cd ~/ros2_ws/src git clone -b ROS2 https://github.com/hku-mars/FAST_LIO.git cd ~/ros2_ws colcon build --packages-select fast_lio livox_ros_driver2 source install/setup.bash这里有个注意事项ROS2 方案里 colcon build 时把fast_lio和livox_ros_driver2写在一起确保 fast_lio 能解析到 livox 的自定义消息类型。ROS1 方案用 catkin_make 一次编译整个工作空间即可不用指定包名。如果编译报错Could not find a package configuration file provided by livox_ros_driver2九成是因为两个包没在同一个工作空间或者编译前没有先编译 livox_ros_driver2。你可以先单独编译一次驱动并 source再回来编 FAST-LIO2。4.2 mid360.yaml 参数解读FAST-LIO2 仓库自带的 mid360 配置模板已经非常完善路径在config/mid360.yaml。不建议从零开始写直接在模板基础上改。核心参数的作用我整理如下参数作用建议值lid_topic订阅的点云话题/livox/lidarimu_topic订阅的 IMU 话题/livox/imutime_sync_en是否启用时间同步falsemid360 硬件已同步extrinsic_est_en是否在线估计雷达到 IMU 外参falsemid360 内置 IMU外参已知point_filter_num点云抽稀间隔台式机 1 ~ 2嵌入式 3scan_line等效扫描线数16maximum_incident_angle最大入射角过滤3.0模板值够用max_iteration每帧最大迭代次数3模板值够用重点说extrinsic_est_en。mid360 的激光和 IMU 集成在一个结构体内部出厂时外参是确定的所以这个参数保持 false 即可。如果你把它开成 trueFAST-LIO2 会在线估计外参虽然也能收敛但前期会有一段不稳定期点云可能轻微扭曲。只有当你外接独立 IMU 时才需要开后面会详细讲。point_filter_num是使用过程中最值得调的一个参数。mid360 每秒 20 万点FAST-LIO2 在配置 0 表示不过滤配 2 表示每 3 个点保留 1 个。实测在 i5 级别的台式机上用 1 很流畅在 Jetson Orin 这类嵌入式平台上建议用 2 或 3CPU 占用能明显降下来而地图精度肉眼几乎看不出差别。4.3 倾斜安装时的坐标系对齐问题这是联网搜索里很多人都遇到过的问题标题也专门提到mid360 倾斜雷达坐标系对齐。先说明一个容易混淆的点如果你的 mid360 只是整体倾斜安装比如装在机器人前斜面上雷达坐标系和 IMU 坐标系之间的相对关系并没有变因为 IMU 也跟着雷达一起倾斜所以 FAST-LIO2 中的外参不需要改直接单位矩阵就行。真正需要处理坐标系对齐的是两种情况。第一种你用的不是 mid360 内置 IMU而是外部 IMU。这时雷达到外置 IMU 的变换不再是单位矩阵必须标定。常见做法是先做一个初始量测把 mid360 底面中心到 IMU 中心的三轴平移量用卡尺量出来填入extrinsic_T旋转部分则通过一段静止和运动数据用工具标定。没有精确外参FAST-LIO2 基本必飘。第二种mid360 点云本身需要转换到另一个目标坐标系比如双雷达融合时要把辅助雷达的点云转到主雷达坐标系下。这个在 livox_ros_driver2 的配置文件里处理把外参填进去驱动在发布点云前就会提前完成坐标变换FAST-LIO2 侧不需要改代码。我在实际部署中遇到过一次看起来对齐了但地图始终有重影的情况最后发现是辅助雷达的 roll 角填反了符号。这类问题排查时可以固定雷达用手轻轻转动雷达或平移观察 RViz 里两个点云是否能始终保持重合如果朝向一致但偏移恒定基本就是平移外参的问题如果相对旋转则要重点检查旋转外参。4.4 双雷达融合的配置思路双 mid360 融合也是被问得非常多的话题。livox_ros_driver2 本身支持同时连接多台雷达只要在MID360_config.json的device_list里把两台雷达的广播码都填上驱动会自动把两台雷达的点云合并发布到同一个/livox/lidar话题上。FAST-LIO2 不用改任何代码。这里有个前提两台雷达之间的外参要已知并且在驱动配置里设置正确。设置路径同样是MID360_config.json在每台设备的配置项里填好相对主雷达的 x、y、z、roll、pitch、yaw。这个外参如果不准合并后的点云会出现重影FAST-LIO2 建图精度直接崩。如果你要让两台雷达的原始点云分别独立发布不合并那需要二次开发改驱动代码或者另写一个节点分别订阅两个话题。我不建议新手走这条路成本高而且收益低。还有一个容易被忽略的坑两台 mid360 如果各自独立供电上电时间不一致会导致点云帧之间出现时间偏移看似都到了驱动但实际采集时刻不严格同步。最直接的验证方法是用 ROS 打印两个话题的时间戳差值差异超过 50ms 建议研究一下硬件同步方案。5. 启动建图验证、保存地图与性能调优5.1 启动 FAST-LIO2 并检查输出一切就绪后启动建图# 终端 1启动驱动如果还没启动 # ROS1 roslaunch livox_ros_driver2 msg_MID360.launch # ROS2 ros2 launch livox_ros_driver2 msg_MID360.launch.py # 终端 2启动 FAST-LIO2 # ROS1 roslaunch fast_lio mapping_mid360.launch # ROS2 ros2 launch fast_lio mapping_mid360.launch.pyFAST-LIO2 启动后终端会不断刷新位姿输出包括当前的平移量和旋转量。确认没有报错后打开 RViz添加以下话题/Odometry里程计位姿注意在 RViz 里选择 Odometry 显示/path轨迹线/cloud_registered注册到全局坐标系下的建图点云/cloud_registered_body雷达自身坐标系下的点云正常建图时当你手持雷达或移动机器人/cloud_registered会以当前位置为中心持续扩展墙壁轮廓清晰、地面平整没有明显重影和拖尾。一个判断建图是否健康的快捷方式把/path拖出来看轨迹如果轨迹平滑连续、来回走同一段还能基本闭合说明系统状态良好。如果轨迹出现突然的跳变或地图开始扭曲立即停止移动先把问题排查清楚再继续。5.2 保存点云地图建图完成后怎么把地图保存下来是很多人关心的。最直接的方法是用 PCL 工具# ROS1 rosrun pcl_ros pointcloud_to_pcd input:/cloud_registered # 默认保存到当前目录文件名带时间戳也可以自己写一个简单的 ROS 节点订阅/cloud_registered话题在收到保存指令时调用 PCL 的savePCDFileASCII或savePCDFileBinary。我更喜欢保存成 PCD 再用 CloudCompare 转成其他格式因为 PCD 能保留点云强度信息后期在 CloudCompare 里做降采样、去噪、拼接都方便。如果你要把地图转成机器人导航用的 2D 栅格地图常见做法是先把 PCD 点云投影成高度图再用点云分割提取地面平面最后转成 pgm/yaml。这个过程可以参考 gmapping 或 cartographer 的建图结果做对齐FAST-LIO2 输出的点云精度足够作为上游输入。5.3 CPU 占用与参数调优我实测过三套不同硬件上 mid360 FAST-LIO2 的负载情况给你一个参考平台point_filter_numCPU 占用建图流畅度i7-12700 台式机135% ~ 45%流畅i5-8250U 笔记本250% ~ 60%基本流畅Jetson Orin NX230% ~ 40%流畅如果你的 CPU 占用长期在 80% 以上优先调大point_filter_num。这个参数是性价比最高的调优手段代价只是地图点云密度略降对位姿精度影响很小。如果 CPU 占用还降不下来可以关闭特征提取feature_extract_en: false在关闭状态下FAST-LIO2 会直接使用全部抽稀后的点参与配准虽然单帧计算量略增但在某些纹理稀疏的场景反而更稳。实测关闭特征提取在室内走廊效果不错因为特征提取可能把墙面上有效的点在提取阶段误删。室外大场景下如果觉得点云太密导致保存的地图文件过大可以在保存后做一次体素滤波降采样比如设置 0.05m 的体素栅格地图点数量能减少一半以上纹理边缘依然清晰。6. 部署过程中踩过的坑完整排查链路6.1 编译期报错从缺头文件到版本冲突编译阶段最常见的报错是fatal error: livox_ros_driver2/... No such file or directory。这个错误的意思是 FAST-LIO2 在编译时找不到 livox_ros_driver2 的消息头文件。直接原因通常是 livox_ros_driver2 还没编译或者没有 source 对应的 setup 文件。排查顺序确认 livox_ros_driver2 是否已经编译成功devel/include或install/include下是否有 livox_ros_driver2 头文件目录。确认两个包在同一个工作空间的 src 下。重新编译前执行一次source devel/setup.bash或source install/setup.bash。另一个常见报错是 Eigen 相关Could not find a package configuration file provided by Eigen3。这种情况在 Ubuntu 20.04 下非常少见但如果遇到先确认系统确实装了 libeigen3-devdpkg -l | grep eigen如果确认装了还是找不到可以在~/.bashrc里加一行export CMAKE_PREFIX_PATH/usr/share/eigen3/cmake:$CMAKE_PREFIX_PATH还有一个看似诡异但确实出现过的坑Ubuntu 20.04 下 FAST-LIO2 编译报undefined reference。这往往是之前系统里装过旧版本 PCL或/usr/local下残留了不完整的三方库导致 CMake 链接到错误版本。解决办法是临时把/usr/local/lib从链接路径中移除或重新sudo make install覆盖旧库。如果你不确定哪里来的库建议直接重装系统保持干净省得后面排查时间比重装还长。6.2 运行期点云发散定位是数据问题还是算法问题建图时最常见的故障是跑着跑着点云突然发散或者一开始就乱。遇到这种情况先压住性子不要急着改 FAST-LIO2 参数按链路分层排查。第一步看驱动原始点云。在 RViz 里订阅/livox/lidar如果原始点云本身就存在大量离群噪点、断线、或者点云帧之间有跳变问题在驱动或硬件不在 FAST-LIO2。这时要回到驱动的网络配置检查网线质量、交换机链路速度和网卡是否协商到了千兆。mid360 每秒 20 万点百兆网卡扛不住点云会大量丢帧。第二步看 IMU 数据。打印/livox/imu的加速度和角速度数值静止时加速度计模长应接近 9.8 m/s²角速度接近 0。如果静止时数据都在大幅跳动检查雷达是否固定牢固或者是否被什么东西干扰。第三步才是看 FAST-LIO2 输出。如果原始数据和 IMU 都正常但 FAST-LIO2 一启动就发散重点检查mid360.yaml里的extrinsic_T和extrinsic_R。mid360 用内置 IMU 时确认为单位矩阵即可如果填错了某个值点云必飘。第四步考虑时间戳。如果点云和 IMU 时间戳不同步典型表现是快速转动雷达时地图边缘出现明显的旋转拖影。mid360 内置 IMU 硬件同步正常情况下不会出这个问题但如果你的系统时间本身跳变过比如用了 NTP 且时钟频繁校正也可能导致时间戳错乱。我碰到过一次工控机断电重启后系统时间跳到 2012 年当时所有 ROS 时间戳全部乱套解决方法是先同步系统时间再重启 ROS。6.3 驱动和算法的时间戳细节这里单独说一下 ROS1 和 ROS2 在时间戳处理上的差异。ROS1 下/livox/lidar的header.stamp默认使用雷达采集时间而/livox/imu使用雷达内部 IMU 时间。FAST-LIO2 对这些时间戳非常敏感如果同一帧点云的点时间戳和 IMU 时间戳相差太大可能出现点云到得早但 IMU 来得晚的情况导致卡尔曼滤波里预测和更新的顺序错乱。实际表现是点云建图静止不动时稳定一移动就扭曲但原始点云和 IMU 单独看都正常。排查方法是在终端里用rostopic echo /livox/lidar/header/stamp和rostopic echo /livox/imu/header/stamp做对比正常情况下差值应在几毫秒以内。如果差值很大检查是否有第三方节点在中间做了TimeSynchronizer之类的同步或者是否有人把 mid360 点云重新 stamp 过。ROS2 下时间戳问题相对少一些因为驱动内部使用的是rclcpp::Clock但如果手动设置了use_sim_time true而系统没有发布/clock话题也会出现所有消息时间戳为 0 或者完全异常的情况。这个坑不太起眼但一旦遇到表现就是 FAST-LIO2 认为所有数据都没有时间戳直接拒绝处理。所以我的建议是如果在 ROS2 下运行这套系统务必确认没有开启 sim time默认配置保持use_sim_time: false。6.4 雷达固件和驱动版本的隐性搭配最后说一个很少被注意到但真实存在的点mid360 固件版本和 livox_ros_driver2 版本之间存在隐形搭配关系。如果你用的 livox_ros_driver2 是较老版本而 mid360 固件已经升到比较新的版本可能会出现驱动能发现雷达、也能建立连接但点云数据断断续续或者超过一定时间自动断开的情况。相反如果固件太老而驱动太新可能出现驱动报固件版本过低请升级的警告。我当时的处理方式是把 Livox Viewer 2 装好用它连接雷达查看当前固件版本再根据驱动 README 里记录的固件支持范围判断是否需要升级。升级固件时注意升级过程中不能断电否则有变砖风险。升级完成后再把雷达恢复到需要的静态 IP 配置。如果你已经排除了网络、外参、时间戳等问题但雷达还是偶尔掉线建议查一下供电。mid360 对供电稳定性要求不低我用过一个质量一般的外接 POE 供电模块跑半小时后雷达会自己重启现象非常像驱动崩溃折腾了大半天才发现是供电纹波太大。后来换了工业级 POE 模块问题彻底消失。写在最后的一点实际体会这次部署让我最深的体会是mid360 FAST-LIO2 这套组合的稳定性依赖的不是某个单独的炫技环节而是它每一层都按预期工作。SDK 层连不上、驱动层点云类型不对、算法层外参不准任何一个环节出错最后现象可能都长得差不多都是地图飘了或者没点云。所以我把逐层验证这件事放在比确认最终能跑更高的优先级因为一次跑通不代表下次还能稳定跑通。另外还想分享一个小经验调试这类系统时建议每次都只改一个变量。比如先只调整point_filter_num看效果再动外参不要同时改多个参数否则出了问题你根本不知道是哪个改动导致的。这套组合参数不算多但每个参数对结果的影响都很大逐个调、逐个验证才是最快的路径。本文还有配套的精品资源点击获取